Emlid

Community Forum

Reach M+ Raw Logging Error


#1

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”:
image

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'

(Michael Lambert) #2

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


#3

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


(Tatiana Andreeva) #5

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.


#6

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


#8

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


#9

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.


#10

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

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


#12

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


(Tatiana Andreeva) #13

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.


#14

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.


#15

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


#17

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 :smile: