Espruino on Magic3 high consumption in sleep mode

[spyx1]

Hello everyone.
I tried all firmwares @fanoush, @jeffmer, @enaon for the Magic3 watch (c17) Unfortunately, in sleep mode, the consumption is high, about 6.6 mA.
Is this the case for everyone? With such consumption, the watch needs to be charged every day.

[fanoush]

When I charge it an just let is sitting advertising it lasts up to 2 months for me. 6mA is like CPU running at 100% all the time.

Check this example https://github.com/fanoush/ds-d6/blob/master/espruino/DFU/Magic3/code.js
By default with no code running after poweron the HR sensor is blinking and you need to run at least D7.write(1) for it to stop
This is only needed for Magic3/C17, it does nothing for Rock or QY03.

Also putting touchscreen to (auto)sleep and spi flash to sleep helps a bit. see https://github.com/fanoush/ds-d6/blob/master/espruino/DFU/Magic3/code.js#L931 and below (and BTW QY03 needs writing 0 to register 254 instead of 1 to auto sleep)

[spyx1]

Thanks for the prompt response.
Installed https://github.com/fanoush/ds-d6/blob/master/espruino/DFU/Magic3/espruino_2v10.102_magic3.zip.

Load code.js into RAM. I get the following result: with the display on, 50mA, with the consumption entering sleep mode, 7.1mA.

If I change the line if (process.env.BOARD=="MAGIC3") D7.write(1); to D7.write(0); Then after loading I get an error in the left part of the IDE,
example: Uncaught Error: I2C Error: Arbitration (start)
at line 1 col 23
i2c.writeTo(0x15,254,1);

You wrote that if no code is running, the heart rate sensor should blink, but mine doesn’t blink.

My watch https://sl.aliexpress.ru/p?key=1kUY3qK

[fanoush]

You wrote that if no code is running, the heart rate sensor should blink, but mine doesn’t blink.
: Uncaught Error: I2C Error: Arbitration (start)

I wrote after poweron with no code running (at all). Even with code in flash when I just tried to call E.reboot() now, the red led of HR sensor turns on until the D7.write(1) turns it off.

The I2C error is indeed caused by having the value 0 and not 1 (as per comment in the source) so hopefully your device is same as mine regarding pin 7. Do you see it blink once after E.reboot?

If the RED led is not on or blinking and i2c works then the power drain is somewhere else.

How do you measure the current? Do you have the device open on the back? With battery disconnected?

And BTW also after using SWD with openocd the power draw can be high until reboot.

[spyx1]

After E.reboot() the diode does not light up.

The watch is open, I unsoldered the gnd of the battery and connected the multimeter to the gap, setting it to measure current.

I also wrote a code on the Arduino, the display, accelerometer, touchscreen worked, I put them into sleep mode. And I also get about 7mA, after that I put the processor into deep sleep NRF_POWER->SYSTEMOFF = 1; and I got 6.5mA, that is, of these 7mA the processor consumes only 0.5mA, everything else is some kind of peripherals

[spyx1]

I saw a blinking LED when power was applied, very dimly, but it was there.

WhatsApp.2025-05-03.17.02.59_b506c86c.mp4

[fanoush]

Then I don't know. Either you have different revision hardware that needs different pin setup or maybe the hr sensor (or something else) is damaged and drains current. You can try to disconnect hr sensor or display and see if it goes away. Or try to toggle pins up and down - or a safer way is to set pin as input with internall pull up or down like this. Setting pin as output and to wrong value could drain even more current and possibly even damage something if the pin is tied directly to ground or VCC.

[spyx1]

Сurrent measurement

[fanoush]

6mA is pretty high current, like LED or display backlight. BTW does the motor vibrate? I think someone had broken vibrator motor and it was drawing current all the time and was not working.

If you have more pieces it would be interesting to see current draw still with original firmware. And then if it is OK and after flashing Espruino it draws current like this it is some missing hardware setup. Did the watch get firmware update with original dafit app? What is the model code in firmware (like MOY-NXXX) and firmware version?

[spyx1]

This is the code that makes the vibration motor work:
D7.write(1);
D6.write(0);

I have two of these watches, unfortunately I did not check what the consumption was in the dafit firmware by default, as well as the model code.
On one watch I installed espruino, and on the other arduino.
My mistake, that I did not take measurements initially.

I also turned off the display and the sensor cable, the cable going to the heart rate sensor. The consumption did not decrease.

I also noticed one thing.
On the Arduino, after putting all devices and the processor into sleep mode, the current consumption was more than 14mA. After I set D16 as an input, the current dropped to 7mA

[spyx1]

Most likely I will have to order another one of these watches, wait for it to arrive and measure the consumption on the stock firmware.
It will be funny if it also has 7mA)

[spyx1]

On aliexpress where i ordered this watch there is a user comment:
has moy-nba firmware on it.

[fanoush]

MOY-NBA5 is old known version, I am running Espruino on NBC5 model but it would be pretty strange that nobody reported high power draw on NBA5 for years. I guess I do have at least one NBA5/C17 somewhere still new in a box.

If you have two identical watches and both have same issue it is probably not hardware fault.

[spyx1]

two identical Magic3 with identical firmware and code.js running consume different current, 6.6mA and 13mA
I can't figure out what's wrong.

[fanoush]

If you disconnect battery between tests and run exactly same code then I don't know what should make difference except having different (or faulty) hardware.

I would suggest disconnecting various connectors on PCB to see if it makes difference - display touchscreen, HR sensor. I do not have this device open so don't have first hand experience with internals, maybe @enaon could help more.

