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/
Latest video busting that poor Monkey:
Where did you get the troll?
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....
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).
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.
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.
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()
{
}
Did they start manufacturing?
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.
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.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.
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
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 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)
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.
{
...
Serial.println(buf); // Boom!
}
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.
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.
I don't think Dave or anyone here really cares to influence the Batteriser campaign to the average Joe Public.
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.
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.
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.
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);
}