Hi Aburton, How did you upgraded to new bootloader? did you go to bootloader mode and replaced the UF2 file? or you have upgraded by programmer?
I guess! the updated bootloader saves and runs the program binary from internal flash of NFR52. I think this means we are losing the space from external 16Mb QSFP and it would be disabled to save the current. That is not a big deal if we can use deep-sleep mode.
the 60mA is due to the board being defective I believe.
Another identical board is working properly instead.
I uploaded the bootloader both with the UF2 method and with the flashing method using a JLink edu Mini ($20 but good luck finding one) and JFlashLite.
Dr_Bluble,
I used the UF2 method.
Double click the reset button to enter bootloader mode, it shows up as a flash drive would, then drop the UF2 file in.
I got the file from the repository that the deep_sleep.ino is in from the wiki. Specifically you can find them here to match your board.
But I would still like to get down to 5µA or less in sleep. So Seeed (@Cirtic), I’m still looking forward to that rework for “early May”.
1 Like
Hey, I’m glad there was a forum started on this as I couldn’t get this working as well. I was wondering what power consumption people were getting in general as with reading accelerometer values and sending the data over BLE, Im currently getting around 15mA which is way too high for a wearable device. Is there ways of reducing this power usage such as changing the sampling rate of the accelerometer, and how to do so if possible.
Thanks
Adding to this, I also found that the 1.0.0 firmware does not work with the accelerometer.
1 Like
@jonyu FYI, i just created a new thread on using interrupts from LSM6DS3. Later on, when deep sleep finally works, some should reach long runtime while using accelerometer events to wake up.
Jonyu,
Thanks for reporting this, Actually I was about to update to the new bootloader and roll back to 1.0.0. The accelerator is the main component of my project and if I can not use it alongside sleep mode, it is useless. At this rate, this board is just a bad joke! It has many fundamental hardware and software issues, one can not read the battery properly, does not go to deep_sleep, IMU conflict with battery readout, no BLE URAT support or other features that you can use in similar NRF52 boards in Arduino and … .
I have started to give up on XIAO (and all seeed’s produtcs)
1 Like
Battery readout off-topic:
Unsolicited suggestion: the voltage dividers are great to determine how the battery is doing, but the amount of code I had to write to translate this raw value into a credible although inaccurate percentage value, was too much.
Forget voltage division, MAX17048 requires only one external component which it’s likely already on the board.
1 Like
Hey Dr_Blueble
Yea the project I’m working on requires me to have extremely low power consumption while having an accelerometer and BLE. I thought the Seeed wouldve been a good pick as it supports bluefruit to tune the BLE settings but without the accelerometer its not quite helpful. I was wondering if you do give up on these seeed products, what board you would be using or if you had any recommendations for a low power consumption board that has BLE and an accelorometer?
1 Like
I did quite some progress into getting this board to work with PlatformIO low power mode.
The last thing I need to figure out is how to disable the blinking blue LED when advertising.
@jonyu I doubt you can go lower than what you can achieve with nrf52840 and the same level of support of Nordic, have you considered creating a shield with just the MPU?
Example: MPU6050 super thin feather from Turing Complete on Tindie
Hi Jonyu,
I am thinking maybe Arduino Nano 33 BLE Sense, it is a bit more expensive but it has 9 dof and also you have real support and Arduino does not deceive you with fake codes 
(look at the new Xiao BLE sense Motion recognition thread 
)
Cheers,
2 Likes
I was able to setup the board under PlatformIO.
I haven’t tried the IMU yet, but I will soon.
Good luck!
Sorry for the delay in delivery, R&D is still following up.
It’s hard for me to imagine that the deep sleep code they posted will ever work, given that it is clearly written for SAMD architecture and not the Nordic nRF in any way.
Well, the ARM is common for many nRF and SAMDs but the BLE section usually requires additional power saving features. Also even if both are ARM, the M0 and the M4 have many different commands.
Really crossing my fingers for an update soon
The wiki has been updated.
Was there a fix? I do not see an update in github for the “deep sleep” demo BLE_52840_Core/libraries/Bluefruit52Lib/examples/Hardware/deep_Sleep at main · 0hotpotman0/BLE_52840_Core · GitHub