u-blox checksum error while rtkrcv read from stream

[GHolk]

I am a graduate school student using rtklib with rtcm ssr message to perform rt-ppp.
I use ublox f9p chip with raspberry pi running debian linux.
Currently I face a problem that rtklib real-time ppp output few solutions.
There are only about ten solution in one minute.

I use str2str to stream the ublox message from serial to file and tcp,
and rtkrcv read ublox message from tcp, and so on the rtcm message.
This is how I obtain the few solutions mentioned above.
However, when I replay the file, the solutions are well, and appear in every second.

I tried many different aproach, and conclude these facts:

1. The solutions are normal if I use the recorded file as stream source,
   Whether I stream the file to rtkrcv with str2str,
   or directly specify inpstr1-type=file in configuration of rtkrcv.
2. On pi, there are many checksum errors when rtkrcv log level 3 -t 3,
   but there are hardly checksum errors when streaming from file.
3. However, on pc debian, nothing strange in rtkrcv log.
   No checksum error, but the solutions are few, too.
4. Finally, the solutions are normal in rtknavi.

To debug, I tried to print the ublox message if checksum error,
but finally realize that I can not understand the message now.
(I need some time to read the f9p manual.)
If anyone is interested, there are some checksum error messages below,
(most of them are SFRBX message,
and some lines repeat because of my bad code.)
and the code to print these message is here:
GHolk@360d282079d9ce589a

3 decode_ubx: type=0213 len=32
3 decode_ubx: type=0213 len=32
2 ubx checksum error: type=0213 len=32
3 error hex: B5620213180006010008042002001011
3 error hex: 3845788D00700E2E02004608F26AB562
3 error hex: 3845788D00700E2E02004608F26AB562
3 decode_ubx: type=0213 len=32
3 decode_ubx: type=0213 len=52
2 ubx checksum error: type=0213 len=52
3 error hex: B56202132C00020C050009470200F03F
3 error hex: 1F0303C90763054644720040046900C0
3 error hex: 1AAF15005E74B56202131800060C0206
3 error hex: 04580200
3 decode_ubx: type=0213 len=32
3 decode_ubx: type=0213 len=32
3 decode_ubx: type=0213 len=32
2 ubx checksum error: type=0213 len=32
3 error hex: B562021318000607000C020010113845
3 error hex: 788D00F100700E2E02004608ED2BB562
3 error hex: 788D00F100700E2E02004608ED2BB562
3 decode_ubx: type=0213 len=32

[rtklibexplorer]

Hi Gold, If you are getting checksum errors in your u-blox messages, most likely you are having trouble with the serial communication link. The most likely cause is probably that the baud rate is too low for the number of messages you are trying to transmit. Make sure you have disabled all NMEA, UBX, and RTCM messages except the ones required for the solution. If that doesn't work, then you will probably need to increase the baud rate. Best regards, Tim

…

On Wed, Feb 12, 2020 at 10:42 AM Gold Holk ***@***.***> wrote: I am a graduate school student using rtklib with rtcm ssr message to perform rt-ppp. I use ublox f9p chip with raspberry pi running debian linux. Currently I face a problem that rtklib real-time ppp output few solutions. There are only about ten solution in one minute. I use str2str to stream the ublox message from serial to file and tcp, and rtkrcv read ublox message from tcp, and so on the rtcm message. This is how I obtain the few solutions mentioned above. However, when I replay the file, the solutions are well, and appear in every second. I tried many different aproach, and conclude these facts: 1. The solutions are normal if I use the recorded file as stream source, Whether I stream the file to rtkrcv with str2str, or directly specify inpstr1-type=file in configuration of rtkrcv. 2. On pi, there are many checksum errors when rtkrcv log level 3 -t 3, but there are hardly checksum errors when streaming from file. 3. However, on pc debian, nothing strange in rtkrcv log. No checksum error, but the solutions are few, too. 4. Finally, the solutions are normal in rtknavi. To debug, I tried to print the ublox message if checksum error, but finally realize that I can not understand the message now. (I need some time to read the f9p manual.) If anyone is interested, there are some checksum error messages below, (most of them are SFRBX message, and some lines repeat because of my bad code.) and the code to print these message is here: ***@***.*** <GHolk@360d282079d9ce589a> 3 decode_ubx: type=0213 len=32 3 decode_ubx: type=0213 len=32 2 ubx checksum error: type=0213 len=32 3 error hex: B5620213180006010008042002001011 3 error hex: 3845788D00700E2E02004608F26AB562 3 error hex: 3845788D00700E2E02004608F26AB562 3 decode_ubx: type=0213 len=32 3 decode_ubx: type=0213 len=52 2 ubx checksum error: type=0213 len=52 3 error hex: B56202132C00020C050009470200F03F 3 error hex: 1F0303C90763054644720040046900C0 3 error hex: 1AAF15005E74B56202131800060C0206 3 error hex: 04580200 3 decode_ubx: type=0213 len=32 3 decode_ubx: type=0213 len=32 3 decode_ubx: type=0213 len=32 2 ubx checksum error: type=0213 len=32 3 error hex: B562021318000607000C020010113845 3 error hex: 788D00F100700E2E02004608ED2BB562 3 error hex: 788D00F100700E2E02004608ED2BB562 3 decode_ubx: type=0213 len=32 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#51?email_source=notifications&email_token=AC3YLOVTJUOYMAE7H2KNEULRCQYHVA5CNFSM4KT6IAFKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INANA3A>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3YLOUM6YFWJPSHET7CYWLRCQYHVANCNFSM4KT6IAFA> .

[GHolk]

Hi Tim:

I fix this bug with the default configuration file.
The number of solution increase after I set the pos1-navsys to 63,
which meaning that use gps+sbas+glonass+galileo+qzss+compass .

However, even if I set pos1-navsys to 1, the solution number is normal
when replaying stored ublox and rtcm file.
I have checked the command observ's output in console, there are only gps satellites.
Whatever, this is another strange behavior; my origin problem have solved.

Sorry for bothering you.
You can close this issue, or leave this issue open for further investagion
about the strange behavior above.

[GHolk]

I just find another strange behavior about str2str.
When I use str2str to cast serial to multiple tcp client,
the client may receive broken data?

this will work if there are only one client connect to localhost:5566:
str2str -in serial://serial0:115200#ubx -out file://f9p.ubx::T -out tcpsvr://:5566.
If I run two rtkrcv both connect to localhost:5566, the solution will be few.

However, this is ok:
str2str -in serial://serial0:115200#ubx -out file://f9p.ubx::T -out file:///dev/stdout | str2str -out tcpsvr://:5566,
even if there are multiple client.