Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Erratic performance of badger OS when using battery #6

Open
bjohas opened this issue Mar 15, 2023 · 16 comments
Open

Erratic performance of badger OS when using battery #6

bjohas opened this issue Mar 15, 2023 · 16 comments
Milestone

Comments

@bjohas
Copy link

bjohas commented Mar 15, 2023

With the badger on usb power, it’s nicely responsive. However, on battery, the exact same disk image reacts differently.

For example,

  • the QR code app usually doesn’t launch when selected from the menu. Also, when it launches, it flashes the ‘no qr codes’ text, despite a qr code existing. When I press up or down, the QR code appears. The happens both on AA power and LiPo.
  • On USB power, the QR code app launches straight away, and straight away displays the QR code.

Also, the

  • A+C combination doesn't work reliably on battery power - it takes several tries to exit an application
  • On USB power, no problem.

I’m running the latest image (v1.19.16 micropython).

https://forums.pimoroni.com/t/badger-2040-w-battery-vs-usb/21698/1
https://forums.pimoroni.com/t/badger-2040-w-alternative-key-to-return-to-menu/21688

Thanks!

@Gadgetoid
Copy link
Member

Managed to replicate this behaviour with the latest builds from #2, I'm not sure what's gone awry but this is definitely not the experience I remember.

From what I can tell it's related mostly to the startup input handling. On battery the Badger (both W and non-W) is turned completely off and relies upon a button press latching the power back on. On W this effect might be exacerbated by importing all the wireless modules, which slows the loading process.

QRGen seems to have a separate bug where it will launch, but not update the display.

I'm looking into it.

Gadgetoid added a commit that referenced this issue Mar 20, 2023
Gadgetoid added a commit that referenced this issue Mar 20, 2023
Gadgetoid added a commit that referenced this issue Mar 20, 2023
@Gadgetoid
Copy link
Member

Things are slightly less awful with the latest CI builds from #2

QR code actually refreshes the screen when it's launched now. It previously made the assumption that all startup button events had been handled and cleared already.

Wake-from-sleep button presses are still finicky, though, and I need to implement some low-level debounce to fix that. It might even make sense to handle A+C as a special case, since it's not easy to press them at the exact same time.

Unfortunately all this requires patches to Pico SDK and low level startup code to catch and latch in the button presses as early as possible and that's completely horrible to work with.

@Gadgetoid
Copy link
Member

Okay there's also this build (GitHub login required for grabbing pre-release builds from artifacts) you could try: https://github.com/pimoroni/badger2040/actions/runs/4471004312

This removes all the Pico SDK patching nonsense and moves the button latching code somewhere I can more easily tweak it. Just my first shot at a 5ms debounce and double read of the button state seems somehow immensely better. So much so that I need someone to confirm I'm not just losing the plot.

One thing I've noticed in this build is that every now and then the system will wakeup but clearly no button press will be latched so it just does a screen refresh. IE: It's possible to press the button just long enough to power on the system, but not quite long enough to register as a button press. This is the behaviour that the low-level patch was trying to address. Ironically, it performs so much better without this "fix" that I'm willing to accept it as a compromise.

Gadgetoid added a commit that referenced this issue Mar 21, 2023
@Gadgetoid Gadgetoid added this to the v0.0.2 milestone Mar 21, 2023
Gadgetoid added a commit that referenced this issue Mar 21, 2023
Gadgetoid added a commit that referenced this issue Mar 21, 2023
Gadgetoid added a commit that referenced this issue Mar 21, 2023
Using `not badger2040.woken_by_button()` to determine if the display should be refreshed on first run prevented these examples from showing their initial display on battery.
@Gadgetoid
Copy link
Member

Gadgetoid added a commit that referenced this issue Mar 22, 2023
Using `not badger2040.woken_by_button()` to determine if the display should be refreshed on first run prevented these examples from showing their initial display on battery.
@thetoastdragon
Copy link

I also have this problem, and I have tried the main build and the newest build of v0.0.2. Everything works reliably on USB power, but on battery if I press any button, the LED will flash, but nothing happens on the screen. The reset button works, and for a few seconds after reset I can go up or down through the menu, but afterwards no response.

@Gadgetoid
Copy link
Member

I've released a new v0.0.2 with yet more tweaks, let me know if it helps.

@thetoastdragon
Copy link

I have given it a try, unfortunately I'm still getting the same problem

@helgibbons
Copy link
Contributor

@thetoastdragon

I have given it a try, unfortunately I'm still getting the same problem

Excuse the possibly obvious question - is your battery charged? Sounds a bit like it's providing enough charge for a few refreshes and then conking out - might be worth trying a different battery if you have one?

