Reach M+ should maintain time marks when signal is poor

Reach Module / M+ / M2 RTK / PPK configuration
1

I use a Globalstar Spot trace on my UAV because I do long time flight over the forest and i want to be able to rescue the ariplane in case of problem.
The device sends GPS information each 60 minutes, when this happens the reach M+ loose signal and get back after some time.
Loosing geotag on some pictures is not a problem but it happens that when some pictures have no GPS fix, the GPSpost loose its time marks and does not count that like zero or weak, the result is a different number of time marks and I am not able to know what pictures corresponds to the positions I get from the post processing.
Is there a workaround to keep no fix positions in the *_events.pos file?
Thank you

image
image.png2280×1009 236 KB

In the image a test flight with Spot Trace setup at 5 minutes interval

2

Hi @lanzo,

Can you please share the GNSS selection and update rate you set up on your Reach device?

You can find this info in the ReachView RTK Settings tab.

1 Like
4

image
image.png1459×794 40.9 KB

Simple system report 
app version: 2.20.8-r0
'wifi_status, interface: wlan0':
- wifi_mode: infrastructure
- ip: 192.168.0.122
  is_added: true
  is_connected: true
  is_visible: false
  mac_address: 6C:21:A2:3A:1A:74
  security: wpa-psk
  ssid: UP
  uuid: 9e1bfbfc-bcff-4498-ac9a-40f62fde89dd
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'
    '1010':
      enabled: true
      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: false
  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: RINEX
    started: true
    version: '3.03'
  solution:
    format: LLH
    started: false
    version: null
lora:
  air rate: 2.6000000000000001
  frequency: 868000
  output power: 20
position output:
  output1:
    enabled: false
    format: erb
    path: ttyMFD2:38400:8:n:1:off
    type: serial
  output2:
    enabled: false
    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
    qzss: true
    sbas: false
  snr mask: '35'
  update rate: '5'
5

Hi @lanzo,

Thanks! Your configurations look properly.

May I ask you to share the raw data from both base and rover so I can examine them and try to process as well?

1 Like
6

trianom raw_201907191845_RINEX-3_03.zip (2.8 MB) 03-no-alt.zip (621.5 KB)
Base corrected position (SIRGAS):
Lat -2° 56´ 15,7298 Long -47° 26´ 36,5232 Alt Geo 104,67 Alt Orto 130,46 UTM N9674995.751 UTM E228374.461 MC -45

7

This is from the first picture raw_201908061721_RINEX-3_03.zip (7.6 MB) 03-BASE.zip (2.9 MB)
Base corrected position (SIRGAS):
Lat -3° 59´ 37,6117 Long -47° 24´ 50,8594alt Geo 226,67 Alt Orto 251,57 UTM N 9558166.522 UTM E 231936.942 MC -45
I was using another reach module, the old one but same configuration, I have flown no more with that GPS tracker but I want to use it again

8

I am going to use Reach RTK (old model) again, the M+ burned, don’t know why but it was going very hot.
So using now v. 2.20.8 on Reach RTK
Can you please look at the files I have share? Thank you

9

Hi @lanzo,

Sorry for the delayed response!

According to the data you sent, the raw data logs from Reach M+ have a lot of cycle slips and generally low SNR. I’ll attach the screenshots.

After post-processing your files, I got 634 time marks. Would you mind specifying how many photos have you taken?

rover-log
rover-log2246×1326 609 KB
rover-log2
rover-log22246×1330 667 KB

Unfortunately, such data quality might result in the loss of time marks. The data quality is affected by many factors like environmental challenges, inappropriate antenna positioning or other receiver placement details. To learn some tips on generally improving the raw data quality, you can check out this guide.

May I ask you to share the photos of your hardware setup and the rover placement? It’d help us understand both the issue with the data quality and the overheating.

Was the receiver properly ventilated in your setup? Would it be possible to generate the Full System Report on the unit and send it to me in PM?

1 Like