RFC: partial reorganization of the CPS format.

[silseva]

Header:

• changed the magic field from 64 to 32 bit
• extented the version number from 16 to 32 bit

Channel:

• changed transmit power from dBm to mW, extending the field from 8 to 32 bit
• dropped the scan list index field
• dropped the group list index field
• changed the longitude field from 8 to 16 bit to fix #30

See also #31

[silseva]

HTML version available here: https://github.com/OpenRTX/openrtx.github.io/blob/cps_refactor/binary_cps_format.md

[tarxvftech]

LGTM!

Power: Max storable value is a bit less than 4.3MW.

Are we sure that's going to be enough? :laughing:

[silseva]

To do:

• change encryption type for M17 to support AES-128, 192 and 256;
• store the M17 AES encryption key, when present. Add a separate block for the keys, with tuples of (key lenght, key) and reference each key by its position in the block as if it was an array;
• store M17 scrambler key, when present. Scrambler uses 8, 16, and 24 bit sized keys;
• specify that channel name and description can be up to 32 characters, in which case the NULL terminator is omitted;
• specify an encoding for channel name and description strings. Plain ASCII?

[mdiepart]

Hi! I wanted to write down a brief summary of what we discussed in Brussels with @silseva. So I suggested that this code plug system, if we want to see a wide adoption, must include a minimum amount of flexibility. By flexibility, I mean that each protocol should be able to be fully customized to the specific mode regarding the length of its entries. Linked to that was the suggestion that the cps should include a way to include your own protocol with a customized length without 1) having to bring this protocol upstream into the specifications and 2) without making the codeplug incompatible with other radios (which could be the same radio with a different firmware). This would allow ham operators to tinker with it more easily, but would also allow industrial manufacturers to use the same CPS system without having to share their protocols with you.

The solution I first suggested was to include a short table at the beginning of the codeplug that would look like this (numbers are just random numbers and this example only considers contacts).

ID (1 byte)	Name (null-terminated string)	Length (1 byte)
0	Analog	8
1	DMR	32
2	M17	28
3	MyCustomMode	64

And then, for each entry you would have something looking like this (for one analog contact and 2 custom contact)	Mode ID (1 byte)	Common data (x bytes)	Mode-specific data (see lengths above)
0	aabbcc	xxyyzz
3	ddeeff	rrssttuuvvww
3	gghhii	llmmnnooppqq

The advantage of this is that you do not really need to update the standard at all to include new modes, but you have to define each mode you want to support, including very ubiquitous ones like analog. Also, you raised the concern that managing strings can be quite computationally heavy for the smallest processors.

The final solution we came up with was to reserve the 128 first IDs for pre-defined modes. Which would mean that in all CPS using this standard, ID 0 would always be analog, 1 would always be DMR, 2 would always be M17, and so on... All IDs from 127 and upward would need to be defined at the beginning of the codeplug. We spare many bytes because we do not need to re-define ubiquitous modes and we still have the possibility to tinker and add custom modes.

The IDs 127 and up could be defined as explained above, but we could also not put the name of the mode, assuming that if the radio does not know about it, it does not need to know the name of the mode. The risk could be that you may encounter a mode with a "known ID" but whose definition is not what you expect (i.e. if I use id 218 for MyCustomMode and you use id 218 for YourCustomMode). However, it would be required for the table to contain the length of the various entries (contacts, channels, ...). That way you can at least check that the IDs above 127 have the expected length. You also know what is the length of the entries if you do not know about the mode.

This solution also means that the radios are expected to keep a table of the lengths of all the modes included in the standard because it might encounter any of those including some it does not support.

Not having a table for the IDs below 127 also means that any update to the standard including a new protocol would not be backward compatible, because if I don't know about ID 17 yet, then I have no idea what is the length of the entry and so the rest of the codeplug becomes unreadable.

Anyway, that is what I remember about what we talked about more than a month ago.

Any remarks are welcome from anybody that might read this comment 😄