Hi Andrei, I’ll do my best to explain what I think I was doing (it’s still a little technically unfamiliar to me). So, I have one BASE and one ROVER. The BASE was located using an CRTN network to average it’s position, which was never turned off in the base. I’m assuming that’s ok, because I was told once the base starts broadcasting, it ignores any incoming corrections to itself and just acts as a static base. Once my rover was receiving the new broadcast from the base, I just let the logs record. Almost immediately (after the base began broadcasting) I realized I was still having trouble so I swapped the LoRa antennae. Up to that point, I had only swapped the cables, keeping the same LoRa with the same M2 unit. Then, I decided to swap the LoRa around so that they are with a different M2 units. I had never done that combination before till that day. So to be clear; in the end, I swapped the cables along with the LoRa antennae and attached them to the opposite M2 units. When I sent the log files I sent all three logs from each unit for a total of six. I understand that you may not need all 6, but I wasn’t sure, so I sent them all from both Rover and Base. There was no third unit acting as a rover. Also, I should point out that my rover appears to have a BASE mode going on in the back ground, but I think I turn that function off and just ignore it. The six files should be notated with a BASE_ and a ROVER_ for each file to make it clear. I assumed what ever files you didn’t need would be ignored. I apologize for the confusion as I am still new to this and I hope I am able to be clear. Thank you for taking the time.
EDIT: After re-reading your questions it occurred to me that maybe what you are seeing is the BASE receiving RTCM from the CRTN network the whole time in the back ground and that log seems to be healthy (which I assume would not be taken into account while the base is broadcasing it’s position after averaging). It would be the other log from the Rover that I am having trouble with. I’m speculating at this point so I don’t know if this comment will be of any help. Thanks!
Hi Andrei,
Yes, for the most part. I’m not sure if the cables have taken a beating or which one it would be (I have new ones coming). There doesn’t seem to be a change in behavior when I swap them around. Also, I have the problem at all times, it’s just in and out. Usually when I start up, it looks fine and then 30 sec later it drops out. So, it’s never right away, usually during start up, it’s ok for at least a half minute. Everything else sounds correct.
EDIT: I do have GPS bars alone frequently, as if the other corrections are being dumped to maintain GPS.
I am updating this thread to share some progress that I’ve made. Using the original cables I ran a new test on my system. 1. I updated the firmware which was recently released. 2. I am using a new set of batteries. Interestingly, my old batteries would lose voltage when I plugged them in to the M2 units (down to 4.78 volts) whereas these new batteries remain at 5.0 volts. This combination seems to have helped with my issue a little. I am still having some dropping out of certain constellations (at the moment Galilieo) but it is operating better than before. I did also switch on legacy RTCM 1008 which seemed to help somehow, but this might be a coincidence. I am going to run some tests and prepare log files and update again.
Thank you for the new data! It helped me to understand the LoRa performance a lot.
I’ve checked your new logs. Raw data looks good. However, LoRas still don’t work as expected.
LoRa radios are low-powered radios and can be extremely sensitive to local interferences and obstructions. In most cases, default settings work fine, but sometimes you need to tune them to make it work in your particular area.
There are 2 LoRa settings that can affect:
Air Data rate. The lower the Air Data rate is, the wider the range should be. However, with the lower Air Data rate, you need to reduce the amount of transmitted data. I recommend you try legacy messages with 9.11 kb/s and then with 4.56 kb/s and check if the reduction of the rate changes something.
Frequency. In ReachView 3, the frequency range is limited according to your local regulations. However, even if the frequency is allowed for common use, there can be other devices in some areas that work on the same frequency, which creates difficulties for LoRa. To check it’s not the frequency issue, you need to test different values. I recommend starting with the maximum value and then going down with a step in 1-2 MHz to find out the frequency that works best in your area.
You most likely have already done it, but just to make sure we nailed down all the possible roots of the error: check that LoRa antennas are screwed tightly enough and directed down.
Your not going to damage it by shorting it if that is the nature of the question. For signal propagation you want as clear a line of sight as possible between the two radios for maximum distance.
Things that decrease signal fast, hills, trees, fog, cars and buildings.
Hi Andrew. Thanks for getting in touch. I did conduct a test today. I was prompted to update the firmware on both M2 units. Once that was complete I began setting up the LoRa antenna and I noticed there was a new message stating “Too many RTCM3 messages”. I reduced the constellations down from four to two and then I was able to use LoRa. That was the first time I had seen that, and I assume it is a feature of the new firmware. I would like to ask the following; 1. Is this a condition of the LoRa antenna that they simply cannot transmit the complete set of constellations RTCM3 data? 2. Is this just my units because there is a malfunction, or is it a product limitation? And 3. Is there someway to upgrade or does Emlid plan on somehow providing a stronger antenna that can transmit the information for all four constellations in the future?
I am currently under the assumption that to receive all four constellations, I will have to rely on NTRIP, and therefore cellular/wifi connection. Thanks again for the time working on this issue.
We don’t have limitations for our products. “Too many RTCM3 messages” message appears when the air data rate is too low to transmit all messages. You can raise it to 18.23 kb/s to allow all messages to be sent.
There is no need for you to rely on the NTRIP only. You can use LoRa to transmit correction messages from all constellations.
Please note that the baseline may shorten with the high air data rate.
Let’s keep an eye on your units. Just drop me a line if the LoRa loses a signal again.