Posts made by Marko Lukat

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.

@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

@Lazar-Demin said in problems with the o2lte command:

Submitting a Pull Request will definitely result in a quicker turnaround time! Please submit a Pull Request for the proposed lted changes!

Fair enough, will do.

And can you clarify which NMEA reading issue you're referring to?

You asked me how the documentation can be improved wrt having ugps running and accessing /dev/ttyUSB1 at the same time. So I was wondering where these documentation bits are kept (assuming they are in git somewhere).

@Lazar-Demin I raised two issue on github for o2lte and lted (#36, #37), where can I find the documentation wrt the NMEA reading issue?

@Nate So far everything runs as expected. If I stumble across something new I'll report it. Thanks!

@Nate said in problems with the o2lte command:

I'm also having issues controlling the gnss on this board.

Firstly, the enable / disable of o2lte doesn't seem to do anything at all. gnss is active on device boot and disable doesn't seem to stop it.

Been there as well ... (a friend of mine keeps me on my toes, he is doing real-life testing, I fix the stuff). Disabling doesn't work because it's the wrong command (AT+QGPS=0 doesn't exist), use AT+QGPSEND instead.

Note, if for whatever reasons you use a terminal with the modem chip (e.g. miniterm.py /dev/ttyUSB2) the terminal settings are all screwed up on exit so the o2lte script stops working completely for GNSS (basically line end translation is off). In this case use something like stty -F /dev/ttyUSB2 sane to reset the terminal.

Furthermore /etc/init.d/ugps does seem to work as far as ubus call gps info is concerned however regardless of it's enabled or not I can always do cat /dev/ttyUSB1 which the documentation implies should not work if /etc/init.d/ugps is enabled.

IIRC there is no way opening a device exclusively. Users of said device have to cooperate on this one. But yes, the documentation is misleading here.

@crispyoz said in single ubus failure during boot sequence:

... maybe you need to look at your init.d scripts, the load order might be out of the required sequence.

FWIW, that's the out-of-the-box firmware for the LTE board (with mosquitto disabled).

Meanwhile I fixed up a custom version of ubus which prints the actual command line when Command failed is triggered:

ubus call service set { "name": "usbmode", "script": "\/etc\/init.d\/usbmode", "instances": { "instance1": { "command": [ "\/sbin\/usbmode", "-s" ] } }, "triggers": [ ], "data": { } }
Command failed: Not found

Under normal circumstances this just works. Which suggests service is not yet available at the time the error is thrown.

By chance I spotted the following error message during the boot sequence (2nd to last line):

[   13.090883] procd: - early -
[   13.093928] procd: - watchdog -
[   13.895493] procd: - watchdog -
[   13.898961] procd: - ubus -
[   14.005720] random: jshn: uninitialized urandom read (4 bytes read)
[   14.026774] random: ubusd: uninitialized urandom read (4 bytes read)
[   14.137722] random: ubusd: uninitialized urandom read (4 bytes read)
Command failed: Not found
[   14.154711] procd: - init -

This error message appears to originate from within the ubus command, usually issued when a call object doesn't exist (invalid method calls throw a different error). So I was wondering if this is some kind of race condition (not ready yet) as opposed to an altogether invalid call.

My other Omega (non-LTE) boards don't exhibit this problem.

It doesn't appear to affect the boards function but I'm curious. Does anyone know what this could be?

Thanks!

@Nate: I run into the same issue yesterday. The problem is that procd latches onto the command given i.e. lted-run which in turn starts lted. So during stop only this script is killed and the real daemon keeps running.

What I did for now (in /etc/init.d/lted) is to run lted directly and merge the two extra commands from lted-run (ifconfig/echo) into it (before the procd sequence).

#!/bin/sh /etc/rc.common
# Copyright (C) 2019 Onion Corporation
START=90

USE_PROCD=1

BIN="lted"
APN=$(uci -q get onion.@onion[0].apn)

start_service() {
    [ "$APN" != "" ] && {
        # do lted-run stuff locally
        ifconfig wwan0 down
        echo "Y" > /sys/class/net/wwan0/qmi/raw_ip

        procd_open_instance
        procd_set_param command $BIN -s $APN
        procd_set_param respawn  # respawn the service if it exits
        procd_set_param stdout 1 # forward stdout of the command to logd
        procd_set_param stderr 1 # same for stderr
        procd_close_instance
    }
}

HTH