I have a RTK Reference Station (GPS-22429) and am having some difficulty setting up / connecting to the station in my desired configuration. After reading over the hookup guide and other documentation / guides regarding the reference station I have not found a suitable solution.
I would like to connect the reference station ideally through Ethernet (WiFi would be ok) to a router. I would require the correction data to be streamed to the router so that a WiFi of Ethernet connected ground station could connect and stream the data.
I have previously attempted to use Ntrip server/caster to cast the data, as well as trying to push the data using TCP to the ground station computer address, but with no success.
If anyone has any resources / guides / comments on how I can solve my problem I would be very greatful.
The Reference Station is designed to act as a RTK Base, serving corrections through an NTRIP caster like RTK2go. Rovers can then connect to and use that correction stream. The Reference Station can also be configured as a Rover if you wish. That was one of my standard tests while I was developing the Reference Station, have one act as a Base, a second as a Rover, with the correction data passed over Ethernet both ways through RTK2go. It’s just a question of working through the configuration steps.
Connect the Reference Station to your router using Ethernet. It defaults to DHCP which should work well with most routers, but you can give it a fixed IP Address if you wish through the serial menu: https://docs.sparkfun.com/SparkFun_RTK_ … _ethernet/
Ensure the Reference Station is in Base mode and allow it to complete its Survey-In. This establishes the antenna position and it will generate corrections based on that position, sending the data to RTK2go. All being well, you should see “Casting” on the display: https://docs.sparkfun.com/SparkFun_RTK_ … ansmitting
5) Configure your Rover to use the same mount point and away you go... The Reference Station can also be a Rover, but I'm guessing you only have a single unit at present? If that's the case and you do want to use it as a Rover, you will need to subscribe to a correction service like Swift Skylark and enter the account details via the serial menu.
I hope this gets you up and running. Let me know if you need more help.
Best wishes,
Paul
Thanks for the quick response, all those instructions are great!
Would it however be possible to have this set up as an “offline” setup? Essentially to have a router not connected to the internet, and push the data from the reference station to the router using the ethernet port. Then to connect a ground station to the router, which will control the rover and receive / process the RTCM correction data. I believe this would make the use of 3rd party NTRIP service not necessary, which would be good in my case.
Using U-Center I have managed to set up a NTRIP caster and cast the raw data to my ground station, but this means bypassing some of the great features of the station.
If you have any further advice or instructions please let me know.
I have a few ideas about how you could achieve this. But I have one question: how is the Rover connected into the system?
If the Rover is also a Reference Station and connected to the same Ethernet network, then one solution would be:
The router acts as the Ethernet DHCP server (or you give everything fixed IP addresses)
Base Reference Station is connected via Ethernet and sends correction data to
A PC running NTRIP Caster code receives those corrections and makes them available to
The Rover which is also connected via Ethernet
Or, we could add a new feature to the RTK Firmware to allow a point-to-point TCP/UDP connection from the Base to the Rover direct, passing standard RTCM corrections as TCP/UDP packets, and avoiding the need for the PC and Caster code.
Or, does the Rover need to receive its corrections via a different interface - so it can be ‘mobile’? WiFi? LoRa radio?
The rover uses 2 other GPS (F9P based) to obtain a GPS for heading / yaw. Then the Sparkfun reference station will act as the base station for RTK corrections. The ground control station will be connected to the rover using a 2.4GHz radio, which will pass the corrections to the rover. At this point the rover will not be connected using ethernet.
The solution to have a point-to-point TCP/UDP connection passing RTCM corrections as TCP/UDP packets would absolutely be the best solution for my scenario. It would allow the ground control station to connect to the router, process the RTCM data, and pass that to the rover over radio.
The rover will not be physically connected to anything, all communication will be via radio.
Attached is a rough functional diagram for the setup I am trying to achieve.
This is very interesting stuff, but I’m still not quite getting the full picture…
Can you add some distances to your diagram? I’d like to understand the distances between the Reference Station Base, the Ground Control Station and the Rover(s). Are we talking metres or tens of kilometres?
Also, you said the Rover is actually two ZED-F9Ps. How are you calculating the heading and yaw? Is the Ground Control Station calculating that, based on the individual locations of the two Rovers? Or are you using a “moving base” set-up with more (separate) corrections going from one Rover to the other, so the second can generate accurate RELPOSNED relative positioning information based on the location of the first?
Is the idea that the Ground Control Station is able to display the heading information in real time - so are you transmitting Rover positions continuously back to the Control Station? I.e. the 2.4GHz radio is carrying RTCM correction one way, and Rover position data in the other direction?
The RTK reference station will be within the range of the routers WiFi, probably within a few metres. The ground control station will be running Mission Planner, which is where the RTK corrections are injected (see https://ardupilot.org/copter/docs/commo … ction.html).
From there, the ground control station and rover communicates using a 2.4GHz radio, over distances up to a few kilometres. The corrections are received by the rovers autopilot. There are 2 onboard GPS’ which use their known relative position to calculate yaw. The GPS for yaw isn’t really relevant to the RTK GPS setup though.
The main functionality I am looking for, as you said in your previous post, is to have a point-to-point TCP/UDP connection. The connection would pass RTCM data from the Reference Station to the router using TCP/UDP through ethernet, and to the ground station running Mission planner over WiFi.
Furthermore, an additional feature that would be nice to have would the option to output the RTCM data in mavlink format. If this were possible, the RTCM data could be sent in the form of mavlink packets from the reference station to the router, from the router to the 2.4GHz radio, then from the radio connected to the router to the rover. See https://mavlink.io/en/messages/common.h … _RTCM_DATA. Also raw code in Github for Mavlink RTCM data format: https://github.com/mavlink/c_library_v2 … 55C7-L55C7.
Also included is an updated functional diagram that will hopefully clear up my explanation a bit.
I’m trying to resist digging into this too deeply as I am busy with other projects, but I will definitely help if I can. I haven’t come across Ethernet-enabled Radio for UAVs before. My brief reading-around-the-subject took me to:
The Reference Station can connect to a TCP Server and pass RTCM data (or NMEA or UBX) to it. That’s the feature that is described here: https://docs.sparkfun.com/SparkFun_RTK_ … tcp-client . If Mission Planner or MAVProxy can be configured as a TCP Server, then the Reference Station will connect to it if you provide the Host and Port details. Then, as you say, the Mission Planner / MAVProxy can translate the RTCM to MAVLink and forward it to the Ethernet-enabled Radio.
I hope this points you in the right direction. If you think there’s a specific feature we could add to the firmware, then please let us know. If it is likely to generate a few more sales, then we can add it to the development list.
I’m not sure how well formatting the RTCM into MAVLink format would work - your Alternate Path. We could do that, but there would still need to be a ‘broker’ of some kind to allow the MAVLink-RTCM to be merged with the Mission Planner flight-control messages, before it hits the radio. Maybe the uart-to-eth is smart enough to do that - but I kind of doubt it? I suspect you’d still need to route the RTCM data through MAVProxy, even if it is in MAVLink format?
Sorry for barging into the thread but seeing the sale on the NEO-D9S got me thinking. I have two Pixhawk drones that use HereLink radios. The HereLink is a tablet/receiver system that includes Android and can create a WiFi hotspot for ground station computers that can send/receive telemetry using MAVLINK/MAVPROXY.
Ground station PC ->WiFi-> HereLink GS controller → HereLink air unit → Serial Telemetry → Flight controller
I have used this setup with a PC running Mission Planner to send RTK data to the drone. However it would be preferable to have a more portable and compact system that wouldn’t necessarily require surveyed points as my application doesn’t require survey grade data, only accurate and repeatable relative position.
Three questions: If I were to construct an ESP32/RPI2040/Raspberry Pi Zero base station for sending RTK from PointPerfect would I still need to have a ZED-F9P on the ground (I think I would)? Does the NEO-D9S only communicate with the ZED-F9P or does the host need to process the PointPerfect data as well, setting aside updating the decryption keys? Would it be better to locate the D9S-F9P on the drone itself (Ardupilot/Pixhawk GPS2 input) and not be concerned about a ground station?
Good questions! And thanks for the pointer to HereLink - that looks like a very useful piece of kit…
You can receive u-blox PointPerfect corrections over an IP network; or from L-Band geostationary satellite via the NEO-D9S. The correction data format is SPARTN, not RTCM. The data output by the NEO-D9S is SPARTN wrapped up in UBX-RXM-PMP binary format packets. The ZED-F9P can digest the PMP packets directly, but needs the current key to be able to decrypt the SPARTN data. It is also possible to extract the SPARTN data from the PMP packets and pass that to the ZED-F9P. But again, the ZED needs the current key to decrypt the data. There is an example here ( https://github.com/sparkfun/SparkFun_u- … arsing.ino ) which CRC-checks the SPARTN data before pushing it to the ZED.
It should be possible to receive the L-Band signal on the drone itself, but I would worry about electrical noise from the prop motors and the antenna losing sight of the geostationary satellite. I suspect you’ll have better results with a NEO+ZED base, passing RTCM corrections to the drone via HereLink. But I’m not the best person to comment on this. Hopefully someone with more drone experience can give you a better answer.
