Hi hobbya,
Excellent!
This method may be sufficient for most sensor applications with little data. In the demo sketch, I changed to advertise every hour and used it for about 4 hours, and it communicates data without any problems. The current is also so low that we cannot hope for more. Thank you very much for your valuable information.
Yes this simple approach is only good for small amount of data. For the exchange of large amount of data, we have to use your connection-based approach.
Based on hobbya’s suggestion, I measured the current when the peripheral only advertises.
- Average current for data transmission every 10 seconds
The method the peripheral only advertise could reduce the current to 115uA, which would be a great benefit for data transmission. This can be very effective for transmitting a small amount of data. - Sleep period current
The average current during the sleep period is less than 5 uA, which is comparable to the DeepSleep mode.
I tried the scan response a little further. The mechanism is:
adv => scan => scan-request => scan-response
Peripheral is advertising every 100ms continuously non-stop.
The hit rate of scan-request and scan-response is good using the NRFconnect app on mobile phone but quite low when running on Xiao board.
If the peripheral receives the scan request and transmits the response, its current consumption is like below:
If the peripheral does not receive the scan request, its current consumption is like below:
When the peripheral is scanned by the mobile phone app, it shows continuous streams of the 1st waveform but when scanned by Xiao central, it shows the 2nd waveform most of the time.
By looking at the serial port of the central, the hit rate is around 5% over 3 minutes, see attached.
CoolTerm Capture 2023-07-02 18-08-54.zip (7.9 KB)
Below is the 15-byte scan response (name of peripheral) I am looking for.
So if using simple advertising approach, the user should pack all the data in a single advertising packet and avoid using the scan response. Then he can reduce the advertising interval to lower the consumption and duplicated packets. If scan response is unavoidable, the advertising interval should be sufficiently long to ensure the scan response can be picked up by the central.
If a very reliable and secure data exchange is needed, the connection-based approach is preferred.
I used a sniffer to capture the scan response packets in the office. Nowadays there are a lot of BLE devices everywhere. Only the peripheral was powered up and the central was not powered. Below shows the scan response transmitted by the peripheral.
It shows that the peripheral was working hard to entertain the scan requests coming from other BLE devices. If the central is placed in a busy environment, it will compete with other devices to make the scan request. It is not surprising that the central may need considerable attempts before getting a response.
I finally found out that of the 31 bytes of the advertised payload, 5 bytes are used for information such as flags and data length, 16 bytes are used for UUID128, and only 10 bytes are available for data transfer. It seems that I still need to transfer data using the scan response as well. I am working on the code now.
Perhaps we can eliminate the UUID128 and only send the packet as a manufacturer specific data (MSD) packet. Use the manufacturer ID as the filter to receive the packets. Pretend to be one of the below companies:
BLE Company ID
Hi hobbya,
Thanks for the spot-on tips.
I was able to get 24 bytes of payload using filter.MSD().
Once I measure the current consumption, I will post the results comparing connecting vs. advertising.
Excellent msfujino !! Your examples will certainly benefit other users who are still struggling. It is always a pleasure to see how other fellow hobbyists develop their interesting applications.
@msfujino
I was able to get 24 bytes of payload using filter.MSD().
For non-connectable advertisements, the flag can be ignored. You can gain a few more bytes to the payload by not sending the flag.
I have considered a method to advertise a small amount of data (up to 24 bytes) added to the MSD(Manufacturer Specific Data) without connecting to Central. Peripheral advertises with data on them unilaterally, and Central retrieves it from the scan data without connection.
The experimental conditions were
BSP : Seeed nRF52 Boards 1.1.1
Board : Seeed nRF52 Boards / Seeed XIAO nRF52840 Sense
System ON Sleep : Using RTOS delay()
Task : Send 8 bytes of data every 10 seconds
Current reduction measure : Turn off the blue LED used for BLE, On-chip regulator is in DCDC mode, On-board Flash is OFF
Measurement: 3.00V applied from pppk2 to 3V3 pin of XIAO
The current consumption for normal connection and transmission was 261uA, and a significant reduction of 20uA when transmitting only by advertisement.
In this experiment, Peripheral advertises 10 times every 10 seconds to ensure that Central captures Peripheral in a reliable scan. The number of times is a tradeoff between reliability of data transfer and current consumption.
In the previous experiments I have posted, I used WFI() and TRC interrupt for System ON Sleep, but from this experiment, I used RTOS’s delay(), which consumes much less current.
While delay(), Peripheral consumes almost no current other than RTOS current since there is no BLE connection.
I think 4uA is comparable to Deep Sleep.
nRF52_XIAO_LightSleep_AdvScan.zip (4.4 KB)
2 Likes
Hi hobbya,
Thanks for the info on FLAGS.
The next topic is data transfer in the case of multiple peripherals.
If I understand correctly, the default advertising type set by Adafruit is: BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED
Within an advertising interval, the peripheral will first transmit on ch37 and switch to receive mode to listen for any scan/connect request; it then will repeat the same again on ch38 and ch39.
If we do not need the packet to be scannable/connectable, we should be able to set the type to:
BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED
I suppose the peripheral’s radio will only transmit on ch37, 38, 39 and will not enter receive mode. Not sure if this can further lower the power consumption. I do not have the tools with me to verify the idea but at least the code compiles and the packet can be received by the central.
Bluefruit.Advertising.setType(BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED);
Bluefruit.Advertising.restartOnDisconnect(true);
Bluefruit.Advertising.setIntervalMS(100, 100); // in unit of ms
Bluefruit.Advertising.setFastTimeout(5); // number of seconds in fast mode
Bluefruit.Advertising.start(5);
I tried a simple test and 20uA is down to 17uA.
Thanks for the update. Indeed it will be interesting to see if the advertising performance is still acceptable with multiple peripherals in the surrounding.
Have a great weekend.
Wow, that’s epic and I’m lurking HARD for the multiple peripheral magic 
can you answer or comment on this ;
If I have 4 BLE devices in a case. The devices could advertise there status WITHOUT any connection and my Central app could connect Only when the Status from an advertising peripheral indicates a need? (all while using the least battery)
Does this seem reasonable to you GURU’s 
So even the Alarm conditions could be Boolean advertised data bits ?
I need to look over the BLE spec on the topic. I like the approach though over a scan & connect and NOTIFY for Alarm data *(you have to be connected to get it)
You guys are doing the Yomans Work , Thank You for sharing the enlightenment 
it definitely inspires and helps MyCode.
GL
PJ
PJ the on-air behaviour of the BLE radio is governed by softdevice and the user has to choose a behaviour which meets his application.
There are 2 types of scanning method by the central: passive scanning and active scanning. The last example released by MJ was based on passive scanning. This means the central is waiting passively for updates transmitted by the peripheral. The peripheral transmits advertising data packets whenever itself wants to and will not care if the transmitted packets will reach the central. Since there is no handshaking between peripheral and central, the peripheral can operate under the lowest possible consumption. Passive scanning is a good match if the application can tolerate data loss and latency.
Active scanning allows the central to play a more active role. Upon receiving an advertising data packet, the central can send a “scan request” to peripheral and peripheral will transmit another advertising packet (scan response) which carries information not covered by the previous packet. Each advertising packet payload is limited to 31 bytes which includes both the overhead and real data. Active scanning allows 2 rounds of advertising or 62 bytes. If the application requires more data or if the central wants to transmit back to the peripheral, a connection is needed. Central will send a connection request to peripheral and once the connection is established the two ends can exchange information in either direction.
All the advertising packets by any BLE devices are transmitted over channel 37, 38, 39. So the peripheral has no idea if its advertising data collides with other users’ peripherals. The central also listens to whatever peripherals. This is why the BLE data rate is high and the packet length is short, it is to avoid collision. To make the central’s life easier, the advertising packet transmitted by the peripheral is divided into different types. For instance if it is non-connectable and non-scannable, central will not bother sending a scan request or connection request.
MJ’s first example is based on connection operation. The advertising packet is connectable and scannable. When the central sees the advertising packet, it will request a connection to collect the data. A connection guarantees the data to be securely exchanged between the two ends because they will negotiate to operate on the other RF channels, no longer limited to 37, 38, 39. It is not surprising that the consumption is higher as more handshaking is involved.
Going back to your question, you have to determine if you can tolerate loss of alarm update using passive scanning. There is no assurance that the central can receive the update every time since the 4 peripherals may compete to transmit to the central if they wake up at more or less the same time. The BLE protocol has automatically added a random delay to the advertising packet to reduce the chance of collision among devices. It is a good approach if there are not many advertising devices in the surroundings. In case collision happens and the advertising cycle is short say 10s then you still have the chance in the next 10s but if the cycle is 1 hour then you have to wait until next hour. In MJ’s example, the peripheral transmits for 1s over every 10s. The transmit interval is 100ms so there are 10 advertising packets sent out over 1s. You can increase the hit rate by extending the 1s duration or to lower the transmit interval (20ms minimum) and of course central will pick up duplicated packets. In other words passive scanning makes use of simple excessive advertising to increase success rate. You can work out the mathematics for the probability but it is more practical to adjust through trials in the actual environment.
That’s a very interesting discussion. I want to build a datalogger for outdoor/cave. To collect data, one will connect to the logger through BT/BLE with a smartphone. My initial idea was to add a button. You press the button and it is starting BT/BLE connection. But if I can avoid the button, I can simplify sealing. So, the logger can send through BLE an advertising packet each 60 s. If a smartphone in the vicinity act as central active scanner, it can start establishing connection and collect data (and configure the logger). Overall, I will stay with a low power consumption (~20 µA). Is my approach right?
Hi Eric_S,
If the battery capacity is small, it is recommended to use passive scan. Peripheral advertises unilaterally every 60 seconds and Central reads data in passive scan (without establishing a connection). If there is enough battery capacity, it is better to have an active scan and properly connected.
I have experimented with Central’s passive scanning of 4 Peripherals.While the advertisements from 4 Peripherals sometimes overlap, at least more than half of them seem to be captured by Central.
The settings that seem to be involved are as follows.
Data length is 28 bytes
Bluefruit.Advertising.setIntervalMS(100, 100);
Bluefruit.Advertising.setFastTimeout(1);
Bluefruit.Advertising.start(1);Bluefruit.Scanner.setIntervalMS(50, 25);