GPS Tuning the Librem 5 Hardware

Phone Hardware debugging in a duopoly

Society is getting pretty used to the idea that the data and applications on phones are completely controlled by large corporations.

Purism is working hard to change that with the Librem 5.

Because of the market capitalization and duopoly control of the phone OS vendors, the hardware tool vendors use are trapped into one of those two OSes (Android or iOS).

GPS debugging as a case example

We’ve been working on antenna tuning in the Librem 5 for awhile to get the best possible reception. The GPS antennas are especially important because their signal level is so close to the noise floor.

The available GPS antenna tuning procedure is a GPS simulator, but the simulator requires feedback from the phone OS to help tune the antenna. If you are on Android the simulator vendor provides an apk that converts the NMEA to a format that the tools can use to do the tuning.

So now we have a tool to do the tuning but no way to use it.

Option 1 get anbox running

So I did seriously consider trying to use anbox to get the apk running on the Librem 5. I didn’t think this would be workable for a couple of reasons.

1. The GNSS chip doesn’t use a /dev/ttyS0 device but a /dev/gnss0 so I had no idea how well Android or anbox would deal with that.
2. There are a lot of moving parts to get anbox running smoothly enough for productive development and my todo list is already pretty lengthy.

Option 2 RE the apk

So the next thing I figured I’d reverse engineer the apk so that I could provide the feedback tool. I didn’t have a lot of faith that this would work as reverse engineering a protocol can be very time-consuming.

Loading up the apk on an Android device the first thing it asks for is an IP and port. Ok, this might be workable. I whipped up a little python program to try and capture the apk output.

#!/usr/bin/python

import socket

UDP_IP = "192.168.0.2"
UDP_PORT = 8080

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

sock.bind((UDP_IP, UDP_PORT))

while True:
    data, addr = sock.recvfrom(1024)
        print("received message: %s" % data)

Immediately I started receiving GPS location and satellite S/N ratio numbers. Perfect so now I just need to figure out what each of the fields meant.

Writing a GPS test tool

I began by capturing all of the JSON strings output by gpsd and trying to fit them into the correct fields for the GTS 1800 test tool. Almost immediately I started hitting some kind of mismatch between the gpsd output and the json libraries installed on the phone. I’m not sufficiently pythonic to understand what the issue was.

Ok, I really don’t need that additional abstraction that gpsd provides so I installed the python-nmea2 library and started working directly with the NMEA strings. In short order, I had a script that would take the NMEA and convert it into something I thought the GTS 1800 could digest. I’d guessed at a couple of the fields but I hoped it was close enough to start the GPS antenna tuning.

Unfortunately, it wasn’t until a few screens captures from the antenna testing engineer running a Windows tool that I was able to refine the test tool to a point that the GTS 1800 would accept the strings. The biggest problem was that I guessed wrong about the first field which turned out to be a message length. Ooops, should have figured that one.

Once I reformatted the fields the GTS tool would accept the strings but it still wasn’t running the tuning algorithm so there was still some kind of error in the fields. This is when the test tool vendor figured out what I was trying to accomplish and sent me a protocol specification. Better late than never. So 2 more minor fixes and we now have a tool that can be used on any box that runs python to tune GPS antennas.

So duopolies aren’t just bad for software, they aren’t any good for hardware development either.