Timestamp inconsistency (survey points vs logs)

Hello All,

I am seeing an inconsistency in my timestamps between my survey points file, and the logs on my base and rover.

I have recently begun testing the EMLID reach modules, and have a question about applying PPK solutions to my survey points.

As I understand it, applying the post processing only concerns the kinematic data contained in the raw logs on my base and rover. I would like to impose the corrected coordinates on my collected survey points.

To do this I am creating a python program, which uses the timestamps from the survey points and the solution file (after post-processing), extracts and averages the coordinates from the solution file and applies these coordinates to each survey point.

The problem is that the timestamps don’t match

  • There is a time zone difference of 2 hours (which I can correct for), this is normal and due to timezone difference.
  • There is a difference of up to between 30 seconds and 2 minutes between my survey points times and my rover times (Can’t easily correct for and seems weird!).

Where does this inconsistency come from and how can I fix it?

I conducted a short test collecting 4 points. For this test I stayed in RTK over LoRa.

  • Step 1, turn on base and enable data logging
  • Step 2, turn on base and enable data logging
  • Step 3, begin collecting survey points (4) while walking around campus with rover module. Point collects are a 15-second average.
  • Step 4, Return to starting point and turn off rover
  • Step 5, Turn off base.

^^Obviously, the end of my last point collect (15 second averaging time) must be within the time of my base rover logs. However, it is not.

Thank you in advance, any advice is appreciated !!
-Zoe

Specs of my set-up :

  • 2 Reach RS2 modules set up and base and rover in RTK over LoRa (staying in RTK until I can figure out the timestamp problems)
  • ReachView version: v2.24.2
  • Survey conducted points collected with the Reachview app on Iphone SE (software version 14.6)

System report base module
:

Simple system report
app version: 2.24.2-r0
'wifi_status, interface: wlan0':
- wifi_mode: ap
- access_point:
    band: bg
    channel: 1
    password: null
  ip: 192.168.42.1
  is_added: true
  is_connected: true
  mac_address: 6C:21:A2:BF:B8:22
  security: wpa-psk
  ssid: baseRS2:B9:9D
  uuid: 3e0728f7-bd8c-4355-b9f5-dc29c9286d00
base mode:
  base coordinates:
    accumulation: 2
    antenna offset:
      east: '0'
      north: '0'
      up: 0.0
    coordinates:
    - 45.199198694300001
    - 5.7733019131700001
    - 263.435
    format: llh
    mode: manual
  output:
    air_rate: 18.23
    enabled: true
    frequency: 870000
    io_type: lora
    output_power: 20.0
  rtcm3 messages:
    '1006':
      enabled: true
      frequency: 0.10000000000000001
    '1074':
      enabled: true
      frequency: 1.0
    '1084':
      enabled: true
      frequency: 1.0
    '1094':
      enabled: true
      frequency: 1.0
    '1124':
      enabled: true
      frequency: 1.0
bluetooth:
  discoverable: true
  enabled: true
  pin: '***'
constraints:
  lora:
    frequency:
    - - 863000
      - 870000
correction input:
  input2:
    baud_rate: 38400
    device: UART
    enabled: false
    io_type: serial
    send_position_to_base: false
device:
  night_mode: false
  power_on_bottom_connector: false
  privacy_policy_accepted: true
  usage_analysis_accepted: false
logging:
  base:
    format: RINEX
    started: false
    version: '3.03'
  correction:
    format: null
    started: null
  debug: false
  interval: 24
  overwrite: true
  raw:
    format: RINEX
    started: false
    version: '3.03'
  solution:
    format: LLH
    started: false
lora:
  air rate: 18.23
  frequency: 870000
  output power: 20.0
network:
  tcp_over_modem: false
position output:
  output1:
    baud_rate: 38400
    device: UART
    enabled: false
    format: ERB
    io_type: serial
  output2:
    baud_rate: 38400
    device: UART
    enabled: false
    format: ERB
    io_type: serial
rtk settings:
  elevation mask angle: 15
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: 1.0
  max vertical acceleration: 1.0
  positioning mode: static
  positioning systems:
    compass: true
    galileo: true
    glonass: true
    gps: true
    qzss: false
  snr mask: 30
  update rate: 1
sound:
  mute: false
  volume: 100

System Report Rover Module:

Simple system report
app version: 2.24.2-r0
'wifi_status, interface: wlan0':
- wifi_mode: ap
- access_point:
    band: bg
    channel: 1
    password: null
  ip: 192.168.42.1
  is_added: true
  is_connected: true
  mac_address: C0:84:7D:27:F2:2F
  security: wpa-psk
  ssid: roverRS2:66:AB
  uuid: 572e66f1-8448-4ee5-aa55-ff31ecbc2839
