I just bought an Energizer CHUSB USB battery charger ('cause some company is throwing them out for free* here in Germany, and I wanted such a thing cause my BlueTooth mouse manages to suck the batteries empty in about 3 days)
Anyhow, this thing can be monitored via USB by software. There used to be a Winblows SW (with pre-installed Trojan horse HEHE), that is now gone.
As I don't use Winblows, I want to write some monitoring application for Linux.
I started a google code project, and have written a small program to read out the
status of the device:
awesome, I've been looking for this too, got the same free device from pearl ;-)
however I did not manage to compile it on FreeBSD, cygwin or Linux (kubuntu LiveCD), maybe the libusb version is too old, which one did you use?!
I have several AA and AAA batteries, but (using some freeware windows usb logger) couldn't read any continuous log data. did you send any commands to the device first, and is it bulk or isochronous transfer?
(my intention was actually to create some Winblows application to read the status and i'm still looking for the original, trojan-infected software, might be useful for some testing (i.e. logging))
okay, so I finally found the original software
(it took some time to get it running without the trojan component; the infected file is %system%\arucer.dll, but can be deleted and the program still works )
the software displays an estimated remaining charging time, which is probably just calculated from the cells voltage.
it shows whether one or two cells are inserted, or if an error has occured in one or both slots.
I used the 'simple usb logger' from incetivespro (on windows) to read the data sent by the device, it continously sends 8 bytes of bulk data.
here's what i found out yet:
0xXX XX YY YY ZZ ZZ ZZ 01
X and Y must be voltage indicators for slots 1 and 2, the first byte seems to be always 0x01 while no error has occured.
during the charging process, you can see the value increasing (though randomly fluctuating by one step)
Z is the type and number of inserted cells:
0xC3 82 40: 1 cell, AA
0xC3 82 41: 2 cells, AA
0x45 2E 42: 1 cell, AAA
0x45 2E 43: 2 cells, AAA
the last byte is always 0x01, except after the device was just plugged in (all bytes still 0x00).
the various patterns that will represent errors are still somewhat confusing (and unfortunately hard to reproduce, you need a bit of luck to actually force an error when you want one ), I guess I'll do some more testing tomorrow... (but i suspect you could force an error when the voltages differ too much)
in AA mode, i got:
0xC3 82 C8: error in slot 1, slot 2 empty
0xC3 82 C9: error in slot 1, cell inserted in slot 2
0100 0000 //0x40
0100 0001 //0x41
1100 1000 //0xC8
1100 1001 //0xC9
so it's just the first bit of each nibble that changes... but that probably means nothing, there's more ways of getting errors, (and i should really get some sleep by now )
okay I can't edit my previous post, but I have the status for "two AAA cells finished":
45 2E 83
curiously, the voltage (or whatever the values for the two cells mean) continue to change, and they were not at all close to each other during the end of charging...
for AAA cells, an error in slot 2 (while slot 1 ok) looked like this:
01 9F 01 14 45 2E D3 01
I inserted a battery with a way too low voltage compared to the first one (01 14 vs. 01 9F), which might have caused the error!?
as for AA cells, I haven't yet fully charged two cells without getting any error after a while... (maybe usb contacts worn-off, resulting in low max. current on usb port!?)
maybe I'll have a look at libusb-win32, and write some fancy tool in Qt or something, when I find the time :-) (I guess as a Qt application it could also be compiled against the linux libusb without too much of modification!?)
Well, I am using the energizer since a long time for caring car batteries and mobile. It help me to save some money and now I came to know this wonderful magnificent energizer who supposed to work efficiently.
(I didn't know they'd actually keep even binary files of ~3MB size in cache, but hey, obviously they do... )
the infected file (or at least one of them / the most obvious one) is Arucer.dll, but can be deleted and the software will keep working. I think it is created both in the program's directory and in your system32 folder, but don't remember exactly, it's been too long ago already
so there seemed to be some spam post in this thread, that sent me a notification about a reply and thus reminded me about that charger software once again, after such a long time...
so, has anyone actually attempted to make some GUI-based replacement for that original infected software?
in the .net Framework libraries I couldn't really find anything useful, that would work with USB devices across multiple platforms (seems like you'd have to compile against a ported version of libusb for each OS instead)
even Delphi was no big help when it comes to making a quick-and-dirty Windows-only application...