M17 Project Forum

Full Version: Re-use of NONCE space
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Wouldn't it be nice to allow the space occupied by the NONCE to be used for other things as well as encryption data?

In the specification, we have the case that if bits 3..4 of the TYPE are set to 0b00 then there is no encryption, and bits 5..6 which are the encryption subtype will be unused. How about extending this so that when their is no encryption, bits 5..6 are used to describe the contents of the NONCE field, which is no longer a NONCE field. For example bits 5..6 with a value of 0b00 would mean unused, 0b01 would mean text (name, locator, etc), 0b10 could be APRS in MIC-E format, leaving 0b11 free for now. That way we would have extra space for data which will be repeated without taking away any bandwidth from the audio. It would mean that the fragment LSF would need constant decoding since it could have multiple data types, and could also include changed APRS data.

Having this data does not preclude encryption, it just means that the encryption data would be sent slightly less often, but presumably that data wouldn't change during the duration of the transmission anyway. Typically for the initial Link Setup Frame, if encryption is being used, then the NONCE would be used for the encryption data, and the other data would appear un the fragment LSFs during the transmission. If encryption is not being used then the initial Link Setup Frame would contain one of the other data items if used, like the text field.
I really like the idea. We can't afford wasting so many bits. Very clever to use bits 5..6 for the data type indicator.
With this scheme we only have one spare type, i.e. 0b11 for none crypto use. If this is an issue, then we could define 0b00 as being text or unused, with a NONCE field full of 0x00 bytes indicating that it is unused. 0b01 could be used for MIC-E data, leaving 0b10 and 0b11 spare. However this is just a detail.

The text would be UTF-8 encoded with spaces used to pack the field to the full length. There is no explicit end character needed therefore every byte can be used for information.

It may also be an idea to rename the NONCE field to something like "Extension Data" or similar, since it is only NONCE data under specific circumstances.
I like this idea.

Jonathan, have you looked at whether Mic-E will fit in the "extra field" completely? I think it may be 2 bytes too long to fit completely within the LSF.

What is the benefit of padding text with spaces rather than NUL terminating?
I think you're right about the MIC-E format, it's a little too long for the available space. However a binary GPS data format can be created I am sure, since the fields are 8-bit clean. If we can get Lat+Long+Height then we'd be fine, if we can get (maybe) Speed+Direction, and a type specifier it'd be even better. The one thing we don't need is a source callsign of course.

The reason I say with spaces is that is what is used in D-Star and System Fusion for their callsigns/text fields. It'd also mean we could use all of the bytes for the data, as the terminator is implied. Since the field is fixed length there is no overhead to filling the data with spaces.
Here is my proposal for the GPS data format. Some of the inspiration is from the Kenwood NXDN GPS binary format. The NONCE field is 112 bits in length, and this fills most of that space. The choice of whether to hold these values as big- or little-endian is left to the M17 team.

Latitude before the decimal point: 16-bits
Latitude after the decimal point: 15-bits
Latitude North/South indicator: 1-bit

These numbers would map directly onto the values used in an APRS message, with the Latitude after the decimal point being divided by 100 before being used. The value of the indicator is 0b0 for North, and 0b1 for South.

Longitude before the decimal point: 16-bits
Longitude after the decimal point: 15-bits
Longitude East/West indicator: 1-bit

These numbers would map directly onto the values used in an APRS message, with the Longitude after the decimal point being divided by 100 before being used. The value of the indicator is 0b0 for East, and 0b1 for West.

Height in feet, datum is -1500 ft: 16-bits


This allows a range of -1500 to +64035 feet which covers from a little below the Dead Sea to higher than a standard jet airliner. It should be enough. Alternatively one bit could be removed to allow more space for the Type field, and limit the maximum value to just above the top of Mt Everest.

Course: 10-bits

This is the value is degrees.

Speed: 10-bits

This is the speed in mph.

Type: ?-bits

The values for the Type field could include the type of radio, for example: portable, mobile, home, bicycle, paragliding, horse riding, hiding in the back of a lorry, etc.

This field may be split into sub-fields so that the type of radio used in specified in some of the bits. Values to be assigned by the M17 team and NOT manufacturers.

Jonathan  G4KLX
Imperial units - I don't like it. km/h and meters would be better.
I agree, apart from two issues. Miles per hour and feet are what is usually output by GPS devices, and they are the units expected for APRS, both on-air and on the network. By staying with those units, we are avoiding having to convert the data twice, to no real advantage.
Ok, let's keep this compatible with APRS.
(04-28-2021, 09:56 PM)G4KLX Wrote: [ -> ]Here is my proposal for the GPS data format. Some of the inspiration is from the Kenwood NXDN GPS binary format. The NONCE field is 112 bits in length, and this fills most of that space. The choice of whether to hold these values as big- or little-endian is left to the M17 team.

Latitude before the decimal point: 16-bits
Latitude after the decimal point: 15-bits

Latitude North/South indicator: 1-bit

These numbers would map directly onto the values used in an APRS message, with the Latitude after the decimal point being divided by 100 before being used. The value of the indicator is 0b0 for North, and 0b1 for South.

Longitude before the decimal point: 16-bits
Longitude after the decimal point: 15-bits
Longitude East/West indicator: 1-bit

These numbers would map directly onto the values used in an APRS message, with the Longitude after the decimal point being divided by 100 before being used. The value of the indicator is 0b0 for East, and 0b1 for West.

Height in feet, datum is -1500 ft: 16-bits


This allows a range of -1500 to +64035 feet which covers from a little below the Dead Sea to higher than a standard jet airliner. It should be enough. Alternatively one bit could be removed to allow more space for the Type field, and limit the maximum value to just above the top of Mt Everest.

Course: 10-bits

This is the value is degrees.

Speed: 10-bits

This is the speed in mph.

Type: ?-bits

The values for the Type field could include the type of radio, for example: portable, mobile, home, bicycle, paragliding, horse riding, hiding in the back of a lorry, etc.

This field may be split into sub-fields so that the type of radio used in specified in some of the bits. Values to be assigned by the M17 team and NOT manufacturers.

Jonathan  G4KLX

It's not clear to me exactly how I would encode a latitude or longitude value. I assume I've mis-parsed some part of "after the decimal point" and "before the decimal point", but even after accounting for that I'm still having trouble - I'm not following why there're 16 bits (or 15 bits?) to the left of the decimal point.

It's tempting to me to make lat and lon standard IEEE754 floats, which offers precision to a worst case of just over 2m, and usually better than that - and makes working with them extremely simple. That's almost certainly going to be the internal representation they get parsed to anyway.

When storing course, is that raw integer degrees or are we going to scale 360 degrees within the range of the 10 bits?
Pages: 1 2