Fenrir

As mentioned previously, I have a GPS tracking device in my vehicle. This suited me well when we drove around Scotland on holiday and I made a simple system to pull the data out and see the route we took. Recently it’s been a little less reliable though. We drove one weekend for about 50 miles and when I checked the tracker it showed that I was still parked on the drive at home. Most of the time it works fine but these occasional hiccups it has developed fill me with fear that if I actually need to rely on the system for recovery, it might not be showing the real location.

I set out to make my own solution to this problem. After a bit of searching online I discovered a product called Linkit One, which seemed to suit all of my needs. Of particular interest to me was that it is produced in conjunction with MTK. Personally I’ve always found them to be by far the most reliable GPS chipset maker so that was a major selling point for me.

After a bit of tinkering and setting up my machine to talk to the Linkit board I started to think about how I should put this solution together. On the server side I already knew it’d be Node, Mongo & Express as that’s what I’m familiar with. I try to use something new to me in each project I do and I’ve been wanting to try using React so I’ll be factoring that into the management web page.

The board is going to be in the vehicle, hidden away and hard to access. Due to that I settled on two main principles for the software on-device. It should be remotely configurable and as simple as possible. That means no processing of location data, geofencing or anything else to be done on the device. What I don’t want to be doing is digging it out and updating the software on it when I decide it should update every 60 seconds instead of 120, or that a 20 metre geofence is too small. Processing the data server-side and having the device pull a remote config with its update interval and other variables means everything is much easier to manage.

Features

I settled on a few initial ideas for what the device should do and then an expanded list to look into once the initial features are complete.

Geofencing. This was mentioned earlier and is a pretty obvious one. If the vehicle moves out of the fence at the wrong time, it should alert me. Through the management website I should be able to set up any number of fences and times. The alerts would happen by GCM to a custom Android app and receipt of the GCM should be relayed to the server as these are not guaranteed to be delivered. The server will retry the alert until it is received.

Parked Monitor. The aim of this is to solve one problem I have with the current tracker. Geofencing is great if you know where and when you are going to be, but if we head out at a weekend somewhere new then I’ve developed the habit of checking the tracker every 10 minutes. With this feature I should be able to tell the server that I’ve parked and left the vehicle. When I get back I can unset that state. If the vehicle moves in between those two events then I should get an alert about it. In this way I no longer have to check the tracker because I will be notified about movement automatically.

Battery Backup Mode. The tracker is going to be set up to run off the car battery, so that it is able to run 24/7 without needing periodic charging. Should the device be disconnected from the vehicle battery (a common way to defeat vehicle alarms) then it will switch to a backup battery and I should get an alert to let me know. When switching to the backup then the operating procedure for the device should be different, so as to conserve the limited power it has available. The likely procedure here would be to shut down non-essentials and switch to a longer update interval. Testing for the optimum balance between backup battery life and location accuracy should yield the best interval, but this is another value that should be remotely configurable.

NMEA Sentence Transmission. This is fairly obvious but I wanted to make the point that the device is going to be sending the NMEA sentences to the server and not actually doing any parsing of its own. Parsing and extracting data from the sentences is all going to happen on the server.

Future Features

Jammer Detection. This one is quite important really. There are a few GPS blockers on eBay and a simple Google search brings up many other sites selling these. They helpfully even plug straight into the cigarette lighter! Now, I’ve never bought one of these so I’m not sure if they actually do all that they claim but it would ideal to detect when a jammer or spoofer is being used. Without access to one in order to test with that’s going to be quite difficult but some obvious ones are erratic movement, long distances covered in a short timespan or being out at sea. One jammer I found claimed it could make receivers just think they were staying in the spot where the jam was enabled, which would be harder to detect. With a more sophisticated system it could maybe detect movement via the odometer (my car is too old to have OBD) or with accelerometers but it is unlikely I will implement such a thing. In the case where a jam is detected, it would be actually quite easy to have the device disable power to the cigarette lighter. For battery powered jammers there isn’t really anything the device can do to recover.

WiFi & Cell Tower Scanner. As a secondary measure for when the GPS is not working, be that because it is blocked by a jammer, heavy cloud cover or just being in a building, there is another system for detecting a coarse location. Obtaining cell tower identifiers using the Linkit is trivial and there are many sources online for discovering the location of these towers. Solutions also exist for finding a location by scanning for surrounding WiFi networks, however this sort one may prove to be cost prohibitive.

SMS Commands. As well as periodically sending data to the server, the device should be able to receive and respond to commands by text message. This is helpful in cases where access to internet is difficult or urgent action is required. The list of authorised message senders should be remotely configurable.

Engine Cutoff. Another fairly straightforward modification to the car should allow the device to cut off the engine and prevent it from being started up again. This one actually needs some consideration because although cutting the engine is easy, it must be designed such that in the event of catastrophic failure of the tracker board it will fail safe. Additionally, a more ideal solution is not to cut the engine immediately but instead to wait for an opportune moment. For example, whilst the vehicle is travelling at 70mph is almost certainly going to end in serious harm to the occupants of this vehicle and any around it. Alternatively when the vehicle is stopped at traffic lights and the speed is zero seems perfectly appropriate. The law needs some looking into for this type of solution, however the last resort option would simply be to signal that the board should prevent the engine from starting up once it has been shut off, rather than actually forcing it to shut off remotely.

There are other features I’m thinking over for the far future such as determining ignition state or geofencing by wifi rather than GPS, but they are going to be things to look at once the features described above are all complete.

The server, client, website and Android app code for Fenrir will all be made available as I’m hoping this system can help others develop a tracking solution of their own. In the future I will be writing about each of these parts of the project as I progress with them. The first stage is to get the Linkit board programmed and sending data to a local logging server, so that it can be left soak testing whilst the other components come online.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.