EEVblog #751 - How To Debunk A Product (The Batteriser)

[SundayProgrammer]

Latest video busting that poor Monkey:

(may not be finished processing)


Technical comments should be really be on the other thread for the previous video:
https://www.eevblog.com/forum/blog/eevblog-779-how-to-measure-product-battery-cutoff-voltage/

Major frustration noticed :-)

Axel.

[SeanB]

Latest video busting that poor Monkey:

Where did you get the troll? 

eBay? They probably still are on sale around somewhere, or Dave went out to the local toy store and bought one.

[EEVblog]

I just found another anti-batteroo video:
Love the "Unstupid" title!

[Fungus]

"This video is unlisted. Be considerate and think twice before sharing."

[Fungus]

Two thumbs up! This is the video you should have made last time.

PS: The battery that leaked could have had a bit more airtime. If batteriser drains every last drop of energy from people's batteries (as they claim) then it's a real danger.

[AmmoJammo]

Two thumbs up! This is the video you should have made last time.

PS: The battery that leaked could have had a bit more airtime. If batteriser drains every last drop of energy from people's batteries (as they claim) then it's a real danger.

And it won't just be when the device is in use, as the butteriser will still put a noticeable load on the battery, even without a load on its output....

So you could leave a device with "working" batteries, only to come back a month or two later, and find the butteriser has over discharged them, and caused them to leak....

[Fungus]

And it won't just be when the device is in use, as the butteriser will still put a noticeable load on the battery, even without a load on its output....

We don't know that for sure.

OTOH they can't go into a shutdown mode in a general purpose booster like this. It's supposed to be able to power remote controls and keyboards so they can't say "stop boosting at less than 1mA current drain" (or whatever).

Yes, many booster ICs actually do that, even the cheapo eBay ones. eg. this one will shut down and consume a few microamps when it detects no load on the output or when it finds it can no longer maintain the output voltage. Batteriser can't do that.

[Godzil]

Dave: you're video miss some really important things, there is no oscilloscope with uncalibrated probe and no new soldering iron not connected on your bench, that's why you don't the same results 

[EEVblog]

We don't know that for sure.
OTOH they can't go into a shutdown mode in a general purpose booster like this. It's supposed to be able to power remote controls and keyboards so they can't say "stop boosting at less than 1mA current drain" (or whatever).

That's going to be the trick.
Making a boost converter go into standby is easy peasy, but trying to do it from a general purpose product that is supposed to work on anything from a low power remote control to a high powered toy may not be easy.
It will be interesting to get one and measure it.

[Godzil]

I've just got a revelation!

Batteroo is just trying to apply on of the standard in the industry to the battery usage:

Do more, with less

I think we can safely say that a lot of company works like this so it should be some sort of a truth: it is possible to do more with less.

[Fungus]

We don't know that for sure.
OTOH they can't go into a shutdown mode in a general purpose booster like this. It's supposed to be able to power remote controls and keyboards so they can't say "stop boosting at less than 1mA current drain" (or whatever).

That's going to be the trick.
Making a boost converter go into standby is easy peasy, but trying to do it from a general purpose product that is supposed to work on anything from a low power remote control to a high powered toy may not be easy.
It will be interesting to get one and measure it.

I'd love to be a fly on the wall at Batteroo when things like this are revealed to them.

[FrankBuss]

There must have been a real "Oh, shit!" moment between those two posts.

Still, credit where credit is due: He did manage to put a compliance "team" together in less than 24 hours. On a weekend.   

Did they start manufacturing? If they look into this problem now, it is possible that they could trash everything already produced and major design changes might be needed. Then the planned delivery in November this year is ambitious.

