NFC reader and alarm/door entry system

A long time ago I made a door entry and alarm system. Actually my first was approx 1989 using a mag head from a Sony walkman on a block of wood on the door and a wire wrap 6502. My latest attempt a few years ago is a lot more sophisticated.

It is good, indeed, I would say it is very good. It has a lot of off line working built in but backed by internet management/control system, so designed for power and internet failure, for hours, or even days.

The NFC door control uses AES on DESFire cards, so no plain text even on RF, and challenge both ways, so super secure. It even has different keys for each card. But it scales to any number of cards, with different access levels encoded in the card so as to work off line if needed (for a configurable time).

Like I say, it is good, and we use it, and a hack spare uses it (maybe two) and several small offices.

But it is tricky to sell.

Insurance and alarm companies have stuff tied up

Perhaps the biggest issue is that insurance companies and alarm companies have some industry standards and something of a private club. Yes, we could join, I am sure, but only if I wanted to be come an alarm company. Open source stuff is not going to get in to the club no matter how good it is. This is a shame as proper (Galaxy) alarm systems can be crap by comparison, as we know because we had one, installed by a certified installer, and were robbed!

My understanding is that one of the rules (I heard from an installer) was you can't have some external indication of armed or not. This ment staff did not understand they failed to arm. It beeps in various incomprehensible ways, and shows stuff on the keypad (which you cannot read from outside when using the fob to arm), so they assumed armed when not.

My system can show such, but we go for subtle - internal lights go off when armed. I mean you would turn off anyway, but staff can tell instantly that the lobby light not going off means not alarmed. The light switch does not allow manual turn off. Simple steps but has meant that on the odd occasion of not arming (e.g. fire exit open) staff knew. This is what caused the problem on Galaxy.

I also allow a forced alarm for such cases as a last resort - where the open fire exit becomes a sensor - someone closing it would set off the alarm. This means I can set forced alarm on timer, and be alarmed if staff have missed the problem somehow and still have a working alarm (all PIRs, etc). The Galaxy, when it does not arm, does not arm, end of story. It is a compromise I suspect an official system would not allow.

So basically you need to check (and record the call) insurance are happy with no proper alarm system, etc. Seems many are, and may not even charge more, but having it on record should mean you are covered.

Monitoring

Another issue is monitoring of the alarm. We had that once at an office, and it was such a pain. And one time when we did not know then code word, they said the police would be called. The police did not turn up so I was stuck there for 4 hours on a Sunday waiting for police. Also police won't come if you have too many false alarms.

My system monitors, but messages people, several people, like me, people with access to the CCTV who can confirm it is a false alarm, and if not call the police explaining they can see the burglary in progress on CCTV. That will, I expect, get a way better response than an alarm company calling.

Also much easier to integrate to external systems - staff in office logging for fire list, etc.

Locks

Another issue is locks, and the typical internal door lock is a mag lock, which is really easy to defeat. I have found much better locks and would recommend using them - Abloy locks. These work without the alarm and use a proper euro profile lock, and can be set to open from inside regardless, but also have a load of sensors (key used, handle used, lock in/out, etc).

Opening from inside also avoids the messy "break glass" and "exit button" you typically need.

So my system has to handle everything from a simple maglock and exit button, to the Abloy with something like 5 inputs - which it does nicely now.

It costs more, but in the end it is worth it.

Professional kit

With all of the above, an alarm or door entry system can work, with insurance confirming OK, etc.

But the kit is not as professional, or is it.

When I started I had single sided copper clad boards milled and hand soldered. I have moved on to proper PCBs made in China. I have moved on through a load of connector types to WAGO PCB connectors which are just simple to use for an installer. I have added per input/output LED status on the PCB.

But still, the case is a messy 3D print on my printer. Well, now we moved on finally with high resolution, smooth, clean, 3D resin prints from China.

The wiring and connector to the NFC reader was also a concern, but ironically the leads I got made in China for Faikin boards are perfect for this, and again, professional, so making it all easy to install and just more professional.

I finally feel like I have stuff that is professional looking.

The NFC sensor on a door. It looks proper now.

I have even now designed one for a 1 gang UK pattress box.

So now I plan to list these boards and cases on Tindie soon. The NFC reader is ideal for a hobbyist working on any NFC stuff.

New door entry and alarm system

