Is it possible to use ogps for a generic GPS tracker

Marko Lukat

@Radek This being Monday I verified that ogps9600 does in fact work with a 9600 baud terminal interface ( @crispyoz). However, I had cases where it simply got stuck. My test sequence is that I feed an external 4800 baud stream into ttyS1 which I then change to 9600 baud and see if ugps recovers. The problem here was that if I feed garbage for too long there was no recovery. If the interval is short enough everything turns out ok.

I'd like you to test the executable from my github repo. This is also hardwired to 9600 baud but it also writes the callback buffer to a logfile (/tmp/oink.log, don't ask).

download
chmod +x ugps9600+logging
stop any other ugps task
./ugps9600+logging /dev/ttyS1 &

If everything works out the logfile will keep growing and you can see effectively how all the NMEA sequences build up.

If you think it's stuck (ubus command doesn't show anything for an extended length of time) check the logfile, my assumption here is that it will have stopped growing at this point. Each line in said file is the buffer length followed by a hex entry count followed by the buffer content (in brackets), e.g.

14, 0000000E: [[random garbage]]

When it gets stuck for me the buffer has grown to a size of 4K which is critical as from this point onward there won't be any more message callbacks to ugps. IOW no recovery. My guess would be that this is the buffer limit for ustream and unless you consume its data you won't get any new stuff.

I'm toying with an idea to force a flush/consumption if the buffer grows unreasonably large for valid NMEA but lets figure out your issue first.

crispyoz

@Marko-Lukat This seems like classic buffer overrun behaviour which would make sense since you're feeding the terminal at double the rate.

Radek

Guys, as first I would just like to say, I'm involved in an Open Source project and participate in few others and I really don't remember to ever encounter such a friendly and helpful community. I really thank you so much.

@Marko-Lukat : sadly it still doesn't work for me and the log file (nice name) is being actually filled with correct data. I'm pretty sure I'm screwing something.

Attaching the log file.

Sorry, wasn't able to upload for some reason. Here it is: https://cloud.sigsiu.net/f/d3d210f48188414581e0/

Radek

wow, wait, it looks like the coordinates in the file are multiplied about 100 times

Marko Lukat

@Radek said in Is it possible to use ogps for a generic GPS tracker:

wow, wait, it looks like the coordinates in the file are multiplied about 100 times

That's how it is defined. Don't worry.

BUT ... ugps is hardwired for $GP on the sequences it accepts (RMC/GGA/VTG/TXT). And your device delivers $GN. Ouch! Looks like we need a lot of fixes!

configurable baudrate (at least 4800..115200)
ignore initial two letters
potentially fix callback starving

Just noticed that your first data dump shows $GP sentences, but the logfile uses $GN where it matters ... otherwise we'd have spotted it earlier.

Marko Lukat

A new test version is available from github. Baudrate can now be specified with the -b parameter, NMEA sentence filtering is now more relaxed.

Radek

Wow, we are definitely a step further. When I start the version @Marko-Lukat provided with ugps -b 9600 -S -d 7 /dev/ttyS1 this is what I am getting:

root@Omega-9A9F:~# ugps -b 9600 -S -d 7 /dev/ttyS1
Failed to add object: Invalid argument
ugps: date: 2020-06-30T19:51:08 UTC
ugps: position: 49.928734 9.003940
ugps: height: 149.8
ugps: date: 2020-06-30T19:51:09 UTC
ugps: position: 49.928734 9.003942
ugps: height: 149.5
ugps: date: 2020-06-30T19:51:10 UTC
ugps: position: 49.928734 9.003942
ugps: height: 149.1
ugps: date: 2020-06-30T19:51:11 UTC
ugps: position: 49.928734 9.003945
ugps: height: 148.8
ugps: date: 2020-06-30T19:51:12 UTC
ugps: position: 49.928726 9.003947
ugps: height: 148.5

I modified the /etc/init.d/ugps like this:

#!/bin/sh /etc/rc.common
# Copyright (c) 2014 OpenWrt.org

START=80

USE_PROCD=1
PROG=/usr/sbin/ugps

service_triggers() {
	procd_add_reload_trigger gps
}

start_service() {
	local tty="$(uci get gps.@gps[-1].tty)"

	[ -d "/sys/class/tty/$tty/" ] || return

	procd_open_instance
	procd_set_param command "$PROG" "-d 9600" "/dev/$tty"
	procd_set_param respawn
	procd_close_instance
}

But ubus call gps info still returns:

root@Omega-9A9F:~# ubus call gps info
{
	"signal": false
}

I am probably missing some small thing. But thanks a lot for your help. It's already a huge successes.

Regards,
Radek

Radek

Ok guys, I discovered another thing. When I start the demon with the file I modified it will return the signal=false. But if I start ugps manually with ugps -b 9600 /dev/ttyS1 & the ubus call gps info will return

root@Omega-9A9F:~# ubus call gps info
{
	"age": 1,
	"latitude": "49.928703",
	"longitude": "9.003965",
	"elevation": "147.6",
	"course": "",
	"speed": ""
}

So I am pretty sure the ogps itself works perfectly ok now.

Marko Lukat

This (Failed to add object) sounds more like there is already/still a gps ubus object added to the daemon. Can you make sure there is no other ugps instance running?

Also in your init.d script, I assume this is a typo and it actually reads -b 9600, not -d 9600?!

Radek

OMG. I am such an idiot. One typo and I am wasting your precious time. But

It is XXXXX works right now

Thank you sooooo much. It works perfectly now. I am sooooo happy.

Regards,
Radek

Radek

Sorry about the f word

crispyoz

@Radek it is a breach of the terms of use. I edited it out rather than apply any penalty.

Radek

@crispyoz I got it. Thanks a lot. I was just too excited

crispyoz

@Radek I think we all appreciate your passion and we look forward to your future contributions.