BTW: for those playing along at home, I did a discharge test myself. I had an Arduino at hand, below is a sketch for a simple voltmeter. I didn't use the "delay" function, because this would be not accurate, because I don't know how long the serial output and ADC measure needs. The best way is to use a timer, with auto reload on compare, because then my interrupt function is called exactly once per second. Don't use the timer overload mode and reload in interrupt, because then again there are some cycles for the interrupt latency are added (parts of the code found somewhere on the internet). If you wonder about the magic value 209.0f: I just feed 3V to it, used Serial.println(val), then calculated the factor with val/3. Because of the 10 bit ADC it is not very accurate for low voltages, but still better than 10% down to 0.3V.

Then I used my RK8511 DC electronic load (you can use "EEVblog #102 - DIY Constant Current Dummy Load for Power Supply and Battery Testing" instead) and set it to 100 mA constant current. This is the result for a not fresh Rayovac AAA battery (diagram based on every 100th value, because Open Office gets terrible slow on my PC with too many values in diagrams) :



The full data and calculations are in this Open Office document: http://www.frank-buss.de/battery/discharge.ods
The battery was not fresh, so the 0.76 Wh capacity looks reasonable. The datasheet says "963 mAh capacity to 0.9V" for 120 mA.

Code: [Select]

int ledPin = 13;
int analogPin = 5;

void setup()
{
  Serial.begin(115200);
  pinMode(ledPin, OUTPUT);
 
  // initialize timer1
  noInterrupts(); // disable all interrupts
  TCCR1A = 0;
  TCCR1B = 0;
  TCNT1 = 0;
 
  OCR1A = 15625; // compare match register for 1s delay
  TCCR1B |= (1 << WGM12); // CTC mode
  TCCR1B |= (1 << CS12) | (1 << CS10); // 1024 prescaler
  TIMSK1 |= (1 << OCIE1A); // enable timer compare interrupt
  interrupts(); // enable all interrupts
}

ISR(TIMER1_COMPA_vect)
{
  char buf[16];
  digitalWrite(ledPin, digitalRead(ledPin) ^ 1);
  float val = analogRead(analogPin) / 209.0f;
  dtostrf(val, 6, 3, buf);
  Serial.println(buf);
}

void loop()
{
}


[Fungus]

Did they start manufacturing?

Let's hope so. 

I didn't use the "delay" function, because this would be not accurate, because I don't know how long the serial output and ADC measure needs.

Correct.

The best way is to use a timer, with auto reload on compare, because then my interrupt function is called exactly once per second.

Interrupts are generally bad and can cause many side effects.

Code: [Select]

ISR(TIMER1_COMPA_vect)
{
  ...
  Serial.println(buf);  // Boom!
}
For example: You're not allowed to use 'Serial' in an interrupt because you might interrupt the function which is taking bytes out of the Serial buffer, causing a cash.

If you want accurate timing you can rely on the fact that millis() changes at regular intervals. For a 1-second delay you can watch the value of millis() and wait until it's 1000 ticks higher than the previous update. It doesn't matter how much processing you do in-between.

[Kjelt]

Dave you are not playing in the same ballpark as their marketing dept.
They make a 2 minute video which everyone can understand (although wrong) with a sexy woman voice, nice graphic overlays and a big dumb looking EE , and you answer with a 20+ minute tech video with (lets skip the voice) an intelligent EE.
A lot of people will skip it after their 1 minute attention span    Mission failed.
You really should make a short 2 minute video , let your wife do the voice over , have some catchy nice graphic overlay and then you can cope with their marketing BS 

[FrankBuss]

For example: You're not allowed to use 'Serial' in an interrupt because you might interrupt the function which is taking bytes out of the Serial buffer, causing a cash.

Why causes this a crash? At least it worked for 8 hours, but in general you are right, never a good idea to do something fancy like serial port data transfer in an interrupt. Would be better to use the interrupt just to set a flag that a second has passed, which then can be used in "loop".

If you want accurate timing you can rely on the fact that millis() changes at regular intervals. For a 1-second delay you can watch the value of millis() and wait until it's 1000 ticks higher than the previous update. It doesn't matter how much processing you do in-between.

