SAMB11 Xplained Pro current measurement and consumption

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the current measurement header and the measurement system via Data Visualizer actually measuring. The user guide talks about "MCU" and "peripherals". What are they in detail? I seem to get with the iBeacon example using ULP around 30 uA from the current  measuring pin while advertising. Data Visualizer shows over 100 uA, but connecting the bypass jumpers one by one I get the same 30 uA and 70 uA. So by default Data Visualizer seems to be measuring a different thing. Where is this 70 uA going to? There is nothing connected to the extension headers and no pins are driven (as far as I know). Is my multimeter measuring all the current used my the SAMB11 module? Or is "peripherals" actually VDDIO on the module?

Why does it take a long while untill the current settles to these values? The current is first around 6 mA (~3s) and then drops first to 1.4 mA (~10 s), 300 uA and very gradually drops to the final value.

How can I get the 13 uA mentioned in the datasheet for 1 sec interval advertising? There seems to be about 25 uA even with 10 s so there is clearly too much consumption during sleep.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I'm even more confused about the power consumption of SAMB11 Xplained Pro. My multimeter scale setting seems to have a huge effect on the current. E.g. now I'm advertising at 10 s interval. Looking with a real oscilloscope or Data Visualzer in AS7.0 there seems to be nothing happening between the 10 s pulses. If I set my multimeter to 200 uA scale (introducing 1 kohm resistance to current measurement pins), I get about 17 uA and 1.2 V voltage drop during the peaks thus 1.2 mA peaks. Also Data Analyzer is showing 17 uA and about 1 mA peaks with the jumper closest to USB set to BY-PS.

The I switch to 2 mA range, which means 100 ohm resistance. Now my multimeter shows 28 uA and also the Data Analyzer shows that. I know from past experience that my multimeter shows very accurately the same on different scales. It is specified to have 0.2% +2 accuracy on 200 uA and 2 mA ranges and it has 0.1 uA resolution on 2 mA. At 2 mA the voltage drop at a peak is almost 400 mV thus 4 mA, which is also shown by Data Visualizer.

Then at 20 mA range (10 ohm) I get about the same, maybe 29 uA and it's already hard to trigger on the peak. Maybe it is about 50 mV thus 5 mA. Not much is changed going to 2 A range with 0.1 ohm (with from the cables and fuses).

This also works the same way with e.g. 500 ms connected. Then Data Analyzer (and multimeter) shows about 16 uA between the peaks at 200 uA range, 930 mV drop and Data Analyzer shows "windows average" of 34 uA.  With 20 mA range the values are 29 uA low and 60 uA average.

Why is the current consumption that much lower on 200 uA range? How is current routed from the current measurement header to the module? 1.2 V voltage drop while running is not that good, but doesn't seem to stop SAMB11 from working. But does the current consumption depend on what kind of filtering is introduced between a LDO/battery and the module?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Grounding AO GPIO pins and not using a terminal connected to the virtual port made by Xplained port helped redusing the current consumption a lot. Now I'm getting about 2.6 uA sleep and 20 uA average running iBEACON example as is. Analysing the power with and oscilloscope reveals that each advertising cycle takes about 16 uAs thus power consumption is now 2.6 uA + 16/adv_int. Seems to be about the same connected and also timer wakeups take the same 16 uAs despite not having any TX/RX. A bit lower current during, but a bit longer time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just stared my computer from sleep and the sleep current of SAMB11 on Xplained Pro was again too high, about 7 uA. Then I started a terminal (Tera Term) connected to Xplained Pro virtual port (USB, not connected to SAMB11) and no change in sleep current. But after closing the terminal the current dropped again to 2.6 uA. So it appears you have to first connect and then disconnect the terminal! What is happening here???

I tried to unplug the USB, thus depowering the board. Then I get to 2.6 uA without this terminal connect/disconnect. Also now the board goes must faster to low current state. I can see the 2.6 uA after about 3 s.

What was actually going on with the AN GPIOs floating? Was it just their input circuit wasting that much? I couldn't see any peaks in the power thus no extra interrupts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So now I have the sleep current close to the datasheet ERRATA value of 2 uA. But not the average one! BlueSDK 5.2 Release notes show iBeacon measurement of 14.7 uA average and datasheet about 13 uA. If I put my multimeter in 200 uA range, I can get similar 14+ uA figures with iBeacon. But then the voltage drop is so big, that trying to connect fails likely due to current jump. Even worse the device can jam into boot taking 3 mA all the time. All this is fixed going to 2 mA range (1 kohm -> 100 ohm), but then the average current is about 20 uA (occasionally 18+ uA).

 

Why does increasing resitance to power line decrease consumption so clearly? According to data sheet higher voltage yields smaller current due to switching regulator at VBAT, which takes most of the current. Or is it just fake by e.g. drawing current from peripherals etc. during voltage drops at peak currents? But there is a small effect also during sleep and then the voltage drop is minimal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be helpful to see the code, if you are willing to share it.

