JarrettSpent a couple hours troubleshooting some gremlins. My patterns were freezing after a few seconds of working properly. My codebase has some interrupts and is a little complicated, conceptually, so I stripped a lot of that code out, gradually, and in the process found absolutely no difference in how the thing was failing.
Turns out, this thing really eats batteries. That's no surprise, considering the quantity of LEDs, especially blue ones.
On power-up, voltage is nominally 4.5V, my PIC starts up and starts sending patterns to the driver chips.
After a few seconds of normal operation, this extra power draw causes the battery voltage to sag, browning out my microcontroller.
...but...
The driver chips don't turn off. They're not receiving any data, but they're otherwise working, so they just hold position. Meanwhile, they're keeping enough LEDs on that the microcontroller stays browned out, and never successfully recovers.
After getting suspicious and popping a few new batteries in, everything works great again.
PICs have a brown-out detection peripheral, but I've never had cause to look into how it works before. I guess I'll delve into it soon and add some user notification of some sort.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Maybe a Dead Man's Switch, er Dead PIC's Switch to turn off the LEDs if no data is being sent out?
Are you sure? yes | no
I have a single green indicator LED on the main body of the PCB. Currently, I use it to represent the state of the hall effect sensor when the PCB is not spinning. It's good for calibrating the position of the magnet.
If I can get the brownout detection shut down the drivers, and then to flash that LED rapidly, it would be a good indicator. I haven't looked into how that peripheral works yet though, so we'll see!
Are you sure? yes | no