Power Modes

Shehryar,

Thanks a lot for doing this. However, for us few non-Git users left in the universe, would you mind describing how to download the test_radio_sleep app, or maybe add it to the slasi-wixel-sdk-ad15b0c ZIP file (I have that one and can re-download it if necessary). :wink:

TIA,

Frank

This link should download a zip file:

github.com/slasi/wixel-sdk/zipball/radio

I’ll merge it back to my main branch as soon as I have done some more testing.

-Shehryar

Thanks!!

Frank

I forgot to mention that I’m happy to help with testing - just let me know. You can reach me directly at "paynterfgmail/dot/com

Thanks for the offer, Frank. Just use it as you normally would, and let me know if you see anything weird.

-Shehryar

Were slasi’s changes for radiomacsleep() / resume() ever merged into the SDK ? I am attempting
to create an app that reads a sensor that is powered off the P1_1. The algorithm uses PM2 to sleep
for several minutes, wakes up, sets P1_1 high to turn on the sensor, takes a reading and sends it
out over the radio, sets outputs low and goes back to sleep.

The app works well but I can’t seem to get the power consumption below 0.23 ma (~230 uA) when sleeping.
I started with the latest SDK and used some code to go enter PM2 for the sleep operation. I set all outputs
low prior to sleep ( powering off sensor ). I thought the radio must be what was using the power, however
after using slasi’s SDK, the app is still using the same amount of power …

Hello.

No, slasi’s changes have not been merged. How are you powering the Wixel, and what states are the I/O pins in? If you drive VIN_IN and VBUS_IN pins low, you might be sinking some current into those pins. You might try using the simple code I posted and see what current draw you get when running that code.

–David

Wixel is powered by battery ( 4xAAA )

I was building with latest Wixel Master SDK. I tried using slasi’s SDK and got the same
numbers 230 uA. This is measured from the battery connection with a BK Precision meter.
From your post the regulator could be responsible for 80uA but that still leaves 150uA

The code drives all the outputs low by calling makeAllOutput()

void makeAllOutputs() {
    int i;
    for (i=0; i < 16; i++) {
        setDigitalOutput(i, LOW);
    }
}

OK

I tried running the simple code you referenced. It measured 0.36 ma. This is about 130 uA higher
than my app.

OK, so it sounds like you have four AA batteries connected to VIN and GND. Do you have anything else connected to the Wixel? Did you try with and without USB connected? I haven’t seen your full code but it sounds like the only difference between your code and the mine was that I drove the USB pull-up resistor line (P2_0) high. That could cause some extra current draw if the Wixel is plugged into USB, so I recommend doing all current measurements without USB connected.

–David

There is a sensor with power connected from P1_1 . Since I set all digital outputs to 0 / low before
going to sleep, I can see that P1_1 is zero volts while sleeping. Originally, I was powering the sensor from the 3.3V pin
and this was drawing 1.8 ma ! I instead use P1_1 to turn on/off the sensor when going into and coming out of sleep mode.
The sensor talks to the wixel using serial data to UART1 (P1_7). There wixel pin P0_0 is also connected to the sensor
and is used to trigger a reading.

There are no USB connections during any of the power measurements. I simply connect my meter in series with
the battery pack to measure the current being used by the wixel while running ( 26 ma ) and sleeping ( 0.23 ma )
Power to the sensor off P1_1 is zero volts, as expected, while the wixel is sleeping.

My code was based on the wireless serial link app.

Today I got a new Wixel from our stock and tried to see if I could recreate your results. I connected power from a variable bench power supply to GND and VIN, with the VIN connection going through a multimeter to measure current. I loaded the code from my first post in this thread and then disconnected USB, so the only things connected were GND and VIN. With this setup, I found that the current drawn by the Wixel depends on the input voltage, going from about 48 microamps at 3 V to about 140 microamps at 6.5 V.

You said you weren’t able to get the current consumption below 230 microamps, so that does seem to be a lot worse. Would it be easy for you to disconnect your sensor entirely from the Wixel just to make sure it isn’t causing the current draw? Also, would it be easy to a different Wixel and see if you can get its current draw to go lower?

It would be nice to see some pictures of your setup. Also, could you measure the voltage between the GND and VIN pins?

–David

I was able to track the issue down to my sensor circuit. The sensor was being powered from
"high current" P1_1 pin. I was able to verify that when the Wixel powered down, the voltage
between P1_1 and GND was 0V as expected. What I didn’t expect, and what I noticed was that
there was a voltage between P1_1 and P1_7 ( Uart Rx pin ) being used to read serial data from
the sensor. I measured 0.5V between these pins while the Wixel was sleeping. :confused:

My sensor transmits TTL serial data, but the data needed to be inverted in order for the Wixel
to make sense of it. I had put together a small inverter circuit to invert the serial data from the
sensor to the wixel’s uart rx pin. Things were working fine with serial data transmission but as
I found out the resistance between P1_1 and P1_7 was now only about 3K.

So, even though the wixel set all its pin to outputs prior to sleep, I was seeing 0.5V across these
pins. 0.5/3k = 166uA ! I figured this must be the extra current I was measuring. So, I swapped out
the 3.3k for 100k in the inverter. Now with the sensor connected, the sleeping Wixel draws only
130 uA with a battery voltage of 5.7 V. This is very close to your measurement and closer to my
design goal. :slight_smile:

It sounds like you probably had a pull-up resistor in your inverter, so when you drove the Wixel’s RX pin low it would cause current to flow through the pull-up resistor. I don’t think this has anything to do with P1_1, but if you could provide a complete schematic of all the connections you made then we could be more sure. I don’t think the resistance between P1_1 and P1_7 is 3k; I suspect you were just measuring that pull-up resistor. You could have just left the RX pin as an input, since it already had a pull-up on it guaranteeing that it won’t be at an intermediate value. You might also try using the internal pull-up on the Wixel so that you don’t need an external pull-up.

–David

Here is the schematic. As mentioned the sensor is powered off P1_1. P1_7 is the UART RX
and the circuit simply inverts the signal. If this can be done without these parts by programming
the wixel’s inputs I’d be interested to know how to do that.

I changed R1 3.3K to 100K and the consumption is now 130 uA

I am not sure why there would be current flowing through R1 if both P1_1 and P1_7 are actually being driven low. Even though you were able to solve your problem, I suspect that something is still wrong with your system so it might be good to debug it further. You might want to measure the voltage on both sides of R1 with respect to GND and see if both voltages are 0 V. If so, there should be no current flowing through R1, so changing the value of R1 should not matter.

Most of the Wixel pins have pull-ups enabled by default so you could simply remove R1 without any code changes. You can read more about the pull-ups here:

pololu.github.io/wixel-sdk/gpio_8h.html

–David

I did measure P1_1 to gnd while in PM2 sleep and it was 0V
The drop across the R1 was 0.5V, hence my suspicion about flow being the issue.
With the 100K the current dropped proportionally as expected.

The sensor is has 4 pins Vin, Gnd, RX (which I pulse to take a reading) and TX
which send the TTL serial data with the measurement.

BTW: Thanks for your help…

I enabled a pull-down on P2_4 and drove P2_0 high in the code below, but there might be other ways to take care of them.

Awesome work here, it’s much appreciated!

A quick (possibly naive) question - the test_sleep app works well, but I’m unable to reprogram the Wixel :sweat_smile:
I’ve tried connecting P2_2 to 3V3 and reconnecting the USB cable, but the device remains unrecognized by the Pololu Wixel Utility. Any advice on how to reprogram a Wixel running test_sleep?

Hello.

I am sorry you are having trouble with the Wixel. I tried to reproduce this problem by loading both slasi’s version and lummo’s version of test_sleep, but everything worked fine for me. In case you have not seen it yet, the “Connecting Buttons and Starting the Bootloader” section of the Wixel User’s Guide has instructions for forcing the Wixel into bootloader mode that should work no matter what kind of app is loaded on it. Keep in mind that the Wixel might be inadvertently powered through its I/O lines, so it is best to disconnect the Wixel from everything as a first step. If you continue to have trouble, please let me know more details about your attempts to get the Wixel into bootloader mode so I can help you troubleshoot.

–David

1 Like