LockNFC - firmware

Microcontroller-based hardware is just a PCB until you have some firmware running on it. Time to get it doing something. I'd already protyped both the capacitive touch keypad and the NFC reader firmware on a development board and I check that they ran together on my PCB when it came back from the fab. There was a lot of tidying up left to do.

I decide that I'd make the device battery powered. The MSP430 is designed to be low power and the locations I intended to use it weren't ideal for running mains power. I spent a lot of time making sure that the NFC reader wasn't wasting battery polling for a tag all the time. The keypad has a combination proximity sensor and guard channel - a concept I took from TI's guide. It mostly worked well, but I meant that I had to sweep by back of my hand over the key pad to be sure that it was trying to read my NFC implant. I wasn't entirely happy with this and it turned out that the TRF7970A in particular is fussy about power. I ran the device from 2 x AA batteries and found that whilst this was fine for the microcontroller (and the keypad) the NFC reader was unreliable. Maybe it wasn't in a powered down state as much as I thought it was? I poked around with the code. I switch 3 x 1.2V NiMH AAs to give 3.6V and still it seemed OK when tested but unreliable long term. I've parked the power saving for now and the NFC reader currently polls constantly. I get much better results and as you'll see in a later post, I solved the power problem a different way.

I decided to get my kids involved in the project. If you read the earlier blog posts you may remember that the keypad is for their benefit. They decided that they each wanted their own secret code. One wouldn't do. In order to make it easier to compare two variable-length passcodes with the last few key presses. it seemed easier to store and compare them from the end of the code. If I got to the start of any of the valid codes then I'd open the door. As they were reversed and zero-terminated, that's if I find a zero.

Whilst I intended to make my front door the first door to have this fitted, I decided that the garage door would be the simplest. All I had to do was simulate a button press. I've actually got two garage doors next to each other. I told the kids that there would be one code for one door and another code for another. My youngest the suggested that after a code is entered you could get a green light and then chose 1 or 2 for what door to open. I was more than happy to code this for them and they were pleased to see the result of the decision. My 5-year old then came up with the idea that as 1+2=3 maybe pressing 3 should operate both doors at the same time. OK - this is nothing groundbreaking. However, the joy of seeing his idea turned into code and then turned into action was just great for a dad. He's invested in the project and owns a part of it. This is how it begins! A blog post just talking about code is a little dry, so here's a video of me scanning my implant and then pressing "1" to open the door.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

LockNFC - firmware

Poster

Upload Preview

Ok

Cancel

There may be more code changes to come. I plan to allow new codes to be entered without having to take it off the wall and reflash it. I'm going with the agile philosophy though. Get the Minimum Viable Product out there and improve as and when you need to. As yet - nobody has wanted to change a code. Maybe I'll get round to it. Maybe not.

There's little else to do that publish the code (excluding the file with the secret codes in!). You're welcome to take a look.

https://github.com/FredMurphy/LockNFC.git

Next post - garage door >>