Message to indicate loss of RTK lock

[henryhallam]

User request:

I'm finding it problematic for the Piksi to always be reporting single-point precision even when the unit is in one of the RTK modes.
It makes it really difficult to know when it's lost RTK because you can't simply look at a transition of the flags.

Picture this: You've got a UAV that has both a Piksi and a uBlox.
You're flying along in RTK Fixed mode. Okay, great, you look at the flag and know that the coordinate is high precision so the autopilot uses it.
Then suddenly, for whatever reason, the Piksi stops outputting RTK altogether and you're left with SPP. Sadly, the Piksi's SPP solutions aren't nearly as good as a uBlox so you'd like to be able to quickly switch to using coordinates that you get from a uBlox. How do you know when to do this? Currently, the only way would be some sort of timeout. That's not a great solution.

We could define a new message type, e.g. MSG_RTK_NO_FIX, and transmit it in solution_thread() if RTK is unavailable for any reason (e.g. not enough sats in common, DOP too high, base obs too old, some kind of solution error).

Should this be in a new message mask group?

[henryhallam]

@denniszollo @fnoble thoughts? I can knock this out if you think the approach is reasonable.

[denniszollo]

I'd like to resurface this issue for discussion.

What would we think about continuing to output baseline messages, but indicating in the FLAGS field that we were unable to produce a solution and maybe setting the data fields to MAX_INT or something. When there is No RTK solution, the behavior could be:

• SPP solution (LLH, ECEF) comes back if in psuedo-absolute mode
• baseline message (NED, ECEF) still comes at the expected interval but the flags field says it couldn't be computed and why. The data values are hosed to a degree that any reasonable user would have to notice that they are invalid.