Trying to debug some minor issues in my ActivityBoard project. The Rigol really is a big help! A great way to check the interrupts I’m trying to handle.
Ever since I've finished the first prototype of my Automatic Curtain project one and a half years ago, the curtains have been running without any issues. Unfortunately, that came to an abrupt end this weekend.
When I started this project, I've always thought the mechanics would be the first point of failure. It turns out, my sloppy electronics design is the first to kick the bucket. It all started during my lazy morning routine: I tried to open the curtains, but after a movement of 10cm it suddenly stopped. Pressing the button again helped, but only for another 10cm or so. The weird thing was that all four of the curtains had the same issue.
It looked like the curtain controller somehow 'thought' it reached the end stop. But before I jumped to conclusions, I took a more scientific approach: I flashed my curtain drivers with a quickly thrown together self test, and started debugging.
Let that sink in for a minute: I started debugging my curtains. And I'm not talking about washing them to remove some dead fly stains!
Anyway, my suspicion was quickly confirmed when my serial monitor started logging false positive end-switch presses.
For the end-switches I used some cheap AliExpress switches, so just to be sure, I checked them with my multimeter, to see if they still work properly. Although it was highly unlikely that the actual switches had some problems, since this would mean that all the end switches on all of four of my curtain motor units would have died at the exact same time. And indeed, the switches worked perfectly fine.
Time to step up my debugging game. Let's grab the big guns and trade in the multimeter for my scope. It's nice to use this beauty from time to time.
The scope quickly showed me something that clearly explained the problem: the end stops had a huge 50Hz interference on the connecting lines. In most cases the 50Hz peaks didn't trigger a state change on the mirco controller, but every now and then it did.
Now, of course, this raised the question: how is it possible that the interference suddenly created a problem for my drivers, after one and a half year of problem free running. The 50Hz interference was obviously coused by the mains power, so just out of curiosity, I turned of all other devices in my house (by switching of the circuit breakers or unplugging the cables) but this didn't have any effect on the measured interference. So I suspect one of my neighbors turned on his self built 50Hz EMP cannon. That must be to only reasonable explanation. Right?!
Anyhow, time to work on a solution. Because closing your curtains manually is barbaric. Of course, the best way to solve this issue is to shield my motor driver and accommodate all the long wires with filter caps. But honoustly, I wasnt really looking forward to disassemble all motor units and the control panel, and rework all the motor driver pcb's. I needed a more creative approach. Luckily, lazy people tend to have the most creative solutions.
So in stead of filtering out all the noise, how about we only prevent the noise from triggering a state change? In other words: why don't we just debounce the signal? And even beter yet: let's make the debounce filter a pluggable connector which simply plug in between the current connection?
A male and female plug, two resistors, two capacitors and a piece of protoboard was all I needed to make this elegant solution. The setup is pretty straight forward:
With the above the setup (which is a debounce filter for 2 input), the signal needs to be low for a (relative) longer period of time, before the signal triggers a state change. Of course, this will only work if we set the input pins to INPUT_PULLUP. The time necessary to change the sate depends on the values of the resistor and capacitor.
Three addition wires allowed me to quickly measure the result with my scope. And lo and behold, this worked as hoped. The interference was gone (and yes, the buttons still work).
Now although the control buttons didn't suffer from the same issue as the end stops since they were already debounced programmatically (something which wasn't a valid option for the end stops due to the speed nessecery for running the motor), I choose to accomodate all the input lines with a debounce filter. Soldering 8 of these cute little boards didn't take that long anyway.
One minor downside: the motor driver start to look a bit like a messy contraption.
Maybe it's time for an AutomaticCurtainMotorDriver® V2 ...
Saelig Company, has introduced the RIGOL MHO900 Series Ultra-Portable High-Resolution Oscilloscopes. Featuring 350/500/800 MHz analog.
Saelig Company Inc has introduced the RIGOL MHO900 Series Ultra-Portable High-Resolution Oscilloscopes, featuring 350/500/800 MHz analog bandwidths, 4GSa/s real-time sampling, and up to 500Mpts memory depth. The MHO98 Special Edition offers 1GHz bandwidth and 500Mpts memory, along with a built-in 2-channel 100MHz AWG and upgraded styling.
Fairport, NY. Saelig Company, has introduced RIGOL MHO900 Series Ultra-Portable High-Resolution Oscilloscopes.
Saelig Company Inc has introduced the RIGOL MHO900 Series Ultra-Portable High-Resolution Oscilloscopes, featuring 350/500/800 MHz analog bandwidths, 4GSa/s real-time sampling, and up to 500Mpts memory depth. The MHO98 Special Edition offers 1GHz bandwidth and 500Mpts memory, along with a built-in 2-channel 100MHz AWG and upgraded styling.
