My Controlled Home

The idea is to re-use the Gate BCU and leave some components like the wireless receiver of the board. I bought two Sea Half Tank hydrolic swing gate openers that offer a serious amount of pushing force. The controller board that is supplied with it can drive two of these openers, the connections are very simulair to those of the Genius motor drivers using for the gate.

• Open-close: This is a normally open connection between pin 5 and 2. When closed for a short period, the gate opens or closes depending the current state.
• Stop: This is a normally closed connection between pin 3 and 2. When opened it stops the current open or close action.
• FSW-OP: This is a normally closed connection between pin 6 and 2. IR sensors can be connected to this input, for this pin 10 (24V) and pin 2 (Ground) can be used to power the sensors. 
• FSW-CL: The same as FSW-OP but than for closing between pin 7 and 2. Since I will not be using detection during closing this can be hard wired closed.

The controller does not support a opened- and closed- switch. Instead it uses timers to drive the hydrolic pumps and assumes the doors are mechanically stopped. They advice to keep the pumps running for a little while longer when the doors are closed so that the maximum ‘holding’ pressure is reached to keep the doors closed. It can also drive an electric lock if the holding pressure is not enough.

I would like to know when the doors are closed, this can easily be made using two magnetic alarm switches that are mounted on the top side of the doors. Open is not needed, or actually fully open is not needed, when the close sensors report open it is good enough. All I want to know is when I start a close cycle during a storm the doors are closed within a specific time. If not, I want to be notified by the MCU.

So, the conclusion is very possitive, I can use two times the same hardware for the BCU, the software of course will be different.

The gates and the engines for the gate arrived.

Each section of the gate will be driven by a seperate engine, I selected the Genius Falcon 8C for this. This engine has an integrated control unit, this makes driving the gate a lot easier than my previously defined block diagram. The whole detection of sensors and engine driving is taken care of by this unit, all the BCU needs to do is trigger the open/close input. Well, I do want access to the IR- and limit- and safety-switches so I can add some logic to the gate but this makes it more of an interface issue than of a driving issue.

The Falcon has a couple of connection using a 12 pins terminal block:

• Open-close: This is a normally open connection between pin 1 and 7/8. When closed for a short period, the gate opens or closes depending the current state.
• Stop: This is a normally closed connection between pin 5 and 7/8. When opened it stops the current open or close action.
• Edge: This is a normally closed connection between pin 6 and 7/8. All edge safety switches need to be connected in series between these two pins. If one (or more) edge switch opens, the current action is stopped and reversed for 2 seconds.
• FSW-OP: This is a current sensing input between pin 11 (current source) and pin 3. IR sensors can be connected to this input, for this pin 9/10 (24V) and pin 7/8 (Ground) can be used to power the sensors. The connection between pin 11 and 3 should normally be closed and must be opened when an object is detected. Since I will not be using detection during opening this can be hard wired closed.
• FSW-CL: The same as FSW-OP but than for closing between pin 11 and 4. I will have two IR sensors between the pillars, they must be placed in series so that the closing motion is stopped when an object is detected.

A second 3 pin connector is available which holds two limit switches. These are normally closed and opened when the gate is fully open or fully closed. These signals are not to be used ‘external’, but I want access to them so the BCU can take action based on it status.

When a sensor is IR sensor or an edge switch is triggered, the Falcon does not take any action when the object is removed. For this reason the BCU needs access to these sensors as well so it can take the correct action by opening or closing the gate. Also, when an edge switch is detected, it is a good option that the MCU sends an allert message to me to check what the rootcause was.

The relays used in the IR- sensors and the edge switches can not be connected in parallel to my BCU and the Falcon, this would  result in signal loops between the two systems which are electrically not connected. If the relays were double switch types it would be OK, but for the edge switches this will not work. So a small board needs to be placed in between the sensors and the Falcon which basicly ‘doubles’ all the signals. This could also be integrated on the BCU board, but there is an advantage to use a seperate board. The BCU for the garage doors  will need the same BCU but it might need a different interface board between the sensors and the control logic (which is also integrated) of those engines. By using two seperate interface boards I can keep the BCU (which is more complex) the same.