I am thinking of the next generation of my SolarSystem alarm system.

It started as RS485, a slot in replacement for a Galaxy system using the same external devices, and running on a Raspberry Pi with USB RS485 adaptors. It worked quite well.

The next generation used ESP8266, then ESP32 based WiFi connected devices. This works well.

Next generation

I am now planning to get rid of the Raspberry Pi and RS485 completely. The idea is the ESP32 modules work together over a mesh WiFi. Yes, one of them would connect to a conventional WiFi access point, but they can work without that - off 12V battery backup if needed, with no "controller" as such.

This is not that complex - devices need to know what inputs and outputs link to what areas and states in the system, and broadcast information to allow every unit to know when alarm armed, or triggered, etc. Using secure AES encrypted DESFire key fobs on door controllers the alarm can be set and unset.

There would still be a "controller" to configure the system, program fobs, record logs, and so on. But this could be a cloud based service. Some of you know my love of cloud based services (not), and as this is all open source it would allow the cloud service to be run locally. But the server is not a "live" part of the system - it allows config, and so on - via a simple web page. Obviously communications would then be secure to the server.

This makes everything simpler to set up as you just need a local WiFI internet access.

To make it work I now have designs (and several prototype boards and cases) for key components:

• Door controller module and NFC reader (can be used as 6 input 1 output module)
• Bell box module (also usable as a 2 input 4 output module)
• General purpose I/O (5 GPIO with ADC if needed)
• Keypad module (fits in galaxy keypad and talks RS485 to it locally)

The nice thing is that just one of these, eg door control, can be set up to talk to local WiFi/NAT and connect to a cloud service allowing configuration of an access system. But you can then add other modules, and set up a whole alarm system if you want. The key fobs have access controls such as which doors, and times of day and days of week that are allowed.

More serious work needed

The issue is that I need to do quite a lot to complete the design and coding for this - not just in the modules, but the controller system and database back end. This is all pure R&D work at present with no concrete customers for the system (though we have had some interest), which can make it a bit hard getting the motivation - but a real customer would also help ensure we are steering the project in the right direction.

Bootstrapping security

One of the design challenges is bootstrapping the security of key fobs and controllers. They need AES keys, and these need to be secure, and need to get in to devices and fobs.

In simple practical terms, you can just buy fobs from the likes of Amazon, and then use one one of the NFC modules - e.g. one of the doors - to program the fob. Similarly you can make ESP32 modules, or use off the shelf modules like nodemcu and flash the code.

But you have to be very sure that this is actually being done by someone authorised to program fobs. Even then, if someone wanted to, they could capture that initial config and get the AES key used. Once the AES key is know the system for a whole site can be compromised.

Once the fob is programmed, any capture of the communications does not help you, but the initial set up of a fob is inherently insecure - this is the bootstrap problem - it has to be insecure as the fob is blank and it has to get the keys - so someone can "pretend to be a blank fob" and get the keys in the same way.

You have the same issue with end devices and a cloud system - you have to be sure the device is the device you think it is. If someone can get a fake device on a system it can get keys. So the devices need a secure client identity too.

I suspect the answer is simple - design the system so that the controller will only do initial config of devices and fobs locally (e.g. USB connected). The controller then sends out the devices and fobs pre-set for the site. Of course this means for a cloud based service the service operator provides the devices and fobs - which may make it more commercially viable to operate a cloud service.

Security

Of course any system has to consider security - the AES/DESFire fobs are massively more secure than 125kHz fobs used by Galaxy Max readers. The WiFi is a bit of a trade off: It is way more secure using WIFi and TLS than RS485 (Galaxy modules can have messages inserted on the bus without it noticing!). It is possible to disrupt (just as cutting an RS485 bus is, which is exposed on outside of building if using Max readers), but like RS485 it would trigger an alarm. At the end of the day you have to be more secure than breaking a window.

Never quite finished?!

The good news is I now have the "proper" PCBs for my door controller and NFC reader...

I have to say they look good - proper boards, and using solder paste and oven means a very professional result.

PCB Train do a nice job, but these were on a three week lead time. Both boards work. However, in the three weeks since I ordered I have made a few design changes.

