Project

General

Profile

Bug #277

Base station mode: can not send some rtcm messages

Added by Youssef Aboudorra about 1 month ago. Updated 9 days ago.

Status:
Feedback
Priority:
High

Description

I am trying to use RTCM (1094, 1097, 4072.0, 4072.1) and I get input/output error when I call send_rtcm. I think they are missing from the ublox driver.

#1

Updated by Anthony Mallet about 1 month ago

  • Status changed from New to Feedback
#2

Updated by Youssef Aboudorra 21 days ago

Thanks, now the messages are sent/received.
However on the mobile-gps terminal I get these messages frequently:

RTCM messages 1097 had CRC failures
RTCM messages 1094 had CRC failures
RTCM messages (xxxx) had CRC failures
Hardware skipped (xxxx) bytes

and on the base-gps:
ring buffer full

#3

Updated by Anthony Mallet 21 days ago

Weird.

Can you summarize the messages ids you stream from the base and their
frequencies? Which hardware is running the base station, ZED-F9P right?
(maybe you can paste the version info, i.e. the output of UBX-MON-VER
displayed at gps-genom3 config. time).

#4

Updated by Youssef Aboudorra 21 days ago

Anthony Mallet wrote in #note-3:

Can you summarize the messages ids you stream from the base and their
frequencies?

id , period
1005 , 30
1077 , 1
1087 , 1
1097 , 1
1127 , 1
1230 , 1

where 1097, 1127 had CRC failed

another time I also included
1074 , 1
1084 , 1
1124 , 1
4072.0 , 1

where 1094, 1124 had CRC failed

Which hardware is running the base station, ZED-F9P right?
(maybe you can paste the version info, i.e. the output of UBX-MON-VER
displayed at gps-genom3 config. time).

Yes, here is the output from the terminal if I understood correctly

gps-pocolibs: hw: software version EXT CORE 1.00 (61b2dd)
gps-pocolibs: hw: hardware version 00190000
gps-pocolibs: hw: ROM BASE 0x118B2060
gps-pocolibs: hw: FWVER=HPG 1.12
gps-pocolibs: hw: PROTVER=27.11
gps-pocolibs: hw: MOD=ZED-F9P
gps-pocolibs: hw: GPS;GLO;GAL;BDS
gps-pocolibs: hw: QZSS

#5

Updated by Anthony Mallet 16 days ago

Can you try with 8ba96a1 to see if that helps?

#6

Updated by Youssef Aboudorra 10 days ago

I gave it a try
-still 1097, 1127 had CRC failed
-now I cannot set the maximum period of 1005 bigger than 12.5, I used 30 sec before
-still cannot achive fix_rtk state

to put things in comparison I used u-center NRTRIP server/client for the base/mobile there were no CRC failures, and was able to achive Fixed state for the mobile while using TMODE3 survey for the base (with 5 meter min.accuracy ), using the following RTCMs:

1005 , 30
1077 , 1
1087 , 1
1097 , 1
1127 , 1
1230 , 1

#7

Updated by Anthony Mallet 9 days ago

On Monday 21 Sep 2020, at 18:02, Youssef Aboudorra wrote:

-still 1097, 1127 had CRC failed

I can't definitely reproduce this.
  • Would it be possible that you experience UDP packet drops?
  • Do you see the same number of packets/bytes on the sender and the
    receiver?
  • What is the receiver hardware?

-now I cannot set the maximum period of 1005 bigger than 12.5, I
used 30 sec before

Yes, period is limited to 8 bits, i.e. 255× the navigation period,
which is 20Hz currently. On the base station, 20Hz may not be useful,
so I could make this configurable.

-still cannot achive fix_rtk state

Given the above I would not consider this issue until the rest is fixed.

to put things in comparison I used u-center NRTRIP server/client for
the base/mobile there were no CRC failures, and was able to achive
Fixed state for the mobile while using TMODE3 survey for the base
(with 5 meter min.accuracy ),

In the gps::fix() service, do you configure the same
position/accuracy?

Also available in: Atom PDF