Re-use of NONCE space

Technical
#1

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.

#2

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.

#3

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.

#4

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?

#5

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.

#6

[size=small]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.[/size]

[size=small]Latitude before the decimal point: 16-bits[/size]
[size=small]Latitude after the decimal point: 15-bits[/size]
[size=small]Latitude North/South indicator: 1-bit[/size]

[size=small]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.[/size]

[size=small][color=#333333][font=Tahoma, Verdana, Arial, sans-serif]Longitude before the decimal point: 16-bits[/font][/color][/size]
[size=small][color=#333333][font=Tahoma, Verdana, Arial, sans-serif]Longitude after the decimal point: 15-bits[/font][/color][/size]
[color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif]Longitude East/West indicator: 1-bit[/font][/size][/color]

[color=#333333][size=small][font=Tahoma, Verdana, Arial, sans-serif][size=small][size=small]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.[/size][/size][/font][/size][/color]

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

#7

Imperial units - I don’t like it. km/h and meters would be better.

#8

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.

#9

Ok, let’s keep this compatible with APRS.

#10

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?

#11

degrees of latitude can be stored using 8 bits (as an ordinary int8_t, or unsigned, then the first bit can determine hemisphere)
degrees of longitude can be stored on 9 bits (just as above, but cant be int8_t anymore)
minutes - 6 bits for the integer part, 10 for fractional.
This is enough to cover (d)ddmm.mmmm format (GPGGA sentences use this).

#12

OH. Not decimal degrees. I took it for granted any new system would avoid decimal minutes, though that’s just my own prejudices I suppose.

[10:00 AM] G4KLX: I hope he isn’t going to suggest floating point again!

I don’t know if being unconvinced counts as suggesting “again” a separate time, but if so: sorry. :angel:

From the chat, I think I understand the main points, some from Discord:
SP5WWP suggests above, and says directly in IRC, that this description saves bits compared to floats.
G4KLX makes the point on Discord that many embedded systems don’t have floating point, or no standard for it.
NMEA GGA sentences are decimal minutes. APRS is decimal minutes.

If I’ve understood the main points correctly, my one-time attempt to rebutt:

Saves bits:
I don’t understand how, because I read G4KLX post to use 32 bits (16+15+1) for each of latitude and longitude, which has the same overall size requirements as standard floats for each. This would be the single most compelling argument to me, to avoid wasted bits. I see SP5WWP’s description would use 16+16+17, which is a huge savings, and would be worth it to me.

Embedded IEEE754-less, GGA, APRS
For systems that don’t have a standard system or any floating point support at all, I can absolutely agree floats would be a bad choice. I’m not sure I see that we’re going to be using this part of the spec on any of these systems, since upstream Codec2 uses floats liberally, and this is within a voice stream.
Even the MD-380 has hardware floating point, and I took for granted that system would be our least-capable handset going forward.

This would be significantly more convincing to me if APRS were the only application and representation.
We already have to have an RF bridge and our own igates, so it seems to me that arguing about translation is arguing about saving cycles on the handhelds and mobiles themselves, not on the thing that has to convert our voice stream with embedded data to ascii strings.
We’re already not doing a byte-compatible APRS format, and I believe but cannot prove that floats make a pure-M17 system - such as from one handheld to another - dramatically easier from the applications development point of view, and avoids yet more bit-by-bit parsing and DD<->DM conversions that will never be able to be avoided.
I note that OpenRTX only exposes DD floats for their location API, and I’d like to congratulate them on the most developer-friendly radio OS to date. :slight_smile:

I’m not interested in perpetrating bikeshedding, and if both of you gentlemen still disagree with my wonderful IEE754 (it’s standard! and my watch has FPU, it’s current_year, etc), I’ll drop it.

G4KLX: Can you point me in the direction of the spec you mention? Maybe it’ll show me the light!