Missing “collection start” and “collection end” values in the csv export

Bug in survey: I’m missing “collection start” and “collection end” values in the csv export.

Hi @tobias-dahms,

May I ask you to share your csv files with missing values? Could you please also post Reach system report?

I only have the exported csv here. If it is necessary I can post the report later.

Hankhausen GPS DGM Test-CSV (1).zip (1.7 KB)

Might be connected to the fact that I used Reach in Single mode. Actually I was hoping to use the file (and the collection start and collection end information) afterwards to process the PPK data in Python.

Is there any possibility to use the survey future for PPK?

Looking forward to your system report! Now it’s hard to say what’s wrong.

I don’t think Single might influence.

If you mean “Stop-and-go” method, it isn’t implemented for Reach in the meantime. I wrote about it in this thread:

Simple system report
app version: 2.14.0-r0
'wifi_status, interface: wlan0':
- wifi_mode: wpa_supplicant
- ip: 192.168.xxx.xxx
  is_connected: true
  mac_address: xxx:f1:xx:xx:9e:bf
  ssid: xxx
base mode:
  base coordinates:
    accumulation: '30'
    antenna offset:
      east: '0'
      north: '0'
      up: '1.045'
    coordinates:
    - '53.1xxxxxxxxxxx'
    - '8.1xxxxxxxxxxxxxxxxxxxx'
    - '47.114'
    format: llh
    mode: manual
  output:
    enabled: false
    format: rtcm3
    path: tcpsvr://:9000#rtcm3
    type: tcpsvr
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: '1'
    '1006':
      enabled: true
      frequency: '0.5'
    '1008':
      enabled: true
      frequency: '0.1'
    '1010':
      enabled: true
      frequency: '1'
    '1019':
      enabled: true
      frequency: '0.5'
    '1020':
      enabled: true
      frequency: '0.5'
    '1097':
      enabled: true
      frequency: '1'
    '1107':
      enabled: true
      frequency: '0.5'
    '1117':
      enabled: false
      frequency: '1'
    '1127':
      enabled: false
      frequency: '1'
bluetooth:
  discoverable: false
  enabled: false
  pin: '***'
camera:
  duty cycle: 20
  enable: false
  period: 2
  polarity: true
correction input:
  input2:
    enabled: false
    format: rtcm3
    path: ttyMFD2:57600:8:n:1:off
    send position to base: 'off'
    type: serial
  input3:
    enabled: false
    format: rtcm3
    path: :9028
    type: tcpsvr
logging:
  base:
    format: RTCM3
    started: false
    version: null
  correction:
    format: RTCM3
    started: false
    version: null
  interval: '24'
  overwrite: true
  raw:
    format: UBX
    started: true
    version: null
  solution:
    format: ERB
    started: false
    version: null
position output:
  output1:
    enabled: true
    format: erb
    path: ttyMFD2:38400:8:n:1:off
    type: serial
  output2:
    enabled: true
    format: llh
    path: :2013
    type: tcpsvr
  output3:
    enabled: true
    format: llh
    path: :2014
    type: tcpsvr
  output4:
    enabled: true
    format: llh
    path: :2015
    type: tcpsvr
rtk settings:
  elevation mask angle: '15'
  glonass ar mode: 'on'
  gps ar mode: fix-and-hold
  max horizontal acceleration: '3'
  max vertical acceleration: '2.5'
  positioning mode: kinematic
  positioning systems:
    compass: false
    galileo: false
    glonass: true
    gps: true
    qzs: true
    qzss: true
    sbas: false
  snr mask: '35'
  update rate: '5'

Could this be an error fixed in 2.14? I’m not sure whether I did the survey before or after the update.

and @EarthImage Peter. ; )

Hi @tobias-dahms,

It might be possible that the survey project is old, and these values just weren’t generated. I recommend you to test it with the 2.14 version again. I tried to reproduce the issue, however, I didn’t succeed.

Please inform us about the test result!

Hi @tobias-dahms,

Did you try to collect points with the 2.14 version?

Yes, I did it and Reach too. So it might be connected to a earlier firmware.

That is good for future surveys, but is it possible to get the missing start and end time from somewhere inside the system?

Thank you very much,
Tobias

Hi @tobias-dahms,

As I said earlier, it seems time values just weren’t recorded. I’m afraid there are no ways to find it out.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.