Anyway I did took one MOY-NBA5 from the box, charged it and so far it is sitting with 100% battery for two days with the original firmware. Too bad we don't have firmware binary for this version. Mine is 2.0.5 but some time ago some guys on discord with 2.0.3 did not get update from dafit app so this is probably too old device and they removed firmware updates from their servers (if they ever had it). So once I flash espruino and will see same issue I won't be any wiser than you. So I am thinking what should I do next, maybe taking it apart first and measuring how much it draws now with original firmware when different parts are on and off.

[spyx1]

I would be very grateful if you opened them up and measured the consumption on the stock firmware.
You can disassemble them from both sides. But it's better from the display side, so it will be easier to disconnect the display and sensor cable.
I was also interested in comparing the insides of your watch and mine.
I ordered two more of these watches, but they will last for two weeks, so it's okay if you don't dare to tear them apart.

[enaon]

I would be very grateful if you opened them up and measured the consumption on the stock firmware.

I have many magic3s open, consumption in idle using 2.15 firmware is ~300μΑ, BT enabled. Stock is a bit better, if it is important I can check (last one I got 2 months ago still had MOY-NBA5-2.0.5 ). In general, the magic3 is working fine with espruino.

The magic3 does not support auto sleep mode for the touch panel, you have to manually put to sleep, maybe this is the problem?.

use this to test sleep.

//setupv i2c
var i2c = new I2C();
i2c.setup({ scl: D14, sda: D15, bitrate: 100000 });
//touch sleep
i2c.writeTo(0x15, 0xA5)

Also ,some time back when I fried the i2c pins on a watch, touch/hr/etc was not working, i did have ~10mA idle consumption, but I guess it is irrelevant to your case.

[spyx1]

hank you very much for the graph.
Unfortunately I don't have ppk2 yet. Could you explain, I see consumption spikes up to 27 mA, could you connect a regular multimeter, what does it show for you?

[fanoush]

I have many magic3s open, consumption in idle using 2.15 firmware is ~300μΑ, BT enabled.

Thanks, so the version named C17 with NBA5 firmware is no different regarding power consumption than the (older?) one named Magic3 with NBC5? How much the touchscreen draws when not put to sleep properly, can it be those 6mA? (sounds too much to me)

EDIT: the code.js example @spyx1 tried already puts touchcreen to sleep here https://github.com/fanoush/ds-d6/blob/master/espruino/DFU/Magic3/code.js#L952 but then it also tries to put Rock to sleep via i2c.writeTo(0x15,254,1); and later i found my QY03 actually needs i2c.writeTo(0x15,254,0);. But if I don't do that I think it still lasts few days so the draw should not be that high.

[enaon]

Thanks, so the version named C17 with NBA5 firmware is no different regarding power consumption than the (older?) one named Magic3 with NBC5? How much the touchscreen draws when not put to sleep properly, can it be those 6mA? (sounds too much to me)

Yes I believe there is no hardware change over time, they all feel the same, and I cannot see something different on the board.

I made a mistake on the previous graph, it was from a dsd6 not a magic3, I tested again (espruino 2.15, always running a few watches so not really idle, but close)

magic3 full brightness:

magic3 idle , BT connected (this falls to ~500μA after some time of BT inactivity)

magic3, idle, BT enabled but not connected:

magic3, idle, BT enabled but not connected, Touch panel not manually to sleep:

so the TP costs ~3.5mA if not put to sleep, it is a drain that fails the night test.

but then it also tries to put Rock to sleep via i2c.writeTo(0x15,254,1); and later i found my QY03 actually needs i2c.writeTo(0x15,254,0);. But if I don't do that I think it still lasts few days so the draw should not be that high.

Yes I think all three are different, rock needs i2c.writeTo(0x15,254,1) and also needs the watch to be on the hand, if not the TP will not auto wake, it is somehow related to the HR sensor, and magic3 has no auto sleep support at all, it is like the bangle.js 2 on that.

[spyx1]

I connected the watch via swd and flashed it via platformio and chose the nrf52840_dk_adafruit board. There is a file with pins, and I changed only those that I used, and left the rest by default. And now I found out that, for example, pin 16 was configured as PIN_LED3 (on the adafruit plan), because of this, by default, it was initialized as OUTPUT. As soon as I removed this definition, the consumption decreased by 8 mA. And before that, it was more than 16 mA. And here is my assumption, perhaps I damaged something on the board due to the incorrect configuration of some pin, and perhaps this is why such large current leaks appeared (although all the peripherals work). I also, in an attempt to get lower consumption, simply tried to configure all the pins differently by brute force, and perhaps at that moment I damaged something on the board.

When the new watch arrives, I will be more careful and consistent with it.
And I am so interested in everything, such jumps up to 27mA on the graph, maybe the multimeter shows an average of 6mA

[fanoush]

And I am so interested in everything, such jumps up to 27mA on the graph, maybe the multimeter shows an average of 6mA

if you just flash espruino and run the code.js and charge battery to full, then keep it idle with display off, then if next day it still shows 100% it is fine, it it shows like 80% or less there is some drain

I think no multimeter would show so much just becasue of tiny spikes like this if most of the time the power draw is in uA but don't really know yours. The one I have (ANENG AN870 from aliexpress, ~25 EUR) also keeps min and max value which would be handy too in this case.

[enaon]

When the new watch arrives, I will be more careful and consistent with it.
And I am so interested in everything, such jumps up to 27mA on the graph, maybe the multimeter shows an average of 6mA

the nordic power profiler kit 2 (the one I used on the screenshot) is very nice, It gives insight on what is going on, but what Fanoush suggested is bullet proof. Let it be for one night, if still on 100% next day then your multi meter is misguiding you.