$GGA vs $GLL

870 views
Skip to first unread message

Alex Lorman

unread,
Nov 10, 2016, 10:44:09 PM11/10/16
to kplex
Hi all;
I'm using kplex on a Raspi 3 connected to a Hemisphere V113 via a usb to 232 dongle (wiring is correct, the hemisphere outputs NMEA over 232 on one port. Also, probably the strangest mismatch in hardware).
For some reason kplex didn't like the $GGA sentences coming from the Hemisphere and would only forward the $GTV (heading) sentences.
After turning $GLL on, it worked fine.

Thoughts? Is this a known issue?

The actual sentences are $GPGGA (etc) but for clarity I've left of GP on the above.

Thanks!
alex

Keith Young

unread,
Nov 12, 2016, 8:03:36 AM11/12/16
to kplex

> Thoughts? Is this a known issue?

kplex doesn't care about the content of sentences unless you stick filters on input or output.  If you have filters maybe there's a bug in kplex's filter processing (but it isn't a known one). If you have no filters then my guess is that turning on GLL is changing something about the way the v113 is outputting GGA. Is there an implicit baud rate change?  Is GGA normally being output on the hemisphere's other port but turning on GLL causes all GPS output to be over the port you request?

Taking kplex out of the equation and just doing:
(stty NNNNN ; cat ) < /dev/DEVICE 
...for appropriate baud rate NNNNN and device DEVICE should give a clue.  If you've looked at that and it all seems normal but the GGAs aren't being forwarded by kplex the most common reason why sentences which *look* ok are being dropped is that they're not terminated correctly. Try adding "strict=no" to the interface configuration for the hemisphere device.  No I have no idea why turning on GLL would change the way GGA was transmitted, but it's worth a try...

Thomas Gersmann

unread,
Jul 6, 2017, 3:00:16 PM7/6/17
to kplex
Hi,
I using also Kplex with a hemisphere. 
I have the same problem. Kplex filtered the GPGGA-Data. If I read the serial Interface directly, I get the GPGGA, GPVTG, GPGSA and GPZDA.
Here is my Config:

[serial]
filename=/dev/serial0
baud=19200
direction=in
[tcp]
mode=server
direction=out
[udp]
device=wlan0
direction=out

I get the GPVTG, GPGSA and GPZDA. But not the GPGGA.
Here is an Example of an GPGGA directly on the Serial Port
$GPGGA,182936.40,XXX8.0621615,N,00X58.6580267,E,2,08,1.2,57.3,M,46.7,M,5.4,0120*73
$GPGGA,182936.60,XXX8.0621609,N,00X58.6580256,E,2,08,1.2,57.3,M,46.7,M,3.6,0120*7A

The XXX I have Change.... ;-)
I Have testet with "strict=no" and filter -all and so on but it doesn´t work.
Have anybody an Idea?
Sorry for my bad Englisch...;-)

Thank´s
Thomas


Keith Young

unread,
Jul 16, 2017, 4:25:39 PM7/16/17
to kplex
Sorry for delay in replying: I've been sailing and avoiding computers for 2 weeks

I'm guessing that this hemisphere is using a strange line termination which isn't being recognised even with strict=no.  Could you do one of the following?  Ideally cat from the device to a file. If you don't want to post something with your location then email it to me, and if you're not comfortable with that then instead of cat-ing from the device can you do an od of a couple of lines, e.g.:
od -t ax1 /dev/serial
change anything you don't feel happy with sharing: it's the line termination we're interested in.  That often isn't visible with cat

Thomas Gersmann

unread,
Jul 19, 2017, 1:16:25 PM7/19/17
to kplex
I have send you a Mail... ;-)

Keith Young

unread,
Jul 19, 2017, 4:14:04 PM7/19/17
to kplex

Thanks for the mail Thomas.  Looking at the od output you will be losing a lot of the GPVTG etc. sentences.  Lots of them are missing any kind of terminators and it looks a little corrupted.  That made me wonder if the baud rate was correct.  I note you are using baud=19200 but the manual says the default for port A is 9600.  I see that you can change the output which is maybe what you've done, but can you check that it's not actually set up for 9600 (perhaps it has reverted to the default?)

Looking again at your GPGGA sentences above...these appear to have more precision than should be present in a GGA.  An additional 5 decimal places on the lat/lon would take the sentence length over the maximum NMEA-0183 sentence length of 82 characters *including* the $ and terminating <CR><LF> unless I'm mis-counting.

Check the baud rate.  If that fixes everything great.  If not I'll send a mail to Hemisphere to ask about their GGA sentences

Keith Young

unread,
Jul 19, 2017, 4:21:35 PM7/19/17
to kplex
ok I see contradictory statements in the manual.  At one point it says port A defaults to 9600.  At another it says 19200 which is what you have.

Try 9600 and see if you get more of the VTGs etc..

Thomas Gersmann

