XMC2Go Design Challenge: Smartwatch/Smartphone-controlled Electronic Lock

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
XMC2GO Design Challenge 2014 Italy – Results Report


An electronic lock able to open a door (or the activation/deactivation of a device) to whoever owns the correct code, just as well as a key lock allows the opening of a "traditional" lock. There are different types of electronic locks, categorized according to the way in which the code is provided. The simplest ones use a keyboard, whereas the more complicated are based on the detection of biometric data (eg, a fingerprint). In the middle are all the locks based on radio frequency technology, which use a badge or a key ring equipped with a transponder. However, all of them require a visible active device (keyboard, biometric reader, and so on) which may be subject to vandalism, or a passive device (badge, key ring, etc.) that could be removed/stolen/lost, or even forgotten. So, why do not implement an electronic lock that can be controlled by an object more easily to bring, such as a watch or a phone? We can use a smartwatch or any smartphone to send via Bluetooth interface the unlock code, made with an Infineon XMC2GO board.

Block diagram
The project can be summarized as follows:
1177.attach

We will analyze each section separately, deepening its operation.

Power supply
Power supply block provides the correct voltage to all other sections. We can use a wall power adapter (5V DC output) with micro USB connector. It is easily available on the market and can power directly the XMC2GO board; this will provide us a power supply of 3.3V that we can distribute to the other stages. For those sections requiring a higher power, such as the actuators module, it is convenient to use directly the 5V DC supply.

Bluetooth interface
The Bluetooth interface will be carried out with a fully integrated module available on the market. This will not force us to approve the radio frequency module, since it was already made by the manufacturer. Moreover, as we will discover, the Bluetooth module will simplify the firmware, which will only take care functional part of the system, without having to take over the management of the radio communication stack.

The XMC2GO (CPU)
The heart of the application is an XMC2GO board. The firmware residing on the microcontroller will manage the operation of the electronic lock, receiving and transmitting data via Bluetooth, and interfacing with actuators.

USB
We can think of using the USB port configured in VCP (virtual serial port) mode to set some operating parameters (eg the relay excitation period, the unlock code, the authorized devices, and so on). Actually, a serial port can be easily connected to a PC running any type of operating system, and it is possible to use COTS applications without having to write a custom software.

Actuators
This module allows the electronic door lock to interact with the environment, activating the electromechanical lock. At first, in the simplest model of lock that can be thought, a relay is enough. We may also use the two LEDs integrated on the board to show some particular conditions. For instance, a LED may flash at fixed intervals to indicate the lock is working, while the other may indicate the activation status of the relay.

Principle of operation
The simplest type of lock we can make has the following characteristics:
  • the unlock code is stored inside the microcontroller memory;
  • an unlock code, received through the Bluetooth interface, to be compared with the one stored in internal memory;
  • the activation of the relay for a predetermined time, in case the two codes coincide.

The unlock code could be directly hardcoded into the firmware, but this would prevent us from being able to change it without programming the MCU from scratch. By using the USB port, which appears on a PC as a virtual serial port, we could instead send some simple commands using a terminal emulator software (eg TeraTerm, Hyperterminal, and so on) and change the code as often as we want.
A little more complex is the Bluetooth management: the memory resources (especially RAM) provided by the XMC2GO board are not enough to handle both the protocol stack and the application at the same time; moreover we need to approve the device as compatible with the Bluetooth standard, and the payment of the related royalties. To solve this issue we can use the Infineon "SPP eUniStone" module. It is an integrated device that exposes a Bluetooth interface with Serial Port Profile (SPP stands for Serial Port Profile), and can be controlled by the XMC2GO board via serial port using AT-style commands. This allows us to simplify the firmware especially on the communication management side, as well as the smartwatch/smartphone application, which will be limited to sending and receiving data over a serial port. In addition, this simplifying will facilitate the debugging of the firmware, since it will be possible to send commands using a PC equipped with a Bluetooth interface, without having to write the Android App immediately.
The actuator section, in its simplest version, consists in a relay controlled by XMC2GO board through a transistor. The relay activation, as an effect of the reception of a correct unlock code, can be performed for a fixed time, possibly modifiable via USB.

Algorithms
The XMC2GO firmware is structured as follows:
1178.attach

Given the simplicity of the application, we can think of writing a monolithic application that does not use a realtime operating system (RTOS). At power on, the firmware will perform the requested board initialization: clock, active devices, I/O pins (including those used as special devices), internal variables (command queue, actuator status, etc. ) and the Bluetooth module.
After that, the firmware enters a loop where the queues holding the commands received from the devices, (serial port connected to the Bluetooth module and USB virtual serial port) are analyzed. The device internal state is then updated according to the processed commands and the relay is activated or deactivated.
Two interrupt routines are in charge of collecting data from serial ports and inserting it into the command queues for following analysis and processing. In order to achieve accurate timing, it might be useful to enable another interrupt connected to a programmable timer.

Android App
The Smartwatch or Smartphone Android App will be in charge of pairing with the lock via Bluetooth interface. Once pairing has been established, a virtual serial port will be added to the operating system, allowing a bidirectional communication with the firmware on the XMC2GO board. Depending on the safety grade we want to achieve, the application can be written so that it sends the unlock code automatically, or it could show a keypad to enter it.

Future developments
The project may be expanded by adding several features in order to increase both safety and efficiency:

  • an encryption algorithm such as AES may be inserted into the serial protocol, so as to make indecipherable the commands exchanged between the smartwatch and the lock. PolarSSL (https://polarssl.org/) is a library suitable for this purpose;
  • a real time clock (RTC) connected on SPI bus and equipped with backup battery could be useful to manage the time slots of operation, during which unlock is not allowed, or during which it locks or unlocks automatically;
  • a E2PROM/FLASH on SPI bus could be useful for storing the MAC addresses of Bluetooth devices considered "trustable", those therefore allowed to send the unlock code; a device not belonging to this list would not be considered and therefore could not perform the lock opening;
  • we could handle the lock opening through a rolling code algorithm, so that the unlock code changes after each use; in this case the Android app will automatically send the code to the lock, without no need to enter it manually;
  • we could add a second relay as an auxiliary output to achieve different functionalities:

    • in case the received code is not correct, or as a result of a number of failed login attempts, it could control the raising of an alarm;
    • it might be activated by a second code, for example to control the switching on of the courtesy lights (in this case the period of the relay activation may be different from the first one);
    • it could be activated simultaneously to the activation of the first relay, but with a different period (always for switching courtesy lights on, or as a consensus to the video recording performed by a video surveillance system).

  • we could add some other (optocoupled) inputs in order to detect additional conditions to the release of the lock, such as the presence of a person at the door (via passive infrared detector or pressure sensor placed on the floor).

The same application may also be adapted to operate for other purposes, such as switching on/off of loads via Bluetooth (acting as a switched socket).
0 Likes
0 Replies