OGN Cube

This write-up was supposed to come in February 2020 but some other, “more important causes” made me to reschedule a bit, well for almost a year. In late autumn 2019 I asked a friend with not only access to spectrum analyser but primarily with knowledge and expertise of using it to measure properties of five various antennas I acquired during that year mainly for experimental purposes. I have been carrying the charts presented below in my backpack for most of this time and now it is finally a good moment to share those measurement results with you.

Antenna #1

This is the first and initial antenna which has been used with the CUBE ONE trackers. It took me some time to find a perfect match which would fit behind the canopy without drilling a hole into the hood. I had discovered this one on the Ampér 2018 eletronics fair that used to take place every April in the Brno exhibition centre. For long time I was not certain what the company name was. I just found out it was Sectron and the antenna type was AO-AGSM-TG09.

It was love at the first sight! Tiny dimensions, SMA connector, specifically designed for the 868MHz band and the ability to bend which made it so perfect. It works considerably well with metallic counterpoise which in CUBE ONE was located inside the box right under the PCB. Surprisingly, it performs rather well in air-to-ground traffic, despite the measurement result. Well, see for your self:

The M1 marker is around 730MHz while the frequency band we require (868MHz) is way out of the valley – find the M2 markers on the right. Also its configuration has a huge impact on its performance – the RED line is when the antenna is straight, light-blue when bent in 90 degrees and the bottom green one depicts its properties with a screwdriver in hand touching the outer SMA connector’s ring and making it almost well tuned. Nice but obviously for children to play as commented by Zdenek.

Antenna #2

Why and how did I find this gemstone? Mainly because the CUBE TWO needed one and as I might have mentioned earlier I had just a fuzzy idea what company I purchased the first ones. It took some time but after endless nights spent with comparing and contrasting various types, sizes, brands and even colours I discovered the 2J010 from SOS Electronic .. which seems to be also out of stock at this moment .. 🙁

This story is still at its very beginning and I am already going to spoil the drama – this antenna performs the best from all here presented ones. It performs very nicely at 868MHz – see the markers M2 and M3 (-16dB or -23dB respectively). The M1 is set at 903 MHz. The bottom green line is again with a screwdriver touching the antenna and its influence is negligible. This antenna has the really best adjustment. It allows you to see other gliders at distance 5-7km all around you (well, this number hugely depends on mutual attitude and position of the gliders, of course).

Antenna #3

Another specimen with a bendable joint. It looks like a wifi-piece but is not. Its performance is low. Attaching a screwdriver to the ground had not much of effect but significant at the joint. Even worse properties were observed when a hand was in close proximity to the antenna – rendering it rather useless. Next!

Antenna #4

My personal favourite. It allowed the longest air-to-air distance I have encountered during the last gliding season – 23km! And that is only the farthest glider I have noticed in a moment of playing with the LK8000. And there might have been even longer distances! (it could be a good idea to add this information to the flight record..) Furthermore, it seems to to receive reliably other gliders at distance of 5-10km which makes it better even than the antenna #2. However, it is a bit bulky and kinda pain to fit it inside the tight cabin of LS-1. But with LS-8 it won’t be better 😉

Screwdriver in vicinity it had no influence whatsoever. Not even a hand around its root and all around the body. Its adjustment to the 868 MHz band is a bit worse but it has certainly better gain than #2. Marker M2 at 868 and M1 at 920 MHz.

Similarly to #3, the #4 has has been sourced from China which makes it with a nicer price tag (but who knows what will happen with shipping and taxes in 2021?) but with the sour uncertainty of repeatability of such purchase. Some other pieces I had bought were completely out of specs and violent manual adjustments had to be performed before throwing them to the garbage bin. This buy might have been pure luck but also a good source of nice antennas! Who knows? But I love it! 🙂

Antenna #5

I spotted similar kind of antenna at the T-Cup 2019 in Káďa’s Cirrus. It seemed to be a good idea to use one (or two sector) antennas to scan the airspace in front of you with higher precision – not only to detect possible incursions but also to spot other contestant’s thermalling on the track before you. Her antenna was apparently custom-build piece of PCB (I had a photo.. somewhere) and I also wanted to explore this area a bit. For that reason I decided to obtain a completely different antena ‘architecture’ including a 2m long cable.

