Position Output not completely NMEA compliant

Reach Module / M+ / M2 RTK / PPK configuration
1

Hi all

I am using Reach M for base and rover.
Correction are done via Android NTRIP Client and rtk2go.
I always have some problems, when coming to a stop after moving the rover, with showing and recording wrong speed data to my android app.

I had a small conversation with lance from lefebure (creator of NTRIP Client) and sent him a NMEA sample from the reach.
This was his answer and maybe we found the problem with it:

“”""""""""""""""""""""
$GNRMC,173526.00,A,4650.4996373,N,01246.0958914,E,6.44,244.31,081018,D4C
$GNRMC,173537.40,A,4650.4987187,N,01246.0933358,E,0.02,081018,D54

Yes, these two messages show the issue - when the speed is slow, the next field (heading) is empty. This means the message is not NMEA compliant and is being discarded.

Tell the manufacturer that the heading should always be a number, even if its zero. Normally the heading is just the vector between the last data point and the current one. When stationary, the noise in the position data will make the heading appear to be random.

“”"""""""""""""""""

I guess thats an easy fix?

2 Likes
2

Hi there,

Thanks for your report.

It’s true that RMC message sent from ReachView doesn’t include speed calculations if speed is close to 0. This is required to avoid sending the wrong direction. The cutoff speed is 0.5 m/s.

So I can’t agree that this NMEA message is not compliant. On the contrary, it’s an industry standard and if you stand still, sending “a number, even if its zero” in NMEA is just not right.

2 Likes
3

Hi
My problem is, we are using it to analyze sports (will write a project thing later this month) and the speed data gets written in the app as it gets forwarded from NTRIP Client.
I guess the discarding happens in NTRIP Client then and the last number is showed before discarding?
Depending on how abrubt the stop happens, there are still around 1,2 - 1,7km/h left that get shown and recorded in my app, while standing still (with having a RTK fix)
A quick disconnect/connect action resets this then.

Maybe any idea I could work around this?

4

or maybe keep the heading from before the cutoff at 0,5 alive?

EDIT
or lower the cutoff?

5

and after some digging into the NMEA standard you are absolutely right, leaving it blank is a way to do it

1 Like
6

Wrote again to lance from NTRIP Client and he said it was the first receiver he saw, that actually kept it blank if there is no value. But he agrees that its the correct way and he just didn´t have seen it till now.

He will tweak the code to correct this in a future update, where this lines dont get discarded in NTRIP Client.

I still find the cutoff at 0,5 quite high (at least in FIX mode), but thats another topic… :wink:

2 Likes
7

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.