Analysis of a noname GPS tracker

As I’ve cancelled theft insurance of my bike, I’m looking for an alternatives.

I don’t want any commercially available tracking, as this is typically coupled with pretty high subscription, resulting in high TCO. I’ve found out that our O2 GSM operator is providing Machine 2 Machine rate for about 20Kč (~ CZK 22 ) a month. Independent GSM GPS tracker looks like a good choice.

At first my favorite tracker was Interphone Angel 20, however I’ve soon realized that it’s very very similar to some noname Chinese models. As I wasn’t sure how it will work, I went Chinese way and I’ve chosen CJ780 2G model.

Tracker has an accelerometer for vibration detection, GPS module, GSM module, 70mAh backup battery and photoresistor on the same side as double-side tape. This should help detect a situation when tracker fall off the vehicle.

You can control the device with SMS messages, and from the Chinese application/website. And that is something I don’t like. That huge APKs from deep Internet really makes me uncomfortable. In addition web site can disappear anytime.

However in tracker’s configuration you can set IP address of your server. After that, tracker should send all the data there. Yay. Small issue is, that there is not any documentation regarding communication protocol. That is task number one. Second issue is, that battery of my bike is 9.1Ah, I want to know how long it can power the device until it will die. This is especially important during winter, when I’m not riding very often— and please remember, winter is coming.

Step 1 — Analysis of the communication protocol

So after some research, I’ve installed SSLSplit, set the NAT of my home network, and setup the tracker with my home IP. SSLSplit forwards traffic to tracker’s homeland.

sslsplit -L trackerTraffic.log tcp 9393 7700

After shaking of the tracker (some brat is touching my bike!), first data came. You didn’t expect data to be encrypted, right?

Raw binary mixed with ASCII data

Obviously there is both binary and text data flowing. I’ve write simple parser reading from stdin, writing binary data as hex numbers, and entering new lines after every transfer.

Simple log parser
Formatted it looks much better

Now it’s not very hard to see that binary numbers are same as textual one. Date, time, device ID, position, and several flags. Why are they sending both textual and binary data — I have no idea. With the help of mobile application (yes, I’ve installed it) and web interface I was able to identify most of the fields.

Byte fields and their function

What was really interesting for me, was data when tracker lost GPS signal. Tracker sent something like this:

BTS IDs and signal strength

It was pretty easy to figure out, that it’s a GSM location. However I had to spend some time to figure out what particular numbers mean. Well it’s simple. It’s list of BTS stations — GSM operator ID, BTS ID, and signal strength.

Interactvie BTS map on

That pretty much clarified direction from the tracker to server.

To clarify opposite direction, I’ve used both mobile application and web interface. And analysis was straightforward:

Cut oil
Restore oil
Upload frequency 35
Upload frequency 600
Take off alarm on
Take off alarm off
ACC auto arm on
ACC auto arm off
Start status on
Start status off
Set timezone -12
*HQ,7805073095,S71,151347,15,^ 12#
Set timezone 5
Vibration sensitivity x,y,z = 5, x,y,z = 1,2,3
1 is most, 9 is less
Tow truck 500–10000m
Tow truck SMS and Platform, 505m
Tow truck Call and Platform, 503m
Tow truck Call, SMS, Platform, 666m
Tow truck Platform, 564m
Set Master Number
Take off alarm on
*HQ,7805073095,S71,152441,09,3# *HQ,7805073095,V4,S71,152441,09#
Take off alarm off
*HQ,7805073095,S71,152455,09,0# *HQ,7805073095,V4,S71,152455,09#

At this point I was pretty satisfied with protocol knowledge, and I’ve moved to second task.

Step 2 — Analysis of power requirements

To analyze power consumption, I’ve connect the tracker on INA219 board and that board through I2C to Raspberry Pi. INA219 on this board allows to measure up to 3.2A with 1% precision many times a second.

INA219 on the web of Adafruit

This way, I was able to log current ten times a second. I’ve aggregated every measurement to current per second, and after that to current per minute/hour/day.

24 hours power consumption looks like the graph above. Tracker is reporting it’s position every 5 minutes. In case that it wouldn’t call home 10 minutes, web page/mobile application reports this to user.

If I would fuse transfer and consumption log, it would be possible to check if the tracker is sending data to some other server. However I didn’t spent time on that. Hopefully Party doesn’t care.

When I’ve averaged values over 24 hours, tracker has average consumption 3.5mAh. That means 84mA a day. After 12 days, 1.08A. Not so nice. Good thing is that tracker is reporting battery level with every call (even it’s not correct and it’s shifted down by 0.3V) However it still means that during the winter, I should charge the battery at least once a month.


Tracker is pretty much OK. For a vehicle used regularly I have no complains. For a motorbike is fine, if you are using it at least once a week or you have easy way to charge it regularly. Am I going to install it to my bike? No yet.

During the analysis I haven’t found a way how to change 5 minutes period. I would expect that with some magic SMS command it should be possible to change it. Unfortunately lists of SMS commands I’ve found, don’t have it.

And that’s it. If you’ve found this article interesting or useful, let me know.