M17 Project Forum
Distinguishing between frame types and FN - Printable Version

+- M17 Project Forum (https://forum.m17project.org)
+-- Forum: M17 (https://forum.m17project.org/forumdisplay.php?fid=3)
+--- Forum: Technical (https://forum.m17project.org/forumdisplay.php?fid=4)
+--- Thread: Distinguishing between frame types and FN (/showthread.php?tid=36)

Pages: 1 2


RE: Distinguishing between frame types and FN - G4KLX - 11-04-2020

The MMDVM doesn't use the internal sync matching either, it's all done in my firmware. It does at least do the symbol synchronisation so you do get some of the hard work done for you.

Having two syncs is great news.


RE: Distinguishing between frame types and FN - WX9O - 11-04-2020

Hi folks. Just getting caught up on this after getting the baseband demodulator completed. I don't think there is any need to treat the two frame types differently by using a different sync symbol. The first frame is the LSF. The demodulator should try to decode it as such. If that fails, then the subsequent frames *must be* data frames and contain a LICH. The LSF, in that case, must be reconstructed from the LICH. There will never be another LSF sent for that session.

Putting information that can be clearly derived from the data explicitly in the protocol is wasteful.

A completely valid audio demodulator can be built that always ignores the first frame, always decodes the LSF from the LICH from the next 6 frames, drops 240ms of audio and then continues on from there. I would prefer to keep the spec as simple as possible and only as complex as absolutely necessary.

If one really cares that, by chance, a data frame was decoded as an LSF with a valid CRC, one can decode the LICH from the next frame and verify that the first 20 bytes are an exact match. I don't think that is necessary.


RE: Distinguishing between frame types and FN - SP5WWP - 11-10-2020

So, basically: you turn on your radio, receive a random frame (that appears as the first one for you) and try decoding it like if it was the LSF. If it fails, it means that this and all subsequent frames are data/audio. I think that having 2 different SYNCs would make it a lot more robust, but let's see what the others think.


RE: Distinguishing between frame types and FN - WX9O - 11-11-2020

(11-10-2020, 08:07 PM)SP5WWP Wrote: So, basically: you turn on your radio, receive a random frame (that appears as the first one for you) and try decoding it like if it was the LSF. If it fails, it means that this and all subsequent frames are data/audio. I think that having 2 different SYNCs would make it a lot more robust, but let's see what the others think.

I have read the DMR spec.  They use multiple sync symbols for different frame types.  It seems to makes sense.  But they also use a longer sync sequence. It is 48 bits or 24 symbols.

https://www.etsi.org/deliver/etsi_ts/102300_102399/10236101/02.02.01_60/ts_10236101v020201p.pdf

See section 4.2.2, page 19.

We are not using 48 bits.  With only 16 bits, are we going to run out of reasonable sync symbols?

I think a more in-depth discussion of sync symbols is warranted, along with general signalling. How do we implement color codes?  How do we handle either packet data or streaming data-only?  Embedding the CC in the sync symbol (or different sets of sync symbols for each CC) would make selective reception of frames really easy.

I see no need for a LICH for packet data as, unlike voice, a late joiner is not really something to worry about.  However, we likely want to use the same frame size to break up the packet superframe.  That means that a receiver needs to know it should not attempt to decode a LICH.  Do we use a separate sync symbol for this too?


RE: Distinguishing between frame types and FN - G4KLX - 11-11-2020

You will notice in DMR that the data and voice syncs are the opposite of each other (think in terms of symbols not bits) so that there is a negative correlation from one to the other. Therefore having two sync vectors without any chance of confusion is easily achieved.

Most DV modes use a copy of the header frame as the ending frame with a bit to indicate the end (see DMR, YSF, NXDN), and so you'd have an obvious change of sync vector, and information about it being the end in the payload too.