Soft RS485 UART using interrupts on ESP8266

My non technical readers can skip this :-)

Background

As you will have noticed, I have made a complete access control and alarm system based on a Raspberry Pi but working over RS485 bus connections to standard Honeywell Galaxy parts like RIO, Max Readers, and Keypads.

As you will have noticed, I have now started making WiFi connected parts for the alarm system based on ESP8266 parts (ESP-01, ESP-12F, ESP-12S). These include a small ESP-01 based board with RS485 driver that fits inside a Galaxy keypad talking RS485 to the keypad.

As you may have noticed, I have NFC readers sorted and working with secure NXP MIFARE DESFire EV1 cards. These are way more secure than poxy proxy cards used by Max Readers.

Challenge

The concern some people have raised is the reliance on WiFi. It will do the job, but it is not that hard to disrupt externally. Now, much like using a screwdriver on a Max Reader, it will set off the alarm to disrupt it, but it is perhaps a tad easier. One has to consider if it is easier than simply forcing the door or breaking a window, which is always the benchmark for any security :-) But it is a concern.

So can I make the door controller, which does the secure cards, look like a Max Reader and do RS485 to a conventional Galaxy system? I think I can...

Approach

Initially, for the keypad system, I used the built in serial drivers on the ESP8266. These are good, interrupt driven, well supported, except...

The code on the ESP8266 using Arduino is the NONOS SDK, and means one thread for all. It can be delayed a bit for all sorts of reasons, even many milliseconds. For serial that is all handled behind the scenes on interrupts this is no problem, until is it RS485!

The problem is that for RS485 you have to enable and disable the line driver around your transmission. Initially I simply set a time to disable after poking the message in the Tx queue. But that could be delayed and mean after transmitting we held the line driven for too long.

The solution was to wait in the main loop task until sent, and then disable the driver. This is not nice, as any other operations of the device are delayed, but for the keypad driver application there is nothing else. So it works well.

This will not work for the card reader as it has to, well, talk to the card reader, and inputs, and outputs for the door control, and so on. Also, if I am a slave device (unlike the keypad where I am master) I am expected to answer polls promptly and not hang around for 10ms randomly.

My plan - interrupts! Make a soft serial RS485 UART on an ESP8266 to do the grunt in the background.

UARTs

A UART (Universal Asynchronous Receive/Transmit) is a device to send and receive old fashioned serial byte / character data. The concept dates back to what? the 50s or 60s. It is simple...

Each byte, or character, to be sent is coded as a series of 1 or 0 on a bus. What 1 and 0 mean in terms of current or voltage depends on the flavour of system (RS232, RS485, RS422, etc). Each bit time (1/Baud rate) the line has a 0 or a 1. The line is idle (1) and then the byte/character starts with a start bit (0), bits in the byte (low bit first), then any parity bit, and then stop bit (or bits) which are 1.

Obviously both ends have to agree the rate (Baud rate) for bits, and byte size, and parity present and if even or odd, and even number of stop bits.

The Galaxy uses 9600 Baud (so a bit every 104⅙µs), 8 bit data, no parity and one stop bit. Simples!

Sending is easy, you need some sort of timer, and you set 1 or 0 on the output to do the start bit, data bits, and stop bit. The Arduino ESP8266 SoftwareSerial sends in real time from the command using careful timers, it seems. I plan to use interrupts.

Receiving is a tad harder. You have to find the start bit for each byte, and then sample each bit, ideally in the middle. But once you have the bits you shift in the data bits and check the stop bit is 1 (else an error). Not that hard?

Edge interrupt on rx?

Interestingly the SoftwareSerial code simply interrupts on each edge and looks at time from last edge to work out the received data (I think). That is one approach but I decided to clock in bits on interrupt - I just need to sample mid bit somehow.

My initial approach was to set an interrupt on the falling edge of the data line to set the recurring timer half a bit later. However, this has all sorts of challenges, no least of which is race conditions on a regular per-bit interrupt and the edge interrupt. I did work, but not 100%. I am sure I could have solved the race conditions, but actually there is a good reason to stick to simple regular interrupts.

