Why is is useful to see realtime NMEA strings?

Didn't someone ask for it for time ago? I have no idea why, I just had this idea that someone wanted it. If I'm nuts, it's probably not worth doing that way. I can do a "flashing led" easily enough.

Didn't someone ask for it for time ago?

I think that was before we had the satellite info screen which gives us some feedback before the gps obtains a good lock and starts sending position updates.

My guess is that early debugging (i.e. did I cross those rx/tx wires) could use some additional feedback, but that should probably stay inobtrusive enough that it won't bother a user once everything is up and running. Which is why a small flashing circle in the 'blind spot' in the upper left corner could be useful.

My guess is that early debugging (i.e. did I cross those rx/tx wires) could use some additional feedback

I think "waiting for data from GPS receiver" is sufficient for that one.

Ok, so it looks like the 4 bytes decodes thus at each db setting in a band:
0db to 23736102

Q is at .55 by default when the above happens. If I change it
If I change Q
.56 gives 24165598
.54 gives 23306606

If I push Q to its extremes:
100.1 gives 4294537728
0.01 gives 429496

A quick resurrection.

It looks like Q = 100*value/ 2^32
I'm guessing that the marginal inaccuracies that we see in the above figures is due to display rounding in the player software. Certainly a 'strings' of the player binary reveals that the display is a printf formatted variable using a precision code, and not a preformatted string.
Using the above formula;
.56 gives 24165598 gives 0.5626
.54 gives 23306606 gives 0.5426
100.1 gives 4294537728 gives 99.98 <== oddity.
0.01 gives 429496 gives 0.00999

In reply to:

---

100.1 gives 4294537728 gives 99.98 <== oddity.

---

Perhaps the fraction is Q = 100.1*value/ 2^32 (since 100.1 is the largest value)?

It fits the values perfectly if you use 100.11 and do rounding to 2 d.p. Bit of a weird number to multiply by so there might be something we're missing still on this calculation.
Does anybody have any more values to check against?

- Trevor

Well, I can't understand why it would use 100.11...My suspicions are that the equation is Q=100.X / 2^32, and that an error is being introduced in the display. Possibly the user input being adjusted by the player is converted to DSP coefficients, and then reverse-calculated for display purposes. Given the lack of native floating point support within the ARM, the code probably uses fixed point math, which could introduce small errors, especially with a double conversion. Purely speculation...

I think that we can live with the accuracy of Q=100.X / 2^32 for anything we might want to do.