We have a pretty sweet access control system at the space. Former President Royce Pipkins put it together for us and it controls all the exterior doors at the space. One problem we have with it right now is that we have to log into a linux machine and tail the log to see interesting info about how many makers are badging in and when.

Well, we used to have that problem, anyway.

I spent some time today with the lovely (if a bit limited) Cosm api. You may know Cosm by its former name, Pachube. I wrote a simple python script to parse out interesting, anonymous data from our access server logs and send it up to Cosm as a new feed, called Milwaukee Makerspace Access Control System with four data streams:

• Number of Unique Makers Accessing the space in a day
• Number of Unique Makers Accessing the space in an hour
• Total number of badge-ins per day
• Number of Access Denied messages per day

Cosm made it easy to graph the data and to send up new data points, but is limited to a gauge-style timeseries.  I can’t submit raw data events and use Cosm to aggregate them up by date or hour, so i had to do that in my local python code.  Their REST API is very simple, clean and well documented, though, which makes up for the limitations a bit.  They provide a graph-builder, but i didn’t like the way the graphs looked so i pulled the JSON data in and used the Google Chart Tools to produce some pretty graphs like this one:

Screenshot of the Access Control System Stats.

The stats are updated from our access control system every hour and are publicly available at http://mkemakerspace.appspot.com/access-control-stats/

We’re looking at doing some more fun stuff with the logs from the access control system at the space, like displaying the names of the members who have most recently badged in, making sounds when someone badges in or a key is denied.  I’m sure whatever we come up with will be noisy and large.

 Royce was able to get the access control system working tonight! 

The PCBs for the latest version of the Access Control system showed up at last. I’m excited to give the a try! The exterior unit really ought to be OK as I prototyped that one. But the interior unit is a new layout. Hopefully it goes well.

The access control system is ready for installation tomorrow! All three circuit boards, and the RFID admin circuit are now housed in enclosures. The exterior unit enclosure is no longer pretty after a mauling by a jigsaw, but I did the best I could.

Above is the exterior unit closed up sitting in the open door of the interior unit. The interior unit case is actually the original door strike power supply case at Bucketworks. The exterior unit case is a box donated by TomG.

Above is a shot of the interior of the exterior unit. The green paint is actually a green epoxy insulating varnish intended for motor windings. I don’t have Tin-it or any sort of solder mask process for my homebrew boards. Typically my boards live indoors and its not an issue. But since this one will be outside permanently I thought it would be a good idea to cover the traces.

Above is a picture of the inside of the RFID administration tool. This device is just an ID-12 RFID reader connected directly to one of SparkfFun’s USB converters. I wrote a program that picks up the a card swipe and display the card’s ID on-screen. It turns out that the cheap cards we bought don’t have the ID printed on them. To set up the database with ID number’s this device is needed.

The case itself is an old Belkin USB WiFi adapter with the original electronics completely removed.

Next up we have the case of the server interface. This case used to be some sort of JTAG programmer. Again all the original electronics have been removed.

This view simply shows the interface with the case open.

As soon as I get a change to package up the source and do a write-up I’ll post it too.

This video is a quick walk-thru of the basic design and operation of the access control system I’ve been working on for Milwaukee Makerspace and Bucketworks. The code on the server side is still in a bit of flux. As soon as I have it polished off I’ll post all the code and schematics.

UPDATE: Oy! There was no noise. Or at least……

practically no noise. I put TomG’s awesome logic analyser on the case to make sure that some how my protocol rules messed up and allowed the two RS-485 transcievers to talk over one another. What I found instead was the server interface dropping the transmit enable line prematurely on a fairly random basis. I think its USB Serial port latency. Its looks like it can be +/- 30ms or so. Kinda bad.

You can see the problem in the picture above. The yellow line is the TX line coming out of the server as it appears on the server-to-RS485 interface circuit. The orange line is the RTS line, which is wired to the TX enable on the RS-485 transceiver chip.  As you can see the orange line drops BEFORE the packet has fully shifted out the door. The green line at the bottom of the picture shows the RX line of the RS-485 transceiver chip on the interior unit. As you can see, once that orange line drops, the interior unit doesn’t get any more bits and winds up with a corrupt packet that it discards. However the server thinks it has transmitted OK and waits the full timeout period of 300ms before it retries.

It only did this about 10% of the time, but it did slow the bus down a little. I’ve since tuned the code with well placed delays and sleeps so that it’s down to something more like 2% of the time, but I worried that the latency is going to vary with the operating system and the system load.

To really fix this right I think I need add another Arduino at the server to be the real master of the RS-485 bus and communicate with the server over a full duplex link using a variant of the protocol that is not timing sensitive.