Thank you msfujino
I’ve seen your response on this topic, and this could partly confirm my findings.
But I still do not fully understand, why I’m getting such a high current during deep sleep. Because the values I find in the datasheet of the charge controller states lower values (if I read it correctly).
Might this have to do with the controller trying to find a connected battery, because it is not shut-down manually as advised in the datasheet?
I’m working with the Arduino IDE and the BSP should be 2.0.14. I cannot confirm this currently because I do not have access to my pc right now, but I strongly suspect it to be this version, because I installed it just 2 weeks ago.
Would you think it would be any better with v2.0.8? Or why did you specifically ask for this version?
And this would imply, that you are suspecting the chip itself using more current than stated in the datasheet of the chip(?).
Hi there,
I won’t deny you 
the pleasure of researching that exact question, WHY?
I will say" they Espressif had an alpha, & beta BSP before the 2.0.14" and some older code doesn’t 
go well. I like 2.0.8 , but that’s just me. I don’t suspect anything or everything, You do you 
and I’m sure it’s fine.
GL 
PJ 
You may be correct about the charge controller, and require additional code to support fully the deep sleep?
I guess additional code will not be enough, as the way to put the charge controller into shut-down according to datasheet is to float the Isense-pin (which is hard wired under the hood).
(I noticed that I might have messed up with some translations 
just replace all the suspect with assume. That was what I meant all the way )
I did now do some additional tests, including BSP 2.0.8 (I can now confirm that I was using 2.0.14).
I did also try the difference between esp_deep_sleep_start() and esp_deep_sleep(), which caused some higher current consumption some time ago (ESP32-C3 power consumption doesn’t match to the datasheet). In my case, this did not make any difference (there was also no difference if wake-up-time was not specified at all (by me)):
The measurements were done with a different DDM (vs. oscilloscope last time).
Hi there,
I’m curious to know how it shakes down with the PPK2. ?
GL 
PJ
According to Seeed’s information, the charge controller is ETA4054. I could not find a detailed datasheet.
See here for the datasheet.
LCSC (based in Shenzhen) is similar to Mouser or Digikey and they stock many parts which are manufactured in China.
Hi there,
I’m wondering if this might explain away some of the Vampire current
(from the data sheet)
“Note 1: Supply current includes ISET pin current (approximately 100μA) but does not include any current delivered
to the battery through the BAT pin (approximately 100mA).”
I’m surprised at some of the Technical design decisions seeed engineering has made with features supported but not implemented correctly or poorly SMH, i.e. devices you can read battery level seems to be their achilles heal.
my.02
GL PJ
Hi there,
Great point and find, I had forgotten about LCSC
I used them to supply my pcb components on EasyEDA and JLPCB, They have some hard to find parts and good e-mail support for the DRC phase ,very helpful.
GL PJ
I unfortunately can’t do any measurements with the PPK2, as do not own one of those. But as I was already thinking of getting one and to check whether my uCurrent is doing right, I did order one.
Let’s wait 'till it arrives for any new values…
@msfujino, @hobbya
This is interesting information which I didn’t find so far.
But this confuses me even more, as when calculating the current which the battery will be charged based on the ISET-resistor (2k7) we get lower values than reported from the thread linked above from @msfujino. So, we now even have contradictory information.
@PJ_Glasso
Interesting to know would now also be, if this Note 1 is really only applicable on the Charge Mode or should be used on the Standby Mode as well. Because under Charge Termination it is noted, that when the chip enters Standby Mode (which I guess happens when no battery is connected but ISET is still pulled to GND) the input current drops to 200 uA, which is well above the values in the table.
This then could actually be this vampire-current. I did check with a second XIAO, which behaves exactly the same.
And regarding the battery level read: they at least justify the lack of implementation. And I guess, an additional voltage divider would mean one more time some more current.
me2,
As shown in the link below, the battery is charged at a charging current of 1000/2.7k = 370mA, set at 2k7.
‘Charging characteristics of XIAO_nRF52840 and XIAO_ESP32C3’
Since I can’t get the datasheet for the ETA4054, I thought about it while looking at the datasheet for the MCP73831, which seems to be almost equivalent.
In the SupplyCurrent(ChargeComplete, NoBattery) section, there is a description of Typ.53uA, Max.200uA.
@hobbya was able to locate the datasheet of the ETA at LCSC
But you are still right in the end, because I was refering to the different formula to calculate the charging current for the ETA, but just simply overlooked the square in the formula yesterday. Without the square it would be around 270 mA (incorrect) instead of now again ~360 mA.
In the datasheets of the XC6802 and the ETA4054 is not exactly specified what happens, when there is simply no battery connected without a proper shut-down. But I came to the same conclusion that it will probably behave as in Standby Mode.
It will then consume around the values you provided (60 to 100(max) uA, maybe even 200 uA regarding the above note).
This all would kind of confirm (except the blinking of the LED) my initial question and makes the XIAO only usefull for low(er) power applications when powered over the battery only.
Hi there,
Pretty sure the LED only blinks for a short period?
AFAIK.
HTH
GL PJ
Really sure the LED blinks only a short time, but not 100 % sure the exact duration of the pulse. The frequency is between 24-25 Hz (checked with oscilloscope during current measurements and optically with a 960 fps camera). The “blinking” is visible by eye and it can be observed, that the LED is on at max one of the frames of the camera (so pulse is shorter than 1 ms).
As mentioned above, the current measurement show, that the pulse duration is around 16-18 us, but due to the low bandwidth (300 kHz) of the uCurrent, the exact values of duration and especially amplithude are to be questioned.
If I find time soon, I will try to probe the LED directly with the oscilloscope, to get better values of duration (but will add no value to current obviously).
So, did some more measurements. The PPK2 did arrive in the meantime and shows some slightly different values.
To estimate, which of the two might be “more correct”, I looked for some DDM with the ability to measure sub-mA ranges directly:
So it seams that my uCurrent is a bit off, as the other measurements without the uCurrent show very similar values.
I did now as well probe the LED directly with the oscilloscope and got again ~24 Hz, but a clearly longer pulse duration of ~353 us, which was not visible in the current measurements with the uCurrent.
If the voltage applied at ppk2 is reduced below 5 V, there is a voltage at which the frequency of the pulse current changes significantly.
I’m really sorry, but I do not fully understand, what exactly you mean with this. The voltage at the PPK2 was set to 5 V, as I was powering the XIAO at the USB port.
The way shorter pulse duration I was mentioning earlier was “measured” with the uCurrent and an oscilloscope. At that time, I didn’t have a PPK2 yet.
Or were you referring to a different response?
I am applying voltage from PPK2 to the 5V pin of XIAO and observing the current. when 5V is applied, the period of the pulsed current that appears during the sleep period is 20mS. when the voltage is reduced to near the lower limit of the ETA4054’s operating range, the pulsed current period is 1.1sec. It appears that the operating mode is changing, but I do not know what is happening.
This is just information; try it when you get PPK2.
Hi there,
So looking at the S3 spec’s on sleep I see this foot note?
GL PJ