gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $GPGGA / increased number of satellites


From: Gary E. Miller
Subject: Re: $GPGGA / increased number of satellites
Date: Sat, 18 May 2024 14:15:57 -0700

Yo Hans!

On Sat, 18 May 2024 22:42:25 +0200
Hans Mayer <gpsd@ma.yer.at> wrote:

> >>>> Now I realized that the logs before the upgrade had 86400 lines
> >>>> +/- 1. This is one line per second. Now the files have about
> >>>> 10800 lines. Each night I do a logrotate.  
> >>> One line a seconds???  No way that is enough!  
> >> Big sorry, my mistake. Before the update there are 86400 lines per
> >> day, but after the update I see now 108000 lines per day ( I
> >> missed a zero previously )  
> > My comment still stands: 86400 lines per day of sat data is WAY too
> > lettle.
> >
> > Exactly how are you "counting lines per day"??
> >
> > I'm totally lost.  
> 
> I run this script:
> 
> gpspipe --nmea -u | grep --line-buffered GPGGA >>
> /var/log/gpsd/nmea.log &

Uh, I already told you the --nmea can be misleading because your are
using ubx binary protocol.

> This writes, as you know, one line per second.

No.  I do not know that.  There are many cases that is not true.

And, are you sure you are not getting other GGA?  Like $BDGGA, $GLGGA,
etc.

> So I can easily count the lines with "wc -l" for each day. And there
> was with the old version ( from around December ) 86400 lines per day.
> 
> But now I count 108000 lines. Exactly 21600 lines more each day.

Well then, we know that what you thought you knew is wrong.

> I figured out that sometimes the HDOP  column is empty and if this 
> happens then there are 2 lines in one second. But this doesn't happen
> so often.

And many other possibilites.  Depending much on how you configured your
receiver.

> Just now I see that there are two lines per second with a 
> different longitude, like this
> 
> 2024-05-16 22:00:24.042232: 
> $GPGGA,220023.00,4808.9574000,N,01617.0305920,E,2,71,0.47,243.79,M,43.919,M,,*61
> 2024-05-16 22:00:24.640521: 
> $GPGGA,220024.00,4808.9574060,N,01617.0305860,E,2,72,0.47,243.78,M,43.919,M,,*67

Yes, that can happen.  Not all of the sentences that send lat/lon do
it to the same precision.  Thus 4808.9574000 and 4808.9574060 are
not different, one is just more precise.  I can think of 6 different
precisions that you can set your u-blox to use.

> But it's interesting that it happens exactly 21600 times per day.

Why is that interesting?  That can easily happen when you have one message
set to output lat/lon every 4 cycles.

> > The way SNMP count satellites is yet again a different way than
> > NMEA, UBX, etc.  If you want to retain your sanity, stay away from
> > SNMP.  
> 
> I took the example from the man page. Fine for me not to do so.

I don't care where bad ideas come from, just don't use them.

> BTW speaking about "man gpssnmp": The example "Dump the entire "sky"
> OID this way:" works for me.
> 
> The snmpget with OID skynSat.1 doesn't work. It only works with 
> GPSD-MIB::skynSat.1

SNMP varies all over the map.  Much depends on your SNMP configuration,
what MIBs are installed.  A mess.  Avoid unless you really, really,
really have to use SNMP.

> And the snmpwalk example with OID gpsd doesn't work too:
> 
> mayer# snmpwalk -c mysecret -v 2c localhost gpsd
> gpsd: Unknown Object Identifier (Sub-id not found: (top) -> gpsd)

Just like NMEA, only way worse, no example can know what receiver you
have.  Or how your receiver is configured, or how your NMSP is configured.

If you really want to get SNMP to work for your, this needs to be a
separate topis.  Unless you really need it, it will be a large yak
shearing expidition.

> And the comment
> 
> # configure pass-thur of GPSD-MIB to gpssnmp
> 
> shouldn't it be
> 
> # configure pass-through of GPSD-MIB to gpssnmp
> 
> A typo ?

Typo. Fixed in my copy, Will push later. As my eyes get worse, expect
more and more types.  Please report them as you see them.


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

Attachment: pgp3mXVJtKggZ.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]