Is it possible to use ogps for a generic GPS tracker

Marko Lukat

@Radek That's puzzling. Given that a simple cat can extract data from that device.

I assume ugps worked before with the/a different device (including ubus). Baudrate may be an issue here (ugps forces 4800 IIRC). Also, is there anything of interest in the log (logread | grep ugps)?

Lazar Demin

@Radek perhaps there's a NMEA string parsing issue in the code. You can take a closer look at the code here: https://github.com/OnionIoT/ogps

Always open to PRs

Radek

The baud rate might be the issue. The tracker I have needs 9600.
I'm not sure if it is important but if oops is installed then I'm getting junk from reading it directly or through screen. But I imagine that might be normal because another software, ogps, is already reading it.

Thank you guys. I'm going to install it back and let you know.

Radek

@Lazar-Demin said in Is it possible to use ogps for a generic GPS tracker:

https://github.com/OnionIoT/ogps

the last time I developed something in C was during my university times and this was a very long time ago

Radek

Ok, installed it again and it won't work.
I haven't use the omega for anything else before. I basically initialised it, installed mc and ogps and it's all.

When I install ogps and then use screen to read it I'm getting junk but as I wrote before, I assume it's normal.

The log file doesn't contains anything about "gps" whatsoever.

@Lazar-Demin @Marko-Lukat is there a way to change the baudrate?

Regards,
Radek

Marko Lukat

@Radek There is a way to change the baudrate but it involves recompiling the program in question.

What you have on the screen looks definitely like a baudrate problem. Could you please install stty (can't remember the package right now) and then run stty -F /dev/ttyS0 after you get the output above. This should show you what baudrate has been set for the terminal (I expect 4800). Then you could try setting the baudrate to something new (ugps only does this during start-up) with stty -F /dev/ttyS0 9600.
While this is not a final/proper solution it should get you what you want right now. Ideally ugps gets a command line option to match the speed of the GPS unit.

crispyoz

@Radek looking at the code you can get some more debugging if you add -d 7 to the commandline in the procd script or you could use set the environment variable DBGLVL to 7. Then you should get some debugging info. Also you could add -S to the commandline so it will log to stderr.

Radek

ok, I am really despaired.

When I have ogps installed:

When I ask baud rate with stty it gives me 4800
I'm trying to change the baud rate to 9600 (with stty) it won't let me
When I'm reading the ttyS0 with cat it gives me junk
When I'm reading the ttyS0 with screen with 9600 baud rate it gives me junk

When I remove ogps :

When I ask baud rate with stty it gives me 9600
When I'm reading the ttyS0 with cat it gives me proper informations
When I'm reading the ttyS0 with screen with 9600 baud rate it gives me proper informations

I enabled also debug but it won't return anything.

Any clues?

Regards,
Radek

Marko Lukat

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

ok, I am really despaired.

Relax, we get this sorted.

When I have ogps installed:

When I ask baud rate with stty it gives me 4800

I'm trying to change the baud rate to 9600 (with stty) it won't let me

OK, I assume this is because the device is already open (in use), my mistake. What's the exact error message?

I'm away from my h/w at the moment but I can have a look on Monday how we can convince ugps to run with a different baudrate.

crispyoz

@Radek @Marko-Lukat From the code we can see the device is opened at 4800:

if (nmea_open(device, &stream, B4800) < 0)

I'm not sure why this is the case.

crispyoz

@Radek I updated the code to set baud rate to 9600, you can see if it works or not, I can't test as I don't have an LTE device.

I built it for you to try, you can find the binary here:

https://github.com/crispyoz/ogps.git

Radek

ok, so I decided to start from scratch. I reseted my Omega2+ to factory settings. Then installed stty, and screen.
Now the default baud rate for ttyS0 is set to 115200 which kinda make sense as it is the baud rate you can see in docs should be the default.
I checked the ttyS1 and the baud rate is by default set to 9600 so I connected the tracker to the ttyS1
After this:

I can read it with cat and it gives me correct data.
I can read it with screen and it gives me correct data as well.

As next I installed ogps, configured it to use ttyS1. Then run ubus call gps info but still no signal.
Then I replaced the /usr/sbin/ugps with the version provided by @crispyoz (a huge, huge thanks for it) run ubus call gps info and not getting signal as well.

Following it I installed gpsd and gpsd-clients, configured it. After running gpsmon and can see following

Screenshot 2020-06-28 at 16.28.18.png

So that seems to be working fine. Also cgps -s seems to be working fine:

Screenshot 2020-06-28 at 15.58.01.png

I could of course try to use gpsd but I would really prefer to get ogps working.

Another question is: can I change the baud rate of ttyS0? Because I need also to connect the GSM module which also requires baud rate of 9600.

If I understand it correctly the baud rate of 115200 is set by the operating system because Omega2 is sending login data during boot process. If I am not wrong in regular Linux I could change the kernel boot option but I don't know how to do this in Omega.

Oh yes, and I can't change the baud rate using stty. When I try to execute stty -F /dev/ttyS0 9600 it just hang until I kill it with ctrl+c

So here I am right now. Thanks a lot for your help guys

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.