Proffie Standby Time Improvements

So long story short here, I believe I have found a way to dramatically decrease power consumption in the low power operation state of Proffie V2.2 boards and I wanted to share my progress so far in case others are interested in contributing or providing feedback. I’m curious to see if this approach works similarly on V3.9 (or older V1 boards for that matter) too.

First, some background. If you are like me you’ve got a few Proffie installs that use kill-keys to restrict battery drain, but there is at least one or two hilts sitting on your shelf yet to be installed that really are not ideally suited for a kill-key installation (either too hard to access said kill-key without a fair bit of disassembly or just straight up not big enough for a full port or switch). I understand that v3.9 has some intended improvements in this regard but they may not be implemented yet (I don’t have a v3.9 board yet, so I may be mistaken). Point is, current power management on Proffie seems to still leave a fair bit to be desired and I’ve come across many posts of people saying they typically only get a few weeks of standby time which largely lines up with what I have seen on several of my hilts.

So just how bad is the current setup was my first question. I hooked up a high-precision current probe and compared Proffie V2.2 with stock V7.12 against hilts with Goldenharvest GHV3 and Xenopixel v3 installs which I felt fairly accurately represented other typical alternatives on the market and should serve as a baseline for standby current consumption.

Results from my findings are outlined below. The chart outlines what each line represents, but obviously each entry is taken when the corresponding board is in sleep or low power mode.

Three very interesting observations:

  1. Proffie registers higher current consumption than both Xeno and GHV3. I suspected this would be the case given that my Proffie hilts always seem to run out faster than my Xeno / GHV3 hilts, but this was confirmed in the above.

  2. Proffie has seemingly two different low power modes: One with the motion controller still active, the other with it disabled or timed out. For testing purposes, I took the “Proffie No Motion” readings with “ENABLE_MOTION” commented out–which is not truly a fair comparison as it bypasses a few fringe cases I’ll comment on below, but does give a theoretical “best case” with stock Proffie code. To get the “Proffie With Motion Active” readings, I uncommented “ENABLE_MOTION” and enabled at least one motion switch activation function (twist to activate for example). I found that this resulted in the motion controller chip never going to sleep, which makes sense if you are expecting to be able to twist the hilt at any time to wake it up (by definition, it can’t go to sleep). Current consumption in this second mode was substantially higher @ approximately 4.8mA vs the ~1.5mA average consumption for the “No Motion” state however I was frankly unable to get into this mode naturally (without turning off ENABLE_MOTION) which is concerning since I did try this with stock profile configurations. I am guessing there may be a bug somewhere preventing the motion chip from powering down but I haven’t looked into this yet.

  3. Alarmingly (and not pictured in these results), I found that some fonts prevented the Proffie from ever entering low power mode, resulting in a constant 17mA draw indefinitely. I am not sure yet what the cause for that is and perhaps it has been identified and since resolved, but this obviously drops the battery shelf life to a matter of days. I am not including this in my findings since this is clearly an OS level bug and not the intended behavior of the device as-is, hopefully someone else here can comment on this case / investigate more closely (I can provide details on which fonts I was able to replicate this on reliably).

So what does this mean exactly in terms of shelf storage time. My philosophy on standby time ratings is that it should be time to reach 50% capacity versus how long does it take to discharge 100%. Arguably, if the battery cell is at or below say 30% state of charge it is not going to last particularly long and therefore it really doesn’t matter how long it takes to get to say 0% since the hilt can’t be used meaningfully at that point. I chose to classify my “expected runtime” calculations in terms of an arbitrary 1500 mAhr discharge capacity, which I estimate to be between 30% and 50% for most commonly sized 18650 cells.

For stock Proffie firmware as it stands today (as of V7.12), I estimate 1500 mAhr discharge occurring after approximately 41 days for optimized sound fonts (ones that do not require motion controller remaining active in low power sleep) or 13 days for motion enabled fonts / prop files which is realistically most if not all fonts I’ve tried so far, but perhaps I was doing something wrong. Compared to the likes of GHV3 which should be around 125 days for equivalent discharge, or Xeno3 at approximately 67 days, that is a fairly substantial difference.