The door controller changes are very minor - instead of 3 inputs with 3 GND on the 6 pin connector I have all 6 pins connected to GPIO, where you drive some pins to GND if you want. This allows a lot more options if needed, etc. The pins all have BAV99S and 100Ω for some ESP protection, and 33pF to help reduce noise. It is a small change, and so the existing boards are more than usable. The only snag is I mis-ordered as 1.6mm not 0.8mm boards, and I have designed cases to be as small as I can to fit in a back box. I think 1.6mm will still fit, but it is annoying.

The bigger issue is the NFC board. As I say, they work. But the tuning is perhaps not spot on. The newer design boards have a loop both sides, allowing the board to be 40mm x 40mm not 42mm x 42mm. However, the newest boards are better - the main thing is they do not get hot which is a big clue (i.e. the antenna is clearly better and easier to tune), and I have them working with more range. So I would rather use the new boards. They too are also 0.8mm which saves space.

So, all in all, I decided to order some new boards - two week lead time. However I have a few dozen of these boards. As I say, they work, and I am testing with them, and may well use some, but once I get the replacements I will end up throwing these away, I am sure, which is a shame.

So, if a hackspace, or other good cause, wants either of these bare boards, to play with. The schematics and code are all on GitHub. Note, need hot air gun at least for the PN532, and fine tipped soldering iron. Let me know. Email me at pcb1@revk.uk

Long term?

These, and some other related modules, should be able to make a WiFi mesh with (not having to be always on-line) "cloud" control and management (on or off site) to work as an alarm and access system.

NFC reader works, what next

It has been a month since I came up with this crazy idea, but the NFC reader board is working really well now. To be fair, every version I have made has worked, just some better than others. The most noticeable impact on how well it works is the inductors. Using small inductors (i.e. 0603) means it is crap - needs fob flat on then antenna to do anything. Now it works around 2cm. I have changed layout a lot, changed the antenna shape, changed component size. Lots.

I have, however, learned a lot about ESD protection, layout for RF, choosing components for RF, using KiCad, and solder paste. The solder paste has perhaps been to be the biggest change as I am no longer afraid of adding passives, which previously would have been far too annoying to hand solder and take too much space. Lots of 0603s are no issue now.

So I have a nice NFC card design, thanks a lot to John for his help. I also have a nice door control module which is tiny, and only 7mm thick. Easy to fit in a back box with other stuff.

If any hack space want to have a play with one of these NFC boards, let me know. I'd be interested in feedback. Main advantages over Elechouse are red/amber/green LEDs, tamper button, door bell input, and more ESD protection.

The boards, and 3D cases, are all on GitHub.

So what next?

Well - battery power - that's what. I have made up a new regulator for my boards rather than using the Pololu boards (they really are very good!). It has an automatic ECO mode dropping to 27uA.

Planning to work on Ultra Low Power mode on the ESP32, see how low I can get it, and run from a battery.

So now I need a board that can be low power. This means the USB chip needs to be turned off when not using USB, which is fun as it means I do not want to power its I/O pins for Tx either - and the ESP32 blurts lots of debug on Tx at start up. So a small FET is in order. Also quite fun as the FT231X USB chip works the RST and GPIO0 pins, so need them to work properly when no USB power.

P.S. Why USB?

Someone asked why do I have USB at all? I used to have boards with USB-C for power, and a header for programming, but it was actually less space and easier to just fit an FT231 to the board instead of the header, so using the USB for power and serial load/debug. The battery board is perhaps an exception as it needs a couple of extra components to let me disconnect the USB, but even so, on a board this small an extra programming header would be tricky, so I decided to stick with USB serial.

Almost a real RF engineer!

As you will have read, I decided to trying and tackle making an NFC reader. It is my first project in any sort of RF, so a massive learning project, but also a first in terms of trying to fit small components (e.g. QFN-40) on a PCB. The QFN-16 for the FT230X was just about doable with a soldering iron, but now I am in to solder paste and re-flow oven territory (more on a later blog).

I decided to give it a go, and made an NFC board, and to my (quite frankly) shock, it worked! It worked well, in fact - seemingly at least as well as the Elechouse board. I have made some tweaks with smaller components, and that also worked. Designing a PCB can be like a never ending piece of art - always one more small tweak or improvement. I am now working on a 3rd version, with even smaller components, but this time I am starting to do it properly from am RF point of view. Instead of just drawing an antenna track and hoping (which worked, to be fair), I now have an "network vector analyser" to tell me how the antenna and tuning circuit works.

The trick is to test the antenna and make component changes, or even adjust the antenna design. Apparently all sorts of things impact the tuning including any components near it, or just bits of copper track, and so on, even the case (even if plastic). But using one of these gadgets it is possible to work out if you have the tuning right, or close, and make adjustments. I am still learning, but getting there. In that image, you can see I changed the loop length a bit, and as expected the centre frequency moved.

My plan is to have a good quality, tuned, working, NFC reader design (open sourced), that I can sell. Something that is better than the standard Elechouse boards everyone uses. Apart from better RF (well, better than all the cheap copies of the Elechouse) it has red/amber/green LED and tamper switch. This makes it perfect for any sort of access control entry reader. I'm not really expecting to make much money, but would be nice to cover the costs of getting this far and learning this stuff.

I expect to make up a few of a final design, maybe next week, and offer some (free) to people like hackspaces to have a play and give me feedback. Obviously, if they are hit, I could have hundreds properly made and sell them. But this whole project was more aimed at a learning exercise in the first place, so covering my costs would be a huge win.

It almost makes me a proper RF engineer, LOL!

Door control

My door control and alarm system has made some progress.

The main change is making access control a bit more distinct from alarm system. The doors at the office were "falling off" the WiFi occasionally, even if only for a few seconds at a time, a few times a day.

I suspect that can be fixed, and it makes a huge difference what channels we use. The AP report something like 60 interfering APs.

So the change is to make the doors work autonomously which means the door controller has to be able to authenticate the fob/card used but also know enough to tell if it is allowed access.

I have actually created six levels of integration and autonomy for door control linking to alarm system.

This means things like times of day, depending on day of week, which doors they can access, and expiry dates and the like (i.e. some way to be sure a lost card is now invalid).

However, the DESFire cards are a challenge at best. I cannot have any operation that produces an error as that kills the authentication. So I have to only read files that exist, and only read the right length of the file, etc.

My original design was to have files for various aspects of security. Allowed doors; Barred doors; Start and end times; Start date/time; expiry date/time. The idea wast to get the file ID list and decide what to check depending on what files existing.

But even that is a challenge if any files can be variable length. The allowed/barred lists are like this, as are other files. So you have to check the file size for each file first.

Before you know it you are doing dozens of operations to the card, each taking tens of milliseconds.

So I ended up making a system that uses a single "access file", which I expect to exist. I ask the size and then read it. In that file I encode the various things I need like allowed and barred doors, and access times. But it is just those two operations on the card and hence a quick operation.

The end result is an autonomous door control system on an ESP8266 based door controller. It even has expiry update so that a card not used for X days expires. I obviously have blacklisting, but that also zaps the file if a blacklisted card is used.

The next step is some key roll-over logic as well as extra belt-and-braces old card expiry logic.

This is giving a fast enough process for door control. Yay!

Choosing interface for PN532 (I²C, SPI or HSU) to ESP8266

I have been working with ESP8266 controllers and NFC readers. My preferred reader is the PN532 based Elechouse reader. As I have noted before, buy from Elechouse direct as there are a lot of bad copies!

However, when connecting to the processor I have a choice of interface. It is one of the rather nice features of the PN532. There are three interface types I²C, SPI or HSU.

So how to choose...

I²C

I²C stands for Inter-Integrated Circuit, so the acronym is IIC, but someone thought it would be fun to treat letters in an acronym in the same way as algebraic variables and write II as I². Arrg!

It is a simple bus for connecting devices and uses a clock and data line. Wikipedia has details (here). Both clock and data lines have a passive pull-up resistor and are actively driven low by master or slave. The protocol is well defined, and works well. It allows multiple devices on one bus and is very popular for a lot of peripherals.

Looking at the Elechouse web site I saw this: "On-board level shifter, Standard 5V TTL for I2C and UART, 3.3V TTL SPI" which rather concerned me. The ESP8266 is all 3.3V, and I did not want to have to mess about. This immediately put me off using I²C. However, looking at the schematic, the level shifter is completely optional, in that the same two pins are used for SPI, I²C and HSU and connections have these at the 3.3V level direct from the PN532 (via 100Ω) as well as via the level shifter, so it can be used for HSU and I²C if you want.