So the approach I took was just a regular interrupt, and this was 3 times per bit. This means ⅔ of the interrupts just count a sub bit and return in most cases, so very light weight in terms of time. But what it does mean is that I could in fact have multiple instances of RS485 busses running on this one interrupt if all the same Baud rate. I have not yet coded that though. It is, however, nice and simple and working for one instance well.

Why 3?

The 3 times per bit is simple. For Tx it makes no odds, skip 2 out of 3 interrupts and set the line to 1 or 0 for the next bit to send. For Rx, it is the same for sampling, except when waiting for start bit. If waiting for the start bit you check for the line going 0 every interrupt, and if it does set the sub bit counter to sample one interrupt later and then every 3 interrupts.

This is not as clean as an edge interrupt adjusting the timing to the microsecond, but it does mean that we can have sampling of the centre of the bit, ±⅙ of a bit which is more than adequate. Doing 2 times bit rate is no good as you could be sampling in the middle or right at the end. Hardware UARTs usually do 16x bit rates, but 3x is fine in my opinion.

This is how I have coded soft UARTs for over 20 years dating back to PIC16C84s, realy!

Messages

The way the RS485 bus works on Galaxy systems is that messages are sent as a sequence of bytes with no gaps, and then a gap - no length indicator in the message (but there is a checksum). So I coded the system to handle this, and even, if we are a slave, auto respond with current status response.

This allows the application to work on a message level, and if it is slow, we answer polls promptly anyway with current status. The driver also does the checksum.

Interrupts on ESP8266

Now the challenge is making it work on an ESP8266. They are rather special. They are a weird mix of old and new. The ESP-12S has 4M of flash! As an embedded controller that is huge! But it has around 80k of RAM (yes, k) and I had a BBC micro with more in the 80s (32k main and 64k second processor). The fact it does TCP at all is mental, but it does, and it does WiFi too.

The usual pressures on coding are complex - embedded systems have pressures on code space, RAM, execution time, power, all sorts.

In this case interrupts are special. The processor has a cache for the code, but this cannot be used by an ISR (presumably some interrupt process handles cache fails). This means the ISR has to be in RAM.

The trick is marking the code you use for the ISR with ICACHE_RAM_ATTR attribute. The RAM used is small, so not only does the ISR have to be fast it has to be small in code space too.

Thankfully a UART is simple code in terms of space and time. Small TARDIS code, even?

This worked, well, sort of, it worked mostly if started after about a second after boot. It turns out that using digitalRead, digitalWrite and pinMode is bad as these Arduino functions are not marked ICACHE_RAM_ATTR. Instead you need to find the underlying GPIO_REG_WRITE and GPIO_REG_READ functions. That then works reliably. The GPIO access is also faster, which is good, but very processor specific.

The result is working RS485, on interrupt, on an ESP8266!

I even added a clock track (blue on that trace) for debug - toggling an output for tx and rx clocking per bit.

It works!

This was deployed as new code to talk to the keypad, but means I can also act as a slave and pretend to be a Max Reader and provide a fob ID derived from the NFC card ID when checked using AES handshake.

It is also quite important as I am using the hardware serial at 115200 Baud to talk to the PN532 NFC card reader!

P.S. I have tested now as both master talking to Keypad, and as slave, pretending to be a Max Reader.

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.

I knocked up a library

So I have made a library from scratch today for NXP MIFARE DESFire cards using AES.

Been a long day.

But here it is: https://github.com/revk/DESFireAES

Have fun.

P.S. Updated and tested and, and made an ESP8266 version....

NXP MIFARE DESFire EV1 for access control

Earlier this week I set myself the task of understanding the NXP MIFARE DESFire cards.

This was more of a challenge than you may expect because the manufacturers don't publish the protocol (except under NDA). Why?!?

• It does not stop people getting the data, as is apparent!
• It means there is also misinformation out there which cannot easily be corrected by reference to the official manual.
• It puts people off using the product, which cannot be good for sales.
• It means subtle details in the official manual will not be known, which could lead to failures in edge cases, making the product look bad.
• It does not help security - as any secure system must not rely on secret specifications.