Next step was to identify what the major draw was on Proffie. The obvious player was the processor, and that ended up accounting for about 95% of the power consumption as expected (will get into how I determined that later on). As it turns out, the processor isn’t entering sleep mode at all currently, it is simply switching to a lower operating frequency in low power mode to reduce current draw. This lines up with the measurements I took.

I then came across this thread during my research where an even lower frequency was used, but it produced instabilities:

Instabilities aside, I decided it was worth trying this configuration to see what the impact was. The claim was that it increased standby time up to 2 years which sounded promising. Results were a bit less impressive unfortunately, shown below (“LP Run” against “Stock” firmware):

Apparently since I am a new user I can only post one picture, so just imagine another beautiful chart here showing a shift from 1.2 mA to 0.600 mA at the lowest

While better, it was still producing about 700 micro-amp current draw on average (note the transition between 0.625 mA and 1.4mA @ approximately 3.65vDC, I have some theories as to why that is happening but nothing conclusive yet). This is largely on-par with at least the Xeno v3 board, but this can be better still.

STM32L4x processors are specifically designed for low power operation so I knew there had to be a way to improve this, especially since we aren’t currently leveraging any clock stopping functionality really at all at present. Per ST documentation, the STM32L4 series chips theoretically could be drawing as little as 30 nano-amps (0.03 micro-amps, or 0.00003 mA) with varying levels of sleep mode capabilities, but it’s complicated by the fact that not all power operation modes are recoverable so this limits options just a bit.

My first attempt was to try STOP 0 mode which, per ST, should result in 110 micro-amp (0.110 mA) sleep current operation and is the most mild / simple solution. It stops the clock, powers down most peripherals while retaining full memory storage leaving full “wake and run” recovery a possibility.

Results from this were very promising:

Still can only show one chart, just imagine being blown away by a chart showing 0.35mA to 0.15mA consumption in STOP mode

Based on the above estimates, this should result in 1500 mAhr draw over approximately 300 days, plus or minus a bit (just shy of my target of 1 year).

So why hasn’t this been implemented in Proffie already? The main challenge as I understand it was figuring out how to wake the processor back up once it was in this mode, since ST defines only 5 discrete wake-up tolerant GPIO pins (PA0, PC13, PE6, PA2, PC5)–2 of which don’t even exist on the processor used on Proffie V2 due to its form-factor. Obviously, if we have to go in and cut power to the board to wake it back up again that largely defeats the purpose of this exercise (not having to disassemble the hilt in between uses and having it “just work” automatically with minimal input or exterior penetrations).

Fortunately the chip has an onboard RTC which gives several unique advantages. First and foremost, it means we can schedule wake-up events at set intervals (actual time-based units) without having to trigger an actual pin-level wake-event. In other words, we can put the chip in sleep (STOP) mode for a number of seconds, wake back up and see if we should stay awake, then immediately go back to sleep again if not to the tune of only being “awake” for a few dozen instructions (negligible impact on overall consumption). We use this technique in battery management controllers for time-based data tracking and maintenance functions.

So the strategy was simple then, set up a STOP interval of 4 seconds inside a loop that evaluates whether either the auxiliary button or power button was depressed when it wakes up (so at most, the operator has to depress one of the buttons for 4 seconds). If not, it goes straight back to sleep. If so, we exit the loop and resume normal clock speeds and re-initialize peripherals and off to the races. The result was basically best of both worlds: low sleep current draw without having to make any hardware changes. The only real drawback to this was that the board can’t be woken using exclusively gesture control (so a bummer for any hilts that have no hardwired buttons). In theory, this approach could be easily adapted to re-initialize the motion controller in between sleep evaluations to check for specific motions, but I don’t currently have plans to investigate this further at this time and it would likely have a non-negligible impact on the sleep current savings. I have not yet decided whether it makes more sense to simply reset the CPU on wake-up to perform initialization, or to just re-initialize peripherals upon wake individually. Currently I have it performing a full CPU reset on wake as this is on par with GHV3 / Xeno3 functionality and for my purposes this is ample, but it is theoretically possible to just pick up where we left off before going to sleep with a few initializations (motion chip / I2C bus in particular).

