Has anyone gotten the LoRaSerial radios working reliably for RTK (Facets, Surveyors, Expresses) ??

GPS/GNSS Development Boards
1

Just like the title says - do the LoRaSerial radios (https://www.sparkfun.com/products/20029) work for your RTK system?

Mine are very spotty and unusable for RTK work. The latency (age) of my RTK solution, as report by the Facets, is very unstable when using the LoRaSerial radios. It will work for a few minutes, then the comm link appears to go down, the latency climbs, I lose RTK fix. Then the comm link returns, I get an RTK fixed solution, things are good for a while, and then it happens all over again.

Based on reading these other threads, perhaps others might have the same problem I am having:

viewtopic.php?f=116&t=60609

viewtopic.php?f=117&t=60671

viewtopic.php?f=117&t=60673

viewtopic.php?f=117&t=60872

I did a bench test today and was able to replicate the comm link problem with the LoRaSerial radios on my workbench. My setup was a windows PC, a couple USB cables, the two LoRaSerial radios, TeraTerm, and a program for serial testing (https://github.com/wh201906/SerialTest)

My radios were in multipoint mode (this makes the most sense for the continuous stream of updated RTK data). I had SerialTest send a 100-character string every 500ms to my “server” LoRaSerial radio, and I monitored the output of the other radio with either Teraterm or another instance of SerialTest. The 4 green signal strength LEDs were illuminated on the receiving radio, I think 3 or 4 on the server/transmitting radio.

The yellow LED on the server radio would flash with every string transmitted (every 500ms), and the blue LED on the other radios would flash with every string received (every 500ms). Sometimes, often after 4 or so minutes, the reception would stop, the data wasn’t displayed in TeraTerm, the blue LED stopped flashing. Nothing would happen for about 30 seconds. Then the green LEDs would blink on the receiving radio, and everything would start working fine again. Sometimes this would happen again every 3-4 minutes, and sometimes it would not.

It’s like there’s some bug and the receiving radio loses sync with the transmitting radio, and it has to restart/resync. The transmitting radio shows no apparent anomalous behavior - that yellow LED just keeps blinking every 500ms.

So far I have used four different sets of radios for my Facets, including the LoRaSerial radios. The other three sets of radios work without problems.

  1. The 0.1W Holybros I originally purchased in 2022 for my Facets work great, just the power was too low. (https://www.sparkfun.com/products/19032)

  2. I purchased a pair of RFD900x telemetry radios and they work very well. They have 1W transmitters and the range was greatly improved over the Holybros.

  3. I tested a set of SATEL radio modems (450MHz band) and they worked great. The lower frequency band seems to help with the hills and valleys a bit. You can buy 1W, 10W, and 35W models These are the type of radios that are sold for and/or integrated with professional surveyor-grade RTK equipment. I had to make custom cables to interface between the RS232 ports and the TTL-serial Facet ports (SparkFun to the rescue on this–> https://www.sparkfun.com/products/11189 was just what I needed.) These radios are heavier, power hungry, very expensive, and require a license (here in the US), and so I’m not using them until I sort all that out, if ever.

My default radios are the RFD900x pair. They are reliable. I have great success with my Facets and the RFD900x radios. However, the status LEDs on the RFD900x are buried and impossible to monitor for when I am losing radio range. I struggle with the radio range, as I work in mountainous terrain with no cell coverage. So those LEDs are important to me.

I really wanted to love the new SparkFun LoRaSerial radios - the LEDs (except the yellow one) are BRIGHT and visible, unlike the RFD900x LEDs. The signal strength LEDs on the LoRaSerial radios would be useful for me.

Tony.

PS My LoRaSerial radio settings (the keys are xxxx’d out)

Base/Transmitter/Server

ATR

AT-AirSpeed=0

AT-AutoTune=0

AT-Bandwidth=500.00

AT-ClientFindPartnerRetryInterval=3

AT-CodingRate=7

AT-DataScrambling=0

AT-EnableCRC16=1

AT-EncryptData=1

AT-EncryptionKey=xxx

AT-FramesToYield=3

AT-FrequencyHop=1

AT-FrequencyMax=928.000

AT-FrequencyMin=902.000

AT-HeartBeatTimeout=5000

AT-MaxDwellTime=400

AT-MaxResends=0

AT-NetID=192

AT-NumberOfChannels=50

AT-OperatingMode=0

AT-OverHeadtime=10

AT-PreambleLength=8

AT-SelectLedUse=4

AT-Server=1

AT-SpreadFactor=8

AT-SyncWord=18

AT-TrainingKey=xxx

AT-TrainingTimeout=1

AT-TxPower=30

AT-TxToRxUsec=280

AT-VerifyRxNetID=1

ATS

AT-CopySerial=0

AT-Echo=0

AT-FlowControl=0

AT-InvertCts=0

AT-InvertRts=0

AT-RTSOffBytes=32

AT-RTSOnBytes=256

AT-SerialDelay=50

AT-SerialSpeed=57600

AT-UsbSerialWait=0

OK

Receiver/Rover

ATR

AT-AirSpeed=0

AT-AutoTune=0

AT-Bandwidth=500.00

AT-ClientFindPartnerRetryInterval=3

AT-CodingRate=7

AT-DataScrambling=0

AT-EnableCRC16=1

AT-EncryptData=1

AT-EncryptionKey=xxxx

AT-FramesToYield=3

AT-FrequencyHop=1

AT-FrequencyMax=928.000

AT-FrequencyMin=902.000

AT-HeartBeatTimeout=5000

AT-MaxDwellTime=400

AT-MaxResends=0

AT-NetID=192

AT-NumberOfChannels=50

AT-OperatingMode=0

AT-OverHeadtime=10

AT-PreambleLength=8

AT-SelectLedUse=4

AT-Server=0

AT-SpreadFactor=8

AT-SyncWord=18

AT-TrainingKey=xxxx

AT-TrainingTimeout=1

AT-TxPower=30

AT-TxToRxUsec=280

AT-VerifyRxNetID=1

OK

ats

ATS

AT-CopySerial=0

AT-Echo=0

AT-FlowControl=0

AT-InvertCts=0

AT-InvertRts=0

AT-RTSOffBytes=32

AT-RTSOnBytes=256

AT-SerialDelay=50

AT-SerialSpeed=57600

AT-UsbSerialWait=0

2

I submitted an issue to the github firmware repo. If you have any data to add, please do, it will probably help.

https://github.com/sparkfun/SparkFun_Lo … issues/587

3

Been pondering this and skimmed the code.

In the One-to-Many situation, really need to establish one as the primary station, driving the hop time and pattern. The primary should be only one broadcasting DATAGRAM_SYNC_CLOCKS, and ideally this should communicate the time to next hop, and where it’s going to go. The rest of the stations need to synchronize to this, and not be sending their own DATAGRAM_SYNC_CLOCKS as this will just result in chaos as there’s no indication of who’s in charge, some of the stations will not be in range of each other, and apt to be synchronized by the periodicity of the messaging from the GPS receivers.

4

Hey ToeKnee,

I’m working with RTK as well. Don’t know if this is similar to what you’ve been experiencing.

The attached photo shows some traces captured on a Saleae Logic Pro. I’m using the EXTINT pin on the rover ZED-F9P to generate a “Button Press” to the host using the UBX-TIM-TM2 message. I’m also sending a 1 Hz position message using UBX-NAV-HPPOSLLH (80 bytes for the two messages).

A trigger pulse is setup on a SDG6022 signal generator to simulate the button (Trace D2). EXTINT is triggered once per second. This generates a nicely monotonic message at the rover UART2 TX output (Trace D1). That message is input to the LoRaSerial unit on the Rover end and sent over the air. Trace D3 shows the serial output from the receiving (base) LoRaSerial unit. There is clearly message loss over the air. It is unpredictable, sometimes pausing for 15 or 20 seconds, sometimes chugging along merrily at once message per second, and typically lagging by two to three seconds.

Trace D0 is the RTCM3 data from the base. The base is transmitting for about 80ms per burst, and the rover for about 14ms. As I do the math, that’s less than 10% channel utilization. Is that considered crowded for these radios? There are no other active messages.

I’m trying to understand the conditions that would cause this. The radios are both on my bench, just a few feet apart. They are both set to the default configuration (57,600 baud, full power, etc.)

Any thoughts?

Thanks, and otherwise sorry to bother you.

David

20240303_113910.jpg
20240303_113910.jpg4032×3024 2.21 MB

5

firmwareguy195:
…Any thoughts?..

David, nice analysis! The behavior you observed appears to be very similar to what I observed.

The conversation got going over on GitHub, and others reported similar behavior. The LoRaSerial radios never usefully worked with my Facets; I’d get an RTK fix for a few minutes, then I’d lose the comm link and the fix. I’d sporadically re-establish the RTK fix, but it was to intermittent to be usable for surveying.

https://github.com/sparkfun/SparkFun_Lo … issues/587

cturvey took a hard look at the LoRaSerial firmware code, forked the repo, made some changes, and posted firmware he wanted tested. I got busy with other things and haven’t had a chance to test it yet.

The “application layer” protocol is one-way: the RTCM flows from the Base to the Rover with no request or reply from the Rover to the Base. The “data link layer” (I use these terms loosely) in the drone telemetry radios (HolyBro, RFD900s, SparkFun LoRaSerial, etc.) is bidirectional, which is overkill for our application. If the radio at the Base can’t receive data link layer acknowledgements, heartbeats, and other protocol overhead from the Rover radio, the link dies. This is unfortunate, as it seems to cause problems with no benefits to the actual application (Base/Rover RTK), and requires the Rover radio to transmit constantly, using up battery power, for no benefit.

I believe that the Holybro, RFD900x, SparkFun LoRaSerial, and other radios based on drone control & telemetry applications are, frankly, the wrong radios for RTK base-rover communications. The bidirectional protocol at the data link layer introduces many problems and limitations.

If I understand correctly, the test firmware fork that cturvey created eliminates the bidirectional protocol. I do intend on testing it when I am able.

Professional surveying equipment (eg. Trimble, TopCon, Carlson, etc.) generally uses radios in 450MHz band, transmitting at the Base and receiving at the Rover. No bidirectional protocol. If they need more range, they use a 35W transmitter (FCC license required in the USA) at the Base with a receiver at the Rover. I once borrowed a set of these radios from a surveyor friend, made some cables, and they worked very well with the SparkFun Facets. They are very expensive however.

Cheers,

Tony.