I have written up what I have found out so far: PDF on github

So, why not just use one of the few (unofficial) libraries out there?

• I probably will for the host application on linux anyway.
• Coding it myself helped me learn more about the cards and how they work and what they can do.
• It was fun!
• The code on my ESP8266 devices to read cards does not need what is in a library - half of it is for handling legacy formats, and DES and 2KDES and 3KDES whereas I need a few specific operations using AES only.

The result - I have managed quite a lot, and made the door control system use cards which cannot simply be copied (unlike the 125kHz proxy tags, which can be, very very easily).

I have even managed to convert from DES to AES for the master key, and crucially I have documented detailed examples of this, and the CMAC logic, and so on, in the manual I have written. A lot of what I have learned has come from other sources as listed at the top, but I have gone through testing things directly and coding stuff myself to confirm things as well.

I have a cyclic record file on the card logging usage (door ID, and timestamp). I still need to add some handling for expiry, and time period controls on the card, maybe.

I am a tad concerned over response times. I am selecting the app, authenticating, getting file list, writing a usage log record and updating a counter, and you notice the slight delay using the card, which is a concern. This may be something that can be improved, not sure. I have not worked out how much is the card, and how much is the ESP8266 doing AES!

But it is working! I am even checking the CMAC on responses to confirm no man-in-the-middle upgrade attack (making one card seem like another once it has done AES handshake).

Happy to take comments and update any mistakes in the manual, but I hope it is useful to people.

P.S. speed improvements by tweaking what operations I do and in what order. Now works very slickly.

P.P.S. I made my own linux/C library (here) and light weight ESP8266 functions (here).

Tipping the scales

I am getting really good at upgrading the scales to do WiFi now, and read cards. The card of choice is a Monzo card which works perfectly well as an ID for weighing yourself. Notably Amex have an ID of 00000000 which is useless.

Really neat PCB, locking molex connectors, cables, the lot. It is working well. Marsden kindly sent the service manual so I can set to "kg" and "st/lb" modes for those that like old-school weights.

The system has a QR code on the scales, which allows you to register any card against your email address. You then weigh yourself and tap the card on the scales to record the weight.

When you tap the card it beeps to confirm it is working, and keep beeping until a stable weight is recorded over WiFi to the server. Simple UI if ever I made one!

Sadly, I have fried a couple of boards whilst doing these upgrades, but Marsden do spare parts (not cheap) and whilst I have a few clues what I may have done, I am not 100% sure of how I killed them. I think, with care, and anti-static, and being neat (avoiding any shorts, or diodes backwards) I can do this reliably now. Obviously very unofficial so I cannot expect any help from Marsden. They do make very nice scales though.

The next challenge is to make the web site that holds the data have graphs and sharing options and so on. At present it is just a list of weights. But even that is working for relatives using this solution.

This is turning in to the new fat-shamers club or something, not sure.

But what was the first thing on the web site? after registering the domain? well, it was getting an excellent lawyer to put together the privacy policy for us and ensuring we are GDPR compliant.

You have to love any lawyer that covers standing on scales with your pet cat as part of the privacy policy. Thank you Neil.

Door entry system

I have been playing with a door entry system, as you will have seen, and there are several steps like choosing processor, and voltage regulators, and relays, and so on. All good fun, but it gets a bit more interesting when you actually want to create some security.

But first, a couple of updates.

The Elechouse PN532 V4 cards really just work, they are excellent, talk to bank cards and MIFARE cards and fobs at a usable distance with no problem. Really impressed. I cannot stress this enough, buy these from Elechouse directly in China - they can ship in a few days - they work. But one extra bit, as I am using these on the "outside" part of the door system - I wanted an LED. It seems the PN532 has some GPIO pins, so a simple bi-colour LED and resistor directly on two of the pins (which the elechouse bring out to pad/holes) gives me a nice red/green LED (with various combinations of blinking as I like). On top of that the WiFi has been really reliable, but it seems that can improve when the next ESP8266 libraries are released soon. I have been using on one of my doors at home for a couple of weeks now, and it is working well.

