Re: How to get raw data from gpsd?

[Gary E. Miller]

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

pgpqVtq3Y3KMp.pgp
Description: OpenPGP digital signature