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.

Software

I have created a git for the main board source code, and I will be pushing all the libraries needed for compile there as well. Link to GitHub will be always located on the right panel for fast access.
This is my first git, so be nice on me :).

RFM12B Radio

The radio part was left out a bit since beginning of the project. I believe in wires in such way that they are more reliable, and also can carry the power for the remote nodes. But the radio is important for future expansions as well. It can be used for remote self-powered PIR sensors, authorization nodes or for data gathering.
Yesterday I have decided to give them a try, because I had two RFM12B at home along with one bought antenna for the main station. Main station is build in metal enclosure and connected to earth that would block the radio waves. I put together one node with ATMega168 and soldered a radio on it. Then the 1/4 wave length antenna made out of single wire:

Wire lengths:

433 1/4 wave = 164.7mm
433 1/2 wave = 329.4mm
433 full wave = 692.7mm

868 1/4 wave = 82.2mm
868 1/2 wave = 164.3mm
868 full wave = 345.5mm

915 1/4 wave = 77.9mm
915 1/2 wave = 155.9mm
915 full wave = 327.8mm

And went for a search for library. I have found this library from LowPowerLab that looked good and suitable to my needs. Radios didn't work out of the box, but I had suspected it because my wiring are not using the ports the library expect. Main Board uses different pin for radio interrupt.

#elif defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
  #define RFM_IRQ     10    // PCINT 10 / INT2

Allowing the PINCHG_IRQ instead of attachInterrupt did not work as well. But luckily changing the attachInterrupt form 0 to 2:

#else
  if (nodeID != 0)
    #if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
      attachInterrupt(2, RFM12B::InterruptHandler, LOW);
    #else
      attachInterrupt(0, RFM12B::InterruptHandler, LOW);
    #endif 
  else
    #if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
      detachInterrupt(2);
    #else
      detachInterrupt(0);
    #endif 
#endif

And packets started for flow through. For a short while, or they would go on on the main board, but the Ethernet stopped working. They both work on the SPI and the RTOS has no direct driver for it. A solution  worked fine:

#elif defined(__AVR_ATmega1284P__)
  #warning W5200 for AlarmBoard only!
  inline static void initSS()    { DDRB  |=  _BV(1); };
  inline static void setSS()     { cli(); PORTB &= ~_BV(1); };  // no interrupt while the SPI bus is busy
  inline static void resetSS()   { PORTB |=  _BV(1); sei();};   // no interrupt while the SPI bus is busy

Edit the Arduino Ethernet library file W5100.h so that it doesn’t allow RFM12b to interrupt while the SPI bus is busy handling Wiznet5100. Just add a cli(); and sei();. I will publish the modified libraies to GitHub.