Everything seems nice and responsive on battery power with v0.0.2. for me, so I wonder if you're running into some other issue?

@thetoastdragon
Copy link

@thetoastdragon

I have given it a try, unfortunately I'm still getting the same problem

Excuse the possibly obvious question - is your battery charged? Sounds a bit like it's providing enough charge for a few refreshes and then conking out - might be worth trying a different battery if you have one?

Everything seems nice and responsive on battery power with v0.0.2. for me, so I wonder if you're running into some other issue?

Thanks for the suggestion - I got some fresh AAAs but still having the same problem. The reset button works every time though.

@cpottle9
Copy link

cpottle9 commented Apr 7, 2023

I don't know if it is related, but I noticed a behavior change between pimoroni-badger2040w-v1.19.16-micropython.uf2 and pimoroni-badger2040w-v0.0.2-micropython.uf2.
I downloaded the v0.0.2 on April 6.

I'm using a 3xAA battery holder I bought from Pimoroni to power my badger2040w.

When running v1.19.16 on battery after I switch the battery holder on the LED lights and my micropython code runs.

With v0.0.2 the LED does not light and my micropython code does not run.
But, when I press any button it wakes up, the LED lights, and my micropython code runs.

@salimhb
Copy link

salimhb commented Apr 27, 2023

Is anybody else having issues with WIFI on batteries? I think that it was working fine for me with pimoroni-badger2040w-v1.19.16-micropython.uf2. With 0.0.2, I can't get WIFI to work at all on batteries (2xAAA).

@cpottle9
Copy link

cpottle9 commented Apr 27, 2023

@salimhb, other than the issue I mentioned in my comment on April 7 (in this thread) it works for me.
I opened an issue in gitthub #14
I see someone from pimoroni added a documentation tag.
So it seems they won't be fixing this problem.

I am running 0.0.2 on my badger2040w.
You can find my app in github here https://github.com/cpottle9/badger2040w-temperature-sensor

When you apply power do you see the LED come on?
If no, try pushing one of the front buttons.
If the LED comes on at that point then you are seeing the problem I mentioned on April 7.

Normally I run with 3xAA, but I tried 2xAAA (just now) and it works fine.
I noticed a bare PICO W stops working when battery voltage is drops below about 2.2 volts.
I do not know what the limit is for a badger2040w, possibly it is higher.
Just in case, try a pair of fresh AAA and see if that helps.

Be aware, there is a problem in 0.0.2 with doing machine.lightsleep() after disabling wifi using wlan.deinit().
lightsleep() will return immediately.
The fix for this is not merged yet in the main micropython repo.
The pull request with the fix is micropython/micropython#10803

@salimhb
Copy link

salimhb commented Apr 27, 2023

@cpottle9 thanks for the tips. Indeed, I tried another set of AAA batteries (Energizer MAX) and wifi worked. I guess that the rechargeable Eneloop batteries are a bit weak. They were able to run all other apps that do not need wifi without problems (badge, QR, ...). Only wifi is not able to connect. I was hoping that the AAA rechargeable batteries that I already had would work. I guess that I will try the battery pack sold here.

@cpottle9
Copy link

@salimhb, I don't know if that battery will meet your needs.
It's capacity is only 400 mAh.

I googled and an energizer max AAA is 1100 mAh.
With two you have 2200 mAh.

That LiPo battery likely can power a badger2040W including wifi.
But, depending on your use case it might only last a few hours or a few days.

@thetoastdragon
Copy link

thetoastdragon commented May 1, 2023

I sent mine into Pimoroni and they found a faulty connection, so hopefully when I get a replacement this will be solved.

Update: Yes my particular problem did turn out to be a faulty connection - solved now.

@bjohas
Copy link
Author

bjohas commented May 1, 2023

@salimhb @cpottle9

That LiPo battery likely can power a badger2040W including wifi. But, depending on your use case it might only last a few hours or a few days.

We've done some measurements on the badger, albeit without wifi. During a display update the current draw is about 32 mA. Suppose you have it running for 10 seconds, this gives about 0.1 mAh per update. (WiFi will consume more.)

If you leave the device running at say 35 mA on a 350 mAh battery, you'd get 10 hours of use.

However, the badger has a clever standby. For 'standby' the badger actually cuts power to the Pico completely, leaving only a current of about 0.03 mA. That's 0.03 mAh consumption per hour, or about 0.7 mAh consumption every day. Therefore, on a 350 mAh battery (using round numbers), you'd get 500 days standby. For the same battery capacity, you'd get 3500 screen updates (taking 10 seconds each), and assuming that the device sleeps in between.

Hope this is useful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants