Looking for some help on my setup as I am struggling. I have two Postcards with LoRa radios attached to each of them thru the UART3 radio port. The radios seem to be linking right away and always have 3 leds (they are 5’ apart for testing). I am using a L1/2/5 antenna on the base and a L1/2 antenna on the rover (ublox ann-mb).
I am running v2.3 in each postcard as well as V6 in the LG290P. Each postcard has been reset after upgrading the firmware.
I have set everything up as per the attached file.
The survey in occurs rapidly and I get an accuracy of around 17cm.
I then monitor my rover and the best I get is 1.018m accuracy (its stuck there) with a DGPS Fix state. When I check my corrections priority, I am seeing corrections over the External radio but they are somewhat old - never newer than 20sec.
Do I have something wrong with my config? I only recently toggled the low bandwidth base option but that doesn’t seem to have changed anything. With toggling the low bandwidth option for base messages, I assume the 4800 bps on the LoRa is sufficient (I can’t figure out how to get it to permanently stay at 19200.
Any help is appreciated. I’m relatively new at this - these forums are such a great resource!
Are your antennas outside? RTK does not work indoors.
Make sure the serial interface speeds are correct. The Postcard needs to output serial at X rate, the LoRaSerial needs to be setup to receive at X rate.
You might try connecting the TX pin on your base to the RX pin on your Rover and eliminate the radio connection for now.
Also, consider ESP-NOW. It’s a free radio for base/rover that will eliminate the LoRaSerial as a variable.
I was able to pair the ESP-NOW radios between the base and the rover.
Tested it out and I had a RTK-Fix before I was able to switch my app over from the base to the rover. Reporting a .007m accuracy. Looking at the connections, the rover is reporting connection via the ESP-NOW at around .5sec - always less than 1 sec.
So, definitely confirmed that the LoRa radios are the issue. I am not sure whether I should post here or in the LoRa board for this issue.
As mentioned before, I have changed the Radio baud on both the PostCards & LoRa’s to 115200 as per the issue on the LG290P not accepting 57600. I haven’t been able to change the permanent airspeed of the LoRa’s so they are still transmitting at 4800. I tried using the low bandwidth option in the PostCard base setup with no change. I’ve got the PostCard base option to only send RTCM. I could cut the wires between the radio ports on the PostCard and LoRa for - Base - no receiving and Rover - no transmitting but I already have that off in the PostCard config so not sure if it will help.
As mentioned before, I typically see transmission times of 30sec while using the LoRa’s.
Any other help to get this fixed would much appreciated!
Yes, I don’t think that’s enough bandwidth to get it done. The air-speed is probably a more LoRa centric number based on bandwidth, coding rate and spreading factor, but something closer to 10 kbps would likely be more appropriate unless we can selectively drop RTCM3 packets.
A disparity in wire/air speeds shouldn’t be an issue if the device has a deep enough buffer, and the volume of data isn’t too high. High wire speeds are good for reducing overall latency in systems with larger packet sizes.
The ESP-NOW and WiFi HaLow look to be an interesting path to project base data
I’ve got both the Postcard and the LoRa powered by a USB (split cord). The Postcard is connected to the LoRa via the JST4/6 cable - picture attached
The green led’s stay lit - either 3 or 4. However in this config the Rx and Tx LEDs were not showing any data being transmitted.
I then unplugged the USB from the LoRa. That instantly changed it so that the Rx & Tx lights lit up and showed data being transmitted and received. However, it made the rover LoRa very unstable - it kept shutting off (all LEDs except power shutting down for a period) and then restarting.
So, I assume there must be an issue with trying to power the device with USB (to get 5v) and having the serial connector attached at the same time as it is confused over where the data is coming from.
And it would seem that it is being overwhelmed/unstable due to the data flow - even with it in low bandwidth base mode.
So, I agree @clive1 if I can permanently up the airspeed on the LoRa I expect that will fix it. I could try reducing the baud rate on the Postcard for the radios but I won’t be able to go low enough to not overwhelm it I fear (and 4800 is not enough anyways).
Any tips on permanently changing the baud rate on the airspeed? If I put 3.3v to the M0 & M1 pins and then power up the board that should allow me to permanently write to it?
I did some more Google searching on the LoRa issue and came up with a number of threads where people had issues with trying to use the LoRa to communicate RTCM from the base to rovers. I couldn’t find where anyone had really resolved the issues.
I was then checking the product description page and ran across the review here where a user had created his own firmware and mentioned he got them working by using this firmware and putting the radios in Multipoint mode. His description of what he did is per below (this looks like it was done by cturvey who was commenting in this issue thread on Github):
The default setting of 1-1 (peer-to-peer) vs 1-many connection causes an unstable RTK connection. It seems these devices require back and forth communication at default settings but an RTK rover only listens so the connection resets a lot. I rarely got an RTK fix with default settings. Only other challenge is the LEDs are hard to see when it’s bright out. After some searching the webs here’s my final notes for RTK use config: Custom firmware for one-way communications: SparkFun_LoRaSerial/Firmware/LoRaSerial/LoRaSerial.ino.SparkFun_LoRaSerial.bin at tinker · cturvey/SparkFun_LoRaSerial · GitHub (install using BOSSA_GUI software from sparkfun) - This custom firmware may not be required but it works. [Terminal Commands](AT Commands - SparkFun LoRaSerial Product Manual): - +++ to enter command mode - at-operatingmode=0 for multipoint, 1 for point-to-point (default). Must be in multipoint for RTK one-way communications - at-server=1 to set one as the multipoint server, leave receiver at 0. The server radio must be used on the RTK base. - atw to write settings to memory after changes - ato to reboot - att to turn on pairing (server and client) - atz to exit pairing
I tried this with the only change of making the AT-SERIALSPEED=115200 as 57600 is not supported by the Postcard LG290P.
This didn’t work - I had similar issues as before. The base worked fine, with the amber LED on the LoRa receiving data every 1sec. The Rover LoRa would continually reset every 30sec or so. It also seemed like when it reset it would take the Postcard down with it - I would always lose BT connection.
The LEDs on the LoRa would do this:
All LED’s flash on start up
Red Power LED stays on, amber LED flashes rapidly for 20sec or so
Blue LED then flashes, everything goes off and then goes back to 1.
I then tried changing the radio port baud on the Postcard and the Serial speed on the LoRa to 9600 on both the Rover and Base.
That made things worse as now both the Rover and Base are resetting - both the LoRa’s and the Postcards.
So, this is definitely pointing towards 4800 & 9600 baud rates being too slow. Unfortunately, I can’t try a baudrate of 19200 as that is not supported by the LG290P.
So, again, I am stuck. To the Sparkfun employees - @TS-Russell@sparky - I am hoping you guys have a solution for this. The Postcard page lists the LoRa as a compatible unit - I assume that testing has been done? Are you able to replicate my test and see if you can get it to work? IE Postcards connected (data and power) to the LoRa via ART3/JST?
I have submitted an issue here as it might work if I am able to permanently up the airspeed on the LoRas.
Based on the above, I disconnected the wire from the rover postcard transmit (to the rover LoRa). For extra measure, I also disconnected the receive wire into the Base postcard from the base lora.
I also reuploaded the standard firmware to the LoRa’s and set them back to P2P and retrained them. Trying to make the AirSpeed save, I had a thought that perhaps the reason why the AirSpeed always reverts to 0 (4800) is due to the underlying configuration values - it says it goes over them but… So, after doing some research, I changed the Coding Rate to 5 and the txTorxUsec to 100. The Bandwidth=500 and Heartbeattimeout=5000 are already as fast as they can go. These configs were able to be saved and stayed after power cycling. I am just going off the internet on the numbers so could be wrong but it does seem like this is faster BPS.
I reset all Serialspeeds to 115200 and then retried it.
Right away there was a significant difference in the rover lora. It was not resetting constantly. Looking at the LED’s on the Rover, the blue LED was flashing approx every 1sec. On the base LoRa the amber led was flashing appox every 1 sec. So that seemed promising.
However when I accessed the postcards via the terminal, I was still only getting a 3D Fix for state. I quickly tried the ESP-NOW radios and instantly went to a RTK-Fix state.
I turned on some more messages and noticed that while the LoRas were the comms source I was getting GNSS Rx: rtkparse NMEA GNGGA 0X0057 (87 bytes). While using the ESP-NOW radios, I was getting 0X005e (94) bytes. I am guessing the radios are truncating the message?
Anyways, unfortunately, while seemingly improving a bunch of things, I am still no further with getting these units to communicate properly.
Tried this and no improvement. The best I can get is DGPS-Fix whereas when I put it on ESP-NOW I was able to immediately get RTK-Float (not Fix however). As soon as I went back to the LoRa radios it went back to DGPS-Fix. I also tried my base message rates at 10 & 2 sec as well as 1 & 1sec with no change. Still seeing a different message being received as per above. Times were perhaps a bit better - with the radio I did see a 14sec time on the correction priorities.
I’ve been working on this a bit more with no success.
I again tried the other firmware that was uploaded by Cturvey with the other suggestions from the other thread with disconnecting the transmit wire from the rover to the lora.
Additionally, to try and get the LoRa to operate as fast as possibly, I changed the following parameters to:
TxToRxUsec=150
HeatBeatTimeout=2000
CodingRate = 5
FrequencyHop= 0
MaxResends=1
Framestoyield=1
Encryptdata=0
SerialSpeed=115200 (essentially the minimum speed that the Postcard (LG290P will accept). I did keep the LoRa’s at 57600 for one test with no change.
None of these changes helped in my testing where I was testing with only GPS and Galileo on. Everytime I would turn on the ESP-NOW radios, I would get an immediate fix. For whatever reason, it seems like the LoRas can’t transfer a long enough data and quick enough as I continually see last transfer times from 14 to 50sec.
Unless there is something I am missing, it seems like I am wasting my time by trying to do more testing and changes to make these LoRas work. Its frustrating as I purchased them with the documentation saying they would work and designed a custom enclosure to fit the LoRas and the Postcards that I was going to upload to GitHub for others to 3d print. No real point in that if they don’t work though.
Sparkfun hasn’t weighed in for awhile in this thread - not sure if they have done any testing or not.
I do think that Sparkfun needs to remove all the verbiage and pictures showing the LoRa’s as options for communications between the base and the rover as it just doesn’t seem like they have the capability to provide the required comms.
Happy to be proven wrong on any of the above or if there are other options I am missing but it doesn’t seem so at this time.
It might be a defective pair; Was it purchased from us? If so head over to Return Policy - SparkFun Electronics (contact vendor if purchased elsewhere) and we’ll get ya squared away
I’m sorry I didn’t respond sooner, one quirk I recall is I had to do a special way of saving settings or they would not stick. I haven’t turned on my postcards in almost 1 year since I went from casually surveying to running a business on top of my day job. All this to say I can’t recall how I got it working besides physically disconnecting the wire and playing with the message amounts and frequency of them. Most the time the link was killed by being overburdened. I also ran battery power straight to the lora to boost voltage but that came later.
