Posts made by cas

And going....

root@Omega-FA93:~# uptime
 07:33:38 up 727 days, 13:49,  load average: 0.00, 0.00, 0.00
root@Omega-FA93:~#

@jokre said:

Another scenario is if I boot the Omega2 up with the battery attached and using USB power and then disconnect the USB power, the Omega2 continues to operate. But... if I re-attach USB power again, the Omega2 dies (and the orange LED goes off and the AP stops to work). Power LED is still on and if I have anything presented on the attached OLED expansion, it still shows even if the Omega2 is not working so the hardware stack has power coming into it.

Fairly common problem I've seen. What I do to overcome it is use a really good power supply (>=2A) and a short USB cable with thick gauge cable.
Typically I see it when powering the device via USB with battery attached and then there's a power failure. The device continues to run on battery, but as soon as the power returns, it dies. Solution = short, thick gauge USB power cable.

@Lazar-Demin

Thanks for the update and indeed, I did receive a "Your Crowd Supply order has shipped!" notification for my LTE's on 1 November.
Apologies, I meant to post a follow up about that, but have been somewhat distracted.

@TheMonkey-King said in Omega2 LTE just launched!:

I haven't heard anything from Onion or Crowd Supply. What is going on with shipments, please? I should have my order in hand or at least an explanation of the delay. I tried Crowd Supply but it's a black hole over there.

Please advise.

Thank you.

Seems some have made it out to backers:

• [resolved]GPS device disappeared on Omega2 LTE
• Omega2 LTE Wireless not working
• Omega2S+ LTE - GNSS/GPS positionning : no init file

So I'm also wondering where in the world my O2 LTE's might be...
@Lazar-Demin - Are you able to provide an update on the current status for us?

@Douglas-Kryder said in [resolved]GPS device disappeared on Omega2 LTE:

@György-Farkas said in [resolved]GPS device disappeared on Omega2 LTE:

