First of all, I guess I most likely see this more often than other people simply due to the amount of Blinks I have. But here it is anyway.
I currently have several Blinks that are not flashing the low voltage error but that at this point have a IR transmission error rate so high that I have to remove them from games otherwise they might get stuck. This is a lot more obvious with games that use datagrams (bigger packets, more chance for error).
In the Custom Blinklib it is most noticeable as a transmission delay (due to guaranteed delivery) but that delay can be upwards of 10 seconds (with the low-battery Blink trying to transmit at every loop iteration) and is considerably more evident on Blinks that have multiple faces connected than with Blinks that have a single face connected.
Considering this, and realistically speaking, shouldn’t the voltage threshold be decreased a bit so that those Blinks would actually show the error instead of not working in some games? Note that although it is more evident on datagram-based games, it also happens with face value based games (and show as a face disconnection event) I understand that this would reduce the rated battery life for Blinks but considering the frustration of Blinks silently failing, I guess this would be justified.
Unfortunately the only insight a blink has into its battery state of charge is to look at the current voltage, and this only a very rough indicator - especially across different usage patterns, battery bands and ages, and temperatures.
The main goal for the low battery indicator was to give some indication to people that the blink was not broken in the case when they took it out of a drawer after it had been sitting for a long time (“cold check”). This is why it is red - the red LED has the lowest forward voltage and can operate when the others can not. Otherwise, there is also a “warm check” that will go into low battery mode when the voltage drops to below the level that the blink needs to run at full speed. This prevents the chip from crashing and again keeps the blink from looking broken when it really just needs a fresh battery.
We tried to pick voltage levels that usually in other cases too, but there are many parameters that make it hard for this to work like, say, your cellphone which uses a rechargeable battery that has been characterized so that the software can “coulomb count” as the battery discharges to know the state of charge relatively accurately.
Yeah, I assumed it would not be trivial anyway. Oh well, it is not a deal breaker but if something can ever be done to improve this, it would be great. Failing outright when it can not function properly is better than trying to function properly and mostly failing.
I should weigh in on this a bit. The 3 LEDs all have different fall off voltages, and so as the battery wares, the Green is the first to go. That said, there is the 4th LED for communication that is likely most critical to functioning games.
In practice, I found that the low battery warning was no more helpful than noticing that the Green LED is quite dim, and that it is now time to change the batteries. I find flashing red to be a loud statement and want to make sure it isn’t throwing false positives as well as reserve it for emergencies. We use this flashing for failed game transfer, since that is a Blink level emergency, and it can be canceled with a single click.
We set the low battery warning to only show on wake if the voltage is below a very low threshold (I believe 2.3v) which is where Blinks no longer communicate (which understandably, as you point out, is not a binary communicate or not communicate). The goal is to handle this moment for Blinks as elegantly as possible. Have you seen the green LED dim significantly on the Blinks that are failing to communicate?
Perhaps we can provide a warning on wake when low, but not prohibit play (i.e. Widgets - TakeawayDice can be used up until the end).
Looking forward to keeping this thread going with good ideas.
Yep, that is what made it clear that the issue was really low battery. I actually now have a test program I use on my Blinks that simply set all leds to green and if I see a noticeable variation on it, I replace the battery on the darker ones (yeah, I am probably being a bit trigger happy here, but blinks also look better when their brightness match so… ).
FWIIW, and considering an ideal world where everything is perfect, Blinks would be able to keep their brightness even on low battery voltages (as long as it is a functioning low voltage, that is) and then when it could not function anymore, it would display the flashing red.
A bit tangential to this but: Because the first thing that seems to fail hard is IR transmission (understandably so. I do not think that this is a problem specific to Blinks, just in case), the first victims of low battery are games that use datagrams (both because datagrams are by nature bigger than face values and because face values are sent at every loop iteration and eventually make it to the other side). Because of guaranteed delivery of datagrams in the Custom Blinklib, those games continue to work and the only perceived issue is a longer time for datagram transmission.
Maybe considering adding guaranteed delivery to the official Blinklib is a way to make this failure mode at least a bit better.
).