Best posts made by Marko Lukat

@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