Re: [gpsd-dev] [PATCH] [log.chk] [TPV timing] implement $GPVTG message, and proper timing for output "TPV" messages

[teyrana]

On Thu, May 17, 2018 at 1:52 PM, Gary E. Miller <address@hidden> wrote:

Yo teyrana!

On Thu, 17 May 2018 13:06:07 -0400
teyrana <address@hidden> wrote:

> We've implemented the $GPVTG message, and I wanted to get the list's
> opinion on what the proper behavior is for emitting messages on
> $GPVTG vs storing and waiting.  ( I've attached the .log.chk)

Interesting.  For example:

$GPVTG,135.49,T,150.13,M,0.03,N,0.05,K,D*2C
$GPZDA,140134.00,17,05,2018,00,00*6D
$GPHDT,185.39,T*03
{"class":"ATT","heading":185.39}

Looks like you have more data in the GPVTG than you are putting in the ATT.

.log.chk pasted here: 

https://pastebin.com/jiKy638y 

'VTG' turns out to not have much data--- JUST track and speed. (repeated with different units, oddly enough)

http://www.catb.org/gpsd/NMEA.html#_vtg_track_made_good_and_ground_speed

And the JSON//ATT message only has "heading", but not 'track'/CoG   We actually run into this distinction frequently.  Particularly at low speeds, when the two values can be different by 90+ deg!

 

> The intended (/implemented) behavior was for VTG to populate, but not
> trigger output.

Yeah, that's a tricky part.  You want to wait until you have all the data
of a cycle before outputting, but no longer.  REPORT_IS, and friends, is
the key to how that works.

Right.  This patch sets "REPORT_IS", BUT NOT "CLEAR_IS". 

I'm okay with this current behavior, but I'm just not sure if other people are.

 

> p.s. I ran into the list's size limit, which is why I tried to
> inclcude p.p.s.

Pastebin works for larger files.

Ah, good point.  Patch uploaded here:   

https://pastebin.com/uGG9jH30