Hey everyone,
I’ve been working with Here4 with the latest firmware from GNSSPeriph. So far, I’ve successfully configured UAVCAN to receive GPS, Magnetometer, and RawIMU measurements.
Now, my goal is to send RTCM messages to enable RTK. I’ve been using RTCM 3.2 (from EUREF casters) with message types 1006, 1008, 1020, 1033, 1045, 1077, 1087, 1097, and 1127. The strange part is that, although I can see the RTCM messages in the DroneCAN GUI tool, the GPS doesn’t seem to be getting an RTK fix/float.
I’m wondering if anyone has experience with a similar setup or has insights into potential pitfalls I might be overlooking. Is the F9P pre-configured to consume RTCM corrections? Any insights would be greatly appreciated.
Are you sending the RTCM correction through ardupilot, also what is the source of corrections? There is currently an existing issue in Ardupilot where the RTCM packet size greater than 300 is not parsed.
I am not using ardupilot software to send the RTCM corrections since I don’t have access on a pixhawk. I’m communicating directly through CAN with the Here4 via UAVCAN library sending uavcan.equipment.gnss.RTCMStream messages. The corrections are provided by an NTRIP client (tried both RTK2GO and EUREF NTRIP casters), and they are spitted in 128 byte chunks. Below there is a screenshot from the DroneCAN GUI RTK Information panel which shows some indicative RTCM messages as they are received from the NTRIP caster.
If you are using ntrip, note that GPS L5 is still considered experimental and is marked unhealthy, and this information might now be published.
Is it mandatory to use the L5 band? Shouldn’t the GPS be able to operate using just the L1 and the respective corrections?
Unfortunately, since I don’t have access to a Pixhawk I cannot connect the device on Windows and therefore to the U-Center to modify any of the GPS parameters. The best alternative I found was PyGPSClient in which I have access to some of the UBX parameters and monitor the message traffic. In the UBX messages I expected to see the RXM-RTCM acknowledgment but there aren’t any of them as shown in the image below. I tried also setting GPS_DRV_OPTIONS to 32.
If you don’t have L5 band correction, that might be ok. GPS_DRV_OPTIONS to 32 will atleast enable use of L5 band even without correction the quality of position is quite good. The automatic setting of L5 band related stuff was introduced in v1.12, so you need to update the GPS module for that to work.
@sidbh Don’t these methods require a Pixhawk? I have already tried the Serial Passthrough from DroneCan GUI tool on Ubuntu with the PyGPSClient as I mentioned before, but I am not able to do that in windows. What firmware version should I use for the NEO F9P?
@AlexPapadimitriou the firmware at v1.12 has nothing to do with Here4 as flight controller. Here4 as flight controller will run Ardupilot firmware. GNSSPeriph project is for GPS only operation.
The serial passthrough should work from v1.9 onwards. I would look into firewall settings on your machine preventing GUI Tool to open a port. You can also try Mission Planner, that also allows creating TCP/IP port through Here3+/Here4 Passthrough option in DroneCAN Config panel
I wasn’t able to work on that for a while but I’m on it again.
So I’ve updated the firmware to the latest v1.13 from GNSS_Periph and set the GPS_DRV_OPTIONS to 32. However, the RTCM corrections provided by the NTRIP caster do not seem to be acknowledged regardless of the mount point selection.
I also tried to connect it via serial port, but I don’t see any data there (also tried it with GPS_DRV_OPTIONS=4)
I it at all possible to debug this without the use of Pixhawk? Have you successfully used NTRIP for RTCM corrections with Here4?
@AlexPapadimitriou you can use U-Center on linux, you will need to install wine. I have run u-center on linux and it works nicely with wine. Yes, I have tested RTK operation of Here4 through ntrip server and it has worked. Can you share what is the firmware hash of the ublox? it is generally printed at boot on Log Message window in DroneCAN GUI Tool and should look something like this u-blox 1 HW: 00190000 SW: EXT CORE 1.00 (8d3640) Also have you tried pushing corrections directly through Dronecan serial passthrough?
@sidbh Indeed I was able to install u-center and connect via serial passthrough. The NTRIP client of u-center works fine and I get RTK-Float and sometimes fixed too. I’ve also tried RTKLIB with DroneCAN’s serial forwarding and it seems to work fine since it get RTK-Float instantaneously. However, using the UAVCAN protocol (and the same NTRIP caster) doesn’t seem to work that well as the fix status very rarely gets RTK-Float. In my opinion it seems like it drops some of the messages or maybe the format is wrong since I split them in 128 byte chunks. The firmware hash is u-blox 1 HW: 00190000 SW: EXT CORE 1.00 (8d3640).
@AlexPapadimitriou there is a RTK Panel available on DroneCAN GUI Tool. You can use that to analyse the RTCM messages flowing through the wire over DroneCAN. You can verify if what you are sending is making it on the wire intact. You can use dronecan_bridge.py tool in pydronecan to expose DroneCAN to multiple ifaces at once for this.
