GPS Time for Small Unmanned Aerial Systems: PPS Beginnings, Part Two
Drone technologies often parallel (and even intersect) the growing Internet of Things (IoT) movement within the prominent cloud infrastructure environment. One of these intersects is Network Time Protocol, or NTP. Most modern Linux or Linux like distributions include support for NTP, be it a client-server such as NTPD or Chrony. These are simply time source dependent daemons that attempt to synchronize host time with a network time sever, via a dedicated locally configured time server or a remote time server over the network such as pool.ntp.org mirrors or Google’s own public NTP: time.google.com.
Given an edge device with connection to the outside world, NTP services can be integrated easily via a WiFi, cellular modem, or hard-wired ethernet connection. When we remove this gateway to the outside world, however, our device clocks drift over time. Hence the NTP services continually run as a service in the background to keep our system time within a range of acceptable clock drift, disciplined by whichever NTP time sources we are pulling time from. In the abscence of a network connection, we can use a local GPS time source, and more importantly it’s Pulse Per Second (PPS) output.
To get started with a Linux Embedded system, a reference or custom board, power adapter or bank, various I/O cabling, and a host Linux or Windows system is required. For this project, I used an Emcraft 3-layer cube kit that includes an NXP System On Module (SOM):
The SOM is based off of the NXP i.MX 8m mini (8mm), which is an arm64 architecture. The NXP chip is a Quad Arm Cortex A53 running @ 1.8GHZ, with a companion Arm Cortex M4 running at 400MHZ. Also on the SOM is 2GB of LPDDR4 memory and 16GB of eMMC flash storage. I have of course opted to use a 32GB MicroSD, which can be had for cheap: a TeamGroup class 10 in this case.
While the SOM is the focus of this article, the other two layers in the cube kit sold by Emcraft are for 1) media (MIPI-DSI lanes, and MIPI-CSI to Google Coral Cam) and 2) PX4 open source flight stack standards which add an I/O compatibility layer to the entire kit. This kit is used in the Hovergames Challenge 2 and is a purpose-built drone embedded system.
I recommend this kit as it is purpose built, but similar Arm-based SOMS, reference boards, and kits can be purchased from the Raspberry Pi foundation , Wandboard, Embedded Artists, and Gumstix.
After configuring my laptop (Ubuntu 18.04, as recommended by NXP), creating a cross-toolchain build environment via the Yocto build toolset, and flashing the image via a utility tool provided by NXP, I was able to boot the image from the SD card and configure the board to connect to my network. Your setup may vary, but i’ve found the following reference and manuals helpful in getting started with Yocto Embedded Linux:
Keep in mind that any additional software I install via the debian package manager can be incorporated in a new built layer via the Yocto build environment on my Ubuntu Linux host system. For now, I’ll use the apt package manager for prototyping purposes, as a new build can take a long time depending on all the development tools.
After ensuring my debian mirrors are good to go, I run an $ apt update, followed by $ apt install pps-tools
Here are some screen snips of common pps tool commands:
Now I make sure the Linux Kernel has recognized the new class in the sysfs:
The above assert command should yield a timestamp in seconds, however I have neither configured the GPIO pin to PPS source or exported the GPIO pin in Linux. See the next few command line snips:
Reading a value of zero is good at this point, as I have not connected the GPS PPS pin to the board’s GPIO0 pin. Part three of this series will cover the GPS receiver connection and reading of actual timestamp values.