In my prototype, I have configured AO GPIO 0-2 to pull down vs floating or hardwiring to Gnd via the extension header. Goes to sleep now very quickly.

Looks like you're very close now. Thank you for the insights on virtual USB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code is just the iBEACON example. All I have done is to modify the connection and advertising interval.

In case CONNECTED (sorry can't get the code insertion to work):

                PRINT_H3("Conn.Interval: 0x%04X %dms\r\n", conn_params->conn_params.con_interval, (int)(conn_params->conn_params.con_interval*1.25));
                PRINT_H3("Conn. Latency: 0x%04X\r\n", conn_params->conn_params.con_latency);
                PRINT_H3("Supr. Timeout: 0x%04X\r\n", conn_params->conn_params.sup_to);

                at_ble_connection_params_t *connection_params = (at_ble_connection_params_t *)((void *)&params[50]);
                connection_params->con_intv_min=(int) (105/1.25); //1.25 ms each, min 20 ms for IOS
                connection_params->con_intv_max=(int) (125/1.25); //1.25 ms each, >min+20 ms and <2 s for IOS
                connection_params->con_latency=7; // The number of intervals we can skip
                connection_params->superv_to=5000/10; //10 ms each, 6 s max for IOS
                connection_params->ce_len_min=0;
                connection_params->ce_len_max=0;
                status = at_ble_connection_param_update(conn_params->handle, connection_params);
                PRINT_H3("Sending connection param update. Status : %d\r\n", status);

 

And under DISCONNECTED

                adv_int/=2; //1600 at first = 1 s
                if(adv_int < AT_BLE_ADV_INTERVAL_MIN)
                    adv_int = AT_BLE_ADV_INTERVAL_MAX;
                PRINT_H2("Start Advertising again at %dms\r\n", (int)(adv_int*0.625));
                adv_data[25] = adv_int*0.00625;
                adv_data[6] = 10;
                adv_data[7] = 20;
                status = at_ble_adv_data_set((uint8_t *)adv_data, 27, (uint8_t *)scan_rsp_data, 18);
                PRINT_H3("Status : %d\r\n", status);
                status = at_ble_adv_start(AT_BLE_ADV_TYPE_UNDIRECTED, AT_BLE_ADV_GEN_DISCOVERABLE, NULL, AT_BLE_ADV_FP_ANY, adv_int, 0, 0);

 

I'm still very confused about the current measuring. Now I'm testing with the LED on board. Turning it on increases current 30 uA in "MCU" and 3 mA in "peripheral" according to Data Analyzer. So is SAMB11 consuming 33 uA instead of 3 uA because it's sinking 3 mA through LP-GPIO? Or is the LED even directly connected to the pin toggled by LED_On/Off? Seems to need led_init in every resume in order to keep the LED on during ULP. For a while I was wondering how bgright the LED is with just 30 uA!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was able to adopt the iBeacon code into my growing app. It certainly helped a lot. I'm now able to access the BLE device from an iPhone app (generic GATT), along with running rest of my AO-GPIO and AO-TIMER app.

What's odd is that after my app wakes up from the AO-GPIO interrupts, the BLE service is no longer advertised. Have tried various things to reinitialize BLE subsystem, but to no success thus far.

My current drain is 10 microamps (less when I'm not using the virtual USB), so it appears ULP is working for me. I'm am initializing AO-GPIO0..2 to pulled Down by default.

Last Edited: Mon. Apr 24, 2017 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm also trying to get my own application to run with iBEACON, but have troubles with events/interrupts. I would like to do my own stuff at the same time the system resumes anyway in order to do the BLE RX/TX. I thought I had it working, but run into the same problem as you: no BLE output. The power consumptions looks just the same as it was transmitting, but nothing is seen on my phone.

 

I used the button callback on SW0 to create one event. It doesn't wake up from ULP, but activates when the system wakes up due to BLE interval. I also tried to setup a timeout for the at_ble_event_get. That works fine, but each timeout takes as much current as RX/TX cycle. So If I want to modify data and send it at 250 ms latency I have to wake up 8 Hz from ULP which takes 140 uA instead of just waking up each 250 ms with 70 uA.

 

Actually you can tell from the current peak, if it is transmitting or not. A slight difference in shape and height, but average current drawn is just the same. Setting latency higher than 0 in the connection shows that doing my callback + event from there makes the system use two time slots in a row. The first one is used for my event (nothing sent) and the second one is a real TX.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm attaching my source file, a modified version of the Startup app. Both my AO_GPIO and AO_TIMER logic are working well at this point. I am able to process application logic in the main loop between BLE wakeup cycles.  It has run overnight without incident, which is an improvement over prior versions.

Only issue I'm facing now is that the iBeacon code stops advertising after the first time my interrupt / timer logic is initiated.

Hope that's helpful.

Rick

Attachment(s):