|
I was messing around with an I2C controlled lithium battery charger on a raspi last night (long irrelevant story) and found out it does NOT support "fast charge" (probably not enough thermal monitoring?) but it does support larger capacity batteries that coincidentally permit higher currents. So the short version is I can charge a battery twice as fast by lying to the charge controller that it's twice as large. On average, probably 99% of people can get away with that, the problem is 1% set the battery on fire or otherwise burn out the battery. No matter how smart you make the controller you can't outsmart the user; to the battery charge controller, a 1 aH battery being treated as a 2 aH battery behaves like a 2 aH battery that's at 50% capacity due to age or whatever issues. I would imagine, as long as I can keep it cool, I could install a 50 mAH micro battery and tell the charge controller its a 2 aH battery and it would charge very fast indeed. Perhaps only once, but it would be very fast. I suppose the worst case scenario is some kind of virus/cyberattack reprograms the FW to believe the battery is either 65536 mAH or 1 mAH, either way the battery would appear "dead" to end users. Another common problem is marketing and mgmt may be a LITTLE over optimistic about a feature; imagine if your IoT cigar humidor (made up idea; probably does exist LOL) has a hardware barometric sensor on the I2C. I2C is famous for dodgy hardware being able to 'jam' the bus. Ah no problem nobody needs a baro on a humidor anyway, we'll just delete it from the marketing materials and remove it from the firmware, no need to e-cycle otherwise good first batch of boards. Well if someone uploads custom firmware and the baro is polled every hour and it randomly jams the I2C once every hundred polls, "must be a thermal issue the CPU crashes" nobody might ever understand the problem. I mean, its gotta be a hardware bug worthy of a return, everyone knows if the code compiles and passes unit tests and works for a couple minutes, it must be good, right? But if the I2C protocol is interrupted due to a wifi interrupt in the middle of whatever it crashes the whole bus so randomly every couple weeks it locks up. Some big expenses are not brick fails but "it burst into flames while on an aircraft" or "everyone knows the hardware locks up randomly every couple weeks" causing all kinds of crazy bad PR. Then there's interference with marketing models. Well, technically the hardware for rev1 and rev2 are the same, its just rev2 has more features because we eradicated bugs, so please pay us again, don't just download new FW. |
A proper SI interpretation of aH would be atto-Henry, where Henry is the unit of inductance (from James Henry), and atto is 1e-18.