I use “ZED-F9P + SparkFun LoRaSerial Kit 915MHz” and “ZED-F9R + SparkFun LoRaSerial Kit - 915MHz”. But when I check LORA Receive as picture. Please help me
this is normal because the RTCM messages are in binary
2 Likes
Help do what, exactly?
RTCM3 is not human readable ASCII text
Uses a binary encoding, so perhaps select a HEX view in your Terminal app, or use something like RealTerm.
The preamble for RTCM3 packets is 0xD3, so you could look/check for that pattern.
1 Like
The Quick Start Guide and Product Manual may help. (SparkFun LoRaSerial Product Manual)(Quick Start Guide - SparkFun LoRaSerial Product Manual)
SparkFun LoRaSerial Kit - 915MHz (Enclosed)
The LoRaSerial Kit is just that Serial UART over LoRa. You could remove them and use a cable to eliminate them from the equation.
If you are trying to decode the messages, I use: pygnssutils · PyPI
It sounds like you are trying to create a base and rover and supply the rover with corrections. If this is the case, remove the LoRa from the equation and first get it working over a cable.
1 Like
I’m probably going to need to revisit this, but would need assistance from people who can build and test the LoRaSerial code independently.
The hopping and recovery needs some better synchronization and recovery.
The radio needs to be more aware of RTCM3 packet structures and boundaries.
They are connected to GNSS receivers at both ends, so time-domain synchronization and prediction about what frequency to listen on next could probably be improved.
I used one frequency, and let the band walking on LoRa spread things out.
If we moved once per second, would that be reasonable? Jumping between packets seems unduly disruptive.
High bandwidth (500 KHz, ~10kbps) and 20 dBm should be able to get a KM with little effort, the 30 dBm hopefully a lot further.
1 Like
My understanding of the LoRaSerial Kit is just a UART transport. You shouldn’t need to worry about the code running on it.
Did you notice that the UART speed is 57600 bps and the Airspeed is 4800 bps? Is 4800 bps enough for RTCM3?
You can validate this by doing a speed test over them. If my assumption is accurate, even though the UART is running at 57600, you’re only going to get 4800 bps across the link.
Or are you saying the frequency hopping is interfering so much that the RTCM3 messages aren’t coming through reliably?
Yeah, that’s great in theory, but with LoRa packet sizes <~250 bytes it becomes an issue with RTCM3 packets that span several transport ones, and you want to limit the ramifications of packet loss. The RTCM3 packet also have readily determinable length, built in integrity checking, in the ZED-F9x and ZED-X20x cases frequently the opportunity to compress by 15% or so. Awareness of what you’ve moving buys a lot of chances of winning more often.
The hopping on the LoRaSerial has a long recovery period, as it’s not synchronized and you’ll end up getting nothing until the Tx and Rx devices get to the same frequency again. One basically needs to stop and wait for the other to cycle back around. I suspect something more predictive in the time domain would save a lot of effort dwelling on mismatched frequencies. Time out’s on reception abort current working transfers with Semtech’s implementation, rather than reset/realign on preamble. Probably fixable, but continuous reception mode is preferable.
RTCM3 transport is inherently a one-way, one-to-many, broadcast opportunity.
My recollection with LoRaSerial was there’s a lot of back-n-forth, registering, and attempt to be a transparent two-way serial link. But for this application something else would be more suitable. I tried designating one a transmitter, and one a receiver.
Not something I’m keen to throw 100’s of hours fighting.
Looks like it was compiled with the Arduino IDE, which is one of the easiest for beginners to get started with. Just pick the MCU of the hardware you have.
Aside from spelunking through the source, if you have two GNSS receivers already, you have incredibly accurate time source. From the sender, just write a little script to send the datetime every 100ms from the source GNSS as the payload and when the receiver gets the message, write the time from the destination GNSS. Now you can see how long it takes for the message to make it through and you can vary it to find the breaking point.
Look at SparkFun_LoRaSerial/Documents/Training.md at main · sparkfun/SparkFun_LoRaSerial · GitHub
You’re able to change the characteristics of the radio without recompiling. Have you explored increasing the radio bandwidth?
Since RTCM3 is sent every second and it’s possible to miss a packet or two without it effecting much. This means that the transport LoRa doesn’t need to ensure delivery. Point to Multi-Point appears to be a better transport. Point to Point ensures delivery and adds additional overhead.
It appears you can even disable frequency hopping all together, for testing purposes of course.
I can build from source and have 2 loraserials and I am willing to test.
@AORPLS it doesn’t appear that you need to recompile. The link I provided above shows you how to change the radio speed (air speed) from 4800 to up to 38400 as well as modify the frequency hoping features that @clive1 asserts is causing the issue.
There are a couple different ways you can stress test the serial port with different settings to find the most reliable at highest speed.
When I goto 38400 my links won’t stay up. Clive did mention something that made me think, the rover is transmitting much more data and flooding the link. So I am going to cut the transmit wire as the rover doesn’t need to transmit over Lora
I was able to get multipoint up
I disabled all nmea on postcard and just enabled 1005, msm7 for gps, gal, and glonass. But my suspicion is that the link was being flooded by the rover with all the messages I had turned on.
The issue was the postcard in rover mode flooding the serial and killing the link I disconnected the transmit wire and bam it works. @sparky can you make a feature to turn off the uart transmit serial in rover mode on the postcard
Issue here.
1 Like
@sparky I switched to P2P mode, ran a airspeed of 9600 and got about 300 feet down the street and my base is in my backyard and I strapped the omni antenna to the tripod leg (literally so terrible LOS) so I ordered a pole clamp so I can get it up higher and away from the tripod. I was curious wouldn’t it be a benefit to switch the jumper to 5v to feed the LORA the lipo battery voltage and help the power levels just a little bit more?
The RADIO port on the Postcard will feed either 3V3 (default) or 5V out. So yes, modifying the VSEL jumper to 5V should provide the LoRaSerial with additional gain.
1 Like
I applied 5v and was able to go 1000 feet in my subdivision so again not great line of sight. But glad to finally get Loraserial working. I was able to run 4800 baud. I did get a couple channel hops but mainly when I was walking probably as it tried to find the base again
Lora at 2000 feet apart it worked I will compare versus ppk and RTN RTK on the correction network. But fantastic that it worked to check into a benchmark. @toeknee you couldn’t topo with it but for an elevation certificate