LICH fragment assembly documentation
Opened this issue · 5 comments
FN->lich chunk mapping needs to be explicit in the spec.
LICH_chunks[frame_number%5], in the meantime.
Just came here to see if this has been raised yet. I think LICH has a more serious issue than just fragment assembly documentation.
The purpose of Golay encoding the LICH, according to @sp5wwp, is that it is less computationally intensive to decode. However, if one needs to decode the full frame anyway just to get the frame number, it's rather pointless. It just adds unnecessary complexity to the spec.
Ideally some way of encoding the LICH fragment number in the LICH itself should be found. I have not come up with any clever ways of doing that.
One could just punt on the numbering and just require that the receiver attempt to rotate the blocks until either a valid CRC is computed or 5 rotations have been performed. I'm not a fan of this, but it is what I have implemented. The microcontrollers I use have a DMA-capable CRC engine, so there isn't much to worry about. The only requirement here is that the blocks are written out sequentially.
If we need to use frame number, I would like to propose dropping Golay encoding entirely, and instead convolutionally encode the LICH with the data.
If we use FN % 5, we should also consider limiting the maximum frame number to 32764 (0x7FFC) so that the LICH rollover happens without discontinuities.
Responding on parallel thread: https://forum.m17project.org/showthread.php?tid=38&pid=269#pid269.
Duplicate posting here.
One option I thought of was changing the Golay to [23,12,7] and freeing 4 bits for each chunk that can be used to indicate the start of LICH. We'd want this to be coded but with 4 bits, the only real option is repetition coding.
Any downsides to the above? What am I missing?
Golay already provides decent error correction and higher error detection per codeword (better resolution than a whole chunk). We can already have good confidence the CRC will pass. I think adding a LICH start indicator will make decoding more straight forward.
Also commented as WX9O on forum thread. If we can shoe-horn in a single bit to indicate the first frame of LICH that would help. But I think brute force is fine. One would need at most 9 frames to decode a valid LICH on a clear channel. I am not in favor of changing to Golay(23,12,7), but not strongly opposed either.
My proposal based on what we discussed on IRC:
- Make Superframe contain 6 frames rather than 5. That makes the LICH chunk 40 bits, giving spare 8 bits each frame.
- Take 3 of these bits for LICH_CNT, it'd then count from 0 to 5 (so that's modulo 6).
- Take 4 last bits for Color Code (we can pick some other name for that).
- Stay with Golay (24,12) as the chunk is still 48 bits long.
One possible issue is that there are no "local" checksums for partial LICHs.
This issue has been addressed. It can be closed.