Still, I wanted to see if there was a way to improve on this further since the chip should theoretically be able to get down to about the 30 nano-amp range which would be the ultimate holy grail as far as low power sleep.

Switching from STOP mode to SHUTDOWN mode (the lowest possible current draw) the results were extremely promising:

And again, be blown away by a theoretical chart showing 0.019 mA current consumption in all its glory

Obviously this is a further substantial improvement and we go way beyond a 2 year theoretical standby time (to the point where it doesn’t really make much sense to compute as other factors like internal self discharge or protection circuit consumption start to weigh in).

The problem though is that memory is completely obliterated during this sleep stage which means the approach used for STOP mode will not work (saber will forcibly restart every few seconds which is a non-starter). So this requires an actual wake-up pin to utilize properly.

Of the 5 pins designated as wake capable, 2 of them are not available on the Proffie V2 processor and 1 of them is the INT pin coming from the motion chip. This leaves PA0 (id-neopixel_data) and PA2 (TX). Now this is where I’m looking for feedback from the community, since neither pin is exactly ideal. The data pin has an inline resistor (and is presumably used on most existing Proffie installs already since it is the recommended data pin to use for pixel), but the TX pin is pulled straight-through. My intention is to use TX as the wake-pin, but I realize this will break backwards compatibility with existing hilts that have serial based Bluetooth chips (which apparently use RX and TX pins). For me, this is an acceptable trade-off (shutdown capability versus bluetooth capability) but others may not feel that way so obviously this should be split off as an optional improvement. Given how successful STOP mode was, it may not be truly needed for most use cases (though smaller cells would obviously benefit still).

Full disclosure, I haven’t yet sorted this out yet as I appear to be fighting internal pull-ups on the pin at the moment and so it wakes up immediately on shutdown with the TX wake enabled (I suspect it may have to do with the internal UART peripheral transitioning from active to inactive during the shutdown command and then triggering itself as a result, but I haven’t had time to sort out decoupling it prior to the shutdown command). This should be a fully solvable problem with the correct register manipulation though. I was able to take the current consumption measurements with the chip forcibly held in shutdown, but I have not yet been able to successfully wake it with the desired behavior. My experience with STM32 MCUs is admittedly somewhat limited compared to other brands so I am learning a lot about the ecosystem as I go here, others more well versed in STM32 may be able to make progress faster on this.

I had planned to wait to post until I had more time this week to sort out the proper wake function for shutdown utilizing the proposed TX pin jumper, but I decided to get the above information out to the community first to start getting feedback / inspiring others in case the shutdown takes longer than anticipated to resolve.

So where is the code? I promise I will release what I have here in the next few days (will update this thread) as I have time to do so since it needs to be tidied up a bit yet (had hoped to get this out this weekend, but the weekend got away from me–spoiler alert, the changes are shockingly simple), but I wanted to start the conversation in the meantime. I am interested in the community response to this and am happy to help answer questions about what I have found so far (afterall, perhaps I missed something in my research or drew some incorrect conclusions).

Thoughts?

2 Likes

This is all very exciting, and it’s really cool that other people than me are working on this problem!

This is about as far as I’ve been able to get.
I have experimented with other ways to reduce power, some of which have worked, but, I usually run into one of two problems:

  1. I can’t reliably make the board come back to life afterwards.
  2. the SD card ends up drawing more power than the CPU when I go to low power mode, so there is no point in doing it.

So I guess my first question for you is: Are these tests done with an SD card? And if so, did you measure power drawn by the SD card? And did you do anything special to make the SD card work properly when going in/out of power modes.

This is a really interesting idea. We may be able to use this to make a deep sleep mode that works for a V2 board. It might not be quite as efficient as a deep sleep that uses a wakeup pin, but it would still be pretty cool if it draws significantly less than 0.6mA.

I usually set my motion timeout fairly low (like 15 seconds or something) when I do my measurements.

