Here is a review with two new projects published on Elettronica Open Source (originally in Italian)
[Archimede] Two Open Source projects: anti-theft alarm and access control
This month we host Archimedes again, this time to work on two application examples very useful and achievable through the basic kit: an access control and an anti-theft alarm. They are really impressive. Read this article, let yourself be intrigued by the potential of the kit and bearing in mind that the kit is up for grabs in the prize pool of our Review4U 2.0 and available on offer on its website.
As you read the introduction, the applications that we are presenting will show you the kit Archimedes working on two distinct examples of real applications. They are a good starting point for anyone wishing to IMPLEMENT their own access control and / or alarm.
The two applications differ, as you will see shortly, only for a small portion of code and the use of different I/O card, a clear sign of how much the card is versatile. Since these differences are minimal, much of the firmware will also be useful for the second of the two applications. Therefore, if you wish, you can combine the two into a single solution for access control / alarm with a minimum intervention on the code. Note, however, that in this case you will need to provide the details of additional I/O (which you can find on the site) .
In this application, in addition to the Archimede Starter Kit, is involved the following hardware (not supplied in kit):
1 reader head for key-buttons;
1 LED with relative resistance for the current limitation;
1 micro sd card ( for persistent storage of keys);
1 electric lock;
The purpose of an access control is, of course, to restrict access to a zone to a group of people more or less limited. For our application we assume a fairly limited number of authorized persons, as the strategies adopted for the storage of data relating to authorizations have been made specially simple in order to maintain a degree of efficiency and at the same time a certain comprehensibility of the code.
The operation is quite simple:
– using a procedure described later are stored codes enabled keys (a file residing on the SD-card)
– during normal operation, when a key is placed on the reading head (normally located close to the door to control) this is read, the code is searched among those stored, and if present, a pulse is generated on the relay to which is connected a electric lock that opens the door. Otherwise, nothing happens and the door will not open.
In this section we describe the structure of software, the “soul” of this application, postponing the details to the reader that certainly will benefit the large number of comments in the code .
The main application (Main function) creates instances of all the hardware resources needed and then enters an infinite loop (idle cycle of the application) in which it is done flashing RUN LED on the motherboard and run the poll on two items:
– the component that takes care of reading any key on the head of reading (OneWireKeyReader)
– the component that handles the scheduling of the list of enabled keys (keylist)
Everything else is handled in the events related to the various objects instantiated in the Main.
The key reader
For this application is used only the OnKeyDetected event on object key reader (OneWireKeyReader). This event is generated once for each event’s key reading on the reading head.
By analyzing a little more in detail what is done in this function you understand how works the heart of the system:
private static void KeyReaderOnKeyDetected (object sender, KeyEventArgs e)
Debug.Print ( e.ROMCode ) ;
/ / I verify that the key is enabled
if ( _keyList.Status == KeyList.ProgrammingStates.Idle )
if ( _keyList.Contains ( e.ROMCode ) )
/ / If the key is enabled I create a pulse of 1 second on the relay
Debug.Print ( "Key is enabled" ) ;
_relay.On ( 1000) ;
Debug.Print ( "Key is not enabled ");
As you can see, the first thing that is checked is the state in which you will find the list of enabled keys. If it turns out Idle means that the list of keys is in its standard condition. If it is in any other state, it means that it is ongoing programming keys (see enumerated KeyList.ProgrammingStates for more details).
Checking the status of the list you go by simply checking the list (_keyList) contains the received code as an argument of the call (e.ROMCode), in which case the relay is activated for 1 second (_relay.On (1000)).
Managing the programming keys
All programming of the keys is assigned to an object of type _keyList keyList (see sources). The real heart of this object is the Poll method which invokes a state machine defined internally handles the programming of keys whose operation can be summarized as follows:
– Is monitored entrance to which is attached a button;
– If there is a pressure that lasts longer than 4 seconds, the programming mode is entered otherwise it returns to normal;
– If the pressure persists and you exceed the 10 seconds, when the button is released the full list of enabled keys will be erased and then you go back to programming mode;
– In the programming mode, simply place a wrench on the read head to read it and store it in the list (internally is checked that the key is not already present, in which case it will be stored again). Going into the programming mode you have up to 1 minute of time between the reading of a key and another, after which interval the system will return to the standard mode;
– To exit the programming mode, without waiting for the minute timeout, just re-press the button at any time.
The LED indicator
The second channel is used to drive a 1-wire LED (50mA max); it is used to give visual cues about the operation of the board and should be carried close to the head for reading 1-wire so as to be visible when you work with the key.
Under normal conditions, the indicator flashes at a frequency of 1Hz. When you go into the programming mode will stop flashing to indicate the expectation of a key. When it is read correctly 3 quick flashes occur.
In case of cancellation before you throw the keys, the button is released (after those 10 seconds) will be issued 6 quick flashes to indicate the cancellation. Subsequently, the LED will remain off (it will be in programming mode). Closed the programming phas , the LED will blink normally.
The operation of this indicator was “abstract” class LedIndicator which encapsulates an object of type OutputPort and encodes operations ON, OFF, and flashing. Once you have created an object of type LedIndicator will interact with it via its two properties and BlinkFrequency Mode: the first indicates the operation mode (ON, OFF, and flashing), the other the frequency of the flashing.
The anti-theft alarm
You had mentioned that the projects would have been 2 and here we are on the second application case. This time, in addition to the basic kit of Archimedes is involved the following hardware (not supplied in the kit) :
1 reader head for key-buttons;
1 LED with relative resistance for the current limitation ;
1 micro sd card ( for persistent storage of keys) ;
1 vibration sensor or contact sensor (eg vibration sensor HAA15 ) ;
1 siren ;
The purpose of an anti-theft alarm, as is well known, is to run as a deterrent against intruders. The modern anti-theft are formed from a multitude of sensors connected to the control unit whose purpose is to interpret and decide if and when to trigger the siren, texting, activate lights and so forth.
This application was specifically designed to be simple, understandable and, if you wish, easily expandable. We made therefore two assumptions: only one sensor connected to the second optocoupler card (the other is used for programming keys enabled). Of course, adding more I / O to the card provided in the basic kit, you can expand the system to handle a larger number of sensors; and a fairly limited number of people authorized to arm / disarm the alarm as the strategies adopted for the storage of data relating to their qualifications have been made simple in order to maintain a degree of efficiency and at the same time a certain comprehensibility of the code.
The operation is quite simple and can be summed up in 2 different states in which the alarm can be:
– Normal operation (not armed): the alarm is disabled.
– Armed: the alarm is armed and if you change the input sensor is triggered, the relay on the board, which will be connected to a siren.
See what has been said in the access control.
As we mentioned, the structure of the software required in this application is almost identical to that of access control and therefore only the differences will be described.
How to control access to the application main (Main function) creates instances of all the hardware resources needed and then enters an infinite loop (idle cycle application) in which it flashes the RUN LED on the motherboard and running the poll on the two objects previously described, with the sole exception that the chimeras to Poll method of the list of enabled keys is made only if the alarm is not active. This means that you can not program the key list when the alarm is armed (after all it would be really foolish to the contrary, is not it?).
Here, too, everything else is handled within the event handler. In this case, the event will only serve to switch the OnKeyDetected _armed flag that indicates the status of the alarm.
Optically isolated input, which is connected to the sensor of the alarm ( type InterruptPort ), was “connected” event OnInterrupt on both sides of the signal.
_doorSensor = new InterruptPort ( HardwareMapping.DoorSensorPin , true, [...]
[...] Port.ResistorMode.Disabled , Port.InterruptMode.InterruptEdgeBoth ) ;
_doorSensor.OnInterrupt + = OnDoorSensorInterrupt ;
So we’re going to manage to the appropriate section of code the activation of the siren
private static void OnDoorSensorInterrupt (uint port, uint data , DateTime time)
if ( date == 0 && _armed )
/ / Active alarm
Debug.Print ( " tripped the alarm! ");
Debug.Print ( data.ToString ());
The LED indicator
Even in this application uses the LEDs to give visual indication of system status. Here, the only difference from the previous case is the flashing LED which will take place at different frequencies depending on whether the alarm is armed or not.
– Fast flashing at 5 Hz = anti-theft armed
– Slow flashing at 1 Hz = anti-theft unarmed
For any other light indication same as for access control.
Ideas and suggestions
To make things simple, once triggered, the siren will continue to sound until an authorized user does not disarm the alarm. Naturally, in a real case it will be necessary to sound the siren for a certain period of time, then silence her but keep the active alarm and so on cyclically.
Unify access control and alarm expanding the board and realizing, ultimately, a more complete project.
Due to object-oriented programming and object-already made and supplied SDK Archimedes, you can make a tele-GSM alarm so that the alarm sends an SMS in case of alarm and alarm status can be reset again by SMS.
The development team on the project said: “We work to other ideas and expansion of these examples to share with the world.”
In the meantime, however, we all look forward to your ideas and opinions. What do you think?
This article has made it more interesting this prize ?