I will try out Emlid studio. Being able to post process points automatically would be great. However, without accurate timestamps in the .csv, I fear that my problem will persist.
As stated previously, after the firmware update the lag seems to have shortened and the timestamps all appear within the time of the survey, but are still not totally correct.
To answer your questions:
Using the minute turn was just for organisational purposes. I did not base my conclusions on that. I only mentioned it because waiting for the minute the turn meant we were waited at the points we wanted to survey before starting the 15 second point collection. This was only done for the first test of the most recent 2 I sent (those of last week).
To test if there was a lag between the times encoded into the .csv and that of the solution file:
I used the timestamps in the .csv file (columns “Averaging start” and “Averaging end”) for each point. I then went to the solution file and took the coordinates collected within those times (for each point) and averaged them. The worksheets for each of the points for the last 2 tests are included in the files I submitted above previously.
I then mapped each point from the averaged coordinates based on the timestamps in the .csv and compared them to the coordinates encoded in the .csv file directly. The map of both sets of points (those written directly into the .csv by the emlid modules, and those I calculated by hand using the timestamps from the .csv and the averaged coordinates from the solution file) are on the map I also sent.
The difference between these 2 sets of points is visible along the ‘tracks’. The coordinates that I obtained using the average coordinates from the solution file occur at an earlier point along the track than the coordinates written in the .csv file. I’m sure that the timestamp in the .csv file doesn’t correspond with the coordinates listed in the .csv.
I quantified the ~15 second lag by selecting the coordinates that were grouped around the survey point coordinates in the .csv file and checking the ‘oldest’ and ‘newest’ timestamps for all close points. This is less precise…. But the coordinates of the data in the solution surrounding the ‘survey’ point (as written in the .csv) correspond with timestamps that occur roughly ~15 seconds later.
I hope that is clear… It is hard to explain all of the details in messages….