Batteroo testing

[Delta]

Excellent work Frank.  Nice pretty graphs for the geeky engineers, and a nice simple video of trains and a timer for the "normal people".  Both result in the same conclusions: The claims of the BatterBros are nonsense.

[TheAmmoniacal]

When doing tests on the Batteroo sleeve, make sure to keep an identical parallel. In order to measure the increased "performance" achieved using the Batteroo sleeve, you must compensate for the normal recovery of the cell.

[quad]

I've been thinking about wireless keyboard testing. What is a good test protocol for this?

Would a Raspberry Pi with wireless keyboard work, as to not tie up someone's computer for a few weeks? Weigh down a key and use the scripts I'm working on the count the number of keystrokes. Display the time of the last keystroke pressed, so you can "set and forget"

What about having users install a keystroke counting software on their everyday computer... and log the time started, total number of keys, and total number of hours, and the time at the end of it. Usage patterns would be different - would this test be valid?

P.S Made some more progress on the Windows keyboard tester, mostly GUI stuff

[Towger]

I am 99% sure you cannot just weigh down a key on a quality wireless keyboard. The processor should put it into sleep mode if it sees a stuck key.
A keyboard would often get stuff resting on it on a messy table.

[FrankBuss]

I wonder why the train test Batteroo did, showed such different results, see here: https://www.facebook.com/revivebatteries/posts/1303252479741119 With the train model I used, the speed for both tests, with and without sleeve, was nearly identical. Too bad that Batteroo didn't publish the full movie or data so far.

So for better comparison, a reliable and honest person, with experience in programming, created a Python script (me  ), with OpenCV to extract the number of laps and lap time for each round, because this is a perfect example to evaluate OpenCV, something I wanted to do anyway. See here for the full script. It was much easier than expected, because of all the useful functions in OpenCV. And the script analyzes the video faster than realtime.

It works like this: There are two rectangular areas, one at the top of the track and one at the bottom. If the train gets inside the bottom rectangle, the lap detection gets armed. When armed and it gets inside the top rectangle, the lap timer is started and it is disarmed. When it is at top again (after armed at bottom), the lap time is printed, and the lap timer is started for the next lap. This is very reliable, even when the detection if a train is inside a rectangle is not reliable, e.g. if it oscillates at the borders, and can measure very slow trains as well, without the need for an arbitrary hold-off time.

The detection if the train is inside a rectangle is easy: I just count the number of dark and bright pixels and if there are more dark pixels than bright pixels, it is inside (because the track is much brighter than the train). To determine the threshold for dark pixels and test the train detection, the script can be started in interactive mode. If it is inside a rectangle, the rectangle is drawn in green:







For the threshold you can press the "h" key while the train is in one rectangle, and you'll get a histogram of both rectangles:



Just choose a value between the two peaks. This could be automated as well and more sophisticated functions of OpenCV could be used, like the train could be tracked on the whole track and it could be evaluated how smooth it moves (looks a bit more jerkily with the Batteroo sleeve), but this quick hack works really good to measure the basics.

With the startStop array at the beginning of the script, multiple test runs can be defined for one video.

I used the raw footage of the train video (glad I didn't delete it already) and created a full video of it, but compressed and scaled down a lot more, so that it doesn't need many GB, but it is the full 3:19 hour without timelapse. I've uploaded it here, 1.4 GB (no worries if you want to download it to play with OpenCV, my server has an unlimited bandwidth hosting plan, it just gets limited to 10 Mbit/s if the traffic gets too high). As in the Batteroo test, I created a spreadsheet with the following number: lap number, lap start time, lap end time, total lap time, feet per minute speed. Unlike Batteroo of course, I publish the spreadsheet, you can see it here. The lap counts are the same as @samgab reported (+/-1). Diagram:



If anyone wants to measure something as well, maybe a drop out art student, feel free to use the script. No need for any extra hardware for a lap counter.

[FrankBuss]

Would a Raspberry Pi with wireless keyboard work, as to not tie up someone's computer for a few weeks? Weigh down a key and use the scripts I'm working on the count the number of keystrokes. Display the time of the last keystroke pressed, so you can "set and forget"

A Raspberry Pi sounds good. But do the logging on a network attached storage or with a web service. It would wear the SD card and the Pi can even crash sometimes, if you write often the last time to the SD card. But exact time shouldn't really matter, because I guess it is a few weeks. So the Raspberry Pi could just control 2 LEDs: one for showing that it is working (should blink), and one for keyboard events. If the working status LED stops, restart the Raspberry Pi, if the other LED stops, the keyboard has stopped. Take a look at it once every day.

Weigh down a key most probably doesn't work, because I think only key-up and key-down events are sent. And easy way if you don't want to build a complicated servo mechanism, would be a 4051 analog mux and then solder it over the contacts of one key (should be possible on the back of the PCB without destroying it), in combination with a good old 555 timer, or just a transistor bistable multivibrator.

What about having users install a keystroke counting software on their everyday computer... and log the time started, total number of keys, and total number of hours, and the time at the end of it. Usage patterns would be different - would this test be valid?

No, this wouldn't be a controlled and reproducible test, because you don't know then it goes to sleep mode etc.

[Stupid Beard]

Weigh down a key most probably doesn't work, because I think only key-up and key-down events are sent. And easy way if you don't want to build a complicated servo mechanism, would be a 4051 analog mux and then solder it over the contacts of one key (should be possible on the back of the PCB without destroying it), in combination with a good old 555 timer, or just a transistor bistable multivibrator.

I had a wireless apple keyboard a while ago. After I spilled tea on it, I tried to take it apart to fix the keys that were no longer working. Unfortunately the back of it is glued on and it's therefore nearly impossible to take off without destroying it. That may be model dependant or other people may have more luck removing it, but I don't think soldering anything to the contacts will be a viable option unless someone is happy to destroy their keyboard.

Probably better to rig up a motor with a cam of some kind on it that just rotates endlessly and presses a key once per rotation.

[razvanme]

No need. I can tell you for sure you have at least 3 events for keyboard.
KeyUp
KeyDown
KeyPress.

[FrankBuss]

Probably better to rig up a motor with a cam of some kind on it that just rotates endlessly and presses a key once per rotation.

Or a servo motor. I forgot that I implemented this on the Raspberry Pi some time ago with one of its hardware PWM output:

https://plus.google.com/u/0/+FrankBussProgrammer/posts/EsFWxnETsGo

But I don't know how durable such a servo motor is, might not survive months of tests.

Another idea would be a solenoid. There are cheap ones on eBay and should survive for a long time.

[Delta]

Break open a relay and bodge an arm onto the moving contact.

[Fungus]

Another idea would be a solenoid. There are cheap ones on eBay and should survive for a long time.

A coil of wire and a nail. The keyboard will work as a return spring.

[samgab]

Perfect! Thanks Frank, now this is the kind of data I like to see! We can learn such a lot about Batteroo just from this chart alone!

We can see that without batteroo, it looks like a pretty smooth battery discharge curve, not much in the way of peaks and troughs. It's also quicker right from the beginning.
The curve with batteroo sleeve, as well as cutting out in half the time, is also a very peaky curve, a lot of noise. This tells us something about the way it delivers its power with this sort of load.
Excellent work! Thanks. 

[StillTrying]

I wonder why the train test Batteroo did, showed such different results, see here: https://www.facebook.com/revivebatteries/posts/1303252479741119 With the train model I used, the speed for both tests, with and without sleeve, was nearly identical.

I think it's just down to each trains' efficiency and current draw, their train being more efficient than yours allowing the batteryslave to stay at or reach 1.5V. When you're discharging a primary cell in 1 or 2 hours, small differences in the current draw lead to larger differences in the run time because the capacity is non linear.

Where are any AA tests, or pictures? If the AA batteryslaves are more powerful than the AAAs they should be better, if it's the same rated circuit in the AAs they're going to be worse, because of the higher currents expected of AAs.

[FrankBuss]

I think it's just down to each trains' efficiency and current draw, their train being more efficient than yours allowing the batteryslave to stay at or reach 1.5V. When you're discharging a primary cell in 1 or 2 hours, small differences in the current draw lead to larger differences in the run time because the capacity is non linear.

Good point. Their train runs about 8 hours (without sleeves), compared to about 2 hours for my train. My train uses more than 200 mA, so this might be about 50 mA for their train, which means it doesn't work well with higher powered devices.

[djos]

Break open a relay and bodge an arm onto the moving contact.

I've got the RF and Servo shields for my RFduino's, they'd be perfect for this!

[samgab]

I think it's just down to each trains' efficiency and current draw, their train being more efficient than yours allowing the batteryslave to stay at or reach 1.5V. When you're discharging a primary cell in 1 or 2 hours, small differences in the current draw lead to larger differences in the run time because the capacity is non linear.

Good point. Their train runs about 8 hours (without sleeves), compared to about 2 hours for my train. My train uses more than 200 mA, so this might be about 50 mA for their train, which means it doesn't work well with higher powered devices.

I tried to find out about those Thomas the Tank Engine trains, but there are dozens of variants of it over the years, so who knows which one they used. But some of them run on a pair of AA cells. So that might account for the long runtime. But we need to see all of the details! And we need the test to be repeated multiple times, to prove repeatablility. For that matter, I'd like to see results of your own test repeated multiple times and the results overlaid on that same lap time chart. 

[Hensingler]

Good point. Their train runs about 8 hours (without sleeves), compared to about 2 hours for my train. My train uses more than 200 mA, so this might be about 50 mA for their train, which means it doesn't work well with higher powered devices.

Someone (here I think) already suggested the trains were these https://www.amazon.com/Fisher-Price-Thomas-TrackMaster-Station-Starter/dp/B0160SNY7Q/ which use 2 AAA batteries so that accounts for a factor 2, and running at lower current the batteries have an easier time, and the trains trade speed regulation for efficiency. I don't find a factor of 4 difference that surprising.

Incidentally I think our friend in Darwin has only posted photos of AAs and never mentioned AAAs which suggests to me he wasn't much responsible for that test and video.

[FrankBuss]

Dave wrote he has an AA powered Percy train, which looks like it is from the Thomas the train series. This will be another good test. And right, my test should be repeated, too. And using different battery brands would be interesting, because there was a major difference between Energizer and Duracell. And some additional wagons would be interesting, because it would increase the required current.

[ez24]

Excellent work! Thanks. 

More proof that the batteroo saves wear and tear on motors.    Great sales point that the Darwinians can use to sell the batteroos.

[EEVblog]

Dave wrote he has an AA powered Percy train, which looks like it is from the Thomas the train series. This will be another good test. And right, my test should be repeated, too. And using different battery brands would be interesting, because there was a major difference between Energizer and Duracell. And some additional wagons would be interesting, because it would increase the required current.

Yes, I have a AA Percy and a AAA version as well.

[FrankBuss]

Nice, do you plan to measure the lap times? Probably faster for you to do the Arduino and photodiode-under-the-track thing, instead of setup Python and OpenCV on Windows (might be more complicated than just the apt-"get install" you need on Linux) and adjust the script for your video. But if you upload a one shot video of the whole test and upload it somewhere in MP4 format in low quality, I can run my script on it.

[quad]

I've set up a GitHub account for any Batteroo testing scripts! Here it is: https://github.com/batterootesting/

I thought we could keep our Batteroo testing software over there.

Any trusted EEVBlog members are welcome to become collaborators and/or I can share login credentials

Wireless keyboard testing project: https://github.com/batterootesting/wirelesskeyboard.   

The Linux version is coming along, it now captures start time & last keystroke time and you can get progress updates by hitting the space bar without updating the last keystroke time (when you eventually switch batteries, just press space bar). Not worrying about GUI for Linux.

Windows version I hit a problem, I think it's a threading issue when running the GUI loop and the Hook Keyboard loop and trying to update the keystroke info in real time. Too hard basket for now. For anyone interested in the exact issue, it's here: https://github.com/batterootesting/wirelesskeyboard/blob/master/Windows/tester.py on line 57

Anyway, it's progressing 

[ez24]

Yes, I have a AA Percy and a AAA version as well.

I hope you got one with a cargo car so you can add a heavy load and do a "load" test.



To be honest I am having trouble - what is the difference between Percy and Thomas ?  Are they brothers?  I remember Thomas as a kid but I do not remember Percy.

[FrankBuss]

Any trusted EEVBlog members are welcome to become collaborators and/or I can share login credentials

Cool, please add me as a member to the github account (I think you might need to change it to organizational, should be still free), my github account: https://github.com/FrankBuss I'll create an OpenCV repository, for anything related to measuring things with OpenCV for Batteroo and upload the OpenCV script for lap time measurement. And maybe I can find the problem with the Windows script.

[EEVblog]

To be honest I am having trouble - what is the difference between Percy and Thomas ?  Are they brothers?  I remember Thomas as a kid but I do not remember Percy.

Thomas The Tank Engine is an entire world (Sodor) with different train characters. Thomas, Percy, Gordon, Diesel, etc are all engines in this world.