The USB Host port of this board is not accessible (it's not exposed) because it's currently used by the LTE module.
So flash the firmware via USB is not possible at all.

thanks. so i read the guide and there is no mention of firmware recovery for this LTE model. is that the case or is there some undocumented path like maybe just creating a serial connection from the interrupted boot sequence menu to a computer. or, maybe store a copy of the firmware in a special folder on the emmc . or did they give this LTE no recovery path? i've been thinking about getting this LTE to replace a particle electron but having had to do the recovery sequence on a few original omega2+ because of bad firmware, i'd won't buy one if recovery isn't possible.
thanks for your insights, very helpful info.

I thought we put our concerns regarding this USB recovery aspect to rest just after the project launched. Well, I seem to have been convinced enough so that I decided to back the project, but I can't seem to find that now...

@Suman-kumar-Jha
This is a bit beyond my skills as I don't python much and don't AWS or MQTT at all, so perhaps someone else can get you to the answer much quicker than I can.

However, looking at the error you posted, it looks like you are getting a timeout while trying to publish.

Perhaps you need to increase the timeout duration?
A bit of google searching reveals that there are a couple of timeout settings that can be tweaked (.configureConnectDisconnectTimeout() and .configureMQTTOperationTimeout()), perhaps you need to look into those?

There's also this open issue on the aws iot python sdk (which I assume you are using): Recommendation on handling publishTimeoutException #211

@Suman-kumar-Jha
Please check if you have both of the ca-certificates and ca-bundle packages installed as explained here: FAQ: I get Error 48 or Error 77 when using curl

[edit]
Or perhaps review if the solution documented in this thread is helpful: Connected and immediately disconnected from AWS IoT ?

Still going strong:

root@Omega-FA93:~# uptime
 12:23:21 up 576 days, 18:38,  load average: 0.00, 0.00, 0.00

@György-Farkas
Is there supposed to be some level of compression built in there? I don't think so, but I haven't been following along to closely recently.

fwiw, I understood @Douglas-Kryder 's question to be more along the lines of: Given a 500K persistent storage facility, how much of my data could I store there compressed as a backup.
Apologies if I misunderstood.

Anyway, that potential misunderstanding aside, looking at your figures regarding the persistent storage, I'm a bit confused with the values that you've posted.
eg. Here:

root@Omega-5BE1:~# rm /mnt/mtdblock7/*
root@Omega-5BE1:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock7          512.0K    196.0K    316.0K  38% /mnt/mtdblock7 # empty

The size: 512.0K - That's ok
The used: 196.0K - That's not empty

So something looks off with that partition.

@Douglas-Kryder
The answer you will find universally for this questions is: "It depends."
Specifically, it depends on the "compressibility" of the source you are compressing.
Some things compress well, eg. text
Some things don't compress at all (or so little as to be meaningless): eg. compressed files

Once you have a reasonably good idea about what you intend to store in the partition in a compressed format, you will have to do some trial and error to determine how well it compresses and whether or not it will fit.

I don't think there's any other way to determine an answer to your question, but if there is, I'd be interested to know as well.

@Andres-Santos
A more recent set of steps can be found here.
There's not a huge difference, basically clean the feeds before updating and installing them and symlink to the preferred .config.

Includes: Jumpstarting the Onion Omega2 (at the $8 level)

Humble Book Bundle: Programmable Boards by Make Community

@UFD
This post of mine might help.
Alternatively, you'd have to review the git changelog, reviewing where the versions change and tag that commit. Which is basically what I did.

@UFD
Troubleshooting similar odd problems on my last builds turned out to be as a result of a misalignment of lede-17.01 feeds and openwrt-18.06 source.
If you're compiling the openwrt-18.06 branch, make sure your feeds are in line with those by cleaning, updating and installing them before running make. i.e.

./scripts/feeds clean
./scripts/feeds update -a
./scripts/feeds install -a

@crispyoz
UCI defaults is a special directory where you can drop scripts to do initial device setups or configurations on first boot.

@crispyoz
Your file will be there, but is being replaced and removed at startup by the code in: files/etc/uci-defaults/14_banner.

@Edward-Cheadle
Make sure that the filesystem on which your docker environment is installed and where the container(s) are housed has plenty (>= 40GB in this context) of free space.

eg. If docker's home is /var/lib/docker make sure that /var (or / if you don't have /var in its own filesystem) has lots of free space.

@Edward-Cheadle said:

it appears that there is no way and no need to increase the container size. BTW I'm running Ubuntu 18.04 with extfs filesystem. Hope this makes sense ?

Yes, that's correct, the container will grow in size dynamically as you build the sources.
What you need to do is to ensure that you have sufficient space in your docker environment to accommodate (at least) a 30 or 40GB container. Apologies if that was unclear.

@Chris-H
I can't speak for all instances, or even previous instances of why you have seen this, but in this instance, the last source build (b223) is identical to the b222 build and contains the same version data.

Based on that, I'd say that the call by oupgrade to https://api.onioniot.com/firmware/omega2p/latest is returning the version info from the source which is consistent with your current version, rather than looking at the binary files present in http://repo.onioniot.com/omega2/images/

The fact that you are on a newer version than the 'latest/stable' according to oupgrade, yet it identifies the older firmware as a new version, is probably just one of language semantics and might be resolved if the tool were to differentiate between 'stable' vs 'latest'.

@Edward-Cheadle said:

It looks like I have alot to learn and feeling a bit out of my depth.
Presumably the firmware revision should match that on my board ?

Take your time, but yes, it may seem a bit daunting at first. And there will be bouts of frustration. Ask questions, the community will help where we can, but we also don't know everything... We all learn from each other's mistakes.

If you are new to this, then it will be best to get to the point where you can do a successful build i.e. run make to completion without any errors, before you start to introduce your own specific changes to the source. That way you will know that any errors are of your own making and not errors with the build environment and you will know where to focus to investigate and solve them.

Regarding the firmware revision, it doesn't have to match what you currently have, any recent one should work on the O2Pro, but it's probably best to stick at one level until you are confident with what you are doing. Comments on the fixes/changes in each can be found in the CHANGELOG.md