On-line, and off-line operation

Even though the WiFi is working well, it remains an area of concern in terms of reliability and fallback for power failure, and vulnerability. The system is using TLS everywhere, so makes it pretty secure against infiltration, but not against disruptive attacks - a weakness of any RF based systems.

The simplest fallback is a system where one, or more, cards are configured in door(s) to be allowed to open the door off-line when no WiFi. Overall this is a good safety net, and the one or two cards with such an ID can be kept safe. As they would be my cards, and there is no door of which I should be locked out, this does not make this a work around of security. Even so, it is a bodge.

A better solution may be to allow off-line working of the doors. This is possible, of course. In fact, cards like the NXP MIFARE DESFire EV1 cards are ideal for this. Ideally you want a system that is at least mostly on-line allowing off-line but with logging, and controls - which suites WiFi well.

How would off-line work?

The trick with off-line is you need to somehow encode the rules for access in a way that does not need live access to a control system. This is complicated - it could be a large database, and what if you have a lot of people - do you literally have to sync a whole user access database in to every small door controller CPU/Flash? That would work, but is not that scaleable.

So code details in the card. Well, that is tricky if the card can be changed. Of course you want secure cards, and the DESFire cards allow this. They allow for a card you cannot copy or change, but allow lots of fields and "files" on the card which could encode details of times of day and day of week and expiry dates and which doors are allowed or barred.

Using details on a card, which can only be changed using a key, means that an off-line system can work with unlimited numbers of users - checking the credentials from the card for each door access, and ensuring very quick response and instant operation without waiting on an on-line system.

From a reliability point of view this is excellent. As long as the door has power (which is easy with 12V and battery boxes) it works! Of course you need a way to blacklist cards from a central control, but this is for exceptions only, and short expiry on cards can keep this to a minimum.

Partly on-line

Of course you can make things a tad more secure by having some things on-line. E.g. if a card has not been used for a few days - this allows for cards to need extra checking if someone has been on holiday, etc. You could also make some doors on-line for most users (except for me!) for added security. You could make doors on-line when "locked", i.e. alarm set, so first use of the day could have a lag if WiFi is iffy. All of these are good compromises for ensuring most, or all, doors are fast response and very reliable all day which few exceptions. Users get upset walking in to a door that did not open when expected - you really only have a few hundred ms to play with here :-)

Of course one trick is "normally on-line" only falling back to off-line working (where allowed) if response takes more than X milliseconds.

Keys

It is not as simple as one would like. Making all of this work at a technical level, making PCBs, making readers, and 3D printed cases, and firmware - all pretty straight forward. Even the low level comms to the DESFire cards is not that hard (with help from datasheets and some internet blogs).

However, the bigger issue is how you manage the cards.

The DESFire cards do not use public/private key logic, which is a shame. If they did, all readers could have public keys with no concern on these leaking, whilst the cards have embedded secret keys used to answer a challenge from the reader. Unfortunately the DESFire authentication is mutual / symmetric, so the same key is needed in the card and the reader.

