Display position error from $GPRRE string

[bchad]

I'm using a sub-meter GNSS unit (Juniper Geode) that outputs the NMEA $GPRRE string that includes and estimated horizontal and vertical position error. For our survey work, it would be nice to be able to display this with OpenCPN somehow. Any suggestions would be appreciated.

[Hakan]

bchad..
An RRE sentence is not supported by OCPN and I can't find it in the NMEA 0183 standards I've seen.

Håkan

[CarCode]

As mentioned by Hakan already GPRRE is not supported by OpenCPN.
GPRRE is explained here:
https://www.hemispheregnss.com/techn...RE_Message.htm


Sadly the NMEA standard implementation is outdated for OpenCPN and should be fixed soon. Meanwhile you have to use other software for modern GPS devices.

[bcn]

Gerhard..


Can you take me to the official NMEA0183 standard or the corresponding IEC 61162-1 where the RRE sentence is defined?


The Hemisphere one looks like a private one. Got that link as well with Goggle Search- but Google does not define NMEA standards - yet.



Hubert

[bchad]

Thanks all, I can't determine if it part of the latest NMEA standard (access is expensive), but it does appear to show up somewhat commonly in GPS/GIS application descriptions on google. I don't see any indication that it is proprietary, but also no clear indication that it is in the standard. In any case, if it is not supported by OpenCPN and there is no way to customize to use it, then I'll have to go another route.

[bcn]

We have access to the latest IEC 81162-1 2016 standard. That's the IEC equivalent to the NMEA0183.

RRE does not show up there.


I would not expect an error estimation from a GNSS sensor anyhow. From an IMU, yes. And proprietary when in a NMEA data stream. Same as attitude values (pitch, roll, yaw).


Hubert

[bchad]

OK thanks for checking the standard. RRE is definitely coming out of our GNSS unit. And it serves an obvious purpose to understand the accuracy of the position estimate based on the range residuals, rather than just assuming a default value based on the specifications of the system. Seems like many people would be interested in this beyond just the survey world, but maybe not. At any rate, we've found that we can use the app that came with the unit to read this out, it just requires switching back and forth across the sharing of the bluetooth link.

Bart

[bcn]

In case you don't want to switch back and forth: why not using the NMEA debug window, looking for the RRE sentence? Is the data human readable?

[bchad]

Yes thanks that's a good suggestion to use the debug window. The numbers come across in meters so it is definitely readable. Will try out the pause feature to see if that allows us to get a good look.

[Dsanduril]

I’d have to try it because I don’t know where O might drop a sentence it doesn’t recognize, but you could use the NMEA Converter plugin to read the RRE information and convert it to some other sentence that is supported by the Dashboard. For instance, if you’re not using wind information you might be able to stick the horizontal and vertical error estimates into an MWD or MWV sentence. You’d need to see if the data you are getting fits well in the range expected for those sentences (i.e. wind direction might balk at values > 360).

It’s a kludge, but the O manual has all the sentences that the Dashboard supports, you might be able to find a couple that are suitable, and that you aren’t using for real data. Takes some experimenting, but I think you could probably find a way.

If that doesn’t work you could install OpenPlotter with OpenCPN and use all the tools there to put the values you need onto a web page (and into a database if you so desire).

[CarCode]

bchad
Because OpenCPN does not support RRE sentences I suggest you disable RRE in your device settings. All other sentences are supported by OpenCPN and are sufficient for navigation. See the attached picture of the settings screen.

[Antipole]

You could easily process RRE using the JavaScript plugin and do with it what you will.
You might want to display the position error in a small window, average it, watch for its variation from some required accuracy and raise an alert if it exceeds it or log it.

[stevead]

Range Residuals are present in the $--GRS sentence (introduced in NMEA 0184 v4.11) and HDOP etc. are present in the $--GSA sentence (which has been around for ages).

I have no idea whether OpenCPN uses these (nor do I really care), but nonetheless, the only reason I can think of as to why a manufacturer uses a "proprietary" sentence is that theirs predates a NMEA standard.

[CarCode]

I don't need the particular data of any GPS sentence but I need a correct fix when sailing. Some company like Spirent and Regulus Cyber have observed about 150,000 attacks to GPS systems with jamming and spoofing the last years coming even from Pokemon-Go players.
So when I have a GPS receiver capable to receive multiple GPS systems I want to have the possibility to switch off the disturbed system either by using the receiver or by OpenCPN.

[bcn]

Originally Posted by stevead

Range Residuals are present in the $--GRS sentence (introduced in NMEA 0184 v4.11) and HDOP etc. are present in the $--GSA sentence (which has been around for ages).

I have no idea whether OpenCPN uses these (nor do I really care), but nonetheless, the only reason I can think of as to why a manufacturer uses a "proprietary" sentence is that theirs predates a NMEA standard.

Both values, the Pseudo Range Residuals i.e. the estimated error of the distance to a GNSS sat at one instance, and the Geometry of sats in sight and used HDOP give you a hint about the quality of the output, but neither of the two provides an error estimate in meters x/y/z for the position.


Different from this the proprietary $RRE message does provide this data about the confidence of the receiver in its computed solution.