Reach M+ Raw Logging Error

RTK_Hunter · April 19, 2019, 6:59pm

My raw log does not contain the whole session on Reach M+ with ReachView version v2.16.1. I have a Reach M+ mounted to Phantom 4 Pro with Tuffwing SnapPPK Kit. This is not in regards to the kit but effects of certain settings on the raw UBX log. I sent an assistant out to fly a site for a first little shakedown run. I pulled the raw UBX file and only contains 5 minutes of about an hour plus of data. I noticed they had on correction input from serial port and was sending two output correction streams one bluetooth and the other over TCP… Didn’t know to check. Should have been logging GPS and GLO @5hz

I am a little confused on why the session was not logged in full. I noticed when testing the other day the log did the same thing (just pulled the data) with same settings and it was on well over an hour. Would these settings have an effect on the raw log? Its almost like the log stopped as soon as the drone left the ground as I made a point to log for several minutes before launching to acquire fix. I am troubleshooting/trying to recreate the issue now. Any help is appreciated. I’ve already turned logging on/off today on several sessions and seems ok.

Here is the “flight”:

Here is the system report:

Simple system report

app version: 2.16.1-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: 8C:F7:10:19:BD:08
  security: wpa-psk
  ssid: reach:42:F5
  uuid: 201fb5df-a99c-4e59-80b0-28372fdb9249
base mode:
  base coordinates:
    accumulation: '2'
    antenna offset:
      east: '0'
      north: '0'
      up: '0'
    coordinates:
    - '0'
    - '0'
    - '0'
    format: llh
    mode: single-and-hold
  output:
    enabled: false
    format: rtcm3
    path: tcpsvr://:9000#rtcm3
    type: tcpsvr
  rtcm3 messages:
    '1002':
      enabled: true
      frequency: '1'
    '1006':
      enabled: true
      frequency: '0.1'
    '1008':
      enabled: false
      frequency: '1'
    '1010':
      enabled: true
      frequency: '1'
    '1019':
      enabled: false
      frequency: '1'
    '1020':
      enabled: false
      frequency: '1'
    '1097':
      enabled: false
      frequency: '1'
    '1107':
      enabled: false
      frequency: '1'
    '1117':
      enabled: false
      frequency: '1'
    '1127':
      enabled: false
      frequency: '1'
bluetooth:
  discoverable: false
  enabled: false
  pin: '***'
camera:
  duty cycle: '20'
  enable: true
  period: '2'
  polarity: true
correction input:
  input2:
    enabled: false
    format: rtcm3
    path: ttyMFD2:38400: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: true
    version: null
  interval: 24
  overwrite: true
  raw:
    format: UBX
    started: true
    version: null
  solution:
    format: LLH
    started: false
    version: null
lora:
  air rate: 2.6000000000000001
  frequency: 868000
  output power: 20
position output:
  output1:
    enabled: true
    format: nmea
    path: bluetooth
    type: bluetooth
  output2:
    enabled: true
    format: llh
    path: :9001
    type: tcpsvr
  output3:
    enabled: true
    format: llh
    path: :2014
    type: tcpsvr
  output4:
    enabled: true
    format: llh_ext
    path: :2015
    type: tcpsvr
rtk settings:
  elevation mask angle: '15'
  glonass ar mode: 'off'
  gps ar mode: fix-and-hold
  max horizontal acceleration: '1'
  max vertical acceleration: '1'
  positioning mode: kinematic
  positioning systems:
    compass: false
    galileo: false
    glonass: true
    gps: true
    qzs: true
    qzss: false
    sbas: false
  snr mask: '35'
  update rate: '5'

michaelL · April 19, 2019, 7:16pm

Did they verify that the battery wasn’t dead before they unplugged it?

RTK_Hunter · April 19, 2019, 7:39pm

Yes, power was good. Still had juice this morning.

tatiana.andreeva · April 22, 2019, 9:34am

Hi @RTK_Hunter,

Could you please update ReachView to the v2.16.2?

I’d also recommend you to change the cable you use to power the unit and check if the behavior persists.

RTK_Hunter · April 22, 2019, 4:55pm

@tatiana.andreeva Thanks, will update today. Will log throughout the day and see if I can notice a power issue.

RTK_Hunter · May 1, 2019, 10:37pm

Time has not allowed for a proper investigation but will return and report back.

RTK_Hunter · May 22, 2019, 5:33pm