The measurement has shown it is adapted somewhere for the 900 MHz band. The cable, however, influences its properties significantly and even more do the dimensions and material of the body it is located on. Dead end.

Summary

The antenna #2 seems to have the best adjustment for the band we need for our OGN adventures while the #4 seems the provide the best air-to-air range. Both of them can provide pretty decent service in terms of range and reliability of data reception. Hence both of them shall and will be considered for the upcoming seasons 🙂 As the #2 is not available at this moment I might try to buy more samples of #4 and check if all of them have the same or similar properties like the single sample I have at hand. Still, buying stuff from China is a tricky business. Either way I will certainly share the outcomes once available! 🙂

This fancy title hides the magic of future track calculation and possible collision prediction followed by reasonable warnings. Reasonable in this case should express no crazy alerts while thermalling with twenty other gliders or in situations like following a tow plane on a fifty-meter-long rope. How is it done? Witchcraft!!

We can work with the information available at each moment coming right out of the thin air. The OGN trackers can and eagerly do receive transmissions from other units in reception range. By sorting and ordering these beacons we could (re)construct trajectory of each particular airborne “target” and in theory predict its future behaviour by employing sophisticated mathematical models. A little concern comes with complexity of such methods and the requirement of real-time availability of such results while all computations need to be performed on a fairly limited tracker’s brains. Hence, some simplifications had to be made..

Let’s start from a single point – the most recent beacon received. Such packet of data contains identification of the other airborne vehicle, its speed, altitude, heading, climb/sink rate and angular velocity. From this single point we can iteratively estimate future discrete locations with certain precision. In case of having two (or even more) consecutive locations received from a single transmitter, the accuracy of this method can rise significantly. Between two known states of the other object we can also include speed changes (i.e. acceleration or deceleration), angular velocity and altitude deltas into the calculation. However, the more distant future we look into the more imprecise this prediction will become. This is not a crystal ball, but it works fairly well.

Exactly the same track prediction can be done based on our most recent location(s) and flight directions. After combining all track-points by calculating distances along corresponding (time-wise) pairs while incorporating headings, climb/sink rates and angular velocities we can issue informative warnings to the acting pilot in charge. And that is the theory of this operation.

Now it’s time to put these hypotheses under real-world flight testing! If you don’t hear from me anymore all this was obviously wrong 😉

Manual maintenance could be a lot of hassle especially when one keeps multiple OGN receivers running. You need to update one thing on the first location. Then you decide to do something similar on the second while the third one wants to be kept up to date too. You really don’t want tame differently configured receivers anyway. Later on, when everything is nicely set up and in sync a friend wants to receive a local weather station or something completely else..

Just a few days ago I hit in my podcast listening queue to a CZPodcast‘s (Czech only) an episode about something called balena.io. As I am skipping the tracks in the queue randomly and I’ve already noticed this balena-thingy to be mentioned a couple of times, it became obvious I have to give it a try. Not only by listening that particular episode but also by installing it on my (surprisingly supported) Raspberry Pi of the very first generation!

It all starts with creating an account (eh, another password to remember) on balena.io website. I was pleased those guys support so many devices, even my Pi 1. To install the “balena os” you need to pre-configure an image that you then just download and flash on the SD card. An old two-gig card was just fine and I was running a Balena node in (almost) few steps (well, this tutorial looks lengthy but is is not that bad, really).

Now: what about the app? Before installing the OGN receiver binaries I’ve decided to run a simple script that would send just some messages across the net just to have a starting point for a more complicated setup. The experimental script was really simple:

#!/bin/bash
id=`hostname`

mqHost=$MQ_HOST
mqPort=$MQ_PORT
mqUser=$MQ_USER
mqPassword=$MQ_PASSWORD

i=0
while true
do
    ((i++))
    msg="ahoj '$i' from '$id'"
    echo "Sending msg"
    echo "  $msg"
    mosquitto_pub -h $mqHost -p $mqPort -u $mqUser -P $mqPassword -t testing/pi1 -m "$msg"
    sleep 4
done

