The Story of LLRP2HRP - Part 2

So, this brash American dude who ran a relay race event decided to go fancy. None of this using phones to manually scan NFC chips for race timing. He was going to have chips in bibs. He convinced another organisation that also ran races to chip in some funding ... and then went online.

He found an RFID reader system. The kind of ground mats that you run over, that connects to a box that goes beep. It was from China. It was insanely cheap. Like fall-off-the-back-of-a-truck cheap. It was delivered, hardware checks out.

It came with no software.

Last time, we'd figured out that it also provided RFID tag information using a proprietary binary protocol and were trying to lock down exactly what that was.

It was one of the most arduous Google sessions I've had for a while. Trawling the entire web for some document or code that probably only existed inside an office in Shenzhen. But I found something! It was amazing, because of the source, and how perfectly it fit my needs.

Under the Office of the President of Bolivia is a small agency, La Agencia de Gobierno Electrónico y Tecnologías de Información y Comunicación (AGETIC). One of the projects the Bolivian government had worked on was tracking fuel truck movements and car insurance with RFID labels. AGETIC was given the task, and as they are open source supporters, provided their code on a hosted version of Gitlab.

In their repositories was one called 'hrp', and I finally learned the name of the protocol: Hopeland Reader Protocol. HRP was written in python, had almost no dependencies and within a few minutes of discovering it I was able to connect to the RFID reader for the first time. I immediately sent a thank you email to the code's author, Arturo Hernandez. This project just became achievable.

I was amazed by the power of the reader. RFID tags hidden deep in my room that I've yet to find lit up.

Of course, getting tags off the reader was just part of the problem. To support race timing, that data needed to be fed into a race timing system. Webscorer is the tool of choice for trail races in Taiwan, and they have long supported automated timing with RFID. Only, they used the standard protocol, LLRP.

Expecting nothing, I fired off an email ("Working with non-LLRP RFID readers") to the support alias at Webscorer, just to see if they had any advice or unreleased plans. In less than an hour, the CEO of Webscorer (no less!) responded and provided sage advice. Less than two hours after my original email, I had a copy of the internal code Webscorer uses for processing LLRP.

A plan formed. I could make a server that faked enough LLRP to make Webscorer happy and tie in the tag data using the HRP library. With the code Webscorer provided I could see which portions of the protocol they needed and debug the app. Crucially, at this point I also found that wireshark had a plugin for LLRP, which is where I would spend a lot of my time later.

So, next question - was there open source LLRP server software out there I could hack to make this work? After a thorough Google, the answer was sadly not. I really didn't feel like working with the Java in LLRP toolkit, and basically everything else out there were clients.

However, Ben Ransford, an engineer at Stripe had made a very well designed open source python client for LLRP called sllurp. It separated the protocol definition and encoding/decoding from the rest of the 'client' bits. I figured I'd have to extend the protocol definition and add a few new methods, but the core functionality of an LLRPMessage should be reusable... and it was.