base mode:
  base coordinates:
    accumulation: 2.0
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - 0
    - 0
    - 0
    format: llh
    mode: float-and-hold
  output:
    baud_rate: 38400
    device: UART
    enabled: false
    io_type: serial
  rtcm3 messages:
    '1006':
      enabled: true
      frequency: 0.10000000000000001
    '1074':
      enabled: true
      frequency: 1.0
    '1084':
      enabled: true
      frequency: 1.0
    '1094':
      enabled: true
      frequency: 1.0
    '1124':
      enabled: true
      frequency: 1.0
bluetooth:
  discoverable: false
  enabled: false
  pin: '***'
constraints:
  lora:
    frequency:
    - - 863000
      - 870000
correction input:
  input2:
    air_rate: 18.23
    enabled: true
    frequency: 870000
    io_type: lora
    output_power: 20.0
    send_position_to_base: false
device:
  night_mode: false
  power_on_bottom_connector: false
  privacy_policy_accepted: true
  usage_analysis_accepted: true
logging:
  base:
    format: RTCM3
    started: false
  correction:
    format: RTCM3
    started: true
  debug: false
  interval: 24
  overwrite: true
  raw:
    format: RINEX
    started: false
    version: '3.03'
  solution:
    format: LLH
    started: false
lora:
  air rate: 18.23
  frequency: 870000
  output power: 20.0
network:
  tcp_over_modem: false
position output:
  output1:
    baud_rate: 38400
    device: UART
    enabled: false
    format: ERB
    io_type: serial
  output2:
    baud_rate: 38400
    device: UART
    enabled: false
    format: ERB
    io_type: serial
rtk settings:
  elevation mask angle: 15
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: 1.0
  max vertical acceleration: 1.0
  positioning mode: kinematic
  positioning systems:
    compass: true
    galileo: true
    glonass: true
    gps: true
    qzss: false
  snr mask: 35
  update rate: 5
sound:
  mute: false
  volume: 100

Can you share your base + rover data files + the csv files for a repro ?

1 Like

GPS time add 18 seg. Please send raw data

1 Like

With pleasure! Unfortunately ‘new users can’t upload attachments’ so here is a wetransfer link:

timestamp_question.zip (8.0 MB)

^^ just got moved up a trust level so here are the files !

So, using the automated tools of EzSurv, the observation you have included starts 08:16:20 UTC and lasts 15 seconds. Is that correct?

Yes.

08:16:20 UTC (10:16:20 UTC +2 = local time) is the beginning of my collection time (15 seconds) for my first of 4 survey points. The rover and base were activated before.

Thanks in advance for your help !

Your Description field looks a bit wierd, is it you that inputted 1013 etc ?

Manually editing that out, I get all 4 points, but then get that the resulting rover-obs file isn’t covering the time-stamps of the CSV file.
Is that consistent with what you are seeing?

yes, I had noticed that the timestamps were a few minutes off from my phone’s clock. i used the description field to mark the times 'but i think i missed 10:14) it was just to have a rough reference of the time on phone.

Yes, this is the crux of the problem. It means that I can’t use a corrected solution file (after post processing) to adjust the coordinates of my survey points… and is also just weird !

Can you reproduce this on Firmware 26.2 ?

I’m an intern testing the precision of the EMLID modules for a lab. My supervisors recommend that I not update the firmware because of the risk of ongoing instabilites…

If however you think that updating would solve the problem that would be an convincing argument to do so.

Are there other possibilites that I can explore first ?

I would go out and do more points, and see if it reproducible. I would assume that has been a fluke of some sort.

This happened with a previous dataset (also just a small test) but I had the same results - The survey point timestamps not falling within the raw data timestamps - The above data was a test I did to confirm that it wasn’t just a one-off.

It is very strange what you mention, with all the versions that I use I was always able to correctly process the ppk files of my RS2s.
Using RTKLIB and Pointextractor.
A few days ago I verified a measurement that I made with Sokkia Stratus L1 13 years ago and the difference with the current ppk was not greater than 2 centimeters.
Do not forget that to be able to do post-processing in PPK you must do a minimum initialization of 10 minutes, depending on the distance of your work.
There is something wrong with your cell phone, my timestamps are correct

1 Like

Ok I will try with a different phone and see if the timestamps I get are correct. I will post an update when I have new results ! I agree that it is super weird !!

1 Like

Hi Zoe,

Welcome to our community!

It seems to be something unusual. I’ll discuss your case with the team and write back.

Thank you! Monday I’m hoping to do another small test with a different phone and see if the problem persists.
please let me know if I can provide any other information to you.

Hi Zoe,

Have you had a chance to conduct a test?