Re: How to get raw data from gpsd?

[张延涛]

Hi Gary!

I just submitted a PR regarding how to filter binary data sent by ALLYSTAR. When using the ALLYSTAR chip, filtering out binary data first can alleviate the parsing pressure on gpsd (perhaps filtering out known garbage data first can reduce time complexity), thus addressing the issue of missing bytes in raw data.

Additionally, I have a small question to consult about. Why do I get so many 0 values printed within one second when using `while(1){gps_read();}` to obtain satellites_visible? Moreover, the value of satellites_visible dynamically increases within one second. The same situation occurs with satellites_used, which also dynamically increases within one second.

My understanding is that this dynamic increase process is gpsd collecting statistical data. Could we design the `gps_read()` interface to only report statistical results without reporting the statistical process?

Best regards,
Yantao Zhang

Gary E. Miller <gem@rellim.com> 于2024年4月15日周一 03:42写道：

Yo 张延涛!

On Sun, 14 Apr 2024 19:57:32 +0800
张延涛 <zh6tao@gmail.com> wrote:

> > Would you like me to send you my copies of the manuals? 
>
> Thank you very much for generously sharing the manuals with me.

The newest I can find is v2.3.6, from 2020.  Here:

https://wiki.datagnss.com/index.php/Allystar_GNSS_Protocol

A "cheat sheet" from 2020 of common commands:

https://docs.datagnss.com/rtk-board/files/datasheet/01_Module/Common%20command/T-5-2010-Common%20Commands%20Exclusive%20to%20Allystar-V1.0.pdf

An NMEA doc from 2020, most of this is in the first doc:

https://wiki.datagnss.com/images/3/31/ALLYSTAR_GNSS_Receiver_NMEA_Protocol_Specification.pdf

And I am finding bits a pieces here and there.

> > I wish it were that easy, but it is not. 
>
> I've found that if we can filter out the binary data of ALLYSTAR,
> based on the rules I mentioned in my last email, before the
> `packet_parse(lexer);`
> function is called, it can solve the byte loss issue.

Care to share the code?  There are changes to the ALLYSTAR driver
every day, I hope you are keeping up with git head.

The driver now decodes several ACK-, CFG-, MON-, and NAV- messages.
More coming as I figure them out.

> > Yeah, 30KBps does not fit in a 115.2Kbps pipe.  Faster spped is a
> > part of the u-blox protocol that they neglected to copy. 
>
> Also, I'd like to ask, is the value 115.2kbps calculated, or is it
> specified by the protocol?

Look at at the CFG-PRT message. the 3rd field is "baudrate" in "Bit/s".
Nothing in the doc about legal values. Maybe 230.4k will work.  So just
test it.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin