Continuous magnetometer reading fails with battery at 38%

I noticed the following behaviour:

• set a listener using Puck.on("mag", lsnr)
  
• start magnetometer reporting with Puck.magOn(5)
  
• lsnr is called only about 5 times and no more
  
  

To be clear: Puck.magOff is not called anywhere in between.

This happened with Puck.getBatteryPercentage() at 38. After replacing the battery with a new one, it all works fine again.

I suppose this should be added to documentation, or handled on a lower level - e.g. throw an error from Puck.magOn when battery voltage is below some level...

Thanks - to be honest I'm not sure quite what can be done about this, short of changing the battery percentage meter.

Basically the magnetometer will run down to 1.95v, and the 0% battery voltage from Puck.getBatteryPercentage() is 2v.

That should be fine, but when Puck.js is executing code it'll be drawing more power, which will drop the battery voltage more, which could then reset the magnetometer - and the Puck won't be aware that it has happened.

The problem with a check in Puck.magOn is that you could have called it when the battery was fine, and then the battery slowly runs down. It even depends on the code you execute on the Puck.mag handler - if you were doing something quick it'd be better than if you did loads of calculations (as those could cause the battery level to drop).

Thanks for the details. I'm looking for any way to make the behaviour more reliable.
Currently, the magnetometer basically can't be depended on for continuous operation.

When the spontaneous magnetometer reset happens, Puck.magOn says the magnetometer is on, even though it isn't. Can we detect in magOn that the reset has happened and warn about it?

A battery level of 38% isn't something I would have guessed to be "low" or "critical". Having individual components fail at different battery/voltage/load levels is an unexpected behaviour in my opinion. Would be nice to mention this caveat somewhere.

For newcomers like myself, it's easy to see Puck as a nice little "black box" with a nice deterministic dependable API, and forget that the API is just a very thin layer over low level electronics.

Yes, as far as 'magOn' is concerned it thinks the magnetometer is still on because the power to it has always stayed on. I'm wondering what the best way of handling that is...

I could make magOn read back the data in the magnetometer, which would help it know if the magnetometer had got reset, but I wonder of that really helps. Just Puck.magOff();Puck.magOn(); would fix it.

You could do:

var magReadings = 0;
setInterval(function() {
  if (!magReadings) { Puck.magOff();Puck.magOn(5); }
  magReadings=0;
}, 1000);
Puck.magOn(5);
Puck.on("mag", function() {magReadings++})

Potentially I could do that internally, but then it ends up using up more battery power in all cases.

In your case, if it always stops working after 5 samples it's not going to help you a great deal.

@Gordon
I think it's not worth increasing base energy consumption just to handle this case.

That snippet does indeed provide some reliability, but still - I think in that situation it's more appropriate to "restore reliability" rather by replacing the battery than repeatedly restarting the magnetometer.

To clarify - I'm not looking for a hack around this particular problem, but rather trying to clarify (in documentation) expectations of reliability and/or make the API more reliable.

If you agree, I'd try to make some PRs to add detail to Puck.mag, Puck.magOn, and Puck.light in https://www.espruino.com/Reference.

Do you think such detail (the "unreliable" behaviour of mag, light) is appropriate for Reference and/or some other place? Or is this something you'd reckon most folks come expecting?

Yes, a PR with some updated docs would be great. If you could focus on magnetometer that'd be great, as I think getting the light readings reliable might be a relatively easy fix.

I guess really it's just mentioning that the magnetometer can drop out when the battery is low. Note that Puck.mag() on its own (without magOn) is unlikely to have the problem as it starts the magnetometer, reads, and shuts it off again.

Also: getBatteryPercentage reads the battery voltage between 2.0 and 2.8v and converts it to a percentage (linearly) - but the battery discharge is non-linear.

So 38% is around 2.3v, which I guess is really nearer 5-10% charge.

If someone wanted to come up with a better function that'd be awesome. Probably a 1/volts relationship would map quite well :)

1 Attachment