@Lazar-Demin Thanks, just came back to post that I figured it out:

0 ~ None, 1 ~ Pap, 2 ~ Chap, 3 ~ MsChapV2

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 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.

@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.

@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)?

@Radek Normally - that is on my board - ugps expects just the tail name of the terminal device (e.g. ttyS0). So in my config it just says ttyUSB1 which is then later extended to /dev/ttyUSB1. Can you verify or better yet, post your

• /etc/config/gps
• /etc/init.d/ugps

Also, verify that ugps is actually running ps | grep ugps. HTH

Updated an LTE board to 0.3.2 b244 just for the sake of it. I still get double entries (see my last post) but so far it doesn't show the increment behaviour but it isn't static either. I keep an eye on it.

@Lazar-Demin
For the record, on two LTE boards I have access to I see the same duplicate log messages. At the moment xdatum.orphan and xref.dead count increase every reboot.

The boards have python installed, apart from that they are in out-of-the-box state (0.3.2 b232).

Just checked my Omega2 Pro (b218): 2 log entries but orphan/dead counts are stable.

Example:

[   10.538884] mount_root: loading kmods from internal overlay
[   10.612430] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[   10.626052] kmodloader: done loading kernel modules from //etc/modules-boot.d/*
[   12.054487] jffs2: notice: (445) jffs2_build_xattr_subsystem: complete building xattr subsystem, 18 of xdatum (3 unchecked, 15 orphan) and 65 of xref (22 dead, 1 orphan) found.
[   12.071277] block: attempting to load /tmp/jffs_cfg/upper/etc/config/fstab
[   12.085997] block: extroot: not configured
[   12.490347] jffs2: notice: (443) jffs2_build_xattr_subsystem: complete building xattr subsystem, 18 of xdatum (3 unchecked, 15 orphan) and 65 of xref (22 dead, 1 orphan) found.
[   12.508068] mount_root: loading kmods from internal overlay
[   12.582514] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
[   12.594977] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
[   13.347454] block: attempting to load /tmp/jffs_cfg/upper/etc/config/fstab
[   13.358145] block: extroot: not configured
[   13.363570] mount_root: switching to jffs2 overlay
[   13.437641] overlayfs: upper fs does not support tmpfile.

@Radek

Pin 16 and 17 (UART2) is connected AT_RX and AT_TX respectively. The UART2 doesn't work by the way.

Let's take a step back. Just short pin 16/17 (jumper wire), start a terminal of your choice on /dev/ttyS2 (on the Omega), disable local echo and start typing. Do you see any response (i.e. remote echo)?

According to this document there are 2 buttons (RST_KEY/PWR_KEY) which I assume are connected to the relevant pins (RST/PWR_KEY), IOW the latter are control inputs.

While not specifically mentioned for this product, I found documentation on a similar pin on a different GPS modem SIM908 where it says the following:

The power control of SIM908 module can be controlled by PWRKEY pin. The switching between on and off states of the module can be controlled by connecting PWRKEY to GND for 1-2 sec and then disconnecting them.
For example, when SIM908 module is on, connecting PWRKEY to GND for 1-2 sec and then disconnecting will make the module switch to off.
If SIM908 module is off, tying PWRKEY to GND for 1-2 sec and then disconnecting will make the module switch to on as well (similar to a warm-boot). When PWRKEY pin is always connected to GND, SIM908 module will remain on.

I'd expect similar behaviour for the A9G. HTH

Found another project, just before the comment section is a diagram where PWRKEY is connected to ground (for normal operation).

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?!

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 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.

@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.

@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.

@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.