root@Omega-FA93:~# uptime 07:33:38 up 727 days, 13:49, load average: 0.00, 0.00, 0.00 root@Omega-FA93:~#
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.
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.
Seems some have made it out to backers:
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?
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...
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
Or perhaps review if the solution documented in this thread is helpful: Connected and immediately disconnected from AWS IoT ?
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.
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.
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. :)
Includes: Jumpstarting the Onion Omega2 (at the $8 level)
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
./scripts/feeds clean ./scripts/feeds update -a ./scripts/feeds install -a
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.
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.
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'.
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
Looks like your connection to Community was lost, please wait while we try to reconnect.