Right, this would be better and more portable, because not every Arduino clone is based on AVR. But would need special handling for periods longer than 49.7 days when it wraps. Microsoft didn't care for Windows 98, so it hangs after this time if not patched.

[Fungus]

For example: You're not allowed to use 'Serial' in an interrupt because you might interrupt the function which is taking bytes out of the Serial buffer, causing a cash.

Why causes this a crash?

Serial code isn't thread-safe. Your interrupt is modifying variables in 'Serial'. The main thread might also be doing it. If the two collide, then, boom! In your case your 'loop()' is empty so you're probably OK.

Other problems? What if the serial output buffer is full? Your interrupt will hang the system because the interrupt that sends data will never happen so no data can be sent (your interrupt takes priority).

At least it worked for 8 hours

Yes, that's the scary thing about interrupts. Errors need exactly the right set of circumstances to appear.

[edy]

Dave you are not playing in the same ballpark as their marketing dept.
They make a 2 minute video which everyone can understand (although wrong) with a sexy woman voice, nice graphic overlays and a big dumb looking EE , and you answer with a 20+ minute tech video with (lets skip the voice) an intelligent EE.
A lot of people will skip it after their 1 minute attention span    Mission failed.
You really should make a short 2 minute video , let your wife do the voice over , have some catchy nice graphic overlay and then you can cope with their marketing BS 

I don't think Dave or anyone here really cares to influence the Batteriser campaign to the average Joe Public. There is no need to fight their garbage videos of marketing with short dumb-downed videos with Sexy lady voices. I'd rather have an intelligent EE-level video for as long as is needed to learn the science. I am here to learn EE, not save the world from fools who buy crap... that is not ever going to be achieved.

[Kalvin]

I didn't use the "delay" function, because this would be not accurate, because I don't know how long the serial output and ADC measure needs.

Correct.

The best way is to use a timer, with auto reload on compare, because then my interrupt function is called exactly once per second.

Interrupts are generally bad and can cause many side effects.

Code: [Select]

ISR(TIMER1_COMPA_vect)
{
  ...
  Serial.println(buf);  // Boom!
}
For example: You're not allowed to use 'Serial' in an interrupt because you might interrupt the function which is taking bytes out of the Serial buffer, causing a cash.

If you want accurate timing you can rely on the fact that millis() changes at regular intervals. For a 1-second delay you can watch the value of millis() and wait until it's 1000 ticks higher than the previous update. It doesn't matter how much processing you do in-between.

You can use the ISR to read the analog pin and set a global flag to notify the main loop about new result. In that way you would keep the ISR short, clean and well-behaving. The main loop will just wait for the flag to be set and then read the variable containing the analog pin, clear the flag and do the computing + printf-sutff. In this particular case it might be enough that the ISR just set the global flag at 1 second interval and the main program would just wait for the flag to be set by the ISR, clear it, and then read the analog pin value, do the processing and print the result.

[Godzil]

You can use the ISR to read the analog pin and set a global flag to notify the main loop about new result. In that way you would keep the ISR short, clean and well-behaving. The main loop will just wait for the flag to be set and then read the variable containing the analog pin, clear the flag and do the computing + printf-sutff. In this particular case it might be enough that the ISR just set the global flag at 1 second interval and the main program would just wait for the flag to be set by the ISR, clear it, and then read the analog pin value, do the processing and print the result.

It will prevent some possible corruptions scenario, but it's not either correct in this way, because the INT could occur at the moment where the main read the data, and you could miss/loss some value in this situation.

The only solution to be sure that there is no corruption would be to use a FIFO, so the INT stack the data read, the serial will unstack data to send.

In the current program sending from the INT or your approach will work only because the INT occurs every 1 second, and sending the data take much less than 1s so conflict/corruption is really unlikely to occur.

[Kalvin]

In the current program sending from the INT or your approach will work only because the INT occurs every 1 second, and sending the data take much less than 1s so conflict/corruption is really unlikely to occur.