Btw, this optimization is currently disabled on github as it causes freezing.
I think the first priority would be to figure out what causes this freezing.

Certain styles can make ProffieOS not able to disable power to the FETs, or keep running without shutting down. If we can identify these styles I might be able to fix them.

Finding and fixing these sort of bugs is important, otherwise any optimizations done on a lower level are sort of meaningless.

YES!
Nice work @linuxpenguin.

All my tests (with the exception of the Xeno3 I just realized) were all conducted with SD cards inserted and operational so it’s interesting that you say you were having problems with SD card sleep current as this never even crossed my radar. How much mA draw were you able to get your testing down to?

I did run into an issue with the interrupt pin on the motion chip causing some additional drain (the “Motion Disable” code around line 244 of lsm6ds3h.h calls for the accel and gyro to be disabled but does not also disable the INT pin which I believe was asserting high in sleep causing additional drain (I2C_WRITE_BYTE_ASYNC(INT1_CTRL, 0x0); cleared that up) but I don’t think this is what you were referring to.

I’ll note that I’m coming off a V2.2 board here as I don’t have V3.9 boards yet. Are you using V2.2 for your tests or V3.9? There may be a difference in the newer board design perhaps.

As far as the board not coming back to life after low power activation, I haven’t focused extensively on this part yet as I’ve been assuming it to be acceptable for a RESET event to occur on wake-up (the ultimate goal is to get the SHUTDOWN method to work, which will require a full reset anyhow) but I haven’t noticed any wake-up issues so far when recovering from STOP mode (which has full memory retention).

1 Like

Yes, this should theoretically open the doors to V1 and clearly V2.2 as well for a true low power sleep (full shutdown capability if we assume that TX can be safely reclaimed for this purpose). I’ll need to nab a V3.9 board at some point to see how well the full shutdown method works with an assigned wakeup pin but I anticipate it being functionally equivalent to the V2.2 with the TX wake-up pin reassignment since that is an officially supported wake pin (won’t work for people using bluetooth modules though).

Yes I ended up reducing my timeouts to about 3 seconds for development. I had to similarly reduce the timeout for motion control in saber_base.h too so it timed out before attempting to sleep however I haven’t been able to reliably get that condition to fire naturally as I was hinting at in my initial write-up. I basically have to force that condition to trigger since my fonts I guess are set up to always require motion when the blade is off (haven’t spent much time digging into that since clearly this is a solvable problem, focus has been on the sleep function itself).

Understood. I haven’t spent much time troubleshooting this since it ultimately won’t be necessary with the STOP / SHUTDOWN modes but I wanted to see how close it got us to where I wanted to be (eg: if it got us 90% of the way there then it would have made more sense to debug that than pursue STOP / SHUTDOWN, but that clearly wasn’t the case).

I suspect the issue has to do with I2C interactions being interrupted (at least it seems symptomatic of such behavior), though I2C should adapt nicely to dynamic changes in frequency so that doesn’t make a lot of sense. If there is a compelling benefit to having this part working I may take a closer look, but my code bypasses the frequency down-step entirely at this point.

Interesting. So I have several fonts I can name that end up in this state–technically these were paid-for fonts (or at least came on the SD / config file with the Proffie I bought from Darkwolf), what’s the etiquette for sharing these for troubleshooting issues? I haven’t had a chance yet to try to replicate with the stock fonts from your main site but I’m guessing it only plagues the more complex fonts (Dark-sword one in particular was easy to reproduce on).

Technically the STOP modification can bypass all of this anyhow since it can force the motion controller & other outputs off during the sleep process, but I agree it makes sense to tackle some of these issues in tandem. Let me know how I can help.

So one interesting detail I just noticed in the STM32 datasheet–STOP of course has 3 different modes (STOP0, STOP1, STOP2) each with varying degrees of standby current draw. I have been using STOP0 because I incorrectly assumed that was the lowest that would fully retain memory, but I see now that STOP1 and STOP2 also fully retain (was thrown off by the asterisk notating RTC usage, but that applies to current draw and not requirement of RTC usage for memory retention it appears).

If that is the case, simply switching to STOP 2 from STOP 0 should, in theory, reduce consumption of the processor itself from ~110 micro-amps down to 1.1 micro-amps which definitely gets us to the “good enough” range without the need for any sort of wake-button still, meaning should be compatible with all 3 versions of Proffie as far as I can tell without any hardware changes or caveats (minus the inability to wake from deep sleep via motion, but that’s a given for any true low power mode).

I still need to test this so it’s not definitive yet, but it sounds promising and I’ll report back once I have more conclusive findings. My ultimate goal is a fully backwards-compatible patch that can be applied to any model Proffie to drastically cut power consumption across the board to the point where kill switches are no longer necessary.

I don’t think that’s it at least. (It’s sometimes hard to tell which component on the board is actually drawing power.) My problem has usually been that the sd card starts in a super low power mode, but once I have mounted and used it, I have not been able to reliably get it back into that super low power mode.

Maybe open a PR for this fix?

I’ve tested and measured both. The boards are more similar than different, but V3 boards have WKUP capabilities on the POW and AUX pads, which might potentially help.

Also, V3 boards use SDIO, which changes the sd card states and interactions a bit.

While it’s true that “deep sleep modes” (modes where the board isn’t expected to be running anymore, and probably reboot when you wake it up) will automatically suspend anything that is running, we still need to know when to activate these deep sleep modes. In an ideal world, we only invoke deep sleep after everything else has already been shut down for a bit. We wouldn’t want to shut down in the middle of something happening…

Depends a little bit, but a lot of times, people end up sharing styles with me privately for debugging.

@profezzorn,

So some good news here guys. As expected, STOP 2 reduced current even further to the point where gains will be negligible at this point.

I am tracking a typical discharge current of 0.021 mA, or 21 micro-amps in low power sleep. This mode is recoverable using the RTC timing trick I mentioned earlier without any hardware modifications on existing Proffie V2.2 installs (does not need to utilize formal wake pins), I assume it will work fine on Proffie V3.9 too and I assume even V1.5 since it’s largely the same as V2.2 (will need to rely on community for testing on at least V3.9 for now, I have a V1.5 I can try testing on later).

Compared to the full “SHUTDOWN” mode, I am only tracking about a 0.002 micro-amp difference (which tracks with the datasheet) and since SHUTDOWN is not recoverable (requires an actual hardware wake-up pin to utilize) I am abandoning that avenue as negligible gains for non-negligible pin sacrifice / effort. This should keep “sleep mode” behavior consistent across all Proffie boards, though if someone wants to hash out the formal wake-up pin at some point for that extra 0.002 micro-amp gain that would restrict to V3.9+ (unless sacrificing TX pin as discussed previous).

For those keeping track, the above consumption is approximately 125x lower power consumption than stock Proffie “low power” code (assuming average draw is slightly above best possible case which is probably being generous), 45x lower power consumption than Xeno V3 and about 25x lower power consumption than Goldenharvest GHV3 sleep per my readings. I’m calling this good enough.

One strange thing I did find is that the power consumption does go up to about 800 micro-amps below approximately 3.55v battery voltage which is interesting. Anyone have any ideas on why that might be happening? I haven’t had a chance to do a deep dive on the schematics yet. The increase occurs even when the MCU is already in sleep (eg: dropping voltage from say 3.8v to 3.5v with chip asleep produces said results too) so it’s not an active transition or anything the chip is logically doing. I suspect something related to the voltage regulator, though the vast majority of the discharge curve of the cell will still be at the greatly reduced current draw rates so this is not likely to be a significant issue. Worst case, it should be possible to conditionally switch back to STOP 0 below ~3.55vDC which should produce results at or below 300 micro-amps at least, but that will probably be a future improvement.

Give me a few days to clean things up (it is pretty messy right now with trying to get all the registers correct, a good chunk of what I have isn’t ultimately necessary) and I’ll post what I’ve got. It should be a pretty simple drop-in mod but may need some assistance from those more familiar with Proffie OS in the community to fine-tune some of the configurable aspects (EG: right now I have my specific aux & power buttons hard-coded for wake functions at the GPIO level, we’ll want to leverage more global defines for those of course so it supports multiple props and what not–still learning about ProffieOS naming scheme as I go here).

Will do. Odd that I’m not seeing the SD card behavior you are though. I am modifying most GPIO pins to a High-Z state as part of the sleep process which no doubt is helping, perhaps that is part of the issue on your end now.

Interesting, yes that could change things up a bit but I am fairly confident that can still be worked around.

Agreed. My goal so far has been to get the low level functions working, but yes if the higher level functions are not properly ending the system up in an idle state to begin with that is equally problematic. Currently I have the board playing a short beep right before it goes into sleep so I know when the mode is being reached–probably not practical for final deployment but may help narrow down existing issues.

Sure, fine by me (just wanting to make sure I’m not violating any rules or anything). What is the best way to send the style privately to you?

Latest update, I am trying to track down one last issue where the sleep current will periodically (say 25% of the time) revert back up to 0.190 mA (up from 0.021 mA typical with this new approach) and I haven’t determined the cause yet. I figured it was something with the SD card perhaps, but removing the SD card has no impact. Motion chip likewise appears to be in sleep, as do the amplifier and booster. There are some peripherals available to the chip still in STOP2 mode that I am investigating, perhaps one of those is not properly going into low power consistently.

EDIT: Turned out to be related to the booster circuit. Problem appears to be solved, getting 21 micro-amp sleep consumption consistently now.

In any case, I’d like to get at least some feedback from others before proposing a formal PR just to make sure I’m not missing something obvious that isn’t present in my setups here. I’m particularly interested in setups with extra “non-standard” stuff like bluetooth modules and additional LED outputs and such.

I have a V3.9 Proffie on order but it’ll probably be a few weeks before I get time to install that properly, so I’m currently limited to Proffie V1 and V2 boards for testing (edit: turns out my V1 installs are going to be very hard to instrument for current consumption, so I’m limited to V2 testing for now). I’m guessing power consumption will be higher on V3.9 solely due to the onboard lithium charger which has a minimum sleep current of ~25 micro-amps (will double the theoretical power consumption of V2) but that’s fairly negligible.

Anyone here have access to a precision current meter and is willing to experiment with this on their (hopefully somewhat exotic) setups too? @profezzorn ?

1 Like

I do have a reasonably good current meter, and I am definitely going to experiment with some of this stuff. Having PRs, or code snippets would make that a lot easier though.

What do you have?
How did you generate the charts in your first post?

I’m also curious about what you use to measure current.
I have a SIglent SDM 3055 myself, which is reasonable, but the values seems to shift a bit when it switches between ranges.

My AstroAI WH50000A multimeter is not very helpful, because it has one input for 10A current measurement which is not precise enough, and that goes up to 600mA, and that’s too easy to go over, which would trip the fuse.

Before I got my SDM 3055, I used to measure small currents by using a small resistor (~0.16 ohm) and measure the voltage over it. The “small resistor” was actually just a piece of wire… It wasn’t super precise, but in terms of “does this draw more than that”, it was fine. The resistor allowed me to side-step the range issue of the AstroAI meter by using voltage measurements instead of current measurements.

Sounds good!

I created a fork of the main Proffie branch and will get my changes committed here in the next day or two to make the process a lot easier–I haven’t had much time the past few days to work on this unfortunately but I’ll get it done and post back here once they are committed.

The reason I’m hesitant to go straight to formal PR is that I had to make some unorthodox changes to SaberBase and Clock_Control to get the board to reliably enter sleep mode due to the aforementioned issues with some sound fonts just indefinitely staying in high power modes. I’m sure there is a better / more appropriate way to do some of these bypasses which is why I’m looking for community feedback as I’m sure these changes are not the correct way to do this long-term (but will help demonstrate the capabilities of STOP2 at very least).

Sure, so I have access to an Agilent / HP 34401A through work which, while fairly old now, is incredibly accurate. I used that to generate the initial charts by taking the batteries out of the different cores that I have and running jumpers through the 34401A to a variable power supply that effectively simulate a battery. I then adjusted the voltage on the VPS to the various different points to compare current consumption figures. the Xeno v3 and GHV3 were easy to determine because it’s very clear when they enter sleep, Proffie I had to get creative with since there are technically 3 or 4 different “low power” operation states right now in stock ProffieOS depending on which modules are active (as it lacks a “true” sleep mode now), but I did my best to go with the “best case” scenarios, with specific modules forcibly powered down. Not perfect, but it gave me a pretty solid idea of where things were initially before we started using the actual sleep modes.

I’ve also been using an OWON XDM1041 meter too for cross-checking which, while not technically quite as accurate as the 34401A, is still plenty capable of tracking currents in these levels and is considerably cheaper / available to buy new today.

So the Agilent 34401A is nice because it automatically switches between channels internally (so can power the board directly through it at all power levels), but I ran into a similar issue with the OWON XDM1041 which I use most of the time now since the Agilent takes up a lot more space on my desk. Now that I have validated the OWON readings with it to be within ~1 micro-amp at the 600mA channel level, I can get by using the OWON for optimizations.

A quick trick you can do to get around the issue of the fuse tripping on the 600mA line is to run two jumper wires back to the VPS for the positive (or negative, whichever you are instrumenting) lead while still utilizing the smaller 600mA sensing channel. When the board powers up the current will primarily bypass the DMM since the second lead is lower resistance, then once the board actually goes to sleep (or other low power states) you can disconnect the secondary lead so that all power then goes through the 600mA channel without the DMM capping out (since power draw is typically 20mA or less in that state, then drops to micro-amps of course once STOP2 activates).

Or you can do what I do most of the time when running the OWON now, run power through the DMM 600mA channel, then plug in USB and let the board go through playing its font track while on USB with the speaker down at say 150 volume (which will favor USB due to the higher input voltage and lower resistance) and then unplug USB to let it time out and go to deep sleep since the 600mA channel can easily handle the ~20mA or so of idle current it draws after removing USB and before entering deep sleep. I put in a wakeup condition for having USB connected in the STOP2 deep sleep code so that either holding one of the activation buttons down or plugging in USB will force it to wake back up, making it pretty seamless to test things quickly by plugging and unplugging USB (or if you have a USB hub with a physical toggle button for each channel, even easier).

In any case, I will do my best to make time here in the next few days (or for sure this weekend) and get my fork updated with the latest that I have so people can start experimenting. I want to clean up a few things first so I’m not just throwing a jumbled collection of things out there and am nearly done with that.

I have several questions about the Booster circuit that seems to be causing some interesting issues–notably, if the voltage on the battery is lowered below ~3.55vDC and the Booster is OFF in STOP2 for optimal power draw, the current consumption of the board jumps from ~21 micro-amps to ~800 micro-amps without any interaction from the processor. I suspect the booster ends up partially activating in this state but I haven’t done a deep-dive in the schematics yet to get a better feel for why that might be. Forcing the Booster circuit ON (and staying ON) in STOP2 results in the current consumption rising to about 300 micro-amp consistently throughout the full voltage curve which is quite a bit higher than I’d like to see but does prevent the 800 micro-amp spike at the low voltages. I might see if I can add in an ADC voltage check to the battery in between the 4 second wake pulses to conditionally engage or disengage the booster circuit to cap the current draw penalty at 300 micro-amps below 3.55v but I’d also like to figure out exactly why this is happening in the first place of course.

@profezzorn I still owe you the sample fonts that I found that seem to keep the FETs engaged–I was apparently just promoted to a normal user on this forum and see that I can send private messages now so I’ll work on getting those to you too.

My recommendation is to commit your changes to a branch in your cloned reposistory. That way the “main” branch is clean, which makes it super easy to pull changes that happen on my branch onto your repository.

Ideally, your changes will be split up into several small PRs that each fixes or improves one thing. Submitting it as one large PR is likely to lead to long and complicated discussions about good and bad changes.

Usually the way to do this is to create a new branch on your repository for each PR, then copy a small part of all your changes onto that branch and then submit a PR. Usually it’s possible to do several small PRs in parallel, which speeds up the process a lot.

Sure, here is a link to the repo:

Changes are in saber_base.h and clock_control.h of course and are shockingly simple.

Some explanations:

  1. More pins are set to analog than necessary, better to work backwards from something that works though.

  2. Proffie V2 is the only board I am targeting right now. I have a V3 that arrived today but will be some time yet before I can install it. For now, I’d suggest sticking with V2 but I’m curious to see what happens with V3.

  3. I put in beeps to tell when the board is entering low power sleep. Press and hold the AUX or POWER button until you hear the second beep indicating it woke up, then you’ll hear the font identifier indicating the MCU reset. The second beep is important since otherwise you end up turning the saber on or switching fonts immediately on startup–maybe there is a better way to handle that.

  4. As noted, I made some questionable changes in the top part of clock_control.h that I’m sure are not correct. I did this to easily demonstrate STOP2 capabilities, but I am genuinely curious as to why “on” was used instead of SaberBase::IsOn(). I only spent a short while on that though.

  5. saber_base.h modification allows for Sleep Mode to issue a motion requested override to allow the motion chip to go to sleep on its own vs forcing it to sleep in the sleep handler. Again, surely not the best way to handle this long term, but it was needed to get the low power sleep to activate reliably.

  6. As noted before, the MCU wakes up every 4 seconds from STOP2 and re-evaluates for button press / USB to determine if wake is necessary. We may need to put in a check for Vbatt voltage to conditionally enable the booster circuit to prevent it from drawing 800 micro-amps below 3.55v, very curious to hear others thoughts on why that is causing trouble.

End results should show approximately 21 micro-amp draw once asleep. Once I get some other people to corroborate this, I’m happy to work up some pull requests.

2 Likes

I was looking for this change on github, but I didn’t see it.
Is it not required for stop mode to work, or did you just not check it in?

It ended up not being necessary as far as I can tell so I didn’t include it for the moment. I believe this was a fluke before and not related to that particular change, but I need to do more research on it to be sure.

Hi All, some updates.

First, I was able to get some results from Proffie V3 with this update. As expected, current consumption was a bit higher than V2 due to the included onboard USB charging chip, though it is higher than I expected it still.

I clocked approximately 90 micro-amps (on average) which is more than 3x Proffie V2. Per my calculations, the USB charging chip should have only accounted for an additional 20 micro-amps or so (so 40 total), so there may be something else going on here. Still, it is still significantly lower than stock Proffie code so still an improvement.

Second, I also found an old Proffie V1 board that I was able to get running again and clocked it at approximately 450 micro-amps (so 21x higher than Proffie V2) even in deep sleep. This is better than stock Proffie code still, but the gains are significantly lower than Proffie V2 and V3, I suspect due to the lack of power enable switch on the SD card slot for Proffie V1. It is possible there may be further ways to reduce current consumption on V1 but this is something someone else will need to investigate as I don’t have easy access to a fully functional V1 install.

I have updated the clock_control.h file in my Github fork with the following changes:

-Separated Deep Sleep logic into separate function DeepSleep

-Re-enabled existing “standard” sleep functionality by default for those not wanting to use Deep Sleep

-Added defines for enabling Deep Sleep (#define DEEP_SLEEP_TIMEOUT to define the time to wait till sleep from last motion request in milliseconds, #define DEEP_SLEEP_OVERRIDE_FONT_KEEPAWAKE to allow deep sleep functionality to override requests by fonts that may hold the system awake for unknown timeframes and #define DEEP_SLEEP_BEEP_ENTER which emits a short beep to indicate that the board enters deep sleep which is optional

-Reverted a few changes made previously that were ultimately unnecessary.

-Added preliminary Proffie V1 and V3 support

Link to the Deep Sleep Github branch:

Note that there needs to be defines added to the config file now (specifically the deep sleep timeout time and whether you want to override font specific motion timeout inhibits) for this to be enabled, otherwise it defaults back to the standard “low power” run mode behavior.

Hopefully we are closer to being ready for a PR.

4 Likes