• Do you have a per card master key, or a common master key? (I'd say per card), but where do you store that?
• Do you have per card keys per application for updating permissions?
• What of a key that can write to a counter and a log?
• What of the key just to validate the application/card.
• How do you handle multiple applications on a card?

The validation is perhaps the most annoying - as you want to avoid a complete database of all cards in every lock with the key for that card. Indeed, that means more keys in more places that could be compromised (physically steal a door control board and re-flash to dump keys). It does not help over having a common key.

So in practice, for each application, you need an authentication key that is stored in the locks if they are to work off line at all. You could have different doors/locks on different applications where there are different levels of security or sensitivity in an organisation. That helps.

That also means communicating the key to the locks (let's use TLS shall we). Does it mean storing in the lock? We could put in flash, or maybe we deliberately store only in RAM and need to be on-line once after any reboot before we can work off line. Remember, if someone gets a key, they can make cards, so no level of fallback key is any good if it could be compromised.

And then the whole access control rights are more complex - not just which doors and what times, but also who has controls to change access on people's cards. The NP532 has a nice feature where you can talk to two cards in RF field at once, so you can make it that programming any card means applying that target card and the card of the HR person that has authority to make changes at the same time on a reader on a desk. Not sure if that is more than a gimmick though. Even so, you can use the cards as part of login processes for management of cards, and should do as at least two factor auth.

A lot of the work on this project will be the management system for cards, and logging, and security (and GDPR).

You also need to consider compromises - what if someone did steal a reader off a door - can you re-issue TLS/MQTT credentials to all readers? Can you update keys? How does that process work. The simple case of a lost card is easy by comparison (blacklist on all readers for X days). Do you roll over keys anyway and have a system to update on next use? All good fun.

Alternative on-line?

There is a way to be on-line and not WiFi - I could install an RS485 driver and have the reader look like a normal Max reader to a Galaxy alarm system - doing the off-line control (all set up over wifi) and reporting a simple "key fob" number to the alarm / door system if all OK. Viable and quick.

Is there a product in this?

It would be easy to make a product - an external reader based on PN532 with LEDs, perhaps a beeper, and an internal unit with contact inputs, solid state really output, RS485 for talking to Galaxy panel, WiFi, 12V power, and even a programming header for hobbyist market.

It would be massively more secure than Max readers, as using proper DESFire cards and keys, and the external unit not housing the relay even. Isolate its power and control lines and you cannot "break" the door control from outside. Nice.

It would cost (mainly in the CE marking, safety and EMC testing). It could be neat, and a drop in high security system for an existing RS485 based door/alarm system, or a WiFi based system. Whilst we spend a lot on R&D, this would be perhaps a tad too speculative for now. Of course if you are a large company with many offices and staff and interested in a serious bespoke entry control system - let me know - we have the technology now.

For now, I expect this is for my home, and maybe office later, not a product. But still, a big step forward in terms of security.

All of this, including manuals, PCB layouts, pictures, and code, are being kept up on GitHub... All part of A&A giving back to open source.

Relays

In doing a door entry / alarm system, one thing you need is outputs that control things, like a door lock. Whilst we have nice motorised locks for external doors, we also have mag locks for internal doors, but either way you need 12V and some reasonable current (around 0.5A). You cannot do that from a 3.3V output pin that can sink 20mA max.

So you use a relay, obviously.

Mk1: ILS relay board

First off, I found a nice, and reasonably small relay board. It works off 12V and designed to take an ESP-01. It even comes with one.

All I need to do is add my own firmware and I have a 12V powered relay on the WiFi. Simple.

There are a lot of advantages, obviously :-

• Simple single complete module for relay control
• Comes with ESP-01
• Runs off the voltage we are using (be careful, there are 5V versions too)
• No wiring, no PCBs, just load my own firmware
• Also available in 2 and 4 relay modules

 

Mk2: More connectors

Unfortunately I don't just want a relay output, I want a door control. So I made a PCB that allowed an ESP-12F and hence more connectors. With some careful design I made it fit on top of the relay board!

This works. But is starting to get quite bulky. Bear in mind these usually have to fit in the back of a electrical outlet box, e.g. with an "Exit" button or similar. I was also not happy at how warm the main relay board got - it uses a simple linear regulator.

Mk3: Separate 3.3V relay

Time to try using the nice Pololu regulator boards. With a regulator I don't need to use the 12V relay board, I can have a stand alone board. But I still need a relay. So time to use an off the shelf 3.3V relay.

Mk4: Solid state relay

That worked, but really it is still rather chunky. After a bit of hunting around I found some nice solid state relays by Omron. I have always seen solid state relays as quite chunky, but it seems they can come in quite a small package, more than adequate for 12V at a few amps even...

The result, as you see, is a relatively small PCB, with regulator, and header to connect to the NFC reader (it does just fit passed the regulator, honest), and contacts for 12V in, exit button, door closed reed, and lock engaged contacts, as well as a relay output.

Now I just need the sort the right NFC reader and change over one of my doors :-)

Mk5: A remote I/O board (RIO)

PCB Milling bits

I have been playing with milling PCBs, and the issue is working out what bit to to use for milling PCBs.

The CNC 3018 I got comes with some fine tipped bits, they are cheap, and sharp..,

They are indeed pointy. If you try milling, they break, as they seem to in a slight breeze. They may have uses for wood or something, but for PCB they do not.

Broken bit

Even broken, they have some use, but the width depends on where they broke. And you have to start the cut again once it breaks. Bugger.

Flat end mill

You can get flat end mill bits...

These are not bad, but as you can see, the end is quite long. This is a 0.5mm diameter bit, which is still quite chunky, but it can cut the copper off a board.

The problem is they snap, and do so easily. It is a tad obvious from the design. So not so good.

What they do work really well for is drilling a hole and moving around to make a larger hole. All of the holes I make are done with this 0.5mm bit.

Bigger bit

I also have a 1mm version...

This is something I use for cutting the PCB outline. Works well.

Cutting the board.

What I found works well is a wider bit...

The issue here is depth control. At 45 degrees it means cutting down an extra 0.05mm means an extra 0.1mm width.

The trick is Z axis levelling, which bCNC can do. I added to my CNC 3018...

I initially tried to connect the wires to "Z" on the controller, but missed and was connected to next pins which are "A5", but it seems they worked and "Z" (I assumed Z end stop) did not work. The bCNC code just worked (with "A5"), and did auto levelling. Wow.

End result is I can cut tracks between 0.1" pitch pins!

I have been getting good at single sided designs with no links, but this makes it that bit easier.

P.S. Designs and code on GitHub... @aaisp giving back to open source.

It is funny how old-school lead(+silver) solder is easier to use...

I've got the power!

In messing with bits for a door entry / alarm system, everything is currently powered with 12V. However, these little ESP8266 processors are 3.3V.

Obviously I need a regulator, and as I am making these up using a milling machine, a small self contained module I can solder on to a PCB as a single component is the obvious choice. Back to Amazon, and I find something simple and cheap :-

It has three 0.1" pitch leads, and so easily mounts on the PCB. It has an offset with a header as it has components both sides. Works well though.

However, I noticed it gets a bit warm. Not really a huge surprise, but even when just powering from 5V in my Galaxy keypad design it still is a touch warm.

So I did a bit more research and found these tiny switch mode supplies, Pololu D24V5F3. A few pounds more expensive, also available from Amazon, but really really nice:-

• Still a very small design 0.4" by 0.5" (yes, bloody inches!).
• Components only one side, so can mount flush to my PCB making easy for something like an ESP-01 to fly over it and save more space.
• Cool. I mean really cool. They say 2mA, and given that my ESP-12F plus RC522, running off 12V on one of these is 30mA total, I am impressed. I was seeing 140mA previously.
• It also has a shutdown input - which I suspect I could use with a button on a battery powered device so you can power up and then have s/w power down. I wonder if I can even do something clever with sleep mode on an ESP8266 shutting down its own power while it sleeps - may need a capacitor somewhere in that :-)
• Will accept from around 3.5V up to 36V as input!
• They do other voltages, and current ratings as well, and step-up regulators.

Actually a D24V6F3, the D24V5F3 are on order

Basically, I am working through the total maze of too much information trying to weed out the good from the bad and work out what sort of components are good. I think this comes in to the "good" category for voltage regulator.

New life for old tech (Galaxy keypad)

I wanted to convert a Honeywell Galaxy alarm panel keypad to be on WiFi.

Simples :-)

Start with a keypad :-

Open it up...

There is not a lot of space...

(This had a proxy reader, which I removed)

We'll need a few parts, including a freshly milled PCB. All from GitHub.

No space for the spacer...

Fits nicely...

Not forgetting a wire link - sadly I could not manage a layout without this...

Add the RS485 convertor and power regulator and some wires, crop the leads nicely...

Looks tidy... (I then sprayed the bare copper with clear lacquer, by the way).

They keypad has handy 5V pads...

And the A/B wires...

And it fits in nicely...

Put back together...

And it works!