I’m running 2.22.4 on two Reach RS+ receivers that are about 1.2 meters apart from each other with a clear view of the sky. I’m mostly leveraging 2 receivers for heading. I’ve started using the altitudes for roll compensation. One of the receivers started reporting an altitude shifted by about 10cm occasionally.
You can see the altitude signal jumping around at the beginning of this plot. This is from the LLH file
I wasn’t operating the machine but it was reported that this problem occurred for around an hour. At that point we rebooted the receiver and the altitude was correct again.
During this time the lat/lon was correct and we had fix level quality.
Can anyone explain what is going on that would cause the lat/lon to be correct with RTK Fix but would cause the altitude to jump around?
I can provide any additional logs from the base and the receiver tomorrow. I’m interested in learning how to analyze these logs and determine the root cause myself when possible.
Processing didnt show any abnormal height difference.
What setting did you use? How is the rig build? picture?
Could one be affected by multipath somehow?
Thanks for taking the time to analyze these logs. Were you able to see the changes in altitude as shown in my plots or did the logs shows the altitude as steady?
When you ask what settings did I use which settings are you referring to? The receivers are basically factory default and then I followed guide on Emlid’s support site to configure RTK over LORA. I’m using GPS, Galileo, Glonass.
The receivers are the tallest point on the machine. We are out in the middle of a field so I wouldn’t think anything would be causing multi path issues but I’m not an expert.
Given the problem went away after rebooting the receiver doesn’t that point to a software issue?
We had a similar occurrence of the problem happen yesterday. Coincidentally it occurred at the same time it started raining. I’m not sure if that is the cause.
The machine is under development so I can’t publicly post pictures of the entire machine.
Any other thoughts? We hope to move to using an IMU but I’d like to understand the root cause as we would like to fuse the 2 together long term. I also would like to understand what would cause the altitude to be incorrect but lat/lon to be correct.
I am assuming your plot if from a RTK solution? Hence the RTK settings used. Elevation mask angle, fix&hold ? etc
You can verify both units runned the same firmware with the same setting right?
If its a multipath or noise issue, reboot doesnt make it go away, its just reconverge its numbers and start over. A single change in the RTK setting would do the same.
If its a recurring problem with the same unit (and not the other one), you should try swapping places and see if the other unit produce the same issue.
Sorry. When I said “factory default and then followed their guide” my intent was that the settings could be assumed default. To clarify the elevation mask was 15 deg and the SNR mask was 35. The acceleration limits were 1 m/s^2. Kinematic, Fix and Hold, Glonass AR On. GPS, Glonass, Galileo.
I did a little research on multipath and I have a better understanding of what it is. Given how my receivers are mounted on 4ft poles on top of the machine I don’t think it is a multipath issue. We are in an open field so there is nothing that it could bounce off of.
I’m new to the idea of post processing…Is there additional logs (corrections RTCM3 maybe) that would help shed light on the problem? Shouldn’t we be able to reproduce the altitude jumps in the LLH file with the raw data? Or am I missing something where the correction would be applied different live then when post processed?
Thank you.
And both recievers runned latest firmware? I ask because recent version have improved RTK engine, specially latest DEV version.
Sure, reduced some functions made this result. A combination of old ephemeris data and fix&hold. Using continous would avoid this but then lose feature of Fix&hold.
From the record it looks like GPS renew its ephemeris every 2 hour and by processing after 2000 hours you would avoid bringing old data into the loop with Fix&hold thus not having such jump late in the ephemeris session.
The rovers are both running 2.22.4. I need to check the base. If I remember correctly I was struggling to get it to update so it is on an older version.
I’m moving at 4 inches a second for days at a time. I have about 4 inches of forgiveness side to side before bad things happen. In this scenario am I better to use continuous or fix and hold? I read your thread Fix & Hold vs Continuous. Ignorance is not bliss on the topic and it isn’t clear to me which is better in my application.
Forgive me, I didn’t understand that. Can you dumb it down? Is there anything actionable to take away from it?
Definitly keep them up to date, and if possible try the dev version (no roll back function yet)
See if this resolves fixed Shift, also try swapping place between the two rover to see if location is an issue.
Few questions. Do you run the same track every time or a new location every now and then?
Do you need continous RTK for several hours at the time, with no break?
If Continous mode works, use it. Do you have a function stopping the vehicle if Float?
Yes. Our track/path is the same every time. We need continuous RTK for several hours/days at a time.
We stop the machine if either receiver goes to float. There is a semi high cost to stopping. We have to wait 5 minutes before starting back up due to mechanical limitations in other systems.
