Reorganize and define `TYPE` bit fields

[sp5wwp]

1. Reorganize TYPE bit fields such that the Channel Access Number is byte-aligned
2. Add META payload type definitions for the Packet Mode

[lwvmobile]

I thought I would float out this idea for restructuring the LSF's Type Field. Forgive the screenshot, but its the best way I could keep the "formatting" of it intact, but this is an idea I was mulling over, its not set in stone, but if a change must be made, I would try to capitalize on it by doing something like this:

[jancona]

For context, this is the Discord discussion that led to this issue being created: https://discord.com/channels/771492414120656907/877593757799813131/1408043688059207680
In particular, @silseva 's idea here is relevant: https://discord.com/channels/771492414120656907/877593757799813131/1408067730396942347

[silseva]

The proposed changes are:

• merge the data type and stream/packet to a unique 3-bit field (because packet is a data type)
• include signed stream mode into the encryption type field, extending it to three bit
• align CAN to the boundary of byte 0, with the four bits 0...3

The rationale is that aligning the CAN simplifies handling of TYPE data, both in the case you use a struct or bit manipulation. Structs are always preferrable to bit manipulation (for readability, ...) and the fields can be organized in the definition to have the correct endianness of the output data.

[lwvmobile]

The proposed changes are:

* merge the data type and stream/packet to a unique 3-bit field (because packet _is_ a data type)

* include signed stream mode into the encryption type field, extending it to three bit

* align CAN to the boundary of byte 0, with the four bits 0...3

The rationale is that aligning the CAN simplifies handling of TYPE data, both in the case you use a struct or bit manipulation. Structs are always preferrable to bit manipulation (for readability, ...) and the fields can be organized in the definition to have the correct endianness of the output data.

The proposal I made above covers all of those bases, I believe, and gives us a bit of future proofing for new META types and call types, and so on. Unless there is something in it that isn't to your liking, I am willing to make adjustments. My proposed opcodes aren't set in stone, and as-is, would need one adjustment, would need to include a NULL META opcode and give it value 0x00, which my "napkin sketch" there had 0x00 for Text Data.

I believe my proposal also helps to satisfy this suggestion as well, since we could allocate a new META opcode for this as well.

[n7tae]

I'm okay with the proposal of @lwvmobile, but how about "Payload Opcodes" instead of "Call Opcodes", moving them to the most significant side of the byte, keeping the existing Data Type values (0x0..0x3), especially the reserved 0x0 value. That way any V3 TYPE will be immediately distinguishable from a legacy TYPE. These suggestions will help when I create a new client type in mrefd to handle hot-spots/repeaters using the new TYPE format. (HINT: V3 clients will connect to mrefd with CON3 instead of CONN, mrefd will transcribe TYPE data so old clients can still talk&listen&message with new clients.)

[lwvmobile]

I'm okay with the proposal of @lwvmobile, but how about "Payload Opcodes" instead of "Call Opcodes", moving them to the most significant side of the byte, keeping the existing Data Type values (0x0..0x3), especially the reserved 0x0 value. That way any V3 TYPE will be immediately distinguishable from a legacy TYPE. These suggestions will help when I create a new client type in mrefd to handle hot-spots/repeaters using the new TYPE format. (HINT: V3 clients will connect to mrefd with CON3 instead of CONN, mrefd will transcribe TYPE data so old clients can still talk&listen&message with new clients.)

Okay, I updated my mock up a bit, what I did was change where Meta Opcode and Call Opcode was, renamed Call Opcode Payload Opcode, and trimmed Payload Opcode to 3 bits, and the Most Significant Bit of the TYPE field should always be 1 to distinguish between the newer LSF TYPE field, and the older 2.0 and earlier style.

[n7tae]

I don't think there is any reason to devote a bit to Version 3. Just reserve 0x0 in the Payload Op. so that it will never be used. I would like to see 15 possible values because we will immediately need at least 6 values for for payloads we already have: data-only, C2-1600+data, C2-3200, C2+1600-Signed, C2-3200-signed, and packet.

I'd like to leave room for some other codecs. Maybe there's some 40ms, 128-bit open-source codec out there that can approach 16-bit, 8000 Hz PCM that's just waiting to be discovered.

[jancona]

I finally had a chance to review this. Some comment/questions:

• @lwvmobile Perhaps you could paste your proposal text in block-formatted code, that is starting and ending with ``` lines. That would allow others to cut and paste, make changes, etc.
• I like the way this is looking, particularly the approaches to compatibility. In addition to @n7tae's idea of transcribing between V2 and V3, I could do something similar in m17-gateway. If new versions of OpenRTX can still receive V2, then the hotspot/repeater could transcribe V3 to V2, allowing radios to interoperate until they all are upgraded.
• I'm not sure what Opcode means in this context. Is it just a synonym for format?
• Does the Encryption field apply to all Data Opcodes? In the old TYPE format, Encryption Type/Subtype only applied to stream format (byte 1, bit 0 = 1) frames.
• How do Data Opcode and Meta Opcode interact? Are they orthogonal or do Meta Opcodes vary for different Data Opcodes? For example, in the old TYPE format, Encryption Type/Subtype only applied to stream format (byte 1, bit 0 = 1) frames so that GNSS, Meta Text and Extended Callsign Data officially only applied to stream data. Is that still the case? I'd vote for making them orthogonal, but some might only make sense for particular data opcodes.