Dear Experts,

Now, that I've bought that ArduSimple device and use the mentioned
app there are, of course, new questions. In the app's preferences you
can choose two different file formats for the recorded position
information: nmea.txt and ntrip.txt.

Okay, GPSBabel has not any problem to convert NMEA data into gpx
format. But what about those NTRIP data? Would it be preferable to
let those data be converted into gpx data? If yes, which program
could do this? As I said: New device, a lot of new questions.

Many thanks in advance for your help!

Regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-16 19:12, Reinhard Zwirner wrote:

Dear Experts,

Now, that I've bought that ArduSimple device and use the mentioned
app there are, of course, new questions. In the app's preferences you
can choose two different file formats for the recorded position
information: nmea.txt and ntrip.txt.

Okay, GPSBabel has not any problem to convert NMEA data into gpx
format. But what about those NTRIP data? Would it be preferable to
let those data be converted into gpx data? If yes, which program
could do this? As I said: New device, a lot of new questions.

I'm a bit old school and to me GPS is a real-time thing, so I don't like
the structure of .gpx. Indeed when forced to deal with it I write
awkward decoders not in the spirit of xml-ish.

I much prefer time stamped "events" (positions or PVT) or "information" (waypoints, features, etc.) in a plain text format[1] on a single line
per item.

I don't like NMEA per se, but it's serviceable for many things.

[1] One of my projects is actually binary at 25 Hz, but that's another
matter and can be a configuration nuisance to be sure.

--
“Donald Trump and his allies and supporters are a clear and present
danger to American democracy.”
- J Michael Luttig - 2022-06-16
- Former US appellate court judge (R) testifying to the January 6
committee

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 17 Mar 2023 00:12:27 +0100, Reinhard Zwirner wrote:

[Lefebure NTRIP Client]

In the app's preferences you can choose two different file formats
for the recorded position information: nmea.txt and ntrip.txt.

The Lefebure client first gets the NMEA data stream of uncorrected positions from the external GNSS device via Bluetooth. It probably extracts the CGA message (basic positioning information) and sends it via Internet (Mobile
or WiFi etc.) to the NTRIP server, that is configured in the Lefebure client settings. The NTRIP server answers with correction information suitable for
the current GNSS receiver position. As next step, the Lefebure client sends this correction information (again via Bluetooth) back to the GNSS receiver.

The GNSS receiver incorporates the correction information into the position calculating process and starts emitting NMEA data with corrected positions
and basic information about the correction. Now the Lefebure client uses
/this/ NMEA information as a basis; and the whole process continues, as long
as everything stays connected and no error occurs.

Back to the files:

The continuous input stream arriving from the GNSS receiver via Bluetooth
can be saved to the logfile nmea.txt. This file can be used as input to position-aware programs. Depending on the amount of information evaluated
from this file, the program reading it may just show a sequence of positions
or present a lot of additional details for each position. (Like used sats, estimated precision, and so on.) The NMEA stream can, therefore, also be
used to debug possible errors in the whole process, like omitting a whole
type of satellites. (Which may happen, when the correction data only
supports a subset of the satellite systems from those the GNSS receiver supports. E.g.: Just GPS and no GLONASS, Beidou etc.)

The continuous input stream arriving from the NTRIP server via Internet,
OTOH, can be saved to the logfile ntrip.txt. This also can be used for debugging. Another possibility is to use it for postprocessing the
position measuring data. Postprocessing usually requires, that the raw satellite data is logged by the receiver, though. Recreating uncorrected
data from an corrected NMEA stream is not feasible.

It is /not/ possible to extract the position of your GNSS device from
the correction data. (= Not included, because the only information the
NTRIP server has about your position is the information of the CGA string
you sent. - Duplicating this in the RTCM answer would be a waste of
bandwidth.) What /is/ included in the RTCM data stream is the position
of the (most likely virtual) reference station, that was used as source
for the correction data.

A free software most suitable for postprocessing is RTKLIB, btw: https://rtklib.com

HTH.
Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

On Fri, 17 Mar 2023 00:12:27 +0100, Reinhard Zwirner wrote:

[Lefebure NTRIP Client]

In the app's preferences you can choose two different file formats
for the recorded position information: nmea.txt and ntrip.txt.

The Lefebure client first gets the NMEA data stream of uncorrected positions from the external GNSS device via Bluetooth. It probably extracts the CGA message (basic positioning information) and sends it via Internet (Mobile
or WiFi etc.) to the NTRIP server, that is configured in the Lefebure client settings. The NTRIP server answers with correction information suitable for the current GNSS receiver position. As next step, the Lefebure client sends this correction information (again via Bluetooth) back to the GNSS receiver.