✓ Only two wires, simplifies wiring and frees up GPIO pins
✘ ESP8266 does not have hardware I²C support, so uses more processor and is slower
✓ ESP8266 has software I²C which means almost any GPIO pins can be used for clock and data, making PCB layout much simpler.
✘ Data sheet suggested level shifted to 5V (which turns out to be optional)
✘ Both clock and data use passive pull up resistors, meaning they can be subject to more interference on long lines

SPI

SPI stands for Serial Peripheral Interface. Wikipedia has details (here). It is more complex than I²C in the way it works - using 4 wires not 2, and allowing different configurations. It is also quite fast, allowing several MHz operation.

The ESP8266 has hardware support for SPI, which is good, but the downside of that is that specific GPIO pins are used for 3 of the 4 signals, so PCB layout is more complex.

✘ Four wires, so more to connect from controller to reader and uses more GPIO pins

✓ ESP8266 has hardware support, so allows faster working

✘ ESP8266 has hardware support, so the pin assignments are fixed making PCB layout more complex

✓ Lines are driven (from master or from slave) rather than using passive pull ups

✓ 3.3V direct connection to ESP8266

HSU

HSU stands for High Speed UART. This is simple old fashioned serial communications, on a Tx and Rx line, and defaults to 115,200 Baud.

The ESP8266 has hardware support for UART, and will work at these speeds. The ESP8266 library has good, interrupt based, serial handling. Unlike SPI there is actually a choice of pins that can be used, but this is still a tad limited. Of course the ESP8266 uses the UART for other things like programming and debug, but there is an additional Tx available for debug (Serial1).

✓ Only two wires, simplifies wiring and frees up GPIO pins

✓ ESP8266 has good hardware and library support for serial UART

✘ Pin usage is a fixed, but a choice of two sets

✘ Data sheet suggested level shifted to 5V (which turns out to be optional)
✘ Serial on ESP8266 is used for programming and debug
✓ Tx and Rx are driven (one each way) rather than passive pull up resistors
✓ The same connector can use used for programming and connection to PN532, reducing number of headers needed on the board

What did I do?

I was initially put off by the level convertor comment, leaving SPI as the only option. The first project I made using an NFC reader was connected to weighing scales, and used the serial on the ESP8266 to talk to the scales, so that rules out HSU. So SPI it is.

There are 4 connections needed (so 6 wires including power and ground). This means you can use 5 pins in a row on the ESP8266 (VCC, D13, D12, D14, D16) and GND to make a 6 way connector. Sadly the pins are not quite the same order as on the Elechouse PN532 board. This just means the connectors need wiring carefully.

This works well. I then used the same design for the door controller.

Hindsight

Firstly, the fact that the level convertors are optional means I²C and HSU are an option. I could have, for example, used I²C on a smaller ESP-01 for the scales rather than using an ESP-12F and SPI. However, the use of passive pull-ups is still a concern if the reader is on any length of wire from the controller as may be the case on a door controller. I could have used HSU, as the ESP8266 libraries have a soft serial mode, which can work at the scales 9,600 Baud rate, so could have used Tx/Rx for PN532 and one of the other pins to talk to the scales serial interface, and used an ESP-01.

I have since tried HSU, which just works, and is only 4 wires to the reader (power, ground, Tx and Rx). I was concerned that it would be slower (115,200 Baud rather than 2MHz) but actually it is slightly quicker (28ms rather than 30ms for InListPassiveTarget on same card), and a lot of the time is the PN532 operation and the NFC card itself. The Baud rate can also be configured!

It also turns out that had I used the more usual GPIO15 as the SPI SS pin not GPIO16 I would have actually wired the PN532 such that it could be used for HSU or SPI, as the PN532 uses MOSI for Tx and SS for Rx and the ESP8266 alternative Tx/Rx for UART0 are on those pins!

In practice, what I have done is make a 4 pin header with GND, 3V3, Tx and Rx. This is the same order as the 4 pins on the Elechouse board, but is also a header that can be used for programming the ESP8266.

I am slightly kicking myself for not trying HSU and I²C to start with, but to be honest I was just pleased to get things working. Freeing up two extra GPIO pins is nice, as is having fewer wires to reader, and pins in the same order both ends of the cable. The libraries do, however, make it very easy to change interface. Just remember to set the switches on the Elechouse board to match what you are using.