Your approach for the peripheral is the same as my sketch. Indeed the central has problems catching the scan response, even though it can recognize the packet as scannable.
/* Display the timestamp and device address */
if (report->type.scan_response)
//if (report->type.scannable)
{
Serial.printf("[SR%10d] Packet received from ", millis());
}
It can print “SR” if I set the type to scannable, which means it recognizes the incoming packet.
The principle of the code is simple, it prints out the report whenever there is a callback. The reports of advertising and scan response shall come up alternatively but as you said the latter does not show up at all.
Some more observations:
Case 1:
Central => my sketch above without MSD filter
Peripheral => adafruit beacon example
Sniffer: peripheral sent out quite a lot of scan responses to central
Central serial: captured a lot less scan responses compared to above
Case 2:
Central => my sketch above with MSD filter
Peripheral => my sketch above but advertising data was reduced to a flag only
void startAdv(void)
{
// Set Flag for discovery mode, optional
Bluefruit.Advertising.addFlags(BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE);
// Construction of data packet to be advertising
if (counter == 0xFF)
{counter = 0;}
else
{counter = counter + 1;}
user_data[0] = 0x59; // little endian format for first and second entry
user_data[1] = 0x00; // (00-59) means Nordic Semi
user_data[2] = counter; // third entry increments with each advertising cycle
Bluefruit.Advertising.addData(BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA, user_data, sizeof(user_data)/sizeof(user_data[0]));
Bluefruit.Advertising.clearData();
// Construction of scan response
scan_rsp_data[0] = 0x59; // little endian format for first and second entry
scan_rsp_data[1] = 0x00; // (00-59) means Nordic Semi
scan_rsp_data[2] = 0xD1;
scan_rsp_data[3] = 0xD2;
scan_rsp_data[4] = 0xD3;
scan_rsp_data[5] = 0xD4;
Bluefruit.ScanResponse.addData(BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA, scan_rsp_data, sizeof(scan_rsp_data)/sizeof(scan_rsp_data[0]));
Bluefruit.Advertising.setType(BLE_GAP_ADV_TYPE_NONCONNECTABLE_SCANNABLE_UNDIRECTED); //Bluefruit.Advertising.setType(BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_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); // stop advertising after 5 seconds
}
Central serial: captured a lot of scan responses
I am wondering if central is not fast enough to catch and decode both the advertising and scan response packets in a short time. I will try to adjust the 2 payload sizes or to increase the serial buffer next time. I have spent too much time on this and my wife is not happy.
Next, I plan to experiment with enclosing Peripheral and Central in an empty cookie can, isolated from the surrounding BLE.
“Scan Response” gets a bit away from the purpose of “System ON Sleep” in this thread, so it might be better to start a new thread on “Scan Response”. I am also thinking of posting this on the following github with issues.
‘GitHub - adafruit/Adafruit_nRF52_Arduino: Adafruit code for the Nordic nRF52 BLE SoC on Arduino’
I just checked. It is working fine.
I will study what is different from the previous sketches.
I will also continue to experiment with how far the data length can be increased and what the current consumption will be.
For the benefit of other users, I would appreciate if you could post something about ScanResponse.
This is a continuation of my experiments to reduce the current consumption of Peripheral by using SystemONSleep in a project designed as a data logger that periodically sends small amounts of data to Central.
Previously, in post #31, I reported that the current was reduced to 20uA by putting 8 bytes of data on the Advertising without a connection.
In a subsequent study,
The length of transfer data can be increased to 59 bytes by using Scan Response,
I found that the current can be reduced to 8.5uA (8 bytes data length, 1m distance, and -70dBm RSSI) by optimizing the transmit power, mode and interval of Advertising.
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 10 ~ 58 data every 10 seconds
Measurement : 3.00V applied from pppk2 to 3V3 pin of XIAO
Current reduction measure
Disable the blue LED used for BLE
Set on-chip regulator to DCDC mode
Set on-board Flash to OFF
Allow Scan only when necessary
Optimize for the application and environment
user data length 8 bytes
Tx Power 0 dBm（RSSI -70dBm）
Advertising Interval 200mS
Thanks MS again for a neat and concise sharing, much appreciated.
At the moment the central is spending a lot of time in scanning since it does not know when the data is coming. BLE 5 actually has a new feature: periodic advertising which allows central to sleep by synchronizing the peripheral and central. Unfortunately, the existing Softdevice used by Seeed or Adafruit does not support such feature.
Originally MS has applied RTC interrupt to the peripheral. Perhaps the same idea can be applied to the central to save power. The central can be set to scan continuously in the beginning. When the scan callback is invoked it stops scanning, starts the timer and goes to sleep. Central wakes up e.g. 9s later and resumes scanning.
hobbya,
I thought that RTC was more accurate and easier to use than delay() and started using it without thinking much about the current during sleep mode. Later experiments showed that RTCs have a monthly difference of more than 1 minute, and furthermore, using FreeRTOS delay() reduces the current, making the use of RTC meaningless.
In my application Central is always connected to the power supply as it writes data to the SD and displays information. I did not think much about the current in Central. Reducing Central current may be an interesting topic. I am now working on the following topic and will think about it in this topic.
‘XIAO_BLE wakes up from System_ON_Sleep and Writes weather data to on-board Flash’
fujino san,
You have spent a lot of time and shared a lot of working examples. It is a blessing to the community if you continue to explore new ideas and post your new findings. Thank you!
Here, Here,
You two guys are a Technical Blessing to SEEED studios FOR SURE. If I were the MAN at that company, Your gift basket’s would have already arrived.
Great examples of what a community of folks can focus on a common problem and sharing the solutions to it. This has helped me personally by shortening my development time $$ and increased my level of knowledge on the over-all subjects. I stand on the shoulders of Giants.
Thanks Guys
GL PJ
Update but leaving it in here for reference, if someone else is wondering:
I just realised while scrolling back trough the postings that you are directly supplying 3.3v to the pins instead of the vbat pads on the back.
I guess this is the reasons and we cannot get lower when using the vbat pads…
Hello msfujino,
i am trying to get my Seeed Xiao NRF52840 non-mbed to use as little power as possible for a battery operated project which will use bluefruit ble as a client.
I used your sketch from 07.07.2023 as the basis to create a bare minimum blink sketch to get some baseline data.
However with i can only get down to 0.14 mA in the delay (measured with a rough resolving 0.00mA multimeter) - 0.41 with blue led blinking.
Did you undertake measures to disable the small charging led on the Seeed Xiao nrf52840?
Hi 1melc,
I measured the current using your sketch. 3.6V is applied to the battery pad on the back. It is about 4.6uA when the LED is off and about 150uA when the LED is on.
WoW,
So who knew, The Interrupt method also effect the sleep, If you use an edge (RISING/FALLING)it uses more current during sleep to maintain the trigger gate, If you use a level (LOW) it uses less current in sleep?? mode.
Here is an Old video demo with a PPK as well worth the View.
PJ
