Power supply

In last post I have mention the power supply is too strong. By checking the documentation again I can say it way to strong, 60W. Originally I have designed my own power supply with transformer, rectifier and some switchers to deliver 13,8V for battery and 5V for GSM. Together with some led signalizing the status of mains and battery. But later I have considered it rather inefficient for 24/7 running.

Developing a true switching power unit is rather expensive, beside I have no previous experience, and I'm just a hobbyist. And my favourite producer of power supplies had a nice choice of 13,8V units. I have chose PSC-60-C, the one with enclosure. It has two outputs, one for battery charging and one to power for main board. It has also open collector outputs for signals when the AC is off, or the battery is reaching low level(11V). Then it also cuts of the battery when it reaches 10,5V. Just everything I wanted and it has 84% efficiency. Also it looks nice and shiny in the box :)

Short wires

Here is what happens when you try to connect PIR sensors to powered up main board :(. Well not really what should normally happen.

I was about to test everything in real life as the software and hardware worked fine together, but didn’t think about short wires on the other ends. I have connected 2 PIR sensors and left the board powered on. All the leds on GSM modem a Ethernet card lit up and I started to connect wires on first PIR that is just around corner. When I went back to main board there was strange light coming out of place where is no led. It was bead!  But before I was able to unplug it it died and took some other components with it. The second PIR had shorted power wires, upps.

I must say the power supply is too strong, with battery connected it can easily put few amps into any 12V rail. As you can see on the picture the power went to second PIR sensor there was shorted and came back to analogue ground that is connected to digital ground by bead. And it didn’t withstand the power that was flowing through it. As is burned it probably touched the 12V rail that is near and killed the rest of the board. So, yes I have designed the board as well as I could to handle over voltage and or short on signal wires, but I failed on power lines.

Damn, I have the input over current, over voltage on the remote board but not on the main board. A simple polymer fuse would save the board as it was able to operate like this for at least 3-4 minutes. Now I have to think if I will make new revision of the main board or just solder another one and put a fuse on the 12V input.

Wiz820io power on problem.

Some months ago I have found that the wiz820io is not recovering correctly on power failure. There is needed to reset it after power on. Sadly I have connected the reset of atmega to wiz820io. There was two possible solutions I had on mind, first to use the Ethernet INT signal that is not used as separate reset, and second to add a watchdog chip to the board.

I went first with with the watchdog variant. I have found, and bought MCP130 which is a voltage supervisory device. It is designed to keep a micro controller in reset state until the system voltage has reached the proper level and it is stabilized. By looking at the schematic I have found that the R22 resistor, 10k reset pull-up, can be replaced by MPC130. The MPC130 is available in SOT-23 package and pins matches the footprint of R22 resistor except GND signal. I have replaced it and soldered extra wire form nearest ground to watchdog.

I happy to say that the watchdog keeps the reset long enough to satisfy the wiz820io and the main board is now recovering from complete power loss without any issue. Just for completeness the wiz820io has its own 10k pull-up.

If there will be some new revision of the main board, I will replace the R22 with  MCP130 and free the INT line to wiz820io for digital input. The price of MCP130 is 0.25 EUR for 1 piece in our local shop and it is well worth it :).

Web interface - zones

Zones  are the basic monitoring elements. Currently the only zones present are the ones that are hardwired on the main board. There are physically present 7 analog zones and 4 digital ones. As you can see on the picture there is table that represents the overview of all the zones and their statuses.

The future is open for at least three possibilities that I have prepared already. One is to use shield that communicate over TWI interface. This can be either analog multi channel ADC for analog inputs or TWI port expander for digital inputs. Other would be remote zones tied to remote boards. These board are equipped with extension header to easily break out the SPI, TWI, analog or digital pins. This would also simplify wiring of the distant zones. For now I'm planning to make the second option available. Third would be radio controlled zone, or radio controlled remote board.

But current stage is just the hardwired zones. And the configuration in web interface is as follows. There is zone number witch represent the port on the board and also type of zone. Then there is a zone name which a user can modify and can span over 15 characters. This name is than used when sending SMS messages or is used when reading log over web interface to better represent it then just the zone number. Next is the switch that is turning the zone "On" or "Off" and it does exactly this.

Auto arm is telling the system to set the zone to arm status when there is no movement in the zone for specified amount of time. I will use this for garage that is attached next to our house. Next switch is open alarm, that does the opposite. It monitors the zone and when it is open for longer then specified time, it issues a message in log and sends out a SMS. It is intended more for digital zones, such as door switch, and allows the system to let you know that you forgot to close them. Again a garage door is a good example, if you forget to close it and you are already in house, system will notify you.

Authentication delay switch is telling the system, how long it should wait for the authentication if the zone is tripped. This let you easily adjust the timing mechanism of alarm. For example if some one triggers the zone in you front door, you can set the authentication time high. Because you can assume that it is normal pathway. On the other hand if someone trips the zone in your bedroom that has only window, you can set the authentication time to zero. Because you would normally not enter your house through bedroom window(too much beer probably, when yours wife is in her sister). The switch multiply the time set in authentication delay parameter present in global setting.

The last option for a group is to select its superior group. This option telling the system what zones are treated as one area. And when one zone is armed it arms all zones in group.

NTP synchronization

There is RTC circuit on the main board which is battery backed up. But it lacked the feature to set the correct time other then the compilation. As it has drifted a minute a month, or so, I guessed it is right time to make it synchronized with some NTP server.

I have put a button on the home page of the interface to get the correct time, as well as letting the service thread synchronize time when it starts.

It took me some hours to combine some examples on the net into working code, that I think is a bit optimized, and also working with the rest of threads and web-service. The changes are pushed to Git Hub.

On the Arduino forum is a good post about choosing the right NTP server, which is a valuable resource to read. Especially the attached link to Flawed Routers Flood University of Wisconsin Internet Time Server.