The interface board can be powered by the engine itself, there is a 24V power supply available. The spec does not state how much current it can supply, but it can drive a 3W flash light to indicate gate movement. Since I will not be using a flash light I can safely assume I can use the 3W for my interface board, so 125mA at 24V.

The IR-sensors use a relay that is normally open. When the power supply is switched on, the relay activates so it is closed indicating to the Falcon board no object is detected. Below the simplified schematic of how the two IR sensors are connected to the Falcon.

The relays of the IR-sensors can be used to drive a new relay that has two switches. In that case one switch can be used for the Falcon and the second one for the BCU. This results in below simplified schematic:

The same principle can be used for the edge switches:

For the limit switches it is a bit different since they are integrated in the housing of the Falcon and not to be connected externally. Luckily the switches are connected to the board using a 3 pin Molex connector. When measuring the signals on the board it seems the two switches are connected to eachother and tied to ground while the two other contacts connect a pull-up resistor to ground. Since I do not know what the current rating is of the switches used and I’m not sure they can handle the current spikes of relays being activated the best option is to drive transistors with them as indicated in below schematic:

All sensors are now available to the BCU as well, since this will be placed on an additional board it might make sense to add an extra relay that does nothing else that switch on when the power is available in the Falcon. In that case the BCU can detect if the Falcon is powered on and the add-on board is functional.

The rest of the functions for the gate are:

• The wireless receiver
• 4 keypads
• 1 relay to control the lighting around the gate
• 2 IR-switches to detect if objects are in front of/behind the gate

And finally, the BCU should be re-usable for the garage doors, so I will first need to do a study on what is needed for the garage as well before drafting the schematic.

The keypad hardware is fully functional, the next step is to develop the AVR code so it can be connected to the frontgate and garage door.

The keypad will act as an IIC slave allowing me to connect 4 of them to the BCU of the main gate and 1 to the BCU of the garare doors. As a base slave address I will use 0b11000xx0 which is used for some sort of TV chip so not lickely to be used in the same design as my keypad. The sub-address is selected by the two jumpers on the board, these jumpers must be hard-wired using a piece of wire, if a headerstrip would be used the RJ45 plug can not be inserted in the connector anymore.

The keypad scans the key in an endless loop by calling the function ScanKeyPad, this function drives the rows low in the correct order and reads the columns to detect if a key is pressed. It basicly maps all the keys as a 16-bit pattern and than compares this pattern with defined patterns that have 1 key pressed. If the pattern matches, the key is returned as an usigned char that ranges between 0 and 11. The 0..9 of course correspond with keys 0..9, 10 is for the * and 11 is for the # key. If no or more than one key is pressed, the value 0xFF is returned.

When a key is detected, the code waits for 40ms usign the Wait function, this function first sets a counter called Timer and than waits until the value of Timer is 0. The part that decreases the value of Timer is an ISR coupled to a hardware timer 0 that is set to trigger every 10ms. So, as an example, in order to wait 40ms, the call Wait (4) is made and after 40ms the value of Timer is 0 again. After the 40ms the keypad is scanned again, if the same key is found as before than it is considered to be stable. The key is than stored in a buffer called KeyBuffer that can hold upto 5 keys. The first 4 keys are the pincode, the 5th key is optional and can be used by the MCU to (for example) indiccate if the gate must remain open until further notice.

When the key is stored, the Beep function is called. This function enables the PWM outputs on OC1A and OC1B which are set to a frequency of 4Khz. OC1B is set to be the inverse of OC1A which results in an AC driving of the buzzer using a peek-peek voltage of 2*3.3V. When the PWM outputs are enabled, the function Wait is called before the PWM outputs are disabled again and all keys are relased again.

The system than sets the value of Time to 1.5sec (150 units of 10ms) using the SetTimer function before waiting until the next key is pressed. This is done to check if keys are pressed quickly after eachother, if not, than any previous key entry should be erased from the KeyBuffer before the new key is stored. When a next key is detected and the value of Timer is larger than 0 the key is pressed within 1.5 seconds, if the value of Timer is 0 than the key is pressed at least 1.5 seconds after the previous key and (as a result) this key must be seen as the first key of a new code.

After 4 keys are detected, the system scans the keypad for 1.5 seconds (so until the value of Timer is 0). If a key is detected in this period it is stored in the 5th location of the KeyBuffer, if no key is detected in this period the 5th location is set to 0xFF before reporting the entry of a valid code to the BCU by pulling the /INT line to ground. A bit is set in the SystemStatus variable to indicate a code has been entered and further scanning of the keypad is blocked until the code has been read by the BCU.

The BCU can read the code by reading a byte from the keypad using IIC. This will trigger the ISR linked to the TWI module of the keypad, in this ISR the correct action is taken based on the value of the TWSR register. The keypad always return the value of SystemStatus as the first byte when a start condition for read is found. The BCU can than stop reading but this will not clear the keypad for scanning for new key. Only when 6 bytes (so SystemStatus and 5 keys) are read, the keypad clears the bit in the SystemStatus, releases the /INT signal and a new code can be entered.

The BCU can also write data to the keypad, for example to switch the backlight on and off. For this a command and a value are packed in a single byte, the high nibble is the command and the low nibble contains the data. At this moment only one command is defined for controlling the backlight but further commands can easily be added.

The latest version of the software can be downloaded here.

The hardware design of the keypad is finished, you can download the design here.

The connection to the BCU is done using the RJ45 connector, most wires will be used for power. The keypad is a I2C slave, the SDA and SCL signals are used for communication and jumpers JP1 and JP2 can be used for selecting up to 4 keypads connected to a single BCU. J3 connects to the keypad S.12150.241, there are 4 columns with a 10k pull-up resistor and 4 rows that can be driven by the ATmega32. The LED’s that are placed in the keys are all conencted together and can be driving using an PWM output in combination with the FET Q1. This will allow me to adjust the brightness of the backlight, not sure if I will do so, but at least I’m prepared.

There is a small piezo buzzer EFM-250D placed on the board that is driven using two PWM outputs. Since the controller runs at 3.3V the amount of noise it can make might be limited, by driving it using two PWM’s that are inverted compared to eachother the piezo can be driven in an AC mode, so it thinks it is driven by a 6.6V making a lot more noise.

The connector J4 is there to connect a big ‘call’ button that is only used in one keypad outside the gate. The LED that is inside this button is driven by the PNP transistor Q2, using this construction reduces the amount of wires to the button from 4 to 3.

The board is a round board of 65mm in diameter so it can fit into a standard installation box. The layout is send to PCB Pool for production, I expect them to arrive on my desk in two weeks from now.

I’m strugeling a bit with the design for the numeric keypad that will be used for the garage doros and for the gate. Not so much from how it should work but more from a chip selection. In the past (pre-microcontrollers) there were keypad encoder chips like the 74C922 or 74C923 from FairChild which encode 16 or 20 keys, take care of the debouncing and generate an interrupt when a valid key has been detected. These chips are no longer commonly available, when you can still buy them they cost more than a small micro.

With respect to the micro, I will use the ATMEGA32L-8AU as the ‘standard’ controller which costs 3.84 EUR and offers many IO pins and interfaces. I admit, using this micro for encoding a keyboard is an overkill. I can safe 1 EUR by selecting a smaller one, but from a logistic point of view I will loose money since I only need 3 keypads.

From an interconnection point of view, I will probably use network cable since the connectors are cheap, I have lots of cable available and installation is easy. That means I have 8 wires available. The wires can each have a current of 600mA, so 2 can be used for the power lines, 2 for the backlighting, 1 for generating a keypressed interrupt and 1 for the serial data leaving 2 wires free allowing 2 wires for the positive power supply and 2 for the ground.

If we than have a relatively large micro available, than it might make sense to add some more logic in the keyboard. For example, instead of reporting every keypress only report a valid entry which exists out of 4 keys pressed within a certain time. In that case the BCU is only interrupted when it actually needs to do something, it has to read the string packed into two bytes and send this to the MCU so it gets instructions what to do based on that string. Since I2C is used, the BCU can also write data to the keyboard and, for example, enable the backlight. Than the 2 backlight wires can be used for power supply again making it more robust.

When writing this down, I realized that it might be a good idea to extend the 4 key pincode with an optional 5th key. Sometimes it would be nice to keep the gate or garage doors open, for example when we are loading or unloading materials. When you than enter a pincode and within ‘x’ ms press the * or # key this could be used for that functionallity. If you do not press the 5th key, that means open and close when passed. The MCU can still override the ‘always open’ function, after a specific time, If the front gate is left open by accident, it is nice that the MCU closes it when there is no activity detected for 30 minutes (for example).

Since we work with horses it might make sense to have two extra keypads at the front gate. When you sit in a car the typical height for the keypad is approx 70cm from the ground. When you sit on a hore this can quickly go up to 170cm making it impossible to open the gate since the keypad is mounted to low. Since I2C is used they can all be connected in parallel (4 of them) for the frontgate and assign different adresses for each of them. The interrupt can be shared but that would require polling which keypad has reported the interrupt, if IO pins are available on the BCU than using seperate interrupt lines make the software more easy.

Next to scanning the numeric keypad it must also be possible to connect a single ‘call’ button to the controller. This will only be used for the lower keypad on the outside of the gate so that visitors can press this button to indicate they want to get in.

The garage doors will use electric motors to open and close the doors. The remote control that is part of the gate is used to remotely trigger the garage doors as well. As mentioned there will be three buttons on the remote control. Pressing A will only activate the gate, pressing B will only activate the garage, pressing C will activate both. Not directly since the remote control is part of the gate BCU, so when button B or C is pressed, the MCU will respond by sending commands to the garage BCU as well.

The garage doors are very large: 1.6m wide per door and 3.2m high. The doors swing inwards to open the garage, not the most optimal direction but cosmeticly the most beautifull. Since the garage is 10x8m there is some room to spare for the doors. Below a schematic overview.

In order to manually open the doors there will be a button on the inside and a numeric keypad on the outside. The IR beams provide ‘some’ level op protection the stops closing the doors when they are triggered. These sensors will be connected to the motor control that is supplied together wiht the motors, they will also be connected tp the BCU so it can report the interrupt to the MCU.

The motors are hydrolic half tank pistons from Sea that deliver an impressive 6400N pressure. Reason for selecting these motors is that the doors face the direction of the wind, when there is a storm the motors need to keep the doors closed or must be able to close the doors pushing into the wind with a large surface.

The BCU of the gate and the garage will look very simular. Main difference is the wireless receiver on the gate, this uses a serial port for communication. Since the keypad is located at a distance from the bCU (several meters) the optimal architecture is to place the smallest AVR controller on the keypad and when it detects a keypress send this using a serial interface to the BCU. The UART is used by the wireless receiver, the SPI by the network controller so this leaves the I2C interface. In theory also the SPI can be used, but I want to prevent connecting long wires to the which might interfear with the network communication.

First step is to select and build the keypad. It must be waterproof and backlighted, possible candidates are the S.12150.241 from EAO or the MCAK207NSSLWPMM. The first one can be build on top of a surface, the second one is placed though a hole in the housing. The first one feels more waterproof and cosmeticly nicer, so that’s the one I will use. The keys are placed in a matric, so it requires a clasic ‘drive a row and read the columns’ approach.

In the past I decided to use the extra wires in the network cable to provide power to my BCU’s instead of using a formal Power Over Ethernet solution. However, I continue to rethink this topic if this is the right choice. Knowing myself this means I do not agree with the decision I made, so it is time to see if alternatives can be found before designing the first BCU’s.

The main reason for deciding to make my own power supply was costs, well, I convinced myself that ist was costs. In practice I’m worried that the power design using a POE chip will be complex since coils and specific layouts are needed to tune the solution. I found a nice POE chips called the SI3402 which includes the rectifiers, the power communication part and a DC-DC convertor. This simplifies the design a lot, but the coil listed in the reference design is not supplied by Farnell, Mouser or Digikey. That means selection an alternative an building prototypes with undefined results. Also the soldering of the thermalpad will present issues, so although this chip is a nice one it will not work for me.

