Hi,
we are flying a drone with an M2 strapped on top to track the flight path. Unfortunately I can’t go into detail about how we are doing it, but it seems that we might be seeing an acceleration dependent shift in the location data of the M2 vs. the real position. I would think of it analogous to pulling a rubber band fast or slow.
Now, disregarding other possible error sources here (we are still evaluating our data), has anyone tested and proven how fast you can accelerate or decelerate with the rover, before seeing an offset of the recorded M2 position vs. the real position?
The shift we see could be as high as 2 seconds after taking into account GPST vs. UTC-0 (all clocks are satellite synced before the flight). We are (only!) flying between 0m/s and 5m/s back and forth several times and the shift – if true – could be as high as 6-8m, which I honestly find hard to believe.
So Ideally, EMLID or some other smart people here can present convincing arguments that my fear is unfounded and I can rule out this error source and rely on the M2s position logging at up to insane accelerations 
Here are two screenshots from ES. We are setting the “Filter type” to Combined (back & forth processing) and the “Integer ambiguity resolution” to “Fix & Hold”. Would you say those are reasonable settings for a dynamic flight?
Thanks for your input on the matter!
Vincent
1 Like
Hi @sunny.droneman ,
The time mark pin on our devices is connected directly to the GNSS chip, which allows you to collect the time marks with nanosecond accuracy.
How much offset do you see? Also, what device do you use as a base? Or do you get the RINEX observation file from a CORS? Further, were the known coordinates manually entered under the Base field, or was it taken from the RINEX header?
1 Like
Hi Ruth, the device combinations is M2 & RS2+ and the offset we are seeing is a delay of about 2 seconds, that translates to different spacial offsets.
As mentioned before, I can hardly believe it really has to do with the precision of the hardware and your nanosec comment add to that. It’s just, I have no feeling for how stable & precise the M2 will track its own position even at hard accelerations (assumption: PPK!) and I need to rule that effect out.
It would be great to have some kind of reference, where between the speed of 0.1m/s and lightspeed a moving M2 will become unreliable - even (or ‘especially’) if that info sets that fear to rest forever
From your comment I’m assuming that in FIXed PPK, I can pretty much bank on the position as a ground truth and any error has to come from some other source - as in our case, this is what seems to be emerging the more we dissect the data.
I’m not sure I understand the issue. How did you determine that there is a delay of 2 seconds? Did you check the timestamp from the RINEX obs file, or are the photos shifted by a certain distance when you geotag them?
The recording of timestamp vs acceleration is not correlated. Reach M2 saves time marks when it gets the shutter signal. At the same time, if you set the GNSS rate at 10Hz and the logging rate at Full rate, you will have ten measurements per second.
1 Like
Well, we kind of know what we should be seeing in a drone image at what point in space. And what we were seeing was shifted in space about 2 seconds worth of flight time. Can’t go into details though
We did find the real mistake though, it was in our code. Somewhere there was a wrong timestamp selected & passed on. That one had a 2 sec delay to the correct time, just as predicted.
We saw a similar effect (shift), before we realized the different export options of UTC and GPST. That one also gave us a shift, but it came from our data processing.
This project is quite the learning curve 
Debugging isn’t always straight forward, especially when the error can also come from the real data that you produced 
Hi @sunny.droneman,
I’m glad that your team was able to figure it out in the end! 