unread,
Jul 20, 2017, 1:16:04 AM7/20/17
to kplex
I have send you a Mail with the Baudrate of 9600. 
I think it´s not the correct one because there is no logic in it.
Last time I have use direct the Uart of the Pi with a max3232 (https://www.gedad.de/projekte/projekte-für-privat/gedad-control/) and it doesn´t work.
This time I use a Seriel-USB adapter and at the moment I get also the GGA files???  Or is there also another Problem?

2017-07-20_06h59_36.png

Keith Young

unread,
Jul 20, 2017, 7:56:00 AM7/20/17
to kplex
Do I understand correctly that this is now all working fine with the serial-usb adapter and that the sentence corruption was down to the hardware between the hemisphere and the pi?

I've successfully used max3232 on a serial port. I've seen some suggestion that it might be unstable above 38400 but nothing to indicate problems at 19200.  Was it set up for 8 bit no parity 1 stop bit?

I note that your GGA sentences here are <79 chars which looks fine.  Presumably the additional characters before were corruption?

I already emailed hempishpere but haven't heard back from them yet.  If the above is the case, presumably they'll ask me what I'm talking about suggesting they're using over-long sentences :-)

Thomas Gersmann

unread,
Jul 20, 2017, 8:33:21 AM7/20/17
to kplex
Hi,
 
could it be, that the Problem is the DGPS for higher precission?
At the first time, I taste it with the Uart and the max3232. At this time we had good Weather  (I send you the File). In this Case the NMEA Data send a fix quality of 2 and it doesn´t work.
At the Moment (in the last file) on fix quality Position is a 1 for GPS, not DGPS.
Could this be the Problem?
I test it in the evening again with the mux3232

Thomas Gersmann

unread,
Jul 20, 2017, 8:41:11 AM7/20/17
to kplex
I have taste it directly because at the moment here is better weather with blue sky.
And it doesnt work!!
Now the Hemisphere work with DGPS ( 2 on fix quality) and the GPGGA are Blocked.

=>
uart with max232 or Serial to USB work with GPS but both doesn´t work if the Hemisphere sends better Quality with DGPS
I have send you the new file.
 
 

Keith Young

unread,
Jul 20, 2017, 9:24:32 AM7/20/17
to kplex

Further to another mail from Thomas it seems the GGAs are indeed 84 chars and not being forwarded by kplex.  I'll await a response from Hemisphere and later this evening consider what the minimal code changes would be to increase the maximum sentence size (it should be increasing the value of either one or two macros)

Keith Young

unread,
Jul 20, 2017, 12:53:21 PM7/20/17
to kplex

I received a reply from Hemisphere.  They say:

To change the GGA sentence length from 82 to 80 you can use the $JNMEA,MARINE,YES command. To save that setting send the $JSAVE command.

 
This should reduce the overall sentence length to the NMEA maximum (also kplex's maximum)

Keith Young

unread,
Jul 20, 2017, 3:15:39 PM7/20/17
to kplex
To recompile for a sentence size larger than standard which accommodates the hemisphere default GGA size:
* change the definition of SENMAX in kplex.h from 80 to 82 and recompile
SENMAX is the maximum size of the sentence including the initial ! or $ but excluding termination characters.

The size of the buffers which these data are held in is controlled by the macro SENBUFSZ in kplex.h.  This is already set to 84 for reasons which I need to investigate further but which *should* accommodate a SENMAX of 82 without update (i.e. sentence length plus \r\n).  Obviously SENBUFSZ should be derived from SENMAX so I'll have to take a little more time to double check I don't write any superfluous trailing nulls into those buffers anywhere and update that for a future release.

Keith Young

unread,
Jul 21, 2017, 4:48:31 AM7/21/17
to kp...@googlegroups.com


I received a reply from Hemisphere.  They say:

To change the GGA sentence length from 82 to 80 you can use the $JNMEA,MARINE,YES command. To save that setting send the $JSAVE command.

 

For anyone reading this in future, I'm presuming that one way to do this would be to stop any existing kplex process which has the hemisphere's device file open and doing:
kplex -f- file: serial:filename=<devname>,baud=<baud> <<EOF
$JNMEA,MARINE,YES
$JSAVE
EOF

...where <device> is the device file (e.g. /dev/ttyUSB0) and <baud> is the baud rate (e.g. 19200).

Thomas Gersmann

unread,
Jul 22, 2017, 2:39:16 PM7/22/17
to kplex

what do i wrong?

Am Freitag, 21. Juli 2017 10:48:31 UTC+2 schrieb Keith Young:


I received a reply from Hemisphere.  They say:

To change the GGA sentence length from 82 to 80 you can use the $JNMEA,MARINE,YES command. To save that setting send the $JSAVE command.

 

For anyone reading this in future, I'm presuming that one way to do this would be to stop any existing kplex process which has the hemisphere's device file open and doing:
kplex -f- file: serial:device=<devname>,baud=<baud> <<EOF
2017-07-22_20h36_21.png

Thomas Gersmann

unread,
Jul 22, 2017, 3:32:51 PM7/22/17
to kplex
I have also try it like this. But it also doesnt work.

(see attached)
2017-07-22_21h29_12.png

Keith Young

unread,
Jul 22, 2017, 5:36:19 PM7/22/17
to kplex


what do i wrong?

Sorry my mistake: can't even remember my own options :-)

use filename=/dev/ttyUSB0 rather than device=ttyUSB0

Also is it 9600 or 19200?  Or are you writing to a different interface on the device
Reply all
Reply to author
Forward
0 new messages