While searching for alternatives I stumbled on devices from Silvertel. They do not sell chips but small modules that can be placed on the board directly, the AG8000 series do not require any additional component like rectifiers or coils, simply connect it to the ethernet connector and done. In heavy load situations an cheap capacitor is adviced to prevent dips on the power lines.

And thats not all… The costs are 7.72US$ (5.46 EUR) for the AG8003S which generates a 3.3V, my original costs for the power supply was 2.68 EUR but this excludes the costs for the power supply part that injects the power and the quoted costs is the non-negotiated price for a single unit. The shop already provide a ‘quote’ button suggesting that the price will be better when I order 100 units. I guess it will increase the costs of the BCU but in return I get a standard network solution with a known-good power supply.

There are 3 versions available that differ in the output voltage: 3.3, 5.0 and 12.0V can be selected. The network controller uses 3.3V so that selecting the AG8003S looks to be the right one. However, many circuits use 5V parts as well, the front gate is a good example were the wireless module requires 5V. I would not like to have both parts on stock if not needed. All 3 modules offer a nice option to change the output voltage within a certain range by adding a resistor to a feedback pin. The 5V version can be tuned between 2.5V and 7.5V making it possible to use the 5V version for 3.3V designs as well. When both 3.3 and 5.0V are required a simple 3.3V LDO can be placed on the board to provide both voltages. I guess the voltage range is liniar by changing the value of the resistor, the spec only states 3 concrete levels so I’m not sure my plans can be executed. I decided to order the AG8003S and AG8005S to do some experiments using the BCU Development Board and below schematic before making a final decision on the power supply.

Note that for larger designs that require more voltages like 24V I have no intention to use the POE module, in that case normal power adapters or a 230V power supply will be used.

The MCU is the central point in the control system, it receives all messages from the attached BCU’s and decides what to do. To keep track of what has been going on it makes most sense to add a logging system on the MCU. There are two methods of logging data. The first one is to log all raw data that is being send between the units, the second one is to log the ‘translated’ messages based on the content of the data.

The first one contains the most information, the second one is more readable. In order to decide how to store the info we need to understand what we actually will do with the logged info. For one, when something went wrong I want to be able to see which BCU reported what data. That can be done in both methods. If I want to know when the front gate was openened yesterday it already becomes more complex to filter this out the translatted messages. When I want a graph that shows the temperature in the horse barn over the last week this calls for data logging instead of message logging.

Messages between the MCU and BCU are always in below format:

const
   cv_MaxFrameSize = 100; // Can be 1472 but limited to micro controller memory
   cv_HeaderLength = 2;
   cv_DataSize = (cv_MaxFrameSize – cv_HeaderLength);

type
   TBCUCommand = record
                                            Command : Byte;
                                            Length        : Byte;
                                            MessageID : Byte;
                                            Data              : array [0..(cv_DataSize-1)] of Byte;
                                        end;

This data can be placed directly on a stream of bytes, however also the ID of the BCU that has send the command and the date/time it was sends needs to be stored. The date does not have to be stored if one logfile per day is generated. This keeps the files smaller and in case of damage only one day of log data is gone.

This leaves system messages generated by the MCU itself, for example ‘System started’. When a BCU sends a command the MCU needs to translate this into a readable message, it makes sense to make objects for each type of BCU so that custom functions can be developed and placed in that object. The MCU than generates a list of objects that matches the installed BCU’s. In the object a function GenerateStatusMessage  can be placed that takes a TBCUCommand variable as input and delivers a string containing the message. This makes most sense since command number 1 for a normal light has a different function than command number 1 for the front gate. In the object for the light the command can than be translated into ‘Light switched’ while in the gate object that is translated into ‘Gate openend’.

