In source mode, 3299mV is applied to the 3V3 pin.
Transmit power is “setTxPower(4);”.
If 3.7V is fed to the battery bads, it passes through the LDO and a large capacitor is also connected, so the current behavior may be different.
Yes this could be the reason. If I understand correctly, the chip has a VDDH pin which allows direct battery connection and saves the external LDO.
Unfortunately we have to live with the external LDO on Seeed board since VDD only tolerates up to 3.6V. We may connect non-rechargeable Lithium battery directly to VDD but we cannot avoid, if it exists, reverse leakage to the LDO.
I got information from hobbya and daCoder about the on-chip DCDC converter and on-board flash memory. I have tried to find out how effective they are together with System_ON_Sleep.
I was able to reduce the current by about half just to get the system into DCDC mode without sleep. Used in conjunction with System_ON_Sleep, I was able to reduce the current by 94% on “non-mbed” and 71% on “mbed”. As expected, using “non-mbed” reduces the current by far. Flash memory OFF was not significantly more effective than the other two, so it was omitted from the data.
Here is the sketch used for the measurement.
XIAO_BLE_SystemONSleep_2.zip (10.5 KB)
An error in the description of the table has been corrected.
Nice work ms !
If the average consumption is a few hundred uA, then shutting down the QSPI flash (~20uA) may not provide prominent results unless the transmission cycle is further reduced to bring down the average consumption.
WOW, Standing on the shoulders of GIANTs, You guys are Bomb!, MS your tenacity and attention to detail is a marvel. Seeed should send you a BIG FAT GIFT for the work you do for them and US.
THANk You…
あなたの努力に感謝します、彼らは私に多くの助けを与えてくれます。以前の投稿をもっとよく見るべきでした。あなたが日本出身だとわかってうれしいです。
Anata no doryoku ni kansha shimasu, karera wa watashi ni ōku no tasuke o ataete kuremasu. Izen no tōkō o motto yoku mirubekideshita. Anata ga Nihon shusshinda to wakatte ureshīdesu.
GL 
PJ
@PJ, MS is Japanese 
お疲れ様でした
ありがとう
1 Like
Thank you all for your encouragement.
It is important not only to reduce the current, but also to be able to wake up and reconnect after a long sleep. I’m now testing to see if the Peripheral can properly reconnect properly to the Central and transfer data after an hour of sleep, it will take a few days, I’ll post the results.
I checked to see if XIAO could wake up and reconnect after a long sleep.
For the experiment, I used a 220mAh battery, XIAO in DCDC mode and on-board Flash in power-down mode, “non-mbed” BSP.
Peripheral sleeps for 1 hour, then wakes up and reconnects with Central, sending 8 bytes of battery voltage and measured time data. Central is always waiting for a connection from Peripheral and writes the data to the SD when received.
The battery, which used to last only a day when not in sleep mode, can now be used for a week with room to spare. I have also confirmed no problem with long periods of repeated sleep and reconnection.
It performs well enough for my application.
Here is the sketch used for the measurement.
XIAO_BLE_SystemONSleep_3.zip (6.8 KB)
1 Like
Wow, Stellar R&D msfujino, Seeed owes you a GIFT basket. there engineering doesn’t even comment which is SAD for them but You are BLE NIJA 
Thank you for the sharing, I’m redoing my stuff for NON-Mbed and hope soon to be converted.
GREAT JOB.
GL PJ
Inspired by msfujino, I was wondering if the consumption of the peripheral could be further reduced.
Attached are two quick sketches modified from Adafruit examples. The peripheral broadcasts a new set of data every 10s. The central scanner uses the uuid to filter the packets coming from the peripheral. No connection phase between the 2 devices are involved, only advertise and scan. As a result duplicated packets will be picked up by the central. The average current of the peripheral gets lower as the data exchange becomes 1-way instead of 2-way and no interrupt routines are needed. The peripheral advertises for 5s and then sleeps for 5s. Sleep time can be extended by changing the delay value in the loop.
NRF52840.zip (2.6 KB)
I also use the NRFconnect mobile app to scan the packets from the peripheral. It is a good tool and helps me understand the construction of the packets.
The attachment is only a simple demo. An advertising packet carries up to 31 bytes. If user wants to advertise more data bytes, he can enable active scan on the central. The extra data bytes can be transmitted by the peripheral as a scan response packet. This should suffice most sensor applications.
1 Like
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