Ankle Monitor Part 1

It may come as a total surprise to some of you that I find the idea of ankle monitors hot. So a few years ago, I set out to acquire one, so I could experience the joys of having my location monitored and tracked 24/7, with no way to escape from it.

The Field #

In terms of ankle monitors, they can be broken down into two main types:

Commercial ankle monitor specifications are hard to find, for obvious reasons. From what I can tell, most of them use proprietary radio frequencies and protocols to communicate back to a similarly proprietary base station. Some newer models are starting to utilize cellular networks.

All that aside, acquiring a commercial ankle monitor is nigh-impossible, short of breaking the law. I've seen where some folks have had luck by just asking a supplier to fit them with one, but that's prohibitively expensive.

On the other hand, a personal ankle monitor is easy to find. You can even get one on Amazon. There's a small handful of solutions available in this sector and all of them are produced by Chinese manufactuers. I found the Megastek MT60x on eBay for cheap and snagged one.

The MT-60x #

My expectations going into this weren't super high, and they continued to dwindle once the device arrived and I started playing with it.

Using a SIM card from Ting mobile (operating on T-Mobile's network), I was able to get the device to communicate with the outside world. The device was configured via SMS messages in a specific format. These were annoying to figure out at first, but I quickly got the hang of it. It helps that Apple devices can use your phone as an SMS gateway, so I was able to send and receive programming texts on my laptop.

As a courtesy, the tracker came with a few months of free access to the Megastek tracking platform, a poorly built web application served up over unsecured HTTP. When I tried to load the site over SSL, I found out they're still using a certificate issued by the now defunct StartCom. None of this is okay, especially when you're handling location data being transmitted by something locked on my ankle.

The hardware, on the other hand, was fairly robust and well designed. The belt's locking mechanism was fairly ingenious (if a little easy to defeat), and the belt-off detection (basically creating a circuit with the belt) was wonderfully reliable. The device is advertised as being IP67 compliant, but since I had to disassemble it to install the SIM card, I wasn't comfortable testing out the rating.


As I said, the tracking platform bundled with the device was just terrible. Scarily terrible. So I looked into other solutions. There's a lot out there. Turns out that the Internet of Things renissance has given rise to a cottage industry of tracking platforms. These servies act as endpoints for devices to communicate their data to over low-level networking protocols. Unfortunately, all of them cost too much, and none of them were designed to support the ankle monitor's data (specifically, whether or not the belt was on).

I decided to build my own. How hard could it be?

In retrospect, it wasn't that hard. The most difficult part of the operation was setting up a listen server to recieve the data being transmitted by the tracker.

Typically, when your devices communicate with the internet as a whole, you're only seeing the top layer of the OSI model. There's a mind-numbing number of processes and services processing your request between Twitter and your phone, for example. The tracker, on the other hand, transmitted raw data over a socket connection, basically the simplest form of transmitting data (without having to actually put packets together by hand). I had to do some extensive debugging to figure out how to set up a listen server.

By default, the tracker communicated using TCP packets, which have a very precise order and structure. If something breaks, or if a packet gets dropped, the entire operationg falls apart. Unfortunately, the tracker's onboard software wasn't well-written or documented, and was prone to failure when it came to transmitting data. I spent a week or two trying to debug this, to come up with a script that wouldn't crash if something went wrong. No luck.

So I switched to UDP and everything worked great. That's because UDP, unlike TCP, is unstructured and intended to be used for applications like this, where you don't care if the data makes it or not. I wrote some python to set up the listen server, parse the data it got from the tracker, and insert it into a database. Unfortunately, I am a dummy who didn't back everything up, so that wonderfully elegant bit of Python has been lost to the ages. Woe is me.

Presenting the data that was stored in the DB, on the other hand, was a wonderful experience. This was the first time I'd needed to use a frontend framework (since we're looking at location data being updated every minute or so) and I decided to use Vue to get my feet wet. I'm pretty proud of what I accomplished with this, even if I can't exactly show it off on my resume.

Next Steps #

All of the above turned out to be irrelevant however. The cellular networks used by the tracker, specifically the 2G and GSM standards, are being deprecated and will be deactivated by the end of this year, if not sooner. This, coupled with the frustrations of trying to get the tracker hardware to cooperate led me to the conclusion that I need to build my own tracker. Luckily, that same IoT renissance has helped spearhead a slew of new technologies I can't wait to take advantage of. I'll talk more about that in my next post though :)