Does anyone have the mavproxy ntrip module working at all? If so what python and OS are you running on? When I use it to connect to cddis-caster.gsfc.nasa.gov, it is not working; only about 1 in 10 RTCM messages are getting parsed and passed on. It seems there is some garbage data in the byte stream that is breaking the checksum calculators. When I connect to that caster using mission planner all is fine.
We use it routinely on multiple vehicles connecting to both the online positionz.linz.govt.nz service as well as our own local Casterrep caster. Our companion computer is running Ubuntu 18.04 and Python 2.7. We have previously also used the Rtklib str2str utility with the Mavproxy DGPS module, though this setup also requires using something like netcat to pipe the output to UDP:127.0.0.1:13320
1 Like
Thanks. Are you referring to http://positionz-rt.linz.govt.nz:2101/ as described here https://www.linz.govt.nz/data/geodetic-services/positionz/positionz-real-time-service? That caster is giving me a āERR_INVALID_HTTP_RESPONSEā error at the moment. Also can you confirm you are not using SSL?
Yes this is the service we use. I have just verified again here at home using these settings:
module load ntrip
ntrip set caster positionz-rt.linz.govt.nz
ntrip set port 2101
ntrip set mountpoint TRNG_RTCM-MSM
ntrip set username jimovo
ntrip set password XXXXX
ntrip start
I have private messaged you my password for testing
AS far as my understanding goes, I believe that the RTCM data is not parsed at all but rather just passed straight through to the attached GNSS module via the serial port.
Looking at the CDDIS site, it would seem that your problem is that they require SSL/HTTPS. I think there may be a solution using netcat to act as an intermediary between Mavproxy and the CDDIS caster. I have registered for an account which should be active within āone business dayā so probably 48hrsā¦ If you share your credentials with me by private message I would be happy to investigate further
@jimovonz Its my understanding that the NTRIP module does parse and validate the RTCM data before sending it on.
It ensures that each packetās checksum is correct (https://github.com/ArduPilot/MAVProxy/blob/master/MAVProxy/modules/lib/ntrip.py#L182) and if the checksum is incorrect it doesnāt send it on. The checksum calc is what is failing for me on about 90% of the RTCM messages.
FYI this issue has been resolved. @tridge posted a fix for the ntrip module and it now works for SSL ntrip casters.
1 Like
I am facing a little prob, ntrip module starts correctly and connects to the service. Gps goes to float than fixed, it stays so for a minute or so than it goes to 3d fix.
Looks like the ntrip module shuts down after a minute or so.
With mission planner everything works.
If from mavproxy command line i write ntrip start than it goes to float and fixed for a minute than it falls again.
First thing Iād check is āntrip statusā. Does the ntrip module report receiving an increasing # of rtcm messages?
From command line i can type āntrip statusā and itāll show me some stats?
@Corrado_Steri today I was encountering the same problems you are describing. when I start ntrip, the GPS goes to rtk fixed or rtk float, for a few minutes, then the gps goes back to regular 3d fix type, even though ntrip is still running. With mission planner this doesnāt happen. Iāll keep you posted on what I learn.
FYI @tridge.
Exactly, with mission planner it works. From command line in mavproxy if i digit start ntrip than it goes to float and fix again for few minutes.
I am using a mount point for a virtual base in rctm3, maybe ntrip module stops sending its position to service station?
@Corrado_Steri today I observed that the RTK message rate from the ntrip module is much lower than the RTK message rate from mission planner. See https://github.com/ArduPilot/MAVProxy/issues/735. I assume this is driving the results weāre seeing, in which the GPS doesnāt maintain a high-precision location lock. I suspect thereās some bug in the ntrip module that causes it to miss or discard some of the messages. Iāll keep you posted.
Thank you very much!!!
I have to say that in the mavinit.scr i use to start mavproxy options i have heartbeat=0 because otherwise system doesnāt detect ground station fail safe. Maybe it effects ntrip in some way.
In my testing today I realized the the reduced RTK messages from ntrip were caused by another unrelated module in mavproxy that wasnāt behaving. When I fixed the bug in that other module, ntrip message rate is now correct. I will keep you posted.
I donāt have any other modules running but till rtk falls all the time with ntrip.
Your rtk solution stays on all time now on ntrip?
thanks,
Corrado
So far so good. Since I fixed the problem described above, rtk lock remains steady. It does switch back and forth between fix_type 5 and 6. Perhaps 45-60 minutes of testing so far without the problem I described above. I did change the ntrip code to calculate and display the RTCM message frequency and total bytes/sec. Iām getting between 3 and 6 RTCM messages/sec, roughly 1100-1300 bytes/sec. (Note that this corresponds to more GPS_RAW mav messages since, as I understand it, RTCM messages of length >180 bytes are broken down and transmitted in multiple 180-byte GPS_RAW messages).
Hello, a little update from my ntrip usage. On the bench the correction works and stays fixed for hours without any prob. As soon as we take off after 1-2 minutes into the flight the correction goes away and Gps goes back to 3D fix.
Reverting back to Mission Planner injecting rctm data fixes the problem and Gps stays in RTK Fixed in flight without any prob.
I am wondering what could cause ntrip in mavproxy to hang after few minutes of flight.
is ntrip connecting over the internet? Any chance your internet connectivity is interrupted in flight?