[op25-dev] Re: Correct decoder: op25_decoder_ff.cc or op25_decoder_bf.cc

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/op25-dev@lists.osmocom.org/.

ikj1234i ikj1234i at yahoo.com
Wed Sep 11 02:49:57 UTC 2013


--- In op25-dev at yahoogroups.com, Steve Glass <stevie.glass at ...> wrote:
> So that means trunking and I am keen to improve
> things and get trunking support working properly.

Hi Stevie 

Couldn't agree more about trunking - haven't spent enough time on it either, but I've just added a small addition to this effort in case you should find it useful [repeater/src/python/tsbk.py].

A trunking receiver needs to populate a frequency ID map from received "IDEN UPDATE" packets (TSBK's) that are sent out repetitively on the control channel.  Once having this info it looks for GRANT and GRANT UPDATE commands (which specify the voice channel freq. map entry ID and offset plus the talk group ID).  Then assuming the talk group ID is not in an exclude list we tune the receiver to the voice channel...

The python code expects to receive TSBK data which has already been decoded via the trellis 2/1 process (Mossmann's code has this) and wants to see the CRC16 which it checks for validity.  Right now it populates the frequency ID map but for most of the rest of the trunking commands it just prints out a dump of the received packet.

In the fully general case such as in a multisystem receiving facility where multiple trunk CCs are fed to this code, there would of course need to be some way to create separate tsbk objects on a per control channel basis...

Best

Max

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/op25-dev/attachments/20130911/e68fa1c6/attachment.htm>


More information about the op25-dev mailing list