Is it possible to use ogps for a generic GPS tracker
-
@Marko-Lukat This seems like classic buffer overrun behaviour which would make sense since you're feeding the terminal at double the rate.
-
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/
-
wow, wait, it looks like the coordinates in the file are multiplied about 100 times
-
@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.
-
A new test version is available from github. Baudrate can now be specified with the -b parameter, NMEA sentence filtering is now more relaxed.
-
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
-
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 &
theubus call gps info
will returnroot@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.
-
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?!
-
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
-
Sorry about the f word
-
@Radek it is a breach of the terms of use. I edited it out rather than apply any penalty.
-
@crispyoz I got it. Thanks a lot. I was just too excited
-
@Radek I think we all appreciate your passion and we look forward to your future contributions.