Inky Frame - Deep Sleep explanation

Is the Deep Sleep behaviour of the Inky Frame explained anywhere? There is a note in the Getting Started that plugging in a battery won’t wake it and you have to press a button to get it to run main.py…

Clearly that isn’t reset as its asleep - which button then? Or do I need to code that in? If so, how?

Currently I have the BBC News example loaded and its fine on USB power (except my power bank goes to sleep - lolz), but it won’t wake up on battery at all…

The product page says:

Inky Frame can turn off the power that drives the Pico W and the display completely. It can be woken back up by the RTC , the front buttons or the external trigger on the extension header.

So I assume it is any front button. If I understand how the deep sleep works it’s a hardware/circuit thing, so there wouldn’t be any software necessary. You issue the deep-sleep command, and when you want to wake the board, you press one of the front buttons.

The BBC news example seems to be set up to prevent deep-sleep, are you sure that is what is causing yours to get stuck?

#set up and enable vsys hold so we don’t go to sleep
hold_vsys_en_pin = Pin(HOLD_VSYS_EN_PIN, Pin.OUT)
hold_vsys_en_pin.value(True)/inky_frame_news.py

It can be woken up is the key phrase, I want to know how to enable that…

Also it is in deep sleep, look down at 2nd to last line and it sets it Pin.IN to allow Deep Sleep then executes time.sleep() but only takes a time not a pin. Hence my original question.

The RTC, front buttons and external trigger are indeed hardware wake ups, you don’t have to do anything to enable them (though you do need to tell the board to stay awake long enough to execute your code if running on battery - that’s what the ‘enable vsys hold’ business is about).

I haven’t had much time to play with wireless on Inky Frame yet, but try commenting out the last time.sleep in the news example if you’re running on battery? I think that’s there to stop the feed constantly refreshing if connected via USB but I suspect it might be interfering with either going to sleep or waking up…

1 Like

Oh that’s cracked it. Now it sleeps for 5 mins (well 255 seconds) and auto refreshes or I can push the buttons to wake it up early. Now I just need to add my Calendar and a few other screens and I’m all set.

Many thanks.

1 Like

For an inky frame, is there a way to determine

  1. if it’s being battery powered?
  2. what the battery level is?
  3. if battery is close to being too low to function?

I think you should just be able to read the system voltage like you would be able to on a normal Pico - we could do with an example showing that. I’ll try and whip one up when I get a moment!

1 Like

@kjw Try this! Inky Frame battery example · GitHub

I’m not sure if there’s a way of checking if it’s plugged into USB power or not (other than checking if vsys is reading out of battery range), I’ll let you know if I figure it out

Now updated to read vbat to identify if it’s got USB power
(this didn’t seem to work so well for me when run through Thonny, wondering if my computer’s USB voltage is on the low side)

Thanks, I had a quick play with the voltage stuff and it appeared ok on REPL but then when I put some similar code into my program it was showing voltage level on USB and about 0.1V (clearly wrong for my 3 alkaline) on battery power. Probably my error.

My Inky Frame does not appear to ever run the MicroPython code when I power it on. After powering it on the reset button also does nothing. This is for code which isn’t using the rtc timer. I think that can confuse the situation at times. It does wake up on button presses but these need to be fairly long presses for it to wake up. I think that’s a little confusing from a user interface point of view.

In Getting Started with Inky Frame it does state

However, if you’re powering Inky Frame by battery things will work a little differently - the hardware level power saving features will kick in, which can be a bit confusing and make it look like you have a duff battery.

Once you hit reset on a battery powered Inky, you’ll have to press one of the buttons to trigger it to wake up and run main.py.

Is that confirming the behaviour I observe? I do not have to press reset at all. If I power it on and then press button B for about 1.5 seconds my MicroPython code runs.

If this doesn’t seem to be working, try holding one of the front buttons down for a second or two - it needs a fairly solid press to wake it up (this is because there’s a short delay whilst MicroPython starts up, so it can miss quick button presses).

Is that delay really related to MicroPython start-up time? Does that imply a compiled C++ program can behave differently? I assumed the RTC chip is somehow waking up the RP2040 and it wouldn’t matter what runs afterwards? Or does the length of button press determine the initial power-on time until Pin(2) is held high to maintain power? If so, that doesn’t seem like an ideal hardware design. Should a MicroPython program bring Pin(2) high as soon as possible in the code?

Are there any plans for a MicroPython library like the C++ InkyFrame class to make all this easier?

For the RTC timer, how accurate is the clock likely to be?

Is there documentation on how the external trigger works? Is it 5V safe?

then when I put some similar code into my program it was showing voltage level on USB and about 0.1V (clearly wrong for my 3 alkaline) on battery power. Probably my error.

Sounds like you weren’t pulling GP25 high? I got those sort of readings before I figured out you needed to do that on a Pico W.

