We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

problems with the o2lte command



  • Hello everyone,

    Checking on multiple different lte boards, I noticed that once connecting to an apn ( i tried hologram and tmobile ) turning off the data connection doesn't seem to work. Even though o2lte says it turns it off, the interface is still there, it still has an ip address and traffic is still routing out off it.

    There also seems to be an issue switching from one apn to another. If I add a sim after a fresh restart, it will provision it correctly, but if I want to switch to a different sim and run the apn command again, it doesn't switch correctly.

    Thanks,

    Nate


  • administrators

    @Nate the data disable command shuts off the lted daemon. See the source here: https://github.com/OnionIoT/OpenWRT-Packages/blob/openwrt-18.06/omega2-lte/files/omega2-lte.sh#L195

    That should disable the data connection. Have you found any commands that work to disable the data?
    Maybe try out ifconfig down-ing the lte interface.



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



  • @Marko-Lukat
    That did indeed help thank you. Honestly I wasn't quite sure what the thinking was making the extra call to lted-run in the first place just to do those two commands. I just figured I was missing something.

    @Lazar-Demin Can we get a fix for this and a firmware update please? Seems like we don't get firmware updates as often as I would have thought.
    With the current firmware, if I have a SIM card in the board, when I boot it the cellular interface is up on it's own. Running o2lte data disable doesn't turn it off. I have to bring down the interface manually, remove the default route manually and add a new default route pointing back to the network gateway. It's very frustrating.



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

    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.



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



  • @Marko-Lukat Thanks so much that did indeed fix it. Are there any other gotcha's you've learned with this board that someone should be aware of if they are trying to use it in a real project? Thanks so much.

    @Lazar-Demin I hope we can get a fixed firmware for everyone else?



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


  • administrators

    @Nate said in problems with the o2lte command:

    I hope we can get a fixed firmware for everyone else?

    Definitely! Please submit a PR on GitHub.
    The code for the omega2-lte-base package (which includes the o2lte script) can be found here: https://github.com/OnionIoT/OpenWRT-Packages/tree/openwrt-18.06/omega2-lte

    We've added a readme to make it easy to figure out what's what.


    @Marko-Lukat said in problems with the o2lte command:

    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.

    How can we improve the documentation to make this more clear?



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


  • administrators

    @Marko-Lukat We'll take a look.
    Submitting a Pull Request will definitely result in a quicker turnaround time! Please submit a Pull Request for the proposed lted changes!

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



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


  • administrators

    PRs have been merged! Thanks for contributing!

    How to update your Omega2 LTE

    Option 1: Update a Software Package

    To get the updates, you can update just the omega2-lte-base package to install the latest 1.0.2 version. Make sure you're connected to the internet and run:

    opkg update
    opkg upgrade omega2-lte-base_1.0.0
    

    Option 2: Firmware Update

    Or you can update the firmware of your Omega2 LTE.

    Make sure you're connected to the internet and run:

    oupgrade -l -f
    

    What does this fix?

    Two things:

    1. Can properly disable GNSS scanning (current consumption will drop about 20~30mA @ 5V)

    2. When the lted service is stopped, the modem will actually stop the cellular data connection


    @Marko-Lukat re the Omega2 LTE Guide:
    This guide is hosted on our website, it's not on GitHub.
    Let us know if there are any changes that you would like us to make!


Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.