I’m trying to use Emlid stop and go. the time covered by my rinex records does overlap those in my .csv file of points. However It looks like the rinex maybe in UTM and my csv file in UTM-4 (local time). is there an easy way to get them to alight to the right time zone? I’m getting the message “Point timestamps cant be converted” if I edit the times. If I don’t edit the times nothing converts.
Yes, the time covered by base RINEX files has to overlap with the rovers for any PPK workflow in Emlid Studio. As a workaround for your case, can you try downloading the base file logs that will coincide with the time zone set on your rover?
You mentioned your CVS file is in UTM-4 (local time), so you should start by adding 4 hours to your rover’s time when selecting the base logs.
So the logs do overlap, however have different time zones which emlid studio doesnt seem to recognise so the software isnt seeing any overlap. The problem was how to format the cell after manually correcting the local time to UTM. It seems it requires " UTC-00:00" at the end of the timestamp.
I did discover though, that you can re export the survey data to csv from emlid flow with a device that is in UTC timezone. this then provides updated timestamps.
This really helped, however i noticed in a second set of test data that it still wasn’t finding a match. In lookin at the po file i noticed that the rinex data was at 10Hz but started at 0.008 seconds. the csv only had one decimal place, so couldnt find an exact match. I assume this is why the instructions say to average the point. i changed the end average time by .1second and that solved it. So in future we will average a point. to get around this issue it only needs to average by 1second but im now feeling a bit uncomfortable about the difference between UTC (csv file) and GPST (18 seconds difference i gather at the moment). If the csv file from flow is truly UTC then if this is not corrected studio will match it with the wrong rinex record.
If studio cant recognise that the csv is in UTC-4 and correct it, i find it hard to believe that it will correct between UTC and GPST.
Equally, it seems surprising that the UTC is infact used at all, i suspect that the csv is actually GPST with some sort of hour correction based on local time? In which case the 18s doesnt need correcting for?
We will average points in future for 20seconds to try and account for any differences between GPST and UTC. If anyone can confirm the correction is made, or isnt needed then we will probably just average for more like 5-10 seconds to make surveying easier / faster.
Emlid Studio should parse the time zones in the CSV correctly. You do not need to edit the time zone or change to GPST; Studio will do it.
To investigate further, could you please share with us the original(unmodified) CSV along with the raw data logs from the base and the rover? I need the RINEX observation and navigation files.