This is the hardware mounted on a PCB. Going around the board from bottom left the various bits are:
Because the peripherals use I2C & SPI the PCB is quite simple.
Everything operates at 3v3 and the maximum current drain is a few hundred milliamps. I have some clever ideas that could make this battery powered & portable should a need arise.
I cut front & back panels with our laser engraver. This was as much to protect the bits as to make it look good.
The board in the image above is mounted behind the front panel.
Also in this image there are three status LEDs and a 16x2 LCD.
The LCD has an I2C interface so only requires four wires to connect it to the main PCB.
Power is supplied via a USB connector to the Teensy. In this photo my iphone charger is the power source.
This photo is taken at boot up. The device announces itself and displays the time. Then it displays an IP address, I skipped that shot as it only does this to help me while debugging. I might add a video of it in operation.
After boot up the device just sits and waits for cards to be presented. The ready LED flashes & when a card has been read successfully the OK LED flashes. Obvious really!
The time is displayed on the LCD which is reassuring for the user but it's a bit of a luxury.
Currently the time is kept by a RTC. I had intended to use sNTP for the timekeeping but it's a pain to parse the data returned from the WiFi interface and extract the time. Something to look at if/when I have time to write the code.
This is an issue - this device requires minimal intervention. Right now there is no way of updating it other than plugging it into a PC. I might implement 'POST' functionality to correct this. I suppose I became aware of this limitation when our clocks changed recently.
The device has a web server on board. I decided to implement it this way as it's quite(!) easy to interface with an Excel spreadsheet which is handy for demonstration purposes.
Each row of the table contains a RFID and the unix timestamp of when the card was seen. In this example the register is empty. Here is an example with a few real entries.
Obviously a PHP script could handle stuff like this too.
The root page of the web server shows a live view from the device. Essentially this is an open register.
As each WiFly device has a unique MAC address this seems an appropriate way to distinguish one reader from another.
Clicking the 'Access archived registers link' takes us to the archived registers!
More correctly it takes us to the SD filesystem. When a register is full (113 entries with the Teensy) an archive is automatically created.
The archives are stored as html pages and each file is uniquely identified by its name which is a unix timestamp which records the time & date of when the file was created. Conveniently, the Arduino SD library uses DOS 8.3 filenames which are just right for a timestamp.
An archive file is also created automatically at 11pm every night. The system automatically makes the files 'clickable' so they can be rendered as web pages &/or accessed from an Excel spreadsheet with relative ease.
The other files seen here are 'helpers' of one sort or another. Most of them are text files comprising menus, http headers etc. There's a lot of space on the SD card so we may as well use it!
I've used FAT32 and currently only use the root directory. This limits us to 65,534 files but this shouldn't be a limitation.
Using the SD filesystem is a slightly expensive luxury when a fairly small EEPROM would suffice, however it does afford a level of portability as the card can be easily removed and read externally.
Clicking on an archive file opens the archive page...
I make these pages a different colour to distinguish them from the live register page while I'm debugging.
Each archive file uses about 6 kilobytes of space on the SD card. I'm currently using a 16G card (the only one I had!) so we won't run out of space for a while! In fact, unless I implement hierarchical storage we'll never use more than half a gigabyte.
The SD filesystem is FAT32 format so an added bonus is that the card can be removed if necessary and read on a PC.
Currently that's it at the server side. There are still a few tweaks required but nothing major.
To monitor the data I constructed an Excel spreadsheet which uses a table lookup to convert a RFID code to the card holder's name.
This was a bit tedious! I needed to associate students RFID to names. We don't have an available database so I needed to read the cards and enter the data myself...
A little bit of Excel trickery is also used to convert the unix timestamp into a more readable format. This is mainstream stuff - Excel is quite fussy but the format conversions are well documented.
btw my RFID is FBA46ED2, what's yours?
Getting the data into the spreadsheet uses another bit of Excel trickery. I was blissfully unaware that it could do this until quite recently!
Excel has the ability to import data from html tables using its 'web query' facility. The photo shows this.
As outlined earlier, this provides a convenient demonstration.
The relevant log can be linked to the spreadsheet for analysis.
I can't imagine Excel being used for our application but this is great for demonstrations!
Apparently this only works (easily) on PC based Excel...