Ramble: AC Power DoS attacks via a GFCI tester

GFCI (ground fault circuit interrupters) are the rarely-recognized heroes of the electrical world. They can protect a person who is unlucky enough to end up between the AC line and ground, and, if working correctly, are a life-saving invention used in almost every home, commercial and industrial building out there.

2013-08-22_21.59.39[1]

Although GFCIs come with a built-in test feature, AC outlet testers are available that simulate a true fault condition; that is, it actually induces a ground leakage to verify that the GFCI circuit actually works. However, I was thinking that, if used maliciously, these tools can be used to disrupt power circuits that are protected via a remote GFCI breaker; for example, outdoor power outlets on a building which generally are wired 2 to 5 per breaker.
If the breaker trips, then someone will have to go to the breaker room and manually switch the circuit back on, which can definitely cause headaches for anyone who needed to use that circuit.

The effects of this aren’t that dire. One can’t take out a whole building’s power infrastructure this way and the worst that happens will be some downtime until maintenance comes out to restore power. Still, that doesn’t mean some prankster would do this just to have a laugh at anyone who needed to use that power outlet later.

Ramble: Consumer external batteries that have firmware updates and SCADA? I don’t get it!

I’m looking at  XPAL Power’s website, where they advertise that their batteries can:

  • check battery manufacture date
  • remotely report charge cycle count, and remaining cycle count before wear-out
  • perform a battery calibration via a charge-discharge cycle
  • remotely monitor and report battery temperature
  • perform battery firmware resets and updates

Some of these features are definitely feasible, some others… well, I have a very hard time trying to believe some of these.

  • Manufacture date check: Definitely doable. Any decent manufacturer would keep records of serial numbers and correlate it to manufacture date, lot codes and so on.
  • Remote cycle count and SoH (state of health) reporting: I honestly cannot see how this would be feasible without either a USB cable or some other means of data transfer. Bluetooth may be an option but that brings issues of its own (you’d need a BT transceiver in the battery, which I strongly doubt exists in a consumer external battery). However, the idea of cycle count and health monitoring isn’t anything unusual; as mentioned in previous posts, modern gas gauges are definitely capable of counting charge cycles and other battery health parameters.
  • Battery calibration: If the battery has a (at least moderately) smart gas gauge IC, then this would be done for calibration anyway; nothing novel here.
  • Remote temperature monitoring and reporting: This would fall under my statement about SoH reporting and so on. Additionally, the whole idea of continuous reporting of temperature to the user (and the manufacturer) would require some sort of network connection, whether it be wireless or wired. Either way, this would mean that a prohibitively expensive solution would be needed to implement what is essentially SCADA (supervisory control and data acquisition)… in an external battery used to charge a phone, tablet or laptop. But, if this feature is used then I guess there could be a way to use the device’s network connection (maybe USB-to-serial or something) to communicate with the manufacturer to transfer data. Once again, this would bring problems with device compatibility, and I strongly doubt that a USB charger would implement a microcontroller system that has enough oomph to implement USB host functionality just to send battery data.
  • Remote firmware control:  I don’t see how this would be implemented outside a laptop battery that uses the Smart Battery System to communicate. Even if a battery had a microcontroller (most out there would have basic protection, charging and DC-DC conversion), I doubt that a means of programming would be exposed to an external data port. What if  a communication problem caused the firmware update to abort prematurely?

I don’t mean to bash XPAL or anything (I have many of their products and their batteries have outlasted any other Li-Ion based devices I have had) but I’m just not sold on how they can implement remote reporting and firmware updates  for their batteries, given the amount of processing required host- and battery-side to implement these functions. Even if it was a fully remote and wireless solution, then it’d require RF interfacing which would cost far too much to implement in a way that would require nearly zero user intervention.

That said, I myself have plans to implement something like this (a battery with a BT interface) but it definitely isn’t something that would be feasible for the mass market. That will be revealed in a later post, but in the meantime I’m mourning the loss of a very nice 4-cell battery that I built that used my bq27421 chip to do charge gauging.