Creating a Dockerfile based on the example was a bit trickier. The documentation describes there can be multiple dockerfiles and the order in which they are processed. There is also something called Dockerfile.template which ought to help you with multi-architecture setups and some other matters. And here was the spot I hit a wall. The example Dockerfile.template did not work due to the first line “FROM balenalib/%%BALENA_MACHINE_NAME%%-node:10-stretch-run” – on git push the hook on the server complained something about uppercase letters in this line. Googling it was helpful only to that extent that there shall be another – dockerfile.template (with lowercase D!). Solved by creating a symlink. However, the git hook complained the ‘Dockerfile’ is missing (had to make a copy of Dockerfile.template; yet another symlink didn’ help). And the initial image had to be changed. The resulting Dockerfile/Dockerfile.template/dockerfile.template is then as follows:

#FROM balenalib/%%BALENA_MACHINE_NAME%%-node:10-stretch-run
FROM balenalib/rpi-debian:stretch-run

RUN apt-get update
RUN apt-get install mosquitto-clients -y

RUN mkdir -p /opt/app
WORKDIR /opt/app

COPY testScript.sh .

ENTRYPOINT ["/opt/app/testScript.sh"]

Concequently, by calling git commit & git push the image gets build on the balena cloud server and after seeing blue unicorn you know it got through successfully. In the project dashboard you can observe the docker-image update progress on all your devices (you can have as many as the free quota (10) or your wallet allows).

So far so good. A neat great on the device detail page is you can seamlessly connect straight to the shell and also into a running docker image (or images if there are more of them). But wait – what is that device load? 18? I understand it is only Pi 1 but..!? The ACT LED on the board indicates there is no disk IO (which is a good sign – the card is old, slow and I don’t want it to die by wear too early). It could be caused by the docker image update process. The Pi is connected to the Balena cloud servers through a VPN and the update itself could be a bit demanding. Lets wait for some time for things to settle down..

After an hour the load was still around 12. I guess the 256MB of RAM is just too little. The Compute Module 1 has double of that and it may do the difference. This is a dead end for my Pi 1 in combination with Balena. Our most powerful receiver runs on quad-core Pi 3 is currently down and I will have to climb the hangar roof anyway – will try that ONE very soon!

Full track recording is one of the nice-to-have functionalities of the CUBEs. The problem here, however, is that the SD card which is used to keep the data gets easily damaged as data flushes to the FAT filesystem cause considerably high wear, especially in the file allocation table (file size & last modification time). The latter could be avoided by disabling the last file updates time in code. Still, the file size and number of sectors allocated is updated every time a block is added to the file. Keeping the data in memory and flushing in larger chunks may seem to be obvious solution, but when taking the MCU’s RAM size of 20kB (while a lot is already allocated) and FAT sector size of 512B into consideration, one can see there is not much maneuvering space.

Hence, the LittleFS seemed to be the perfect solution. Power resilience and wear leveling make it an exact fit for this troubles until you realize its code base is over 4000 lines and make it considerably spacious after compilation – 8KB, even when forcing size optimisation and omitting unused routines in the compiler settings.

In combination with the pending problem of the rest of my code being already a tight fit into the F103CB’s 128kB FLASH (there is also a custom 8kB bluetooth boot loader for firmware updates), the size of resulting binary with LittleFS included has reached the point it does not fit into the program memory space.

Well, what now? There are two options. The first one is to use an F103 MCU with more FLASH like the STM32F103RB. The catch here, are its 64 pins on the larger footprint while the current PCBs is layed-out only for 48 pins of the CB variant. And as I don’t really want to be redesigning the PCB at this moment another option seem to be quite feasible – to replace the MCU with another one. The nice thing with STM’s controllers is they tend to have compatible pinouts. And as I already have some supply of STM32F030CCs in my drawer (and have big plans with that one in another project), this one seem to be the right fit for replacement. It’s got 256kB of FLASH and 32kB of RAM (comparing to 20kB of the F103CB). Some of the libraries I use will have to be extended to support the F030’s architecture (ARM Cortex M0 vs. M3, the buses and peripherals are organised in a bit different manner) but it would keep the footprint small while opening the opportunities for further development! 🙂

But as things never can go easy, there is another problem. In the recent months the Standard Periperal Libraries (SPL) are for some reason not available for download for the System Workbench for STM32 (sw4stm32) and I cannot make it work even when downloaded them manually from the STM’s web. I have reported the problem on the openstm32.org forum already in two posts (the first, the second) with no success so far. Even the SPL firmware for the F103 doesn’t work now for me.

(Edit) I’ve eventually found a workaround. It’s crude, but it does the job! 🙂

(Edit2) Here you can find backup of all STM32 firmwares that were still available from the stm32targets.xml file.