I have noticed that the Reach’s altitude can take a few minutes to settle to within half a meter of accuracy compared to the base station altitude while both on the ground. Also, I had an incident where I walked towards the copter flying at 3 m and the Reach altitude dropped 10 m, which caused the copter to climb 10m to compensate. (My GCS updated the waypoint’s altitude to compensate for the lower predicted altitude to hit the target altitude of 3 m.) It appears that 1 satellite dropped out of the solution. Went from 9 to 8 right before the drop in altitude.
The Reach is GPS2 in this plot:
It looks like it was slowly recovering, but I landed the copter to reset the GPS. What factors would help speed up the altitude prediction of the Reach and prevent rapid jumps like I saw in flight? Should I use continuous mode or fix and hold mode? It looks like it might help for USA locations to only use GPS satellites rather than both GPS and GLONASS satellites, have others found that true?
BTW, I am also using 10x10 cm copper ground planes for the base and rover.
(I have RTCM3 and ublox logs, but not Rinex. I’m having mixed results with the converter.)
Could you share your logs, please?
I didn’t save the Rinex files only correction*.RTCM3, raw*.UBX and solution*.ERB on the base and rover. Can you work with those? I tried using rtkconv, but it didn’t want to generate the rinex files.
Yes, raw logs will be fine. Also, what app version was that? Please also upload ardupilot logs.
Here’s the Arducopter log file:
210.BIN (6.0 MB)
I’ll upload the raw ublox files next. Since I can’t look at them, I’ll be guessing at which log file corresponds to this test case.
I believe the glitch happened around 3:00 PM CST, but I included all of the log files for that day just in case the times were off.
What’s the best way to view this data?
Here are the logs for the base station and rover
I’m using the latest app version: 2.1.5
I’m guessing that its raw_201612142031.UBX or raw_201612142047.UBX
My initial impression from a systems standpoint is that I would expect the main problem to be interference from something associated with changes in prop motor speed. Your data shows interference to barometric altimeter and GPS when there are rapid changes to motor speed.
Make sure there are no common ground returns from motor and sensor circuits including GPS.
Basic systems designs include shielding of all transient producing circuits and leads. Sensor circuits are always best powered by separate power leads and grounds.
I have no idea what your actual wiring looks like, but I would look there first. I would not be inclined to suspect software first.
Second, it appears that the GPS response time is slower than the barometric sensor response time. I’m not sure what parameters adjust the Kinematic response, but this would most likely be different for each device.
I’ve processed your logs and could say that it’s hard to find glitch, because there’s no base pair for raw_201612142223 rover file.
Here’s what I can see at around 3:00 PM CST.
Also you use only GPS satellites, try to turn on GLONASS next time.
And I’ll be really thankful if you’ll send set of rover & base logs for one time in the future
Thanks! I’ll delete all my logs next time before I start. How did you convert to the Rinex format? If I could get timestamps out of the files, I could better correlate with what I saw in the Arducopter log posted above as well. The Arducopter log has GPS time, but I’m not sure what it date/time its referenced to. (midnight of January 5th 1980?)
I turned off GLONASS since it appeared that I was getting better solutions with just GPS based on casual observations.Will more satellites make it more robust or add more variability - how does more satellites impact the time to solution?
You should use RTKCONV from this post to convert raw logs to RINEX.
Try to do it with RTKPOST. You could find it in the same post.[quote=“rrr6399, post:11, topic:4608”]
how does more satellites impact the time to solution?
In some cases it could help to lower time (ex. small amount of GPS satellites), but it has more effect on robustness.
Which messages from the base station does the rover use for processing the RTK solution?
1002 GPS L1 observations 1Hz
1006 ARP station coordinates 0.1Hz
1008 Antenna type 1Hz
1010 GLONASS L1 observations 1Hz
1019 GPS Ephemeris 1Hz
1020 GLONASS Ephemeris 1Hz
1107 SBAS 1Hz
1117 QZSS 1Hz
1127 BeiDou 1Hz
I’m only sending the RTCM3 1002 and 1006 messages now.
I figured out how to convert the GPS2.GMS time from the ardupilot log into UTC. Looks like its GMS is seconds of the current GPS week. The glitch occurred at GMS=334865 for the week of 12/14/2016, which ends up being: 21:01:05 UTC.
(Used this handy converter: https://www.labsat.co.uk/index.php/en/gps-time-calculator )
I noticed one satellite’s SNR was oscillating around the glitch time:
What levels of SNR are needed by the base station signals. Here is what I’m seeing:
I’m curious about whether you found a solution for this problem. Hopefully, you have as I’ve seen later postings by you.
I just felt I should point out confirmation that motor transients can cause problems. See RTKExplorer blog on “RTKLIB on a drone with U-blox M8T receivers” posted a day or two ago. There is also a description for testing the drone tethered to earth.
Although you may have found a different cause in your case, I felt I should pass these results on to the Emlid Forum.
Turning high current devices ON and Off generate tremendous rf transients compared to weak GPS signals. The first step in eliminating this problem is to move antennas or receivers as there is no weight penalty. If that fails, try shielding cables, etc. Slight weight penalty. Be careful not to shield Reach module WIFI antenna. Finally, placing a small capacitor plus resister at motor control lines can help. The capacitor should end up being rather small, so ,fortunately there should not be be too much of a weight penalty. Too large will create excess motor current with risk of overheating motor drive components.
Search internet for “motor transient suppression”.
I thank you for this post as it is a good example to illustrate what the Emlid group has said many times. Thank you for the opportunity to illustrate this often overlooked system design problem.