I have two proposals for the LICH.
1. Split the superframe into more segments
The current superframe (link setup frame) is split into 5 chunks of 48 bits (240 bits total). I propose splitting this into 6 chunks of 40 bits each. Use the first 8 bits in the LICH as an “info field” containing 3 bits for a superframe segment counter (0…5), and 5 bits in each frame for other uses.
2. Send the superframe less frequently
The current LICH is defined as sending the superframe back-to-back, 5 times a second (or about 4 per second for the previous proposal). M17 transmits 25 frames per second. We could send the superframe once or twice per second instead. This would increase the time required to for receivers to sync with a channel. But it would also provide a side channel for additional information, such as location information (APRS-like data), personal avatars, or many other uses. The LICH is a 1200bps side channel (48 bits per frame, 25 frames per second = 1200bps). By sending the superframe twice per second, we have about 600bps available. By sending the superframe once per second we have a 900bps.
Combining these two ideas, we can use the 5 bits to encode 32 different types of information being sent (text message, location, status text, public key, avatar, etc). Or we can just indicate that it is “data” and require the data format include a data type descriptor. The type of data to be allowed in the LICH is outside the scope of this proposal.
If nothing needs to be sent, then the superframe can be be sent. Or, one can think of this as allowing the superframe to be interrupted 2-3 times per second for additional data.
An argument against the second approach is that this data could be sent by switching to D/V mode. If that approach is taken, it might be useful to be able to switch between 3200bps Voice and 1600/1600bps Data/Voice modes seamlessly during a transmission. DMR uses different sync words for this. But it also uses a longer sync word.
If we went with the second option, any receiver looking for the superframe would look at the new “info” field and start decoding when it indicates a superframe. It would collect all 6 segments and assemble the superframe. If the info field indicates something else being sent, it could watch for that or ignore it.