October 6, 2014

Arduino RFID (Part 4)

(... continued from part 3.)

I feel so bad, I thought I had posted part 4 of my RFID project but I completely forgot. I wrote most of the code while taking care of my mom at the hospital, I had even started to make a post, but life had been a mess and I forgot to publish this post. So I cleaned up the draft and here it is.

The source code is quite messy, but it works quite well. I'm proud to say that in the two years since the RFID boxes have been online, they've worked perfectly. We have 300+ employees in two shifts that scan their cards as they come to work and go off work every single day. The boxes surved storms and electrical failures and hardware failures and continued to work. Employees have tried to trick the system by reporting their cards being lost then requesting a second backup card, and the system was able to detect this (through the Windows side software). The only hardware failure was that the POE Ethernet Shield had a design problem where the POE module is way too close to the Ethernet chip and the magic smoke escaped. Out of the eight boxes I deployed, two failed this way.

I'm only posting the code for the Arduino. On the Windows side, there's a .NET program that handles pulling the data off the boxes into a SQL database, then calculates the data into working hours. There's also a separate Windows program for programming the RFID cards. The RFID cards are standard MiFARE Classic cards, and we print our employee photos on stickers and stick them to the cards.

Hmm, I can't figure out a way to attach the code and comment inline, so I'll do it in points. First up is rfid_standalone.ino which is the main program. There's a lot of bad code and I'm sure things could be improved, but I never found the energy to work on this again. (Besides, it wasn't broken!)
  • The Sector 1 Key A is 0x102030405060 here (change as needed). It's to make sure we're reading our own cards and not random data from other people.
  • MAC_ADDRESS can be defined as needed. I have a DHCP server so I put the MAC for each RFID box in there to let it pick up the IP address from there.
  • I used a regular LCD module. The LCD module displays current time and whether the box is programmed for IN or OUT. In/Out can be swapped using a special card. If the box is booted up without network connectivity it shows -- otherwise it shows the day of the week.
  • The RFID card reading code continuously polls the card until valid data is read then stops. There's no "SUCCESS" or "FAIL" unlike some systems. I discovered it confuses our employees.
  • Data from the card is displayed on the LCD screen and logged to the SD card.
  • A sprintf command that writes card data to the SD card. This can of course be customized, but as written it's RFID_UID, Employee_ID, In/Out, Time
  • Along with that spaghetti code, there's a command to create directories on the SD card. So if the SD card is removed and read on the computer, each year is a separate directory and each date is a separate file.
  • The command to read data off the SD card is http://ip_addr/yyyymmdd which prints in plaintext the log written from above. If yyyymmdd is omitted, then the RFID box data and uptime is printed.

Second up is rfid_util.ino which just separates some of the utilities used by the main program into a separate program to stop myself from confusing myself.
  • Some code is used to display a ticking clock. When there's no activity the LCD backlight is turned off.
  • NTP code. There's actually a RTC, so if the network is offline (such as during a power outage), the RFID boxes can continue to function and record by using a UPS.

Finally, rfid_admin.ino is the RFID card creation utility that sets up RFID cards for employees.
  • The commands are handled using regular serial port messages. We write the employee names and codes to the cards, so they can be read back and displayed when the cards are scanned.
  • The RFID boxes can have fixed IP addresses which can be set using the utility.
  • As mentioned above, there's a Windows program to handle the interface, but all the commands can be easily accessed using a regular terminal program.
The code is probably really difficult to understand, but I did put in comments in the code. Please also refer back the previous parts for additional comments and libraries used. There's no guarantees whatsoever that this code will work for you, but if it does and you find it useful, please put it to good use.

Download: rfid_arduino.zip

(... continued in part 5.)

August 20, 2014

Chrome 64-bit font rendering

Google Chrome 64-bit dev came out a few weeks ago, and I quickly switched to it. Unfortunately it had a bug displaying Chinese text, so after a few days I switched back to the beta version, but then 64-bit filtered down to the beta version, so I moved back to the stable release. Unfortunately when 64-bit came to the release version, I had to figure out how to resolve it.

Luckily, after some trial-and-error, I found the setting in chrome://flags. The setting is Disable DirectWrite Windows. (Disables the use of experimental DirectWrite font rendering system.) #disable-direct-write

Before:

After:


The strange thing about this display issue is that it can display the Chinese text properly if I zoom in or zoom out. Only the standard text is affected, bold text is also not affected. I imagine something in the accelerated font rendering system accelerates the font display so much they just slip off my eyeballs. Oh, the problem also affects other similar fonts, such as Japanese and Korean.

Update (2014/09/23): As of Chrome 37, the DirectWrite font bug has been fixed. Unfortunately, enabling DirectWrite causes all the fonts in Chrome to be ugly. Sigh.

March 19, 2014

Linksys NSLU2 and Attitude Adjustment

Time is such a strange thing. I was cleaning up my pile of junk and suddenly saw my dusty Linksys NSLU2. I was wondering why it's sitting in the pile and whether OpenWrt would be available for it to make an easy print server. A quick search on the Internet revealed that I had written about OpenWrt myself 2.5 years ago.

I had completely forgotten that I had done this. I guess with Mom being sick and being overworked I had just lost track of things. Incidentally, this is why I haven't written much on my beloved blog. Since I'm in need of more print servers now, I decided to upgrade it to the current version of OpenWrt.

I booted up the NSLU2 and sure enough, it still has the exact same version of OpenWrt "Backfire" 10.03.1-RC5 that I installed back in 2011. The current release version, "Attitude Adjustment", was released in April 2013. So I downloaded an image for the NSLU2 and proceeded to upgrade it. The upgrade can only be performed using the Sercomm utility and not from the OpenWrt web interface, so I had to boot up my VMware image like before to perform the upgrade.


In Attitude Adjustment, the first USB printer device is /dev/usb/lp0, so the device name has to be edited. After that, everything works just fine.


Stupidly enough, after finishing the upgrade, I remembered why the NSLU2 wasn't being used. I actually let my users test it, but they didn't like it since it had to be manually powered on if power was lost. The NSLU2-Linux site actually has a page specifically for this issue. However, this may not be an issue any more today, as the new Epson printers that we've started using recently do not automatically turn themselves on when a print job is received. We used to use Canon printers that has this feature, but Canon stopped making small sized printers so we stopped buying them.

February 12, 2014

Garmin Forerunner 220 foot pods

I've been running (as a form of working out) off and on for the past few years. As an engineer, data analysis is important to me, even if I'm a poor and slow runner. I first started with a Garmin Forerunner 205 to track and analyze my runs a few years ago. The 205 is a "GPS watch" and it relies on GPS signals to track distance and speed. The 205 only works as a GPS and doesn't support linking to "foot pods", which is required for running indoors (no GPS signal) or on a treadmill (no movement).

Of course, at the time I bought the Forerunner 205, I didn't think I would ever run on a treadmill since I don't have one at home and I didn't plan on getting a gym membership. But eventually I realized that I had to run indoors during rainy seasons. Anyway, so I decided to get a Nike SportBand. The SportBand uses a foot pod (placed inside the shoe on specific shoe models or tied to the shoelace using an accessory or duck tape) to measure the foot's movement instead of relying on GPS for movement. So it works both outdoors and indoors, but unlike a GPS, it's not able to map the course of the run, and it needed calibration to the individual in order to be accurate.

A lot of people say the Nike+ system is inaccurate and without calibration it makes most people think they're actually faster than they are, usually by 5% or more. Since I have both the GPS and the Nike+, I discovered that my Nike+ is actually slower than my GPS by about 5%. After calibration I get 99~100% accuracy compared to my the Garmin GPS.

Fast forward to 2014. Recently I finally got tired of using two systems and constantly having to convert my workouts between systems (details in another post), so a few weeks ago I upgraded to a spanking new Forerunner 220 with a foot pod (purchased separately), so I can use one system for both outdoor and indoor runs.


The Garmin Foot Pod (usually called the "SDM4" to distinguish it from generic foot pods) costs way too much locally, but I managed to find Adidas miCoach Stride Sensor locally for half the price of the SDM4. Contrary to popular belief, the miCoach Stride Sensor is available standalone, although I have no idea where it's available online (I searched) as I found it at a local shop. (The miCoach sensor is half the price of the Garmin locally, but only because they sell the Garmin at twice the price they should be selling.)


The Adidas Stride Sensor looks exactly like the Garmin SDM4 Foot Pod, apparently being manufactured by the same manufacturer. They both use the same ANT+ protocol, so they are completely compatible with each other. Strangely enough, it does NOT fit inside the Nike+ hole inside my Nike shoes, despite everything I read on the Internet that the ANT+ sensor is exactly the same size as the Nike+ sensor. But the Garmin / Adidas sensor is microscopically bigger and it does not fit.

(Oh, the Stride Sensor is a different product from the Adidas miCoach SPEED_CELL. The SPEED_CELL has built-in memory and will upload workout information to your computer after the workout without having to have a recording device at the time of the workout. I guess it might also function as a regular foot pod, but I don't have one to try it out.)

Stupidly enough, one thing that caught me completely off guard about the Forerunner 220 and the ANT+ foot pod is that the watch only supports linking to one foot pod at a time. This is unlike the Nike+ system that supports up to 10 sensors. When I was using the Nike+ system, I actually bought one sensor for each pair of shoes I have, so there's no need to swap the sensors. I don't quite understand why I can only link to one ANT+ foot pod on the Garmin. Am I supposed to move the foot pod to whichever shoe I decide to wear before I start my workout? Completely illogical.