March 15, 2018

Arduino RFID (Part 5 The Final Chapter)

(... continued from part 4)

As implemented, my Arduino RFID boxes are in the style of separate In and Out walkways as seen in most typical MRT systems where the incoming and outgoing people use completely different walk ways and separate scanners. Unfortunately we don't have electric gates, so sometimes employees get confused and scan their cards multiple times at the wrong scanners. My Arduino code prevents multiple scans that immediately follow one another, and our Windows side software will take care of other duplicate scans.

The guards have a special RFID card that's used to "swap sides". Our In and Out walkways are normally fixed, but in case a box goes out of order, we can immediately change the walk ways and redirect the employees to scan correctly. So far we've only had to do this a couple of times, when the POE Ethernet Shield blew up, and when the electricity went out for so long that the UPS that feeds the POE switch ran out of power, and we had to rig up a battery pack for a single RFID box to let the employees get off work.

The point of this is that the RFID card itself doesn't know if it's "inside" or "outside" of the premises. The boxes only do the scanning and logging, and it's up to the Windows software to figure out the working hours and overtime hours. The Windows software can also check the current time and check the logs to see if the employee is "inside" or "outside". I mentioned in the previous article (also via source code), the employee's name and code are written onto the card. They're displayed when the card is scanned for the user to read, but only the RFID card's UUID and the employee code are logged. There's no need to log the name.

However, since the MiFARE Classic cards are actually capable of being written to (like cash cards). An alternate design is the bus system where a single scanner can be used for both incoming and outgoing, and it's up to the card itself to remember its state. In this design, if the employee forgets to scan the card, the in/out status would be reversed, and they would need to reverse the status by scanning the card again, or letting HR reverse the status. This was to be my initial design, but I felt the employees would be too confused by this implementation.

Oh yeah, while working on the RFID boxes, one issue that came up was the accuracy of the time clocks. I tried to explain to the HR people what NTP is, but couldn't get through their skulls. Eventually I ended up doing a completely different project to handle the clocks.

All good things must come to an end, it's been a while since the last article, and over the years my Arduino RFID boxes have performed admirably, except for every month or two (roughly once every 10,000 scans) HR would complain that an employee missed a scan which I could never discover the problem. So late last year (2017) I finally gave up and the company purchased new scanners directly from vendors with warranty and we switched to the new system on the first day of 2018. And two and a half months into this year we've already missed more than 20 scans. Garbage I say.

However, since Raspberry Pi 3 B+ is released today, I might pick up this project again just for fun. The Raspberry Pi is easier to manager than the Arduino because it runs a full OS and even though I've never written about it here, I've played with them quite a bit since the very first release and I've done a really simple project that I'm actually proud of. Will write more later.

March 14, 2018

RIP Hawking

"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." 

I don't think it's an exaggeration to say that Stephen Hawking was every geek's childhood hero. Rest in peace, and thank you for being an inspiration for a generation of scientists and engineers.

February 23, 2018

Fake Logitech Wireless Presenter R400

I've been looking to buy a Logitech Wireless Presenter R400 since my ex-boss stole mine. The R400 is like the pinnacle of the PowerPoint remote since it does everything so well without any fuss, and it's backed by a well-known brand. I briefly considered again getting the R800 with green laser and vibrating alarm, but the few times I used green laser pointers in my presentations, the overly bright green laser only served to annoy my audience.

Anyway, if you've looked at online shops selling the R400, you might've noticed there are tons and tons of cheap "genuine" R400's. I found a shop selling one slightly cheaper than retail, and it showed the packaging with the Logitech logo, and it has hundreds of feedbacks claiming the shop is really good and the product is genuine. All the signs point to it being fake, so I bought one immediately.

Well, I couldn't lose anything. If it's fake I'll just return it, if it's genuine I've got myself a good deal, so here it is. Oops, I forgot to take a picture without the outer wrapper, but it says Logitech R400 on the box, and it has the old Logitech logo. Hundreds of online shops show this genuine blister packaging. Inside the plastic shell it still looks fine, but once unwrapped...

Comparing to a genuine R400. All images has the genuine on the left and fake on the right. I lost my original R400 when my ex-boss stole it. The one pictured in this post is a new one I just bought from an authorized dealer at list price after the fake one turned out to be, well, fake. Click the images to see close-ups.

The genuine one has better plastic and all the silk screening on the buttons as well as the buttons themselves are well-aligned. The genuine one has somewhat shinier plastic on the buttons, but the rest of the body feel similar.

As said above, the bodies feel quite similar, so that's a good thing for the fake one if you just want a cheap PowerPoint remote and don't care much for quality. There are many really cheap "R400-style" presenters being sold without the Logitech logo, but this is being sold as a Logitech R400, so I'm calling it a fake. Notice my genuine one has the new Logitech logo that they started using around mid-2015.