If you are doing this in your code bear in mind that pulling this pin high this might interfere with doing things with wireless - GP25 is also the wireless interface’s SPI pin (though I haven’t noticed any problems reading the battery and posting data via wireless on Enviro).

My Inky Frame does not appear to ever run the MicroPython code when I power it on. After powering it on the reset button also does nothing. This is for code which isn’t using the rtc timer. I think that can confuse the situation at times. It does wake up on button presses but these need to be fairly long presses for it to wake up. I think that’s a little confusing from a user interface point of view.

This is correct, you will always need to press a button (or use the RTC/external trigger) to wake it up when running on battery, whether or not you press reset. I found it useful to think of the battery behaviour as ‘off by default’ - you need to hit a wake up trigger/tell the board to stay awake, otherwise it will turn itself off to save battery.

Is that confirming the behaviour I observe? I do not have to press reset at all. If I power it on and then press button B for about 1.5 seconds my MicroPython code runs.

Yep, you don’t have to press reset, under most circumstances a button press will wake it up on its own. I found reset to be occasionally useful when Inky Frame got itself into a confused state when I ran broken code on it and I needed to interrupt it :)

Is that delay really related to MicroPython start-up time? Does that imply a compiled C++ program can behave differently?

Yes, I believe so. I think our software folks have recently merged some super early wake up stuff for the Badger and Enviro builds, so hopefully we’ll be able to roll that out to Inky Frame and make things a bit more snappy.

Are there any plans for a MicroPython library like the C++ InkyFrame class to make all this easier?

Not sure, probably best to pop in a feature request/ issue on Github if this would be useful to you?

For the RTC timer, how accurate is the clock likely to be?

I can’t see an accuracy figure based on a quick scan through the datasheet (it’s here if you fancy some light reading), but it seems pretty accurate so far, the frequency of my Enviro readings seems accurate to the second…

Is there documentation on how the external trigger works? Is it 5V safe?

You need to transition the external trigger to high to trigger a wake up. It’s 3.3V max.

Hope that helps!

Thanks for the information.

For one minute and three minute alarms I timed it as 55 seconds and 146 seconds. That doesn’t seem very linear so maybe I’m doing something wrong there. I’ll do some more testing when I get a new one.

Do you have a rough idea of when Inky Frames will be back in stock?

I think we’re hoping to make some more this week!

Would it be possible to get an example that demonstrates the button wake-up more directly? I’ve been unable to get it working. My inky is connected to power and not a battery.

Given a simple case like this:

while True:
    button_a_led.on()
    time.sleep(3)
    button_a_led.off()
    time.sleep(3)

I would expect that I could press a button to cause the LED to turn on/off early without setting any explicit IRQs, but that’s not the case. Also, maybe this is more of pico question than an inky question, but is there any difference between time.sleep and machine.lightsleep? To then tie it back to inky, should the buttons be able to wake the device from machine.deepsleep (to run main.py) or can the buttons only be used to interrupt a light sleep?

Inky Frame will never go into (hardware) sleep if you have it powered by USB - the sleep behaviour only kicks in whilst on battery. I don’t think machine.deepsleep (or more specifically, the waking up part!) is implemented on RP2040 yet which is why we’re building in sleep functionality to the hardware.

The LEDs are user controllable LEDs and not specifically linked to the buttons so won’t (currently) automatically do something on a button press. I think you’d need to set up an IRQ interrupt if you wanted to be able to interrupt a standard (software) time.sleep?

Do the buttons have pin numbers such that I could implement an IRQ interrupt for them?

Speaking of which, is it documented anywhere what the pin numbers for everything are? So far I’ve only been able to identify pins via the example scripts.

I haven’t found a complete list of pins in the documentation, but the pins are declared with their respective names in the InkyFrame C++ class:

    enum Pin {
      HOLD_VSYS_EN  =  2,
      I2C_INT       =  3,
      I2C_SDA       =  4,
      I2C_SCL       =  5,
      SR_CLOCK      =  8,
      SR_LATCH      =  9,
      SR_OUT        = 10,
      MISO          = 16,
      EINK_CS       = 17,
      CLK           = 18,
      MOSI          = 19,
      SD_DAT0       = 19,
      SD_DAT1       = 20,
      SD_DAT2       = 21,
      SD_DAT3       = 22,
      SD_CS         = 22,
      ADC0          = 26,
      EINK_RESET    = 27,
      EINK_DC       = 28
    };
1 Like

The buttons are connected to a shift-register. So they can be polled by clocking out the current state. Interrupts are not possible. But the InkyFrame-class records which button was pressed during a hardware-wakeup event. So this might help.

The inky_frame functions make reading buttons easier now particularly with the gap in time between Pico W on the Inky Frame powering up and first line of MicroPython code running. Keep an eye on Some inky_frame functionality looks broken due to bit order confusion · Issue #719 · pimoroni/pimoroni-pico · GitHub as I think it’s a little buggy at the moment.