I’m used to work with a timing module (M8T from u-blox) configuered as rover, which provides access to raw-data of the GNSS sensor, that can be used by a bunch of apps (many of them around RTKLIB) to calculate precise position using VRS provided over NTRIP as base station.
How can I use the ZED-F9P as rover getting correction data from NTRIP (over BT on UART1) and use it to output already corrected position without the use of external RTK-app?
Hi, after doing a few testing and comparing the two solutions:
1) F9P -> raw data to rtklib (with NTRIP-client connected) -> precise position from rtklib and
2) Lefebure Ntrip-client -> RTCM3 data to F9P -> precise position from F9P
I must admit, that the second solution works quicker and is more reliable. So if one ownes a F9P, the internal postprecessing seems to be by far more efficient that the use of rtklib.
As the LEFEBURE-client has the possibility to provide a mock-location, the precise position of the F9P is accessible on Android phones and tablets for most apps (Webapps are not supported in Google Chrome, but in Firefox and Safari).
That’s an interesting conclusion. Looking forward to see more tests like this one.
The ZED-F9P already does the hard work for you, so no need of postprocessing the data with RTKLIB or similar apps.
If you provide it with RTCM corrections, it will output the corrected position automatically.
OK, I’m familiar with the T-chips, but not with the P-chips like the F9P. When I have only a connection over UART1 > BT: Would it be sufficient to configure the UART1 to send UBX and NMEA and recieve RTCM3? When using a single board as rover and NTRIP as base I would need a programm / app like LEFEBURE NTRIP-client to send the RTCM3 data and get the corrected position (over NMEA) back to the PC/Tablet. Then if the app supports Mock-location, the corrected position should be accessible to all apps running on my device. Thats the way also described in the C099-F9P user guide. Can I expect a quicker or better position or a more stable configuration with this constellation? or what is the improvement in comparison to RTKLIB?
We are not familiar with RTKLIB, but the configuration you describe has been tested and it works.
In this forum there are many experienced users of RTKLIB which will explain you better the advantages/disadvantages.
The advantage of not using RTKLIB is that you don’t need additional hardware/software for processing the raw data.
With the ZED-F9P you can report the position up to 8Hz in RTK with all the constellations and up to 20Hz by removing some constellations.
Don’t know if I should start a new topic, but I have this simple question related to @geom ‘s answer. How do you manage to get position information back from F9P to Lefebure client? I think I already tried with enabling all possible messages in and out of UART 2 through XBee Bluetooth, but only see ‘No Data’. RTCM corrections get to the F9P well, no problem with that.
@kareldew: I run into similar problems when trying to use the XBee Bluetooth on UART2. as described in this post:
https://www.ardusimple.com/question/how-to-configure-xbee-bluetooth/ I think You should use XBee BT on UART2 ONLY as a port to feed correction data (RTCM3 or NMEA) to the F9P. It seems that UART2 isn’t capable to deliver the corrected NMEA data to LEFEBURE. Try it on UART1 and it should work. I asked the guys from ArduSimple if it would be possible to connect the UART1 to the XBee socket, but I did not get an answer yet.
Hi geom and kareldew,
These are two different topics.
What UART2 can’t do is output UBX protocol, but it works perfectly with Lefebure Android app.
This app needs to receive data in NMEA format and outputs RTCM corrections from the NTRIP server.
@kareldew, if you are using our BT module, you need to configure UART2 at 38400bps, protocol out NMEA, protocol in RTCM, that’s all.