Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Re-use of NONCE space
#12
(05-08-2021, 03:06 PM)SP5WWP Wrote: 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).

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.  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!
Reply


Messages In This Thread
Re-use of NONCE space - by G4KLX - 04-19-2021, 10:16 PM
RE: Re-use of NONCE space - by SP5WWP - 04-20-2021, 07:56 AM
RE: Re-use of NONCE space - by G4KLX - 04-20-2021, 08:41 AM
RE: Re-use of NONCE space - by WX9O - 04-22-2021, 02:18 PM
RE: Re-use of NONCE space - by G4KLX - 04-22-2021, 06:41 PM
RE: Re-use of NONCE space - by G4KLX - 04-28-2021, 09:56 PM
RE: Re-use of NONCE space - by tarxvf - 05-08-2021, 04:18 AM
RE: Re-use of NONCE space - by SP5WWP - 04-30-2021, 09:21 AM
RE: Re-use of NONCE space - by G4KLX - 04-30-2021, 12:43 PM
RE: Re-use of NONCE space - by SP5WWP - 05-04-2021, 05:08 PM
RE: Re-use of NONCE space - by SP5WWP - 05-08-2021, 03:06 PM
RE: Re-use of NONCE space - by tarxvf - 05-08-2021, 07:40 PM

Forum Jump:


Users browsing this thread: 1 Guest(s)