Question regarding dPMR Frame Sync

[MattSR]

Hi Guys,

Since theres a few signal processing gurus here I thought I'd ask this in an open forum. I'm reading the DMR specs and the DSD source code to understand how MotoTRBO works. From what I've seen, the frame sync is in the middle of the packets - unlike say P25 where its at the start.

My question is this:- How does the radio decode the first half of the first frame received if the demodulator isn't "trained" to the symbols and decision points? I under P25 well, and it makes sense the FS is at the start of a field since that trains the receiver for the incoming stream of symbols, but how is this achieved in TDMA systems? What am I missing?

Regards,
Matt

 

[KA1RBI]

My question is this:- How does the radio decode the first half of the first frame received if the demodulator isn't "trained" to the symbols and decision points? I under P25 well, and it makes sense the FS is at the start of a field since that trains the receiver for the incoming stream of symbols, but how is this achieved in TDMA systems? What am I missing?

Hi Matt

Locally we have a P25 trunked system that's close enough to capture mobiles transmitting ISP's (inbound packets) on the trunk CC. Unlike the outbound CC (which blasts continuously) the input consists of short bursts. Looking inside these shows the same thing - the P25 FS appears after some symbols have already been sent. Guessing that the stuff after the FS is according to the published spec, whereas the stuff prior is proprietary to Mother Moto...

As to "how they do it" - that's easy - once the frame sync is acquired they can just look back in the stored buffer/delay line at the previous samples. The data samples appearing prior are just as much in sync with the FS as the data afterwards....

Best

Max

 

[MattSR]

Thanks for the explanation Max, that entirely makes sense. I am curious as to weather or not Franks 4FSK block remembers the sync well enough to do this with TRBO. From monitoring P25 stuff using OP25, getting a valid decode on HDU's seems to be hit and miss and my guess is that its not training itself in time to a valid FS and NID codeword.

Since TRBO stuff is popping up more and more I'm very interested in how it works.

...the P25 FS appears after some symbols have already been sent. Guessing that the stuff after the FS is according to the published spec, whereas the stuff prior is proprietary to Mother Moto...

Cheeky bastards indeed - that's quite a clever way of "hiding" things

 

[KA1RBI]

I am curious as to weather or not Franks 4FSK block remembers the sync well enough to do this with TRBO. From monitoring P25 stuff using OP25, getting a valid decode on HDU's seems to be hit and miss and my guess is that its not training itself in time to a valid FS and NID codeword.

Technically the FSK4 demodulation stage has no knowledge of frame syncing - its only job is to output a stream of demodulated symbols. FS syncing occurs either prior to it (as in Mossman's py code) or afterwards (as in Stevie's, and as in DSD).

As far as missing HDU's due to delays in training, that's a probable hypothesis...

Max

 

[MattSR]

Since the CQPSK demod stuff works, are there any plans to integrate that with the current python based receiver? (usrp_p25_rx_gl) I'd love to use our own I/Q based stuff as opposed to franks 4FSK slicer (which works, but he's not contactable..)