Recreated same error last night. I logged for about an hour (55:43). When I went to turn off logging it again saved only (1:43) worth of data. Working on testing on various versions of Reachview but it appears to corrupt the raw log file during save command.

bide · May 23, 2019, 5:38am

How much disk space is showing available in the logging tab?

Have you tried to retrieve the contents of the logs directory over SSH?

RTK_Hunter · May 24, 2019, 12:07am

@bide disk space is plenty sufficient. I will post some more later tonight or tomorrow. I’ll try over SSH, thanks.

tatiana.andreeva · May 24, 2019, 7:28am

Hi @RTK_Hunter,

If the issue appears again, please also generate the Full System Report before you shut down the unit and send it to me in PM.

RTK_Hunter · May 24, 2019, 2:51pm

Will do @tatiana.andreeva. I have updated version to latest development build. Have not had chance to log. I know not as stable but have other Reach M+ in my fixed wing that I can move back and forth easily. Will test later today off to fly said fixed wing now.

RTK_Hunter · May 24, 2019, 10:22pm

Today it worked or at least saved the log in its entirety. Will be analyzing the results later. thanks.

RTK_Hunter · June 12, 2019, 4:39pm

I went to 2.18 after reflashing firmware, something was off and was definitely buggy. I got functional and raw logging worked and saved in entirety, timemarks too it appeared.

Unfortunately, we had issue with drone on last flight. The drone has yet to come home and there is a new Reach M+ out there with it. I guess we will never know if it was truly fixed

RTK_Hunter · July 11, 2019, 9:50pm

My drone came home today with my Reach M+ in pristine condition. Been in a tree since June 5th. Finally, fell out a few days ago so it could be found!

RTK_Hunter · July 12, 2019, 6:38pm

Logging error still persists. I will SSH into Reach and see whats going on.

This should be at least 2-3 hours of logging… I only see 953kb in the .zip. It is not saving correctly and in its entirety.

tatiana.andreeva · July 15, 2019, 12:57pm

Hi @RTK_Hunter,

This seems very strange.

May I ask you to describe your step-by-step actions of saving the raw data log before you turn off the unit? Please advise if you follow the next sequence:

Disable raw data log recording
Wait until data processing finishes
Turn the unit off

RTK_Hunter · July 15, 2019, 8:25pm

Hello @tatiana.andreeva. I follow this generally on every logging session. In the case of the last flight this was not the case as the drone was in tree. The Reach shut off when the onboard battery died.

For all other instances I turn off logging, let process, then power off. Can clarify “wait until data processing finishes”? Is there any way to not do this and it show up in the log directory?

tatiana.andreeva · July 16, 2019, 2:17pm

Hi @RTK_Hunter,

I’m currently trying to reproduce your issue (unsuccessfully till now). It’d be great if you may answer a few questions and accomplish some tests as well.

Have you got another Reach M+ unit to check if an issue remains with another device?
Could you please generate the Full system report and send it to me in PM?

I suggest trying the following tests:

The 1st test

Put the unit to record a log for 40-50 minutes
Disable raw data recording once it’s done
Wait until data processing finishes
Disconnect unit from the power
Power the unit on and check whether logs are presented
If yes, try to download them and check whether they are correct or not

The 2nd test

Put the unit to record a log for 40-50 minutes
Disable raw data recording once it’s done
Wait until data processing finishes
Power off the unit from ReachView
Disconnect unit from the power
Power the unit on and check whether logs are presented
If yes, try to download them and check whether they are correct or not

The 3rd test

Put the unit to record a log for 40-50 minutes
Disconnect the unit from the power once it’s done (don’t switch the logging off)
Power the unit on again and check whether logs are presented
If yes, try to download them and check whether they are correct or not

The 4th test

Put the unit to record a log for 40-50 minutes
Power off the unit from ReachView once it’s done (don’t switch the logging off)
Disconnect unit from the power
Power the unit on and check whether logs are presented
If yes, try to download them and check whether they are correct or not

It’ll help a lot if you may check all these scenarios so I can compare it with the results I’m getting.

RTK_Hunter · July 16, 2019, 3:49pm

Thanks @tatiana.andreeva I will start going down the list!

I do have another Reach M+ on fixed-wing and that unit has had no issue, regardless of how saved. I will send full system report via PM. Please allow a few days for me to complete these tests on my end, thanks for assistance.

dmitriy.ershov · July 16, 2019, 3:50pm

This is becoming really interesting. Thanks for making tests!