I have built a garage door opener using the Concentric linear actuators driven by the dual VNH5019 shield (connected to a 3.3V FRDM-KL25Z using the mbed toolchain, there is also a nRF24L01+ for wireless control, but I haven’t activated that in the software yet).
I have two control panels, one inside and one outside. These are switches (normally open) that ground a signal line. I started using the internal pullups on the KL-25Z but I’ve now added some stronger (5K ohm) pullups. The outside control panel has 3m of 4-way shielded cable (GND, open and close buttons, and a ‘tamper’ signal that till trigger if the case is opened). The inside control panel has about 4m of 6-way shielded cable.
The signal lines seem to be rather susceptible to interference, both from other sources (eg turning on a nearby light can on occasion trigger something) and probably the actuators themselves are causing problems becuause I sometimes also get spurious signals while the garage door is moving (not at the start, typically after a second or so, which would about when the actuators get to full speed).
I’ve added some ferrite cores to the signal lines and this seems to have helped, but it is still a problem and obviously it needs to be very reliable - I don’t want the door to spontaneously close when someone is driving a car under it!
The system is powered by a 12V SLA battery. This is trickle-charged by a wall-wart that goes through a 500mA (approx) current limiter followed by a 13.5V regulator. I’ve also got a 300mA 5V down-converter (D24V3F5) which is going into the VIN pin on the KL25Z (which then gets regulated down to 3.3V, which drives the KL25Z and the shield logic).
Any suggestions for what to do?
I am sorry you are having problems using your linear actuator. How are you reading the signal change with your microcontroller? If interference is causing the signal line to read low for a brief second and triggering your microcontroller to open or close the actuator, you might consider having the microcontroller take multiple samples of the signal line and requiring the signal to be low for at least a second before moving the actuator.
By the way, your project sounds very interesting. Do you have your project documented someplace or videos of the garage door opening and closing?
Thanks for the reply. Yes, it is interference both from the actuators themselves and nearby AC power cables. There is a flourescent light not too far away, and a couple of times turning that light on has triggered the door to open.
I’ve made some progress I think. I wasn’t sure what to do with the shield on the cabling, searching around I saw mixed advice on whether to ground the shield at one end, both ends, or leave it floating. So I’d left it floating. After talking to an electronics engineer friend I’ve grounded the shielding at both ends, which appears to have helped a lot, I don’t think I’ve seen any unexpected issues since. I wasn’t doing anything special to debounce the switches, except some software debouncing which wasn’t doing its job in all cases. I’ve fixed that up too. I was doing the debouncing by ignoring inputs for 10ms after an edge transition, which stops the problem of debouncing but will still trigger if there is a brief transient. The better way (which I’m now doing) is to only trigger after 10ms from an edge if the switch is still in the same state, so that it ignores transients that last < 10ms. I could improve it even more - currently I’m only checking the state of the input 10ms after it detects a transition, and ignoring the state of the input until then. This would be susceptible to an unlucky case where two transients come exactly 10ms apart. So I could improve the debouncing software even more by only triggering if the input stays in the same state for >10ms.
For extra security I’m in the process of adding some RC filters to the switch inputs. I found it surprisingly difficult to find information on how best to do this, but I eventually came across http://www.ganssle.com/debouncing-pt2.htm which was actually the same circuit that I was thinking of anyway. I’m thinking that for a 3.3V microcontroller input, an RC filter with a time constant of around 10ms, using 0.1uF cap and 100K resistor should do the trick. I think the discussion in that paper on TTL levels and ‘dead zones’ isn’t applicable here?
I’ve also got some microswitches that detect when the door is open and closed, I haven’t done anything to the hardware of those, but I’ll simply make sure that the software is robust against spurious signals.
I’ll post some video of it in operation once its completed. It works pretty well, and it even comes pretty close to meeting the safety standards
I am glad you were able to get it working more reliably. I agree, you probably do not have to worry about TTL levels and dead zones. I look forward to seeing a video of it in action.