RFC - drop "tag" fields from the public interface

Discussion:

Eric S. Raymond

2014-08-24 05:01:07 UTC

There's going to be a libgps version bump in the 3.12 release. This
makes it a good time for a featurectomy I've been thinking
about. I'm requesting comments.

The "tag" field in JSON reports is a historical relic from before the
design of the JSON protocol, back when there was fairly close
correspondence between one GPS sentence in and one GPSD report
sentence out.

Now that JSON reports correspond to the last GPS sentence in some
group composed to gather all their information, that correspondence is
gone. In the NMEA case, for example, a TPV is composed from up to
four sentences and the tag only tells us which one happened to arrive
last.

I think this is useless. I'm contemplating removing tag
fields from the data exposed by the JSON - might have done it
sooner, but it certainly wasn't worth forcing a library version
bump for this.

This featurectomy will drop out a bunch of dodgy code in binary drivers under
which there isn't a hard and fast notion of "tag" for sentences and
you have to make one up from the number of the sentence type.

Does anyone have - or can anyone even imagine - a use case for the
tag fields as they are now? If so, speak up. If all I hear is
crickets, I'll drop them. Affirmative responses of the form
"I have no use for the tag field" would be useful, too.
--

esr>>

Moe

2014-08-24 05:23:49 UTC

Permalink

On Sun, 24 Aug 2014 01:01:07 -0400 (EDT)

Post by Eric S. Raymond
There's going to be a libgps version bump in the 3.12 release. This
makes it a good time for a featurectomy I've been thinking
about. I'm requesting comments.
The "tag" field in JSON reports is a historical relic from before the
design of the JSON protocol,<snip>
Does anyone have - or can anyone even imagine - a use case for the
tag fields as they are now? If so, speak up. If all I hear is
crickets, I'll drop them. Affirmative responses of the form
"I have no use for the tag field" would be useful, too.

As well as TVP tag being one of 4, my understanding:

{"class":"SKY","tag":"GSV","device":"/dev/tty...

"tag" is always "GSV", If you have SKY you have GSV. It's just the
nature of the beast.

I have no use for the tag field.

--
<bɹo˙ɐppɐʍ@ǝoɯ> ǝoW

Eric S. Raymond

2014-08-24 05:53:32 UTC

Permalink

How does Watch work today? How does/will it work for the timing case? There
are several NMEA sentences that provide timing. If the transmitter is
stable, it would help to get the time from the same sentence type each time.

Time is collected at the same point in the cycle every time. What
sentence that is varies by GPS type but is always the same sentence
type for any one GPS.

There's a cycle detector in the code that watches timestamped
sentences (ignoring others) looking for where the stamp changes from T
to T+1. It then marks the sentence type just *before* the T+1
sentence as the end-of-cycle type. Thereafter, reports (including time)
are issued on end-of-cycle.

The uBlox 4 LEA is a representative example. Each cycle it ships
$GPZDA, $GPRMC, $GPVTG, $GPGGA, $GPGSA, $GPGSV, $GPGLL. Timestamps
occur in ZDA RMC GGA GLL; the timestamp is incremented on ZDA.

In this case, gspd notices that the timestamp is incremented on ZDA,
which comes after GLL. GLL is marked as end of cycle, reports are
issued on every GLL using info accumulated from ZDA RMC GGA GLL,
and GLL fills the tag field of the resulting TPV.

--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Eric S. Raymond

2014-08-24 11:25:07 UTC

Permalink

One quirk to consider. I've seen some units that do something like send GSV
every 5th second.

Yes, that is pretty normal. The cycle detector doesn't get confused by
this, because GSVs are not timestamped.

--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Hal Murray

2014-08-24 05:30:07 UTC

Permalink

The "tag" field in JSON reports is a historical relic from before the design
of the JSON protocol, back when there was fairly close correspondence
between one GPS sentence in and one GPSD report sentence out.
Now that JSON reports correspond to the last GPS sentence in some group
composed to gather all their information, that correspondence is gone. In
the NMEA case, for example, a TPV is composed from up to four sentences and
the tag only tells us which one happened to arrive last.

--
These are my opinions. I hate spam.

Hal Murray

2014-08-24 08:01:31 UTC

Permalink

Time is collected at the same point in the cycle every time. What sentence
that is varies by GPS type but is always the same sentence type for any one
GPS.
There's a cycle detector in the code that watches timestamped sentences
(ignoring others) looking for where the stamp changes from T to T+1. It
then marks the sentence type just *before* the T+1 sentence as the
end-of-cycle type. Thereafter, reports (including time) are issued on
end-of-cycle.
The uBlox 4 LEA is a representative example. Each cycle it ships $GPZDA,
$GPRMC, $GPVTG, $GPGGA, $GPGSA, $GPGSV, $GPGLL. Timestamps occur in ZDA RMC
GGA GLL; the timestamp is incremented on ZDA.
In this case, gspd notices that the timestamp is incremented on ZDA, which
comes after GLL. GLL is marked as end of cycle, reports are issued on every
GLL using info accumulated from ZDA RMC GGA GLL, and GLL fills the tag
field of the resulting TPV.

Thanks.

OK, if that's how it works, I agree that the tag isn't useful.

One quirk to consider. I've seen some units that do something like send GSV
every 5th second.

$GPRMC,074835.000,A,3726.0787,N,12212.2705,W,0.37,253.56,240814,,*1E
$GPGGA,074836.000,3726.0786,N,12212.2701,W,2,07,1.9,42.2,M,-25.7,M,1.8,0000*7D
$GPGSA,A,3,31,11,01,32,20,04,23,,,,,,3.5,1.9,3.0*3A
$GPRMC,074836.000,A,3726.0786,N,12212.2701,W,0.46,321.68,240814,,*17
$GPGGA,074837.000,3726.0789,N,12212.2698,W,2,06,2.0,42.9,M,-25.7,M,0.8,0000*73
$GPGSA,A,3,31,11,01,32,04,23,,,,,,,3.6,2.0,3.0*31
$GPRMC,074837.000,A,3726.0789,N,12212.2698,W,0.80,10.86,240814,,*23
$GPGGA,074838.000,3726.0793,N,12212.2694,W,2,06,2.0,43.3,M,-25.7,M,1.8,0000*71
$GPGSA,A,3,31,11,01,32,04,23,,,,,,,3.6,2.0,3.0*31
$GPRMC,074838.000,A,3726.0793,N,12212.2694,W,0.55,359.72,240814,,*16
$GPGGA,074839.000,3726.0799,N,12212.2699,W,2,07,1.9,44.7,M,-25.7,M,2.8,0000*7C
$GPGSA,A,3,31,11,01,32,20,04,23,,,,,,3.5,1.9,3.0*3A
$GPRMC,074839.000,A,3726.0799,N,12212.2699,W,1.10,10.08,240814,,*23
$GPGGA,074840.000,3726.0801,N,12212.2696,W,2,07,1.9,44.6,M,-25.7,M,0.8,0000*70
$GPGSA,A,3,31,11,01,32,20,04,23,,,,,,3.5,1.9,3.0*3A
$GPGSV,3,1,12,32,71,348,28,31,64,090,22,01,54,273,27,11,39,235,22*7E
$GPGSV,3,2,12,20,31,307,18,04,23,312,29,14,22,056,,23,19,258,23*79
$GPGSV,3,3,12,22,14,114,,25,08,052,,17,01,315,,48,45,197,28*7B

--
These are my opinions. I hate spam.