Just to update, I went ahead and ordered the cables per the advice from Emlid Support Team (thank you!). Here is a link directly from another thread describing the cable for those that are looking for the part.
I’ve checked the data from July 9.
RTCM log with time mark 18:32 looks good instead of RTCM log with time mark 18:31, which has multiple breaks in the data.
However, you’ve sent two sets of logs, so I have some questions:
Can you please elaborate on how you’ve recorded two RTCM logs simultaneously? Do you have two rovers?
Can you please elaborate on which log is made with cables swapped and which one is with LoRa antenna?
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!
Thanks for the explanation!
To summarise, we have the following:
- Grey bars in the Status window of the rover are not visible frequently
- RTCM corrections drop off from time to time
- RTCM corrections work fine with the NTRIP connection
- One of the cables has taken a beating, and you’ve ordered new cables
- the base unit has corrections input from the CRTN enabled
- the rover has base mode enabled
Can you confirm that all statements are right?
Can you please also confirm that you have this LoRa behavior from the first try of setting up?
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.
Thank you for the explanation!
At this stage, there seem to be 2 possible reasons for why it happens:
The LoRa module itself may cause this behavior
Cables may also affect transmission if they are damaged
That’s why I’d suggest checking if changes to the cables will help first. If this will not help, we’ll find a solution for you.
Keep us posted.
Thank you. I’ve got cables coming and will update you guys as soon as I know. Thanks!
I am having difficulty locating the correct cables to order. Is it possible that you could direct me to a source? Thanks for your time.
When I connect M2 to rtcm3.0 from trimble base I get the bars, using 3.2 i do not, the info is probably just not being sent.
m2 runs at 50-55C during normal operation, measured with an infrared thermometer.
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.
Keep me posted.
Is that a must ?
On the rs2 its down due to packaging.
Up is usually better. But getting it as high as possible applicable to the job for a clear line of sight is #1.
Does it matter if the antenna are touching other objects, like the aluminum leg of a tripod, or the mesh of a canvas bag?
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.
I think a better term is vertical.
The LoRa antenna shouldn’t touch metallic details. They can affect the signal.
How are you doing?
Have you conducted any further tests with your M2s?
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.
Finally! I no longer have to explain this! Thank you emlid!