Exactly this is assumed in my suggestion that the main loop will be able to complete the computation and print before the next ISR will occur. Otherwise there would be a need for a queue, and the queues can also overflow if the input rate is higher than the output rate. Only when the processing rate can match the input rate, the system will behave correctly.

[Fungus]

I don't think Dave or anyone here really cares to influence the Batteriser campaign to the average Joe Public.

Nope.

But some tech site might pick up on it and do an article.

[Kalvin]

In the current program sending from the INT or your approach will work only because the INT occurs every 1 second, and sending the data take much less than 1s so conflict/corruption is really unlikely to occur.

Using an oscilloscope with one or two channels is a simple way to estimate how well your system behaves and how deterministic the system is in time-wise. Dedicate two GPIO pins for the oscolliscope monitoring: One GPIO for the ISR and the other GPIO for the main loop. When the ISR starts, set the ISR GPIO to "1" and when the ISR is completed set the GPIO to "0". Same thing in the main loop: When the main loop is triggered set the main loop GPIO to "1" and when the main loop is completed set the GPIO back to "0". Now, hooking the dual channel oscilloscope to the GPIOs, setting the triggering to the ISR GPIO rising edge, one can observe the ISR and main loop processing times and the processing jitter. Using a digital oscilloscope, set the display mode to indefinitive persistence and let the system run for few hours/days and observe the jitter and maximum processing time.

[edy]

I don't think Dave or anyone here really cares to influence the Batteriser campaign to the average Joe Public.

Nope.

But some tech site might pick up on it and do an article.

I think the best approach is to continue to analyze the scientific issues behind this, and many other products. I agree, the chatter will be picked up by other tech sites and hopefully people who think of buying either existing stuff or support crowd-funding campaigns would do their research before jumping in. Let's face it, there is a sucker born every minute. All we can do is try to give a few of those suckers at least a healthy bit of skepticism by offering a more educated scientifically-founded critique to counterbalance the marketing hyperbole.

We can't make it a personal thing or a crusade. It will be a full time job trying to fight every single device, gadget, Kickstarter or IndieGogo campaign out there. There have been worse things already making way more money, and the flood of these gadgets does not seem to be abating. The crowd-funding sites turn a blind eye and the Internet media blog syndicate for the most part just wants to repeat the same media press kit to gain clicks and ad revenue.

What I love about EEVBlog is that we have a great community of people who all want to learn or teach or just chat about electronics. These "scam" devices just give Dave and the forums more variety of topical subjects to ramble about, refresh our fundamentals and joke around. But at the end of the day, we hope the world is listening in and can learn from it, or some media site will run "the other side of the story - one based on knowledge and truth" but even if nobody else cares, at least if Google indexes it, a few people may actually open up their eyes.

[Fungus]

In the current program sending from the INT or your approach will work only because the INT occurs every 1 second, and sending the data take much less than 1s so conflict/corruption is really unlikely to occur.

Yep.

PS: If you want to see it crash just add "Serial.print('X');" to your loop()

[FrankBuss]

I wrote a more portable version of the Arduino-voltage logger. Has a bit more jitter than the interrupt version, but this is not important for the 1 s sample clock. It should work on any Arduino and not crash. I think it might even work longer than 50 days, because of the magics of "unsigned int" sub/add C-behaviour.

Code: [Select]

int ledPin = 13;
int analogPin = 5;
unsigned long time = 0;

void setup()
{
  Serial.begin(115200);
  pinMode(ledPin, OUTPUT);
}

void loop()
{
  // wait for next second
  while (true) {
    unsigned long t2 = millis();
    if (t2 - time >= 1000) {
      time += 1000;
      break;
    }
  }

  // measure ADC input, scale and send to serial port
  char buf[16];
  float val = analogRead(analogPin) / 209.0f;
  dtostrf(val, 6, 3, buf);
  Serial.println(buf);
  digitalWrite(ledPin, digitalRead(ledPin) ^ 1);
}