The GNSS receiver incorporates the correction information into the position calculating process and starts emitting NMEA data with corrected positions and basic information about the correction. Now the Lefebure client uses /this/ NMEA information as a basis; and the whole process continues, as long as everything stays connected and no error occurs.

Hi Bernd,

thanks a lot for your comprehensive explanations.

So would you recommend to wait a few minutes at start position before
setting out on a hike the track of which is to be recorded as precise
as possible?

Back to the files:

The continuous input stream arriving from the GNSS receiver via Bluetooth
can be saved to the logfile nmea.txt. This file can be used as input to position-aware programs. Depending on the amount of information evaluated from this file, the program reading it may just show a sequence of positions or present a lot of additional details for each position. (Like used sats, estimated precision, and so on.) The NMEA stream can, therefore, also be
used to debug possible errors in the whole process, like omitting a whole type of satellites. (Which may happen, when the correction data only
supports a subset of the satellite systems from those the GNSS receiver supports. E.g.: Just GPS and no GLONASS, Beidou etc.)

That ArduSimple device can receive at least Beidou, Galileo, Glonass
and GPS as well as SBAS signals. It is possible to switch off
reception of all these GNSS signals using ublox' u-center. Do you
think deactivating reception of some of the signals would optimize
position precision here in Germany?

The continuous input stream arriving from the NTRIP server via Internet, OTOH, can be saved to the logfile ntrip.txt. This also can be used for debugging. Another possibility is to use it for postprocessing the
position measuring data. Postprocessing usually requires, that the raw satellite data is logged by the receiver, though. Recreating uncorrected
data from an corrected NMEA stream is not feasible.

It is /not/ possible to extract the position of your GNSS device from
the correction data. (= Not included, because the only information the
NTRIP server has about your position is the information of the CGA string
you sent. - Duplicating this in the RTCM answer would be a waste of bandwidth.) What /is/ included in the RTCM data stream is the position
of the (most likely virtual) reference station, that was used as source
for the correction data.

A free software most suitable for postprocessing is RTKLIB, btw: https://rtklib.com

I'm convinced the son of my mother should rather keep his hands off
this ...

Thanks again and best regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 17 Mar 2023 23:42:18 +0100, Reinhard Zwirner wrote:

[Timeout before a GNSS receiver receives and applies corrections]

So would you recommend to wait a few minutes at start position before
setting out on a hike the track of which is to be recorded as precise
as possible?

If there are no problems with the Internet connection to the NTRIP server,
a couple of seconds (less than 10) should suffice. Depending on the type
of the receiver and the used correction data, you should see the position status go from 3D (uncorrected) to a better state (DGNSS -> float -> fixed). You need a program, that retrieves this information from the NMEA data
stream. The Lefebure client shows just "RTK" in the upper left corner,
IIRC, when correction data comes in.

Apart from this, you should wait a couple of minutes, anyways, if you
just powered up the receiver. Cold start time for the F9P receiver (to
acquire GNSS signals) is about half a minute in good reception conditions. Afterwards you need to give it time to receive the almanac data for all satellite systems supported. Typically, you wait about a quarter of an hour after a cold start before beginning any serious measurement. If you used
the receiver in the last couple of days and didn't change your position
since the last measurement more than a couple (less than ~100) kilometers,
the receiver will perform a hot start and will have all almanacs, already. Then, waiting just a couple of seconds should suffice.

That ArduSimple device can receive at least Beidou, Galileo, Glonass
and GPS as well as SBAS signals. It is possible to switch off
reception of all these GNSS signals using ublox' u-center. Do you
think deactivating reception of some of the signals would optimize
position precision here in Germany?

Definitely: No! All four GNSS systems provide excellent worldwide position data. Depending on obstruction (dense tree canvas is especially tricky)
you'll need any information available, to get fast and reliable positions.
I had measurements in the last couple of years here in Germany, that got position /only/ from Beidou. The satellites of all other systems were obstructed by trees and hills. (The same happened sometimes for any of
the other GNSS systems, of course.)

When your correction provider does not support one or a couple of above mentioned systems, the GNSS receiver will drop any satellite of these
systems from calculating the position, all by itself.

Here is a link to the SAPOS caster table for Niedersachsen:

http://openservice-sapos.niedersachsen.de:2101/sourcetable.htm

If you want support for all four satellite systems, you need to use the mountpoint VRS_3_4G_NI. "VRS_3" stands for the correction data format
(RTCM 3.x) and "4G" for the number of GNSS systems supported. Column
GNSS of the sourcetable shows /which/ four systems.

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

[...]

Hi Bernd,

Many, many thanks again for all your efforts to transfer expert
knowledge to a plain amateur :-)!

[...]

mountpoint VRS_3_4G_NI. ...

This has been my choice every time I used my new "toy".

Have a nice weekend!

Best regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)