I found a thread in the lvgl forums where @Lazar-Demin was talking to those guys trying to get a working build of micropython + lvgl for the omega here: lvgl forums. Unfortunately I don't know if he was successful or not and couldn't find a package anywhere for it. I'm not a c coder and would very much be interested if someone knows how to get micropython + lvgl working on the omega 2.

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.

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

@Lazar-Demin You beat me to it, I was just about to post that in response.
@crispyoz Keep in mind though we do only have USB2 so there will still be a bottleneck.

@William-Srite

I'm just starting with the expansion and also finding it frustrating to use. But I had some comments on your thread and thought I'd share what I've figured out in the two days I've been messing with it.

I'm a security researcher and need to build a handheld, barry powered device to scan a client's employees badges to do an audit.

Me too! Specifically I do penetration testing of all sorts. I would think you'd want something with a bit more range for an engagement?

basically what i'm asking is how to control the rfid/nfc exp from inside a progra...any program: python node.js, etc.

First, you should forget there are any "tools" installed on the Omega for use with the expansion. And while the documentation is frustrating, it does tell us some useful information that would have taken us a few minutes to figure out or if you are me quite a few minutes to figure out:

The Expansion is based on the popular PN532 NFC Chip and communicates with the Omega via UART1.

• PN532 chip
• talks via UART1

# nfc-scan-device
nfc-scan-device uses libnfc reboot-3483-gd1bcad0
1 NFC device(s) found:
- pn532_uart:/dev/ttyS1:
    pn532_uart:/dev/ttyS1

• device is on /dev/ttyS1

error   libnfc.driver.pn532_uart        Serial port already claimed: /dev/ttyS1
nfc-mfultralight: ERROR: Error opening NFC device

• their "tools" are using the libnfc driver

Ok so to get back answering your question, to control the expansion from inside a program you have two choices:

1. Find a library in the language of your choice that uses the libnfc driver and tell it to talk to a pn532 chip on /dev/ttyS1.
2. Find a library in the language of your choice that can talk to the pn532 on /dev/ttyS1 directly.

OK, I figured it out. Here's a test script I wrote real quick to have a proof of concept:

import os
scan = os.system("nfc-list")
def scanFunc():
while 1:
scan
return scan 
print(scanFunc())

import string
outfile = open("result.txt", "w")

outfile.write(scan)

Even ignoring the issues with the code I probably wouldn't want to use this in any real-world scenario. Did you by chance come up with something else? And honestly for something like what you are trying to do here you could just write a shell script and save yourself the overhead of the python interpreter.

However, if you do want to write something in python, find a library that lets you use one of the above two methods I mentioned and I think you'll be much happier with the expansion. I know I was.

You're trying to run that command inside the python interpreter in interactive mode, but you need to run it on the command line in your shell. The python command will also need to be in your path, there was a checkbox for that during install. (You may have already selected it and be good to go.)

@Lazar-Demin @haythem,

As that was my thread I'll join in here.

I ended up resolving my issue by purchasing and attaching an antenna.

I had made the assumption that the device would be ok without one if it was near the router, but that was not the case. The antenna made things a lot better.

You're trying to run that command inside the python interpreter in interactive mode, but you need to run it on the command line in your shell. The python command will also need to be in your path, there was a checkbox for that during install. (You may have already selected it and be good to go.)

@crispyoz Following that logic you could also say that bringing up another interface shouldn't cause the routing to be updated in favor of that interface as that may not be your intention. Yet that is what currently happens. And if the routing is going to be modified when I bring up that interface, I'd expect the changes to be reverted when I bring it down.

@Lazar-Demin Ok I will take a look.

Hey Guys -- @Lazar-Demin,

Pulling out the LTE for another project and came across another issue.
I updated to the latest firmware and was delighted to see that the "o2lte" command was correctly disabling the LTE data now. (I haven't tested sharing yet.)

However I did notice that when you disable the LTE data, the Omega does not fix the routing table.

• When you boot your board and are connected to WiFi, the default route is correctly configured to use that.

• If you then enable LTE data, the default route is correctly configured to go out of that interface.

• However, when you then disable the LTE data there is no default route added back to the routing table so some traffic will fail. At this point there is no default route at all.

If we could get this fixed and another firmware pushed out, let me know and I'll test it.

Edited -- Enabling and disabling LTE sharing works well too now.

Thanks,

Nate

I found a thread in the lvgl forums where @Lazar-Demin was talking to those guys trying to get a working build of micropython + lvgl for the omega here: lvgl forums. Unfortunately I don't know if he was successful or not and couldn't find a package anywhere for it. I'm not a c coder and would very much be interested if someone knows how to get micropython + lvgl working on the omega 2.

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

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.

@Lazar-Demin

I saw you were working on getting a build of micropython with lvgl for the Omega2 working here. I was wondering were it stood and if you were able to get it working?

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

Considering it's just OpenWrt / linux I'm sure there is a way. I'll keep digging into it. Might just need to swap ap / sta.