Gate PIC replacement.

Alan Robert Clark

1 February 1999

1 Introduction

The Gate opening machine is a standard ``Remez'' swing opener, with a 12V motor (windscreen wiper!), and battery etc. It is a marvellous design, works well, except for three things:

It doesn't respond, and slows down in really cold weather.

It gets seriously confused after a large rainstorm.

It doesn't respond to multiple triggers to start/stop things

Not to disparage the design, it is well thought out, especially the use of 12V! There have been several occasions when lightning has tripped the power, and the gate carries on merrily; it is exceptionally sturdy from the mechanical perspective; the charging circuit is well protected (MOVs inc) etc, but the PIC just doesn't respond! They use a 16C57, which is a big bugger, for the various options, but then proceed to use IC-like DIP switches, which conduct at the slightest sign of humidity. Under rainy conditions, the gate is in permanent ``pedestrian mode'', where it only opens so far, and closes again after 5 sec. If you keep triggering, you can get it to open, but to close it, you have to fool it by ``double triggering'', ie trigger, it closes a quarter of the way and stops. Trigger, wait for 1/2 sec, trigger again, and it closes another quarter. If you miss sync the double trigger, it opens a quarter instead, and you have to trigger it all the way open again.

Frustration isn't the word. When you've almost got it closed, it will re-open of its own accord since it now thinks its closing it. Attempting to keep the thing dry has no apparent benefits-the design itself is just too sensitive. They probably used 10 and 100k resistors where 1K or lower would have been more robust. They have fancy sensitivity pots which control the stopping of the gate should it encounter resistance. Its just too fancy.

In really cold weather, the PIC simply slows down (Couldn't find a crystal on the board, they probably use the RC mode which is very sensitive to temp). The pedestrian mode is obviously on a timed basis (there is no feedback mechanism), and the colder it is, the less space you get to walk past!

The primary problem is it's response time. Come hell or high water, you can VERY seldom stop the gate mid-flow. Clearly they are either using a VERY long debounce cycle, or a large capacitively coupled input (I haven't really investigated) As a result, if it is about to bash into someone's car, it bloody does. The ``autoclose'' facility is great, since certain members of the family have a tendency to forget... :-), but at a max of 40 Seconds, its a pain in the arse when multiple guests are leaving :-)

So...... what I want:

a two-minute autoclose, for when certain family members forget :-), but long enough to let guests out etc....

IMMEDIATE response to a trigger. If an autoclose is in progress, a trigger must reverse the closing, and the autoclose timer must start again from scratch!

IMMEDIATE response to a trigger. It must simply stop if it is moving, and go back.

The philosophy is thus that a fancy pressure sensitive thingy is not necessary, but that I can judge when I want the action aborted, but then I want it done!!!

One of the problems is that the battery supply voltage drops below 12V when the gate motor is operating. The QD receiver then does not listen to a keypress. (Designed for 12-24V, but clearly needs at least 12V - will address with monster cap and diode, I think.)

2 Operating modes

2.1 Manual

The trigger input comes straight from the QD receiver, which is a relay output, closed for as long as the button is pressed. There is not much of a delay in the process. A trigger needs to trigger an opening or a closing. When it is fully open, the cams on the gate operate a microswitch which switch off the juice automatically, and only respond to juice in the opposite direction. Quite Nifty really.

A trigger during opening or closing operation must stop the gate and reverse.

A pedestrian input must open the gate for a period of time, so that it only partially opens the gate, followed by 10 seconds of being open, and must close fully. Only after this cycle is complete must it again listen to the pedestrian input. ie it must not be possible to re-trigger it all the way open. (Pedestrian mode not yet implemented)

2.2 Automatic

If the gate is fully open, a two-minute timer needs to be started, and the gate closed automatically. If a trigger happens during the closing, the gate is to be opened, and the timer reset.

3 Hardware Design

3.1 IO Reqd:

I	Trigger
I	Pedestrian
O	Direction
O	MotorOff

The Direction output feeds a relay to reverse the polarity of the juice to the motor when this is given via the MotorOff output. I could also use an H-bridge I guess.

The use of the n/c contacts ensure that the gate is always closed, as power is always applied in that direction, until the cams cut it off. ie with both relays de-energised, the gate closes-hence MotorOff!

4 Software Design

I shall use my standard RTOS (Real-Time Operating System) kernel, which spends most of its time in a wait cycle, waiting for the RTCC to kick-in, and then begins a processing cycle, which runs through the various tasks. These can be of variable length (they usually are due to external conditions etc), but the maximum time taken must not exceed a processing cycle. In this philosophy, all external events (triggers) are synchronized to the processing cycle granularity. If more instruction cycles are needed for a task than are available in a processing cycle, the task is split into sub-tasks, and the progress through the task is monitored by flag-passing. In this class of RTOS, interrupts are a) not required, and b) can mess things up a bit!

4.1 System Scaling

Once again, I shall use my HyQ 451.550 kHz crystals :-), but this time we need a processing cycle of around 0.1Sec response time. Since this is quite slow, we can dispense with the debouncing process!

The instruction cycle thus runs at 451 550/4 = 112 887.5 Hz! meaning that an instruction takes 8.86mSec. Using the full 1:256 Prescalar, we get to an RTCC rollover of 2.27mSec.

To get a 0.1Sec processing cycle, we therefore need 44.0967 counts :-). Thus at 44 counts, we get 0.09978 Secs, which is pretty good enough as a time base.

Thus in terms of the system scaling granularity, the RTCC rollover occurs at 2.27mSec, and the smallest (logical) time interval avaliable is a tenth of a second, which is perfectly adequate for this simple project. Since an instruction cycle is 8.86 muSec, we have 11 264 instructions per processing cycle!!!

My standard RTOS requires 1 label to be defined-UserProgram, and requires a goto Wait at the end of the task list. In this way, I prevent the unnecessary use of a stack level, and since I designed the RTOS originally for the 16C54, with only 2 stacks...

4.2 Modules required

My RTOS approach above allows for a very modular system, and individual modules can simply be dropped in and taken out at will. There will be a number of common modules.

4.2.1 InputCheck

Simply checks and processes a Positive Edge on the Trigger input.

4.2.2 DoTrigger, DoDirection, DoMotor

Since a trigger has occurred, reset timers, change direction, and start gate. I implement a guard-band where power is removed, slight wait, direction relay changed, slight wait, power restored. This tends to overcome the rather nasty +12V to -12V transition :-)

4.2.3 DoAutoClose

Ensures that if an opening motion occurred, that a closing one occurs after two minutes! Note that a trigger during an autoclose re-opens the gate and restarts the timer, giving another flood of guests time to leave :-) (BTW, What is it about guests that the most they talk all night is at the car in freezing conditions :-)

File translated from T_EX by T_TH, version 2.86.
On 7 Feb 2001, 15:56.