Proper Off menu item and 'Turn On' gesture

[pwarren]

While my current implementation of an off button 'works' it doesn't seem to preserve the battery much more than a day or so.

Also, I need to figure out how to get the unit into a state that can monitor the buttons for the turn on gesture, I don't think my EnterSTANDBYMode() can do that, it appears to only be able to look for rising edges on the PA0 pin or interrupts.

[MichaelRColton]

I haven't had time to look at or play with your new code yet, but I think I remember you mentioning turning off peripherals. Were you talking about those internal to the MCU, or the various external devices attached to the MCU?

I didn't design the PSDR with an eye for excellent standby efficiency (not that I don't want to, it just wasn't high on the list and I had other things to worry about) but I did include the ability to kill power to many of the sub systems on the board (via MCU controlled FETs), and some of the chips can be turned off by setting them to lower power states via whatever bus they are connected to.

I was pretty sure that the pins I used for the encoder switch, and maybe (hopefully!) the paddles supported pin change interrupts that should be able to wake the MCU, but I am not positive. Also potentially helpful would be slowing the clock way down, and setting up a routine that, for example, wakes the MCU on the first pin change event, then quietly watches for the other events in the gesture (whatever form that ends up taking) before bringing itself (and the other subsystems) up the rest of the way. If it doesn't see those other events within a certain time window, then it assumes that first event was unintentional and goes back to sleep.

I think the boards draw around 8mA (is that right?) before they are programmed, so that might be as low as we end up getting, but that should give 10ish days, which I think would be reasonable at this stage of development.

[pwarren]

All I've done so far is do the opposite of the setupPeripheralPower() function, i.e: __GPIO_CLK_DISABLE() etc etc. then call HAL_PWR_EnterSTANDBYMode(). Not sure how much it helps, but It does recover when the reset button is pushed for at least a few hours after turning it off.

I should have a bit of time this week to look a things in a bit more depth for power management, after I get myself together for my https://linux.conf.au/ miniconf presentation. I'll definitely be showing off the PSDR while I'm there :)

[MichaelRColton]

I made a mistake in my measurement before (I was using a different meter and misread it) so it draws ~80mA before it's programmed, and that's about what your turn-off code gets us down to.

Some thermal imaging shows that our biggest power consumption is the frequency synth chip (U241: SI5338). Pretty sure that can be powered down in code.

The LCD control circuitry is wasting some power (not sure if there is a command to power that down), not including the backlight.

Also bad are the phase/mag chip (U314: AD8302), And the AD8131s (U260 and U253) and there isn't anything that can be done by the MCU to power them off.

Looks like I have some changes to make in the next rev.

We'll want to issue a command to put the SI5338 (and LCD if possible) into a lower power state, and then I don't think we'll get a whole lot lower than that.

And, of course, getting the wake-up gesture going. (P.S. Sometimes hitting reset didn't see to want to wake it, not sure why...)

Top side with LCD

Top without LCD (that bright spot in the middle is the heat from the back of the SI5338)

Bottom

[sanamon]

I know it's not so high-tech, but perhaps an old-school switch between battery and radio would solve the problem? :-)

[jeffersonbenson]

Gonna see if I can revive this thread 😁
Is the goal here to work something like (https://github.com/chacal/stm32sleep) where there is a low-power SLEEP state and then a WAKE gesture?
Based on the circuitry, there isn't really a great way to completely disconnect the device from the battery. At this point it looks like the best we can do is get it to a low enough power state for short to medium-term storage, and then advise users to bring a spare battery pack?

[jeffersonbenson]

To follow up on my above comment, couldn't you also just add a slide switch inline with the battery and have it poke out the "front" of the case, over by the rotary encoder? See below crude mockup:

[sanamon]

Hi, I’m sure it’s the easiest route at least. But i’d start by looking into the preamp issue (preamp not enabled, perhaps by not bing initialized in software) as this thing is deaf as a brick right now (sensitivity around -70dBm if I remember correctly, indicating 50 dB “missing”) Regards Jonas

…

4 feb. 2021 kl. 18:48 skrev Jeff Benson ***@***.***>:  To follow up on my above comment, couldn't you also just add a slide switch inline with the battery and have it poke out the "front" of the case, over by the rotary encoder? See below crude mockup: — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jeffersonbenson]

@sanamon I see what you're saying with regards to the preamp issue. Perhaps something that can be brought up in a separate issue for further discussion?
For the issue at hand finding a compatible switch is the quickest way to power the whole device off.