Is there a way to only accept corrections from your own RS3’s when using LoRa for corrections?
When doing some drone surveys yesterday, I was using two RS3’s in a Base-Rover configuration with LoRa for corrections between them.
I was initially getting some odd results, with the baseline switching between 30m (my local RS3) and 13.25km. In an attempt to get the corrections to stabilise, and without realising the unit had connected to another LoRa source, I manually switched frequencies and the issue was cleared.
When I checked the points I’d collected, I spotted one had recorded a different base location which again said 13.25km away - when I looked up the location, it was at an archaeological site on the UK’s Hadrian’s Wall 13.25km to the NW of me. There was a completely clear line of site between us - no trees and no other obstructions like buildings. So, it seems I’d unwittingly connected to their LoRa stream, and they most likely had also unwittingly connected to my LoRa at some point too.
So, is there a way of restricting my RS3 Rover to obtaining the ‘local’ corrections from my nearby RS3 Base… and I presume the output data-stream is totally open and unencrypted?
Or is it just a case of (hopefully!) spot there’s a collision and manually change frequencies?
Finally… given the problems people encounter with loRa Range… is this a record distance for LoRa!!!
Oh, wow, it’s interesting! Thank you for sharing it.
I can’t think of a way to restrict which base corrections are received in such a setup, but I agree with the idea of changing the working frequency. Overall, testing different radio frequencies before the survey at a particular site is a good idea. You can go through them with a 1-2 MHz step as a part of the survey prep.
I don’t know what sort of data is carried in the correction stream, but perhaps some option when configuring a Rover to reject corrections over a user specified baseline distance, or over a certain age in seconds? I noticed when trying to figure out why things were behaving strangely that the receiver status screen gave both figures in it’s readouts - the baseline obviously was long, but if I recall correctly, the age of corrections was also far older than those it received from my local base.
Having read the forums and seen the distances some people have had trouble with receiving LoRa, I was astonished!
Others complain the range is too short, and you complain it’s too long!
This is going to become more prevalent as the user population grows and raises concerns, for example data integrity and legal traceability for survey work.
You have no idea how bad the other base coordinates really are. For example, they could be averaging single while you remain blissfully ignorant and contented that your base was double checked precisely positioned on a known control.
This is more of an issue for LORA as UHF is typically contained within professional environments.
Hopefully the LORA protocol has been future proofed with a user configurable ID field that can be implemented in Flow at some point.
I don’t know how all these sorts of problems keep managing to find their way to my doorstep . All I want to do is take some accurate measured points and fly a drone to make some pretty maps & models .
In all honesty, it was probably a very unusual set of circumstances - two of us using LoRa simultaneously on high ground without any obstructions between us, and with the LoRa on default settings. Probably atmospheric conditions played a part too.
But yes, as more units are sold and more used near each other, then collisions might occur. If the baseline hadn’t been so obviously way out, then I might not have realised until it was too late & had to revisit & redo the measurements a different day.
That’s pretty crazy odds that you would actually have another compatible signal in your area but this has always been an issue regardless of brand. I recall this happening to me years ago with Topcon. Unfortunately at that time they were on a predefined set of channels so there weren’t as many options as you have with the more granular control of the actual frequency Emlid provides. We had to learn to not use channels 1, 7 or 10 which were the most common or your stakeout point might end up a mile away. One problem with changing the channel/frequency is that it will break daisy-chaining. I’ve worked on projects that were 10+ miles long with poor LOS where we would setup 2 or 3 bases on the same channel and localization so as you or a machine roamed it could hop bases like a phone hopping cell towers.
SparkFun has a version of a LoRa spread spectrum and includes a way to generate a new random network ID and AES encryption key for syncing between two of their radios.
SparkFun LoRaSerial Kit - 915MHz (Enclosed).
“the LoRaSerial is very good at getting whatever data you need, encrypted or not, from point A to point B without fuss. The radios in this kit automatically frequency hop (FHSS) between channels to avoid collisions. The LoRaSerial firmware supports an innovative and simple-to-use ‘training’ method. Pressing the train button on both radios will generate a new random network ID and AES encryption key to share them.”
I don’t know if it would be possible to use them with the Emlid line of receivers.
Javad GNSS has UHF frequency hopping capabilities. We have 2 for our Triumph LS+ receivers. Their costs are comparable to the RS3, but I’m not sure how you would interface with these but you probably can somehow.
We’ve never have had problems with the HPT901BT and the radio has excellent range at approx 3 km in open areas. Even through our thick “Vietnam” vegetation wooded areas in SC, we usually get at least 1 km range.
As with most modular radios with built-in external antennas, you can’t turn it on or charge without the antenna or you’ll blow out the circuitry in the radio. They start broadcasting as soon as it’s turned on.
Wonder if not connecting the LoRa antenna to the Emlid receivers while operating has caused some of the decreased range issues with some of the users in other recent posts? As Emlid instructions say, to make sure LoRa antenna connected during use. I’ve always connected antennas even if LoRa turned off just in case.
Just to clarify, a Call Sign configured in a radio is a countries radio spectrum licensing authority thing and separate to the correction data. It helps the authority (e.g. US FCC, Australian ACMA whatever) to generally manage the airwaves and ensure you are legitimately licensed and behaving. As the name suggests it’s the same as a call sign to be used for other licensed radio transmissions in aviation, maritime, etc.
In this case the Call Sign is broadcast in morse code and typically only at 15-minute intervals. And it’s snuck in between data packets which are momentarily paused to get it out so it’s not seen by the receiver, which in Emlids case is only sniffing for TT450S data packets containing the RTCM3 messages. You can hear the Call Sign though if you are anal-retentive, have a UHF radio on frequency & plenty of time, but not so helpful when you are trotting around in the field.
The RTK relevant thing is the Station ID field that’s internal to the RTCM messages. You would configure it into the base receiver (if the receiver includes the functionality), and it’s added into the outgoing packets and so available to the Rover. But the Rover would also need corresponding functionality programmed in to do anything with it. E.g. to only accept the RTCM messages with a particular ID.
That’s interesting Wombo - the call sign sounds kind of like the yellow dot ID pattern that is added to laser printers and copiers so that the source can be tracked. We don’t see the dot pattern on our print outs, but it’s there for those who know.
.
. All I want to do is take some accurate measured points and fly a drone to make some pretty maps & models 
.
- unless they own up to it on here 