The laser covering of the genuine one is curved and shaded. The fake one is flat and clearer so you can see the hole behind the covering.

The power slider of the fake one is really difficult to slide, and the shape of the switch doesn't quite fit inside the cutout so you can see a bit of green there. On the fake R400, the red sticker that's supposed to be shown when the remote is off is missing.

The battery compartment look similar except for the text, but the springs are lower quality on the fake one, and the batteries don't sit so well. Oh, and the fake one doesn't come with batteries. The genuine one has the newer R-R0008 part number while the fake one has the old R-R0004 part number. The fake one is missing a serial number.

The battery covers look similar, but the genuine one is shiny inside while the fake is matte. The battery cover of the fake one doesn't fit quite well and will fall inside if pushed too hard. Funnily enough the two battery covers are incompatible with each other.

The USB receivers look very similar, but the genuine one is shinier. The fake one appears to have markings that look used, but it came that way.

They come with different storage bags. This is just a difference with the year of production. Older R400's also came with the pouch on the right side, while newer ones have the low cost cloth pouch. The fake R400 comes with the old style pouch, but it feels rough compared to the genuine one that my ex-boss stole.

And finally, this is what a current genuine Logitech R400 packaging looks like. Even though the Logitech website still shows the old logo, but they're being sold with the new logo and new style packaging.

February 14, 2018

Can't boot into Windows after BIOS update

I think the scariest thing for a sysadmin is Windows failing to boot, especially after an unnecessary (?) BIOS update. Recently we got two Lenovo ThinkServer TS150's. They're cheap and work really well, and we quickly put one into production since the old server just suddenly up an died. So I was staring at the other server sitting there doing nothing except having a brand new install of Windows Server 2016, and seeing that the BIOS is dated 2016 and the latest is 2018, so I decided to upgrade the BIOS.

After the flashing was completed and the system rebooted, I got a black screen and this text: Error code 1962 - No operating system found. Well, the BIOS must've been reset to defaults. Go into BIOS, nope, everything is same as before. Maybe there are new BIOS options... tried some different configurations... didn't work... tried every possible configuration... didn't work... tried resetting to defaults... tried optimized setting... tried swearing... nothing worked. Luckily I have the other TS150, but since it's in production I had to wait until midnight to take it offline to look at the BIOS. Compared all settings and they're all identical except for the BIOS dates. Tried all possible configurations again just in case I missed something.

Next, I tried using Linux Live CD's, Windows 10 Live DVD's, and also Window' own rescue mode to flash different versions of the BIOS. Nothing worked. Tried going back to the original BIOS dated from 2016 but it wouldn't let me. Apparently there was a security update in 2017 and they disabled going back to older versions.

Next, I used rescue mode and the bootrec command to tried to fix the boot sectors. No go.

Gave up. Tried installing Windows from scratch. Nope, Windows complains that it can't be installed to this disk because the hardware may not support booting to this disk. Nooooooooooooooo.

Punch reset button in frustration. So while I was tearing my hair out again and pondering what to do next, I suddenly saw the familiar screen.

And next thing I know, Windows Server 2016 was booted up like nothing has happened.

After much head scratching, I discovered the reason it booted was because it was booting from the Windows install DVD, and because I was tearing my hair out and ignoring the server, the "Press any key to boot from CD or DVD..." prompt timed out, and it automatically booted into Windows. Nothing was changed in the BIOS, the boot sequence was correct, and after testing I confirmed that it will only boot Windows if it was booting from the DVD initially then let the prompt time out.

So... apparently after any BIOS update, something somewhere got modified in the boot sector and it would no longer boot correctly. But booting from the DVD then letting it time out seemed like a really strange thing, since this suggested the hard drive's boot sector was still functioning properly, it just wouldn't boot as the first boot device. Tried searching Google for this problem and found thousands and thousands of people with similar problems and no real fix except things I've already tried. Most ended up reinstalling Windows, which didn't work for me.

Well, after a week of even more head scratching, I finally came up with a working and reproducible solution (workaround). The ThinkServer came pre-configured with two hard drives which are configured as RAID1 array using the onboard Intel RSTe. I'm guessing the problem could be related to the Intel chipset and the RAID array configuration, but a BIOS update should not mess it up so much. Anyway, the fix was to remove one of the hard drives from the RAID array by booting into the Intel RSTe configuration screen and selecting the option "Reset Disks to Non-RAID". Remove one of the drives then add it back immediately. After that reboot into Windows using the DVD workaround method above. After the array was re-built, Windows could boot normally again.

Now let me go test this on my production server.

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.


(... 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



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.