So far, I’m getting awesome results with my Reach unit mounted on a fixed wing, but its been hit and miss with a quad rotor, I thought the results would be the other way around. I’m going to double-check the settings and software versions on both Reach units to see if there’s any differences, but I ran both of these tests with GPS only at 10Hz on both Rovers, and I’m correcting both Rovers to a Survey Grade Dual channel base unit running at 5Hz.
The fixed wing ground track and corresponding cycle slips are on the top, and the quad rotor and its cycle slips are on the bottom, what I need to figure out is why the cycle slips for the quad correspond to all satellites at the same point in time, its like its choking on the data, simply can’t write to memory fast enough or something, not sure whats causing the long data gaps.
I think I found the problem, in comparing the settings on the two reach units, both are running the same software version, only difference was the positioning mode for the fixed wing was set to single, the quad rotor was set to static. I’m not doing RTK, just post processing both to the same base unit, so will change the quad rotor to single positioning mode and give it another try.
Happy to hear you have good results!
The single/static mixup only matters if you use RTK, because the logs are saved unprocessed. What version of RTKPOST do you use?
Hi Egor, I’m using RTKPOST v2.4.2, (Emlid patched version) being I need to extract time events with a camera hotshoe, that reminds me, is anyone working on adding the IMU data to the time marks yet? I looked into writing the code myself, but just don’t have the time, and I found the easier solution for now is to just extract the IMU data from my Pixhawk, it works for now, but would much prefer to get all the exterior data from the Reach.
Ok, good to know the single/static setting doesn’t matter when post processing. I think I may have figured out what the issue is, it might be vibration related, I’ll try to secure the antenna mount better on the quad, I had to build a custom mount for it, that’s really the only difference I can think of, when I have the same antenna mounted on the fixed wing, the mounting is very secure. I’m also testing an antenna that’s different from the stock antenna, its a larger, heavier Tallysman with an excellent ground plane.
I think, that first you should try our newer version of RTKPOST, which is based on a recent beta. We had a cycle slip related bug fixed.
Ok, I re-ran the above posted flight with the 2.4.3 b16 RTKPOST, it processes much faster, but results are similar:
I still think I have a vibration issue with the antenna mount, will get that secured better and will do another test flight.
I flew the same test flight today after securing the antenna mount better, and very good results, all fixed solutions for the short flight lines at 200FT(left side of ground track), the only float solutions occurred on the right-hand side of the track where I was flying only 20FT above the ground, just to see if there would be any difference in the cycle slips, note the corresponding cycle slips on the right. Very windy conditions today and gusty, the quad was bouncing around a lot more near tree-top level when flying at 20FT being there are rows of trees on both sides of the flying field.
So, the only thing I did different is make sure the antenna is mounted as securely as possible, and maximized vibration dampening with a 2" piece of EPP foam. I also processed with RTKPOST v2.4.3 b16
I’m going to try some PPK processing this week, and this comment caught my eye. I plan to set up my base over a known point, and try to test the RTK setting as well. My Rover will be set to Kinematic in this case.
I figured I would use the base data for one round of PPK, and local CORS/CACS data from a station with a rather long baseline to see how they differ, and also see how they differ from the RTK results.
The question is, will I actually be able to use the Raw data from the rover (Using RTK mode) for PPK, or would I need to perform another survey with the Rover set on Single or Static? (Based on your comment above it seems that either would do)
If you’re running the newest version of the firmware, the mode doesn’t matter at all, you still end up processing the raw log from the rover with the raw log from the base.
I would make sure your Reach units are updated to the newest version being there was a log corruption issue not long ago that was fixed, and turn off logging for all logs that you don’t need, I think that helps as well to avoid the log corruption issue.
So does this mean that the raw RINEX log files I get if I am doing an RTK survey are not the real time corrections?
I meant the mode doesn’t matter at all for PPK processing, I don’t have a need to do any RTK processing with the Reach unit, so can’t comment on that.
A post was split to a new topic: Issue