I have trained the radios and they are setup with a short transmission range. When I scope the output of the RTK reference and the serial receiver I get the following trace (RTK reference blue, LoRa output yellow)
I’m not exactly sure of what you’re trying to acheive.
The end-to-end latency is important, but the RTCM3 packets are not typically going to fit cleanly into LoRa maximal packet size, and with the SparkFun implementation are not aligned to RTCM3 packet boundaries in any way.
If you’re missing packets, that could be due to frequency hopping. Or just the unforgivingness of radio as a medium.
The RTK Rover can maintain itself for a minute in the absence of new data, and so it doesn’t need data every second to keep an RTK Fixed solution provided you have solid lock on the GPS/GNSS signals and ambiguity resolution of the carrier signals.
+1 to @clive1’s answer.
Assuming the Base output (blue line) is 1 second epochs on your scope, a RTK rover wouldn’t have any problems when receiving the base observations as shown in the LoRa output (yellow), in the context of the age of the correction data.
It’s my understanding that the sources of the errors that the RTK concept is used to correct simply aren’t changing over this time scale (successive 1-sec epochs)…and likely not much across 1 minute as mentioned.
When I hardwire from the RTK reference I get RTCM correction on my receiver.
When I connect via the wireless link that drops out.
Looking at the scope output that’s self explanatory. The thing that is frustrating is that on the RTK Reference page it explicitly states that the LoRa Serial Radio is an ideal solution for remote RTK transmission. (About 3/4 down this page: Correction Transport - SparkFun RTK Product Manual)
One other thing I noticed is that on the transmission side the RTCM packet is around 60ms in duration, while the receive message is truncated to 40ms or so. Looks like some of the packets are getting lost.
Is there a setting within the Radio or RTK reference that I need to set?
The wireless link is not continous, it is packetized, after a radio packet is received it will be output, the length of the radio packet will determine the burst length.
For the uBlox ZED-F9P / NEO-M8P you should be able to gauge RTCM3 packet reception via UBX-RXM-RTCM
Hate to be the naysayer here, I love almost every single SparkFun product that I’ve used.
However I never got the SparkFun LoRaSerial radios to work reliably with my Facets. Maybe it was me, maybe it wasn’t, I just don’t know.
The Holybro radios that I bought from SF when I purchased my first pair of Facets work well, no fuss, just limited by the 0.1w power.
If I want to use the 900MHz band, I now use a pair of RFD900x radios, they work amazingly well, no fuss.
I also wired up a pair of 450MHz-band professional surveyor radios - 35W base transmitter and a receiver. I used the excellent SparkFun TTL-RS232 level converters (the more advanced one ones, MAX232, not the simpler level shifters) and built them into my cabling. These radios work amazingly well. 35w on a 16’ antenna on top of a hill gives great range. Also, the professional surveyor (Satel) radios are designed knowing that the RTK data stream in this use case is one-way only, so they don’t do any handshaking or require the base radio to receive data back from the rover, eliminating many potential failure modes. I had to get an FCC license (I’m in the US) to use these.
Sadly, I never got the SF LoRaSerial radios to work reliably. I have three other pair of radios (Holybros, RFD900x, Satel) that work excellently and very reliably. I don’t know if it’s issues I caused or a problem with the radios. I tossed them in a box, was too busy to put any more time into them. I tried P2P and multipoint modes with them to no avail.
User cturvey even forked the firmware to make some improvements for the RTK use case. I never had time to test it, got busy doing actual surveying and just use the radios that work for me.
That’s not quite the bundle I purchased. I don’t know what the TXMOD is. I bought a similar bundle but with two RFD900x modules and no TXMOD. You do want a bundle with those better antennas as shown in the bundle you linked.
Note this is not a turnkey solution. You’ll need to examine the pin outs on both ends, source parts, and build yourself a set of cables to connect to your SparkFun GNSS devices. I was able to Frankenstein the cables I needed by taking apart various cables I bought (via depinning) and putting things back together as I needed them. You’ll also need to configure the RFD modules to work with the GNSS receivers (baud rate only IIRC). Finally you’ll need to consider the power the GNSS receiver can supply and the power the RFD modules needed. You can either dial down the transmit power the RFDs use or power them independently.
Honestly it might be easier to work with SF support to get the SF LoRaSerial radios working. I bought my RFD900x radios before SF released their LoRaSerial radios, so when they came out and I couldn’t get them working after a couple field days and 4 hours of bench time, I just gave up and went back to what worked for me.
I’ve never used the LoraSerial Kit that @ry1808 linked to in the Original Post, but I have used similar Sub-GHz radios.
Are you folks using Continuous Mode, or Packet Mode ?
For me, I enjoyed the simplicity of a Transparent/Continuous Mode for this type of application.
It removes the Overhead (preamble, Sync word, CRC, etc).
If for some reason a RTCM message comes out the other end with an error, the RTK engine wont get upset.
From the Datasheet
2.1.9.2. Data Operation Modes
The SX1276/77/78/79 has two different data operation modes selectable by the user:
Continuous mode: each bit transmitted or received is accessed in real time at the DIO2/DATA pin.
This mode may be used if adequate external signal processing is available.