The MCU can also be an object which sends messages to itself. For example command 1 is a system status change command, data parameter 1 indicates the new status like ‘started’, ‘warning’ or ‘critical’. In that case data can be logged as it was coming from a BCU and it allows searching through these data entries as well, for example ‘when was the last time the system changed to a warning state’ and ‘how long did it take to go back to normal mode’?

It might look like an overkill for now, but in the future I want to ask (not type, bus ask) these kind of questions and expect the MCU to answer them.  All functions are available in the unit LogFiles, this contains an object called TLogFile and this object supports functions like CreateLogEntry (FromNode : Word; BCUCommand : TBCUCommand) and FindLogEntries (FromNode : Word; StartTimeStamp : TTimeStamp; EndTimeStamp : TTimeStamp; var SearchResults : TBCUCommandList). The TTimeStamp type is a simple record that holds year, month, day, hours, minutes and seconds. The TBCUCommandList is a list object that holds the original BCUCommands that a BCU has send to the MCU.

As mentioned, one ‘big’ computer is controlling my house, this is called the Master Control Unit or MCU for short. Well, big…. It is an Intel D945GSEJT Fanless UltraFlat Atom Mini-ITX Motherboard using 2GB of DDR2 667Mhz RAM and a 30GB SATA II solid state disk. The power supply is a 12V adapter, also fanless. As a result I have a silent computer (really silent as in no noise at all) that can use Windows 7 Pro as it’s operating system. As a monitor I will be using a 15″ TFT with a touchscreen on top to use as mouse and onscreen keyboard.

The first step is to install Windows 7 Pro, I will not be using a DVD player for installation but a bootable USB stick of 8GB. In order to prepare this stick for installation, below steps have to be followed using an installed PC:

• Delete all content from the stick
• Open command prompt with admin rights by typing cmd in the Start menu search box and hit Ctrl+ Shift+ Enter
• Type DISKPART and hit enter
• Type LIST DISK, hit enter and note down the disk number of the USB stick, in my case it is disk 1
• Type SELECT DISK 1 and hit enter
• Type CREATE PARTITION PRIMARY and hit enter
• Type SELECT PARTITION 1 and hit enter
• Type ACTIVE and hit enter
• Type FORMAT FS=NTFS and hit enter
• Type ASSIGN and hit enter
• Type EXIT and hit enter
• Insert the Windows DVD and note down the driver letter of the DVD (D in my case) and of the USB stick (G in my case)
• Type D: and hit enter
• Type CD BOOT and hit enter
• Type BOOTSECT.EXE /NT60 G: and hit enter
• Close the command prompt and open explorer
• Copy all content from the DVD to the USB stick

That’s it. A bootable USB stick. All commands might take several seconds to minutes to complete, be patient.

One thing I like about the central compunter from Startrek is that is communicates with the user using speech. Needless to say this must be part of my own system as well, but not using pre-recorded phrases but real-time generated status messages.

Microsoft offers the Text-to-Speech functionallity on the PC, what we need to build is a function that takes a string as parameter and sends this to the text-to-speech library. Older version of Windows required installation of the speech SDK before this could be done, with Windows 7 this is pre-installed. In Delphi use the Component | Import Component menu option and select the Import a Type Library option before pressing the Next button. Scroll down to Microsoft Speech Object Library, select it and press the Next button. Create a new pallete page called Speech, press Next, select the option to create a new Unit and press Finish. This will create the unit SpeechLib_TLB which I placed in the same folder as my GlobalTypes unit.

This unit needs to be included when speech functionallity is used in the application. In order to speak out loud a string, I developed a function call SayIt which is part of the GlobalTypes unit:

var Voice : TSpVoice;

procedure SayIt (TextToSay : String);
begin
  if ((Voice <> nil) and (not SilentMode)) then
    Voice.Speak (TextToSay + ‘.’, SVSFlagsAsync);
end;

When called it uses the voice that is setup on the computer used. The SilientMode variable used here is a global that overrules any playback of audio to prevent my computer start talking in the middle of the night. By default Windows 7 uses Microsoft Anna as the default voice. Using this one my computers sounds scarringly simular to the voice of the starship Voyager…

Next to investigate is how the speech-to-text option can be used.