you can check out this tutorial

https://onion.io/2bt-omega-bittorrent-machine/

You need to edit the file /etc/config/wireless
Under config wifi-iface sta
set option disabled '0' to option disabled '1'

reboot your omega2+ and it will not try to scan or connect to any WiFi.

@William-Scott

My only concern with using a FET as the power supply is depending on the model it may not supply enough pick current for the normal boot process. I like your suggested setup if we can find a FET that works in normal boot.

Breadboard dock would be a idea dock for the setup. would you mind coming up with a block diagram of the setup?

@György-Farkas

In our test we used a 1000uF polarized capacitor. The power supply is the one used in a the Expansion Dock. Check out the schematics here.

Here is another tutorial you an follow
https://onion.io/2bt-single-command-losantomega/

We have done some internal testing by manually adding a large capacitor between 3.3V and GND while the system is running to emulate a large load. This is enough to introduce a brownout.

What kind of setup do you have in mind so we can programmatically change input voltage?

@William Scott

We are happy to collaborate in coming up with an automated tests procedure. Doing it publicly here on the community is definitely the way to go. This way more people can contribute of rip the benefit of the test result.

Can you share what test setup you have in mind and specifically what input do you need from Onion side?

how are you connecting to WiFi? wifisetup command? Can you share you console log?

Nice project, we will get you on Onion news letter in the coming weeks and you will be able to get some free Omegas for being featured ;)

Lately there has been a lot of discussions about the Omega2+ not being able to boot after unexpected reset. We did some digging and found a solution.

The Problem

In short here is what we have identified as the root of the issue.

• By default both the Omega2+ CPU and Flash memory boots from a 3 Byte address mode
• During boot loader the CPU upgrades both Flash memory and itself to a 4 Byte address mode in order to access higher memory addresses
• During an unexpected reset (brownout) the CPU resets but the memory remains in the 4 Byte address mode.
• The mismatch in the address mode prevent the CPU from booting normally.
• A power cycle at this point will reset the Flash memory back to 3 Byte mode and the system will boot normally

Here is a table summarizing different boot conditions:

The Fix

According to the above table we need to build a solution to have GPIO 6 pulled sown during cold boot and pulled up in at hot boot in order for the system to boot successfully in both conditions. The following circuit does just that.

• During a cold boot GPIO 11 starts as LOW
• GPIO 6 is reads LOW
• During boot the boot loader sets GPIO 11 High (Originally used to provide power to the user pushbutton on Omega2 docks)
• This will charge up the capacitor to 3.3V
• During an unexpected reset or hot boot, the capacitor will temporarily pull GPIO 6 High setting the CPU to boot from a 4 Byte address mode

Please let us know if this setup helps with your situation. We would also like to hear if anyone have came up with a software only solutions. So far we have not yet figured out a way to make the flash memory to cold boot from a 4 Byte address mode.

Here is the Flash memory data sheet for those who are interested in dig deeper MX25L25635E.pdf