Bug #277
closedBase station mode: can not send some rtcm messages
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.
Updated by Youssef Aboudorra about 4 years 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
Updated by Anthony Mallet about 4 years 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).
Updated by Youssef Aboudorra about 4 years 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
Updated by Anthony Mallet about 4 years ago
Can you try with 8ba96a1 to see if that helps?
Updated by Youssef Aboudorra about 4 years 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
Updated by Anthony Mallet about 4 years ago
On Monday 21 Sep 2020, at 18:02, Youssef Aboudorra wrote:
I can't definitely reproduce this.-still 1097, 1127 had CRC failed
- 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?
Updated by Youssef Aboudorra about 4 years ago
- Priority changed from High to Normal
Hello, I know it took a while to reply, but we had to wait for good weather conditions here in Enschede :)
We had a chance to try again using the latest commit you pushed . No error messages appeared so far (CRC failed, Hardware skipped bytes, ring buffer full) and finally we got an fix_rtk state.
With the following RTCM used & period:
1005 , 12.75
1077 , 1
1087 , 1
1097 , 1
1127 , 1
1230 , 1
I will first reply to your points:
Anthony Mallet wrote in #note-7:
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?
- For the time being I am using the same computer to connect to both receivers (the network connection is internal 'localhost')
- both the base station and mobile are the same hardware (ZED-F9P)
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.
Could be useful indeed
In the gps::fix() service, do you configure the same
position/accuracy?
I used fix_here() service with avg_time of 30 mins, the sigma value during the fix was around 0.2.
Is it possible to configure the service to stop average if a desired sigma value is reached, it could reduce the time
Observation
several RTCM which I didn't use are sent by the base station for only one time, the mobile side ignores them and uses only the ones I desire, here the list of them
1568 17 2123 2437 3845 805 1412 1108 934 3221 3047 2094 3399 1092 353 1827 3982 3846 769 692 69 499 0 560
Coming tests, I would report back if I encounter issues with:
- check different RTCM 1074 , 1084, 1124, 4072.0
- check with network in the middle between 2 computers (one for base station and one for the mobile gps recv.)
minor bug report:
although I changed the rtk data port number, the message on the base terminal appears to mention the default number (8083)
base:
gps-pocolibs: serving rtk data on port 8081 gps-pocolibs: 127.0.0.1:8083: pushing rtk data
mobile:
gps-pocolibs: 127.0.0.1:8081: listening for rtk data
Thanks a lot for your support Anthony!
Updated by Anthony Mallet about 4 years ago
- Status changed from Feedback to Closed
Thanks for your feedback!