HAB Base and RTTY

Once the HABHUB server is disconnected next month, the map will stop working and you won’t be able to upload RTTY telemetry to HABHUB. However, you can if you wish continue to use dl-fldigi or fldigi to decode the RTTY, and have HAB Base show a map with your tracker on it. Additionally, HAB Base can forward the decoded telemetry to the sondehub/amateur system. You can then view your payload on the Sondehub amateur map.

Install

Use the latest release from github. V1.6.6 is when the new functionality was added.

Set Up Source

Add a new source, setting the type of source to “TCP (DL-FLDigi).

Set the code and name to whatever you like.

Set the Host to be the hostname or IP address of dl-fldigi / fldigi; typically this will be “localhost” for the same machine that is running HAB Base.

Set the port to 7322.

If you want to upload to Sondehub, check the “Upload to Server(s)” box. Also, make sure that Sondehub uploads are enabled in the System Settings dialog:

Usage

If dl-fldigi/fldigi is not running, then start it. It doesn’t matter if you start it before or after HAB Base.

If all is well then the source window will show a green background:

Once telemetry has been successfully received then this will turn lime green:

You can see the telemetry in the history tab:

And, as with other sources, you will have a payload window for each received payload:

and it should appear on the map, with a prediction if sent by the tracker:

Sondehub/amateur uploads

If this is working correctly then you will have a lime green status button for Sondehub:

That is now a clickable button, showing a log window:

Sondehub Map

You can open the Sondehub map from the Payload / Settings tab:

Click the link to open the map in your default browser:

Moving from HABHUB to Sondehub

As I hope you’re already aware, the HABHUB system is due to be shut down in October 2022. This system has supported HAB in the UK and elsewhere for many years now, however the hardware is old, the operating system is old and unsupported, the database engine and other installed software components are old, and maintenance of these things is no longer tenable.

(Very) fortunately, we have an alternative. Sondehub has been running for about 3 years now, providing tracking of met office radiosondes, and Mark and Michaela of the Sondehub team have been busy providing the same infrastructure for amateur flights. Sondehub was designed to cope with the large number of radiosonde flights, and their high data update rates, so the system is well capable of coping with the much smaller number of amateur flights and their generally rather lower update rates.

HABHUB includes various components that are used daily by HAB enthusiasts, such as a burst calculator, predictor and the balloon tracking system with live map. All of these things either have equivalents with the Sondehub system, or have been ported over to it.

For more information on Sondehub and the transfer from HABHUB, see Mark’s article.

Supported Tracker Modulations

For details information on this, see this article.

Most UK flights use RTTY or LoRa.

RTTY

The usual method for RTTY was to use dl-fldigi which uploaded directly to HABHUB, but this will stop working when the HABHUB server is switched off. However there are alternatives:

  • Use Horus GUI
  • Continue to use dl-fldigi (or, better, just fldigi) and have the output read by HAB Base which will show the decoded telemetry, place the payload on its own map, and upload the telemetry to sondehub/amateur.

LoRa

There are several programs available for receiving LoRa telemetry:

  • HAB LoRa Gateway. This has been modified to upload to sondehub/amateur; you will need to update to V1.9.2 or later.
  • HAB Base. This has been modified to upload to sondehub/amateur; you will need to update to V1.6.2 or later.
  • HAB Explora. A new version will be released soon, with sondehub/amateur support (balloon telemetry and chase car upload) and also support for Android 11/12.
  • HAB PADD. A new version will be released soon, with sondehub/amateur support (balloon telemetry and chase car upload) and also support for Android 11/12.
  • Windows Serial Gateway. I don’t currently plan to modify this for sondehub/amateur as HAB Base does everything that it does.

What Do We Lose?

Flight Documents

Sondehub has no concept of flight documents, so please be sure to publicise your flight in the UKHAS Google Group. Obviously, you will no longer need to create flight documents or get them approved.

Payload Documents

Sondehub has no concept of payload documents, which were used to tell HABHUB which field in the UKHAS telemetry string contained what information. This means that you no longer need to create a payload document, but that Sondehub will only show the basic, essential fields such as latitude and longitude. However, see the following section on Tracker Telemetry for an alternative mechanism.

Tracker Telemetry

Sondehub has no concept of payload documents, or indeed of the format of a UKHAS telemetry string, so it’s up to the receiving/uploading software to parse the UKHAS telemetry from a tracker, deciding which field means what (latitude, longitude, temperatures etc.), then passing those values on to Sondehub.

All such programs assume that the telemetry string is of this form:

$$<callsign>,<count>,<UTC>,<lat>,<lon>,<alt>[,<optional_field1>....]*CRC<LF>




Provided that your tracker follows this format – and I don’t recall seeing one that didn’t – then you tracker can be stored by sondehub/amateur and will (assuming a valid GPS position) appear on the live map.

That’s great, and it avoids the issues of people creating payload documents that don’t match their tracker telemetry, however it also means that any extra telemetry is not displayed on the map and aren’t charted on the sondehub Grafana page.. Such telemetry might include the number of satellites, internal and external temperatures, and it would be a shame to not have those displayed, stored and charted.

There is a solution, which is for the tracker to also broadcast the field list. The method supported by my various receiver programs is for the field list – a sequence of digits/letters one per field – to be included in the regular telemetry. For example:

$$PITS,676,10:42:48,52.37709,0.45973,00473,10,32.7,0.0,0.000,0.07,52.37810,0.45927,12.3,30,0123456A9PTCDUV*D64F

The part in bold is the field list. Every character in that string represents a field type; e.g. the “0” represents the payload callsign. Since we always assume that the basic telemetry is as shown earlier, the field list will always begin with the characters for those standard fields, namely “012345”. This is used by the decoding programs to locate the field list.

I have defined a list of field types that my receiver programs understand and can then send to sondehub/amateur. I’ve listed the field codes in the following table, together with which of my trackers and receivers support them currently. HAB Rx is a common library for HAB Base, Explora and PADD. The HAB Base column shows that HAB Base displays those fields in the Payload window.

#FieldNotesFlexTrakFlexTrackPITSHAB RxSondehubHAB Base
0PayloadIDYYYYYY
1CounterYYYYY
2TimeYYYYYY
3LatitudeYYYYYY
4LongitudeYYYYYY
5AltitudeYYYYYY
6SatellitesYYYYYY
7SpeedNot WorkingNYYY
8HeadingNot WorkingNYYY
9Battery VoltageYNYYYY
AInternalTemperatureYNYY (if no ext)Y
BExternalTemperatureYYYYY
CPredictedLatitudeYYYYYY
DPredictedLongitudeYYYYYY
ECutdownStatus0 = Idle
1 = Armed
2 = Triggered (Altitude)
3 = Triggered (Manual)
4 = Triggered (Other)
YYYY
FLastPacketSNRYYYYY
GLastPacketRSSIYYYYY
HReceivedCommandCountYYYYY
I-NExtraFieldsYN
OMaximumAltitude
PBattery CurrentYYY
QExternal Temperature 2Y
RPressureYYYY
SHumidityYYYY
TCDAYYY
UPredicted Landing SpeedYYY
VTime Till LandingYYY
WLast Command ReceivedYYY
X
Y
Z

Tracker Support

Follow me on Twitter for release announcements.

All of my existing trackers will work fine with Sondehub/amateur, however you will only see the essential fields (see above) unless you update and enable the fieldlist function.

PITS

Update to the current version, then edit /boot/pisky.txt and add the following line:

Send_Field_List=Y

The field list will then be automatically built and appended to the telemetry.

FlexTrak (Pi/STM)

The next release will support sending the field list. This can be configured using the configuration file on the Pi, or by connecting the tracker to a PC with a USB-serial cable and using the Windows configuration program. The field list itself can also be configured using either of those methods.

FlexTrak (Pi/AVR)

The next release will support sending the field list. This can be configured using the configuration file on the Pi, or by connecting the tracker to a PC with a USB-serial cable and using the Windows configuration program. The field list itself can also be configured using either of those methods.

FlexTrack ESP32

The next release will support sending the field list. This can be configured using the Windows configuration program. The field list will then be automatically built and appended to the telemetry.

FlexTrack AVR

The next release will support sending the field list. This can be configured using #defines at the top of the flextrack.ino file. The field list will then be automatically built and appended to the telemetry.

Receiver Support

Follow me on Twitter for release announcements.

LoRa Gateway

Update to the current version, then edit gateway.txt and add the following line:

EnableSondehub=Y

Tracker telemetry will then be sent to sondehub/amateur. If the telemetry contains a field list then the specified fields will be sent as well as the basic ones.

HAB Base

Update to the current version.

Uploading

To enable uploads sondehub/amateur, click the System Settings button and click the Sondehub option:

Tracker telemetry will then be sent to sondehub/amateur. If the telemetry contains a field list then the specified fields will be sent as well as the basic ones.

Local Payload Receiving

To receive telemetry of nearby payloads from sondehub/amateur, (equivalent to the previous HABHUB Logtail, option), add a new source and choose “Sondehub” from the drop-down list of source types:

For any payload that you are uploading to sondehub/amateur, you can load the Sondehub map for that payload by using the link under the Settings tab:

HAB Explora

This is being worked on.

HAB PADD

This is being worked on.

FlexTrak STM flight with 3D Printed Holder

Yesterday I launched a FlexTrak STM32 tracker to test my latest firmware, test my HAB Base software during a flight, and to try out a Raspberry Pi camera with a wide-angle lens. It was also my first flight using a 3D-printed tracker holder and aerial.

3D-Printing and HAB

It took me a long while to decide to buy a 3D printer, as I wondered if I’d use it very much, but the reality is that once you have one you find no end of things to make. After a while though I found that there are things I wanted to make that I couldn’t find a design for, so I started to play with TinkerCAD which is an online 3D designer that is pretty easy to use.

One thing I wanted to do was to make payloads easier to build, plus be more resilient and re-usable. So I set about designing tracker holders that incorporate an aerial with holes above and below for easy connection to the parachute above and another payload below. My printer has a print base of about 26 x 26cm, meaning I had to print in 2 parts so I made separate designs for the tracker holder the aerial, with mating surfaces that can be glued or screwed together. Here’s the holder for FlexTrak:

https://www.tinkercad.com/embed/ev7vAJZy4QG?editbtn=1

Note the ring at the top to connect to the payload train, the holes for screwing on the tracker, the indented strip for where the GPIO pins go, the hole at the bottom for the radio aerial connector and the hole at the back for the Pi camera cable to exit.

This is the 434MHz aerial for FlexTrak:

https://www.tinkercad.com/things/jCZYnFBzhaU-aerial434ft

Note the hole for the SMA socket, the grooves for the aerial wires, and the hole for mounting a payload below. The latter avoids the usual problem of the hanging cord fouling the aerial.

To complete the aerial, insert an SMA chassis plug in the hole, with the plug side above and the solder pin below. Solder solid wire to the pin, cut at a total of 164mm, run it along the centre groove and fix with superglue. Similarly, solder 2 wires to the ground connection and run along the horizontal radial groves. The aerial can then be fitted to the assembled tracker. I found that the SMA connection was solid enough but you can screw or glue (superglue or hotmelt) the mating surfaces together if you wish.

To complete the tracker glue a battery pack to the rear of the frame, connect a camera to the Pi, and mount the lot in some expanded polystyrene foam:

Image

Flight Planning

I didn’t announce the flight as it was planned to be a short flight with a small balloon landing locally. However the predictions showed that the landing area with a small balloon was the other side of the a motorway, and the only way I could keep the flight away from local towns and motorways was to send it up quite high where it would be taken west into a very rural area.

Going high means using a large balloon and a light payload. I was hoping to test a second tracker but doing so would mean using a rather larger balloon, so I left that for another day. I settled on a 1000g balloon. Here’s my launch data sheet:

I also checked the changing flight profiles during the day, and opted for a 3pm launch to land in the best area.

What I didn’t take into account, but should have, was that hydrogen flights don’t have a constant ascent rate. The prediction software works best for helium which does, but for hydrogen the initial ascent is slower and the later ascent faster than the prediction assumes. For my flight, that meant more time going east and less time higher up going west, so the eventual landing spot was well east of prediction. The landing area was still safe, as I’d built in a large margin as we should always do, but it meant landing in an area with quite a lot of trees!

Flight Check List

For those new to HAB, it might be worth me going through my usual launch procedure for my solo launches. For those launching with a team, many of these tasks can be done in parallel.

  • Final check on predictions (worth doing as the prediction data updates every 6 hours and it’s best to use the latest data). From this I would hope to confirm my choice of balloon and gas fill. Most launchers will only have the one balloon and parachute, but even then you can modify the flight profile by adjusting the amount of gas, or even adding ballast or “reefing” the parachute to make it fall a bit faster.
  • Fill a water bottle (I use empty/cleaned milk bottles as they have a useful handle for attaching cable ties to) according to the weight you calculated (see my sheet above for an example).
  • Set out the launch area. Be aware of where the wind is coming from so you can have that behind you while you are filling (so the balloon doesn’t want to hit you in the face). Lay out the ground sheet, with a weight or peg at each corner if needed. Have the gas cylinder to your right (if you are right-handed) and a box with duct tape, cable ties, scissors and wire cutters to your left. Connect the balloon filler to the cylinder, and cable-tie the water bottle to the filler. My filling arrangement is unusual as I use the cylinder valve to regulate flow, but everyone else can open the cylinder valve at this point (and use the filler valve to start/stop flow later).
  • Connect the payload(s) and parachute together with cord. I use 10 metres from payload to parachute, and 5 metres from there to the balloon. Place the balloon end of the cord to your left, and place the payload on a table or bench.
  • Start up all the receivers. I generally use one receiver at home, and 2 or 3 in the chase car, but 1 at each location is enough. My car has a secondary battery for the HAB receivers and a 4G router, so I can leave everything running for many hours without the engine running. For most people they will use a laptop so ensure the laptop is charged, and take a 12V charger for it, or a mains charger and inverter.
  • Start the tracker(s). Ensure that all receivers are receiving OK, and are uploading to habhub. Check that the tracker(s) have GPS lock, and that they all appear on the habhub map. Close the tracker payloads.
  • If you have any other payload electronics e.g. a camera start it now if it has enough battery power for the launch preparations (30 minutes at this point) and flight. If not, delay the camera startup and payload closure till the balloon is ready to launch.
  • Fill the balloon till it can just lift the water bottle, without wind assistance off the ground and keep it aloft. If it falls back to the ground then add more gas. Once it can keep the bottle off the ground, maybe with a slight ascent, the fill is complete.
  • Fit 2 cable ties to the neck.
  • Tie the payload cord to the neck.
  • Stand or sit on the cord. Carefully remove the balloon neck from the filler, keeping a tight hold of the balloon.
  • This is the first bit where it’s handy to have a helper, though it’s certainly possible to do solo. Fold over the balloon neck so it’s covering the 2 cable ties. Add a tie around the fold. Add a second, then wrap with duct tape.
  • If it’s at all windy, or you have a heavy payload, wear strong gloves for the launch. The pull of the balloon – from lift and wind – can easily cause the cord to cut through your skin.
  • This is also easier with a helper – I have to carry the balloon from the filling area in my garden into the adjacent field. Everything has to be carried – payload, parachute and cord – off the ground otherwise the cord will snag and you will spend the next 10 minutes untying the inevitable knots. As we had to do when my helper didn’t understand my request!
  • Slowly allow the balloon to rise by tightly holding the cord and swapping the cord between your hands. As you do so, check that the parachute is the right way up (!!) and continue till you have the payload just below your hands.
  • Check the sky for any aircraft that that are flying past – usually because the pilot saw your NOTAM and thought they’d come along and watch – and launch if safe to do so.

My launch site is doesn’t have a nearby airport, so I have no need to call Air Traffic Control, but if yours does then your launch permission will state that you must call ATC before launch, typically 15 minutes before, so add that into your checklist at an appropriate point.

The Launch

Aside from the delay untying the aforementioned and unintended knotting, the launch process went smoothly and easily. I then watched the flight online and with my HAB Base program, with the latter being fed from my home receiver (a LoRa Gateway with aerial in the loft). All home and car receivers were feeding habhub and I noticed how much better my car receivers were doing, probably because of the lack of house roof in the way. I do have other receivers available, in my HAB shack and mountable on a 12m telescopic pole, but even the loft aerial managed to locate the flight down to an altitude of 2,200 metres which is pretty good considering the flight was the opposite side of the hill that my house is on.

The flight was predicted to land about 40 minutes away, which is approximately the descent time from burst, so we started chasing shortly before the predicted burst so we could hopefully get to the landing area before the flight landed. The burst altitude was calculated to be 36km, and the balloon actually gave way at 36.6km. Often these Hwoyee balloons manage about 2km above prediction but that’s not always the case and this balloon was 3 years old. Anyway, I’d planned the flight for a range between 36 and 38km this was inside my planning.

We saw a slight difference between the on-board landing prediction and the online one, and as the flight descended the two moved towards each other. The online one was initially closest to the final position which is to be expected but both were plenty good enough to aim for in the car.

We aimed for the closest road to the prediction, and got there a couple of minutes before landing, but with trees limiting our view we didn’t see the flight descending. We did however continue to receive telemetry so we had our landing position. Putting the map into satellite view we could see that the flight had avoided all the trees and found a nice field to land in. Excellent!

The next step was to find a route to the payload. Although we were less than 500 metres away, there was no path available so we checked ordnance survey mapping and found a public footpath that got close to the payload and was accessible from a road the other side of the payload. So we had to drive away from and around the landing position – which may have looked odd to anyone watching our progress online – to get to the footpath.

As we got close we spoke to some locals who said that they were walking that way anyway, so just follow, which we did …

We left the car by the road next to the footpath, and set out on foot …

As I said, we had to drive the long way round to make the on-foot part feasible, so here’s our path in red from the point where we were waiting when the balloon landed, to the footpath by road then by foot out to the payload:

We saw the bright parachute easily and walked across the grass field to collect it:

And to show how close this was to trees …

Finally, here are some photos from the camera. Clearly (or otherwise) the focus was set too short; it had been set up but it is easy to knock out of focus and that’s what happened. Next time, glue! Here’s my Star Trek Tricorder receiving telemetry from the tracker:

Raspad 3 HAB Receiver

As you may know, several years ago I built a portable HAB receiver based on the Raspberry Pi, with a Star Trek LCARS user interface written in Python. It works well enough and I’ve not revisited the project since then.

Instead I developed mobile apps for Android and iOS, to run on phones and tablets, all written in Delphi which is an IDE and language for developing cross-platform applications Of course phones and tablets cannot receive balloon telemetry directly, so they need to be connected to a separate receiver via USB or Bluetooth or WiFi, and those apps support those connections.

Although Delphi can target Linux, that support is currently only for Intel, so Delphi could not be used to target the Raspberry Pi running Pi OS. However TMS who are probably the major supplier of 3rd party Delphi components have a product called TMS Web Core which can be used to develop Web apps, to run on pretty much any browser. Web apps cannot access hardware directly, however Web Core includes a product called Miletus which embeds a web app within a binary executable that can target, amongst other things, Raspberry Pi OS. Further, such an app can then access hardware on the Pi – GPIO, serial, SPI and I2C are all supported – making it possible to develop a HAB receiver for the Pi in Delphi code. I developed such a receiver earlier this year and presented on it in this webinar:

Raspad 3

Initially I ran this app on a Pi 4 in a small plastic case with the official Pi touchscreen. For GPS I used a GPS HAT, and for LoRa I used a LoRa HAT, all from Uputronics.

I then wondered if anyone sells a Raspberry Pi tablet where I could add these components internally. There are some tablets available, but the only one that was currently available, and which seemed to have enough internal space, was the Raspad 3. So I ordered one from Amazon and next day it arrived.

It didn’t take long to install my software (see later for instructions) and get it working. However the internal space is quite limited, and there’s only space for a single HAT. I do have a combined GPS/LoRa HAT, however it uses SPI channel 1 which is already used by the Raspad 3’s internal board (used for power, fan control, and repeating the Pi ports). I didn’t see anything in the documentation about the use of SPI, however I doubt that many people try to add a HAT especially as it blocks air from the internal fan!

Fortunately, I had other options, namely USB. All of the Pi’s 4 USB ports are free to use, so I connected a USB GPS to one and an Uputronics USB LoRa receiver to the other. This did require some software changes, firstly to allow for a choice of GPS device, and secondly to support the LoRa receiver’s serial protocol, but I had code for that already from my Android/iOS apps.

I tried with the GPS internally, but it did make it difficult to pick up satellites, so I opted for a stick-on external GPS which I mounted on the top of the tablet, with the LoRa UHF antenna socket on the left. I think it looks pretty good.

Construction

Raspad 3 is supplied with cables etc. but without a Pi 4, so install that as per the instructions.

This bit is up to you, but I found the fan to be very noisy. It’s not so much the fan itself, but the fact that its mounted on the back of the tablet which behaves as a large sounding board, amplifying the noise from hardly audible to quite annoying. I removed the fan. My application uses little CPU and I saw temperatures around 50°C, way below the 80°C where the Pi slows down. Your Mileage May Vary.

Software Installation

For the latest instructions, see https://github.com/daveake/PiPADD. However note that since we aren’t using the Pi internal serial port, you don’t need to follow the instructions to free that up. The latest release binaries are in the releases section https://github.com/daveake/PiPADD/releases.

USB GPS

For the GPS you will need one that is designed for sticking to as surface and has a sticky pad. The cable it comes with will be much too long, and besides we need to find a way to feed the USB cable through to the inside of the case, so you will need to cut the cable, insert it through a small hole drilled in the top of the case:

Small hole in case

Finally, solder the cable back together (but much shorter than before). Use heat-shrink tubing on the individual wires, then re-cover with the existing screening before covering with more heat-shrink tubing.

LoRa Antenna Socket

Use a short adapter cable SMA male at one end and SMA female at the other. Drill a hole in the case and fit the female connector through it:

You should now have 2 cables fitted, looking like this:

USB Receiver

This is supplied in a case, but there’s no space for that so remove the 2 screws from the case, separate the 2 halves and remove the board from inside.

The board can now be fixed inside. I find the best place to be on top of the connector that plug into the Pi. you could instead place above the Pi but it will partially block air from the fan (if you fit that), and you’ll need to take care not to foul the fan. I think the connector option is best. Use a double-sided pad or hot-melt glue.

I mounted mine upside-down because that suited the best USB cable that I had.

Connect the USB cable, running it as neatly as you can round to one of the free USB sockets on the Pi.

Next, connect the GPS to another space USB socket, and connect the antenna cable to the SMA socket on the LoRa receiver.

Finally, slowly close down the back of the case, ensuring that the cables don’t prevent the case from closing. So long as your cables are fairly short then this should be easy enough.

Configuration

Again, see the github repository for the latest full information, but remember that we are configuring two USB serial devices and not the LoRa HAT, so ignore the section on the latter.

GPS Setting

You will need to set the Linux device name for the GPS device. To find the name, open a command terminal and type the following:

ls /dev/tty*

You will see plenty of entries such as tty19, which you can ignore. The interesting ones are here:

If you see ttyACM0 and ttyACM1, then one is GPS and the other LoRa. In my case the allocation was:

  • LoRa = /dev/ttyACM0
  • GPS = /dev/ttyACM1

If instead you don’t see ttyACM1, but do see ttyUSB0, then that is the GPS.

So, armed with this information, enter “/dev/ttyACM1” or “/dev/ttyUSB0” in the “Device” box on the GPS settings page.

LoRa USB Setting

Similarly, the LoRa USB settings page has a Device box, and this time you should enter “/dev/ttyUSB0”.

Close and restart the program once you have entered the GPS and LoRa device settings.

4G (LTE) and Rural Broadband

This isn’t my usual type of blog post, but if you’re frustrated with slow and/or unreliable broadband, you might find my experience interesting and useful. With a lot of research, learning and testing, we’ve gone from a feeble 12Mbps down / 1Mbps up broadband to around 200Mbps down 70Mbps. How? Read on ….

A Bit Of History

When we moved to Herefordshire 8 years ago, the fastest internet we could reasonably get was around 7Mbps down 0.3 Mbps up, on a copper line to the local exchange. Good enough for browsing or watching iPlayer, it was dire for sending files to customers or uploading to YouTube, for example. So when FTTC (Fibre To The Cabinet) was offered, I got excited. Briefly. Because the C (Cabinet) was about 10 metres from the exchange, and thus about 2.5km from us. So 7/0.3 went to 8/1. Whoopdedoo. Still, when you’re sending files to a customer, a 3x increase in speed is worthwhile.

I knew when we moved that we had a fairly good 4G signal here, if only at one side of the house which faces the local town which is where pretty much all of the reachable phone masts are located. However it took several years before the mobile phone companies caught up with the need for 4G as a home broadband option, and started to provide plans that made financial sense instead of being around £1 per GB. EE were first with, if I remember correctly, £80 per month for 200GB, but after a short flirtation with them I switched to Three who offered unlimited data for about a third of the price. I had an external aerial installed, pointing towards town and the masts, connected through 5m of twin coax to a Huawei B525 router in the house. That worked pretty well, with some outages, at speeds of approx 30Mbps down and 20Mbps up, for a couple of years.

SlowerShire

“FasterShire” has existed for about 6 years now, with the intention of getting fast internet across Herefordshire and Gloucestershire. We’ve had various promises from them as to when “work will start in your area” to get FTTP (Fibre To The Premises) and gigabit bandwidth, but all have come and gone. The latest was last month, stating that our house – and a lot of others according to the planning map – are no longer part of the Fastershire contract with Gigaclear. Apparently the costs of reaching these far-flung places (we’re 5km from the nearby town) are too high for the contractors to reach as they were contracted to do. When we’ll finally get fibre is anyone’s guess.

Still, we have 4G …

When Three is less than 4(G)

Then it broke. Three had sent me a text saying that they were going to work on the mast, so I wasn’t surprised when the signal dropped out a few times, and ran slowly between, for a few hours. But the speed never returned to previous levels, settling at around 12Mbps down 1Mbps up.

It stayed that way for a couple of days so I contacted Three. After the usual “you’re near the edge of coverage” “yes I know but I have an external aerial and it’s been fine for years”, they said that the work was still in progress so try again the next day.

Still slow.

So I complained again. My ticket got raised to “2nd level” support, who called me in the evening. “Let me do a network check”. That was just an excuse to bring up the usual “you’re near the edge of coverage” nonsense. Yes, I know. I also know where the mast is, and that I have clear line of sight to it, and the signal itself is still strong it’s the bandwidth that’s shite. The call ended with the suggestion to “try again in a couple of days, and cancel your contract if it’s still slow”.

It was, and I did.

ISP Testing

I already had an EE SIM card that I use for internet in my HAB chase car, so I put that in my router to compare with the Three bandwidths. It was, despite connecting to the same mast, much faster. Faster in fact than Three on a good day. I also tested with my wife’s O2 SIM card, and a Vodafone SIM card purchased on Amazon, and EE was the fastest of all especially for uploads. My EE SIM card though is a pre-paid 100GB/1 year card, which is great for use in the car and as a backup, but would last about a week in the home router! So I signed up for a 12-month “all you can eat” contract with EE and switched to that SIM card when it arrived.

Which Mastest is Fastest?

In my ISP testing I started to learn about 4G and how to get the most from it. Finding the closest mast, or even the mast with the best signal, will not necessarily get you the fastest speed. Masts are not all equal.

First, if you have a Huawei router, and you want to optimise your connection, download a copy of LTE H-Monitor, which is a great utility for monitoring your connection, and configuring your router’s modem.

As well as the pretty graphs so you can see activity, it shows which mast you are connected to, which cell on that mast, and which 4G band you are connected on. For more information, click the “Find Cell” button, choose the “CellMapper” option, and you will see a map with that particular mast displayed. Click on the mast to see the coverage plots:

As I understand it, these plots are from data that has been crowd-sourced from a mobile phone app, and don’t reflect the range achievable with routers equipped directional antennae.

Clicking on one of the plots shows the cell data, including the direction in which the mast antenna for that cell is pointing, which 4G band it uses, and what the bandwidth is. Different ISPs have a different set of bands to choose from, and in my area Three use bands 3 and 20, EE use bands 1, 3 and 20, and Vodafone use 1, 7 and 20. It’s interesting to use the search function on the map to see which operators have masts near you, and what bands they offer.

Band 20 is on a lower frequency than the others – around 900MHz vs 1.8-2.6GHz – so has the advantage of travelling further but with less bandwidth. So if you find that you have a good signal on a 4G device, but poor download/upload speeds, it’s quite likely that your device has connected to a band 20 mast. For mobile phones it’s a good thing to have a band like this – slower but more likely to get a signal – but for a fixed router it’s not the best option.

Generally it’s up to your 4G device to decide which mast/cell to connect to, but depending on your device this can be overridden. For phones there are some apps to select the band; for routers there is often a band setting in the configuration. For some routers there is even the option of selecting a particular mast. For my Huawei routers, the web dashboard has a band setting or, for more flexibility, I can use LTE H-Monitor:

On EE, I get the fastest connection from the closest mast however that is not the one that is always chosen by the router. However, it is the only mast that offers band 1, so by choosing band 1 for the upload band, my router will connect to that mast. But is band 1 the fastest band?

Battle Of The Bands

In my closest, best mast, I have a choice of the following bands 1, 3 and 20. I’ve found that for fast uploads I need to be connected to band 3 on that mast, but the small problem here is that other masts also offer band 3, so there’s a chance of connecting to one of those instead. However I’ve found that my router seems to give priority to whichever mast it connected to before, so if I select band 1, it connects to band 1 on that mast (the only nearby mast with band 1), then I select band 3 and it will connect to band 3 on that mast.

You may have noticed that more than one band can be selected for download, which is because the router supports downloading from 2 bands at once.

The CellMapper site gives information on all the cells and bands available on each mast, including approximate antennae directions and radio bandwidths. I’ve found though that having a wider bandwidth doesn’t necessarily mean faster uploads or downloads, because of course there are other users so you don’t (unless it’s 2 in the morning) have the entire bandwidth to yourself. So finding the cell(s) that give you the best throughput is trial and error, and having a tool such as LTE-H-Monitor means you can easily try different bands and use speedtest or similar to test the speed.

Which Route(r) To Take

For my initial tests I had my old faithful Huawei B525 router, but once I’d got the “how fast can I get this to go?” bit in my teeth, I wondered about upgrading. The B525 is a CAT6 device, which is old tech compared to the modems inside current routers. The latest routers boast much much higher maximum speeds than the old ones, however they can only go as fast as the kit inside the mast allows. Getting that information about the masts seems to be next to impossible, so I bought the flagship Huawei B818 4G router from Amazon,

Huawei B818-263 5G Router | Huawei B818 5G LTE Cat19 Gigabit CPE Specs

plugged it in and …. wow! Speeds of up to about 150MBps down, more than twice as fast as my old router. Positioning however was critical – I could either get fast downloads or fast uploads, but never both, and connecting my external aerial didn’t get me fast uploads (more important than downloads for me).

Which Way Should It Be Poynting?

So the next step-of-unexpected-expense was to get a better antenna. I’m pretty sure that the old EE-supplied antenna isn’t directional, so I scoured for advice and tech specs online and found the Poynting 5G/4G directional antenna which is both slightly higher gain than their 4G model, and by supporting 5G frequencies means it won’t need replacement if 5G ever arrives.

So, the antenna arrived, I put it up on a tripod near where it would be wall-mounted, connected to the router and thence to a laptop in my shed via a long CAT6 cable, and got this …

Image

That’s some improvement over the B818 on its own, which itself was an improvement over the B525, which with EE was an improvement on Three.

So now I had a more than reasonable 4G connection, but what if it stops? All providers have periods of local and even national downtime, and as I work from home and am online pretty every waking hour (OK, every waking hour) then this is a vital utility. As vital as electricity in fact, nd I have UPSs on my PC, servers and router, so what can I do to backup the 4G connection?

Another 4G connection.

Load Balancing

To backup one 4G provider, I needed to choose another (but not Three!!) so I checked for speeds with local masts again, and opted for Vodafone as they provide download speeds nearly as fast as EE, though slower uploads as the mast is further away. This was with my old antenna, I suspect that getting a second directional antenna will help, but I’ll leave that to another time. Vodafone offer an unlimited data plan, so I purchased that and set up that up in a B535 router connected to my old antenna.

But having 2 separate 4G connections to 2 separate ISPs via 2 separate routers means 2 separate networks. How to connect them together so that, if one ISP fails then traffic is automatically sent to the other?

Enter the Load Balancing Router. Specifically, the Draytek Vigor 2925:

Vigor2925 Series | DrayTek

I’d seen this recommended online – especially the ispreview.co.uk forum – and it’s a very solid load balancing / failover router. It has 2 WAN ports and can also use 4G USB modems but I didn’t bother with those. I paid £75 for mine on ebay. There are other makes and models of course, but I’ve used Draytek routers before and what they lack in user interface design they more than make up for with solidity and flexibility. Kit to rely on, for sure.

And for this application, setup was a breeze. In fact it didn’t need any – connect the 4G routers to the WAN ports, connect my LAN to one of the LAN ports, and that was that. Dual 4G load balancing with failover. The only setup I needed to do was to first set each 4G router to a unique IP address outside my usual range. So I have:

  • EE router on 192.168.3.1
  • Vodafone router on 192.168.4.1
  • Draytek router on 192.168.1.1

The 4G routers each deliver DHCP addresses, which the Draytek picks up to set its own addresses on the WAN ports, like this:

The Draytek routes to those addresses from LAN to WANs, so I can still access the router web pages as before, just using those new IP addresses, and I can set separate copies of LTE H-Monitor to monitor each 4G router separately:

So now, if an ISP drops out, the other will keep me connected. And if (as happened this morning when my local EE mast had an issue) if one ISP is slower, it won’t affect the other.

It’s been interesting to watch how the Draytek splits traffic between the two providers. There are lots of options here, and all I’ve done is select the recommended “session based” rather than “IP based” so that each connection is sent to whichever the router deems best. If I play a YouTube video, I can see the download blips on one of the routers, then if I play another that will appear on the other router. It’s all very slick and seamless. In fact the only issue I’ve seen is that the cPanel interface for my shared internet server complains that my IP address changes after login! Easily fixed by telling the Draytek to only use one WAN channel for that particular web domain. Otherwise, everything seems to work – internet telephony, Alexa, iPlayer, YouTube, my weather station and smart heating system – they all just keep working as they did before.

One thing to note is that this is load balancing and not bonding, so any single internet connection hits the internet through one 4G router or the other, and not both. So if you download a file using software that uses a single download connection, that will go through one WAN only, and not necessarily the fastest one (though you could force it to a desired WAN through a routing rule in the load balancer). However, multi-connection downloads will hit both WANs at full speed, like this:

And here are the upload (green) and download (red) graphs, for EE (left) and Vodafone (right). You can see that the download speeds here are similar, but EE (much stronger signal) is much faster for uploads. Also note that speeds do vary considerably during the day, and I’ve seen close to 300Mbps combined download.

Mini GPS Clock

Something I use more often in my HAB trackers these days is TDM – Time Division Multiplexing – where instead of transmitting continuously, each tracker transmits only during particular time slots. Since trackers always have a GPS receiver, this just requires software to sync the transmissions with GPS time. The advantage vs continuous transmission is that multiple trackers can share the same frequency, meaning that several trackers can be received by each receiver.

Once when I did this, I noticed that two trackers seemed to be using different times. The problem was that one tracker was using UTC, as sent by the GPS module in NMEA messages such as $GPGGA, but the other tracker was using GPS time from a UBlox UBX binary message. UTC is currently 18 seconds behind GPS time, and is sometimes adjusted with the addition of leap seconds to match the rotation of the Earth; GPS time is not adjusted. I adjusted my UBX tracker to match UTC time.

To make it easier for me to test that TDM trackers are transmitting at the correct time, I thought of having a small GPS clock on my desk. There are other uses of course, so it would be a useful thing to have. I thought I’d be able to find something ready made but couldn’t, so I decided to make one.

Thingiverse

When I bought my 3D printer, I wondered how much I would actually use it. That was a couple of years ago and I’ve found that it’s been much more useful than I thought, from making coasters, little cats for my wife, phone holders, and more recently cases for electronics projects. There are some online repositories for designs that can just be downloaded, converted to printer files, and then loaded onto the printer. So I searched the Thingiverse site and found this little housing for a 1.3″ OLED display which I thought would be about the right size for a little clock, with enough space to include a GPS receiver:

The design comes as 2 files, one for the case and one for the base. So I downloaded both into Cura, converted them into print files for my 3D printer, and sent them to the printer.

3D Printing

My printer is a Geeetech A10M which I bought because of its dual print head, meaning that it can make models that either mix 2 colours, or are partly made in one colour and partly the other. It turned out not to be a great decision, because that mixing head was more trouble than it was worth – the convoluted path and non-return valves necessary for such a design cause the head to jam up more frequently than a much simpler non-mixing head. So I’ve swapped out my mixing head for a non-mixing one.

My printer generally stays in my work shed, so rather than take print files to it on an SD card, I have the printer controlled from a Raspberry Pi 4B running OctoPi. I can then send print jobs to it via the web interface, and monitor the print throughout.

Since prints can sometimes fail – if the print base plate isn’t properly levelled then the print can be a ball of string in the air, or I’ve had the reel of filament jam – then it’s good to have a view of the printer in action. I’ll probably add a Pi camera for that, but for now I use a Reolink pan/tilt/zoom camera connected to the WLAN in the shed.

Finally, so I don’t have to go down to the shed to power the printer and Pi up, they are powered through a TP-Link Kasa “smart plug”. These are great, and I have several around the house for things that aren’t used often and would have a significant cost of powered when not in use. I can switch any of these on or off, and even monitor power consumption on some of them, via a phone app.

Electronics

The case that I printed houses a 1.3″ OLED, so I ordered one of those from Amazon for next day delivery. The case was also designed for a particular CPU board, but I have plenty that will do the job for my application, including an AVR 32u4 board that is small enough to fit in the case, and has USB power already. Finally, I removed a GPS module from an old unused tracker. The connections are straightforward:

  • GND from AVR to GPS and OLED
  • 3V3 from AVR to GPS and OLED
  • SDA from AVR to OLED
  • SCL from AVR to OLED
  • Rx from AVR to GPS Tx

I didn’t connect the AVR Tx to GPS Rx as I don’t need to send anything to the GPS – it certainly doesn’t need to be put into flight mode!

Software

The case is intended for use as a status display for OctoPrint, for which all the source code is available. I might even make one the same to monitor my own prints! For this project though, I just need to scrap together some GPS and OLED code from my own tracker source.

You can download the code from here. It’s pretty simple:

  • At startup it sets up the OLED
  • At startup it draws the display, with zero time of course
  • Main loop checks for GPS data
  • Incoming GPS data is split into lines
  • Lines are checked to confirm checksum OK
  • GPGGA lines are parsed; others ignored
  • Time and number of sats are extracted from GPGGA message
  • Once a new GPGGA message has been received, the display is updated
  • Display shows time in a large font, plus a bargraph showing number of satellites.

One point to note is that the OLED mounts upside-down in the case, so the software rotates the display to suit.

Build

This part is very easy, as the 3D model takes care of the case and OLED of course.

The case does have a slot for the intended CPU board, but mine was smaller so I just used a hot-melt glue gun to mount it on the base of the case. The GPS was then mounted just above, with coax connecting it to an SMA socket mounted on the back of the case.

The Result

And on my desk …

HAB Base Update V1.4.0

I’ve released a new version of HAB Basem which is intended for easy management of one or more receivers from a Windows PC.

The changes are:

  • Support for Sondehub import via UDP
  • Support for local Sonde data from a rdzTTGOSonde receiver via UDP
  • Map shows the predicted path and landing point of the balloon
  • Balloon burst altitude can be set for the prediction
  • UI changes to fix issues on high-DPI monitors and other systems where Windows has a font stretch factor set to other than 100%.
  • The APRS source can also be used for OGN (Open Glider Network)
  • Fixed error when removing old payloads
  • Settings window for serial sources shows the list of COM ports to choose from
  • Payloads can be removed from the list and map, either till the next telemetry from that payload, or blocked while the program is running.

Download the installer from here.

rdzTTGOSonde

This is receiver for radiosondes, running on a TTGO ESP32/LoRa board with OLED. It emits position packets using UDP on the wireless network to which it is connected. HAB Explora, PADD and Base can all now decode these packets.

To configure:

  • In Settings –> Other, set the UDP Rx port to whatever you like (I use 12004 which is one of a set that I have reserved for HAB use on my networks, but you can use whatever works for you)
  • In the rdzTTGOSonde configuration, set the UDP transmit port to match above (see screenshot below).
  • In the rdzTTGOSonde configuration, set the UDP transmit IP address to either the known IP address of the device running HAB Explora/PADD or, better, use the UDP broadcast value for the local network. For the latter, use the IP address by taking the local subnet value and set all 1’s in the host portion. For example, if a device has an address 192.168.1.156 and a subnet mask 255.255.255.0, then the broadcast address is 192.168.1.255.

These are the settings in the rdzTTGSonde configuration page:

Flight Prediction

For payloads that do not include their own predicted landing position, HAB Base now refers to the online Tawhiri predictor to calculate not only the predicted landing position but also the flight path.

For payloads that are still ascending, the program initially assumes a burst altitude of 30km however this can be adjusted by opening the payload window and choosing the “Settings” tab:

OGN

This is a system used by gliders and other light aircraft, being broadly equivalent to the ADS-B system but at a much lower cost. OGN receivers upload to a server which HAB Base can now receive from. The received packets are in APRS format so to receive them you should create a new APRS Source within HAB Base, and set the host to aprs.glidernet.org:

To configure:

  • Click the “…” button next to an existing source
  • Choose “Add New Source” from the menu
  • Choose APRS/OGN from the “type of new source” list
  • Fill in the code and name as normal
  • Set the host box to be aprs.glidernet.org
  • Leave the port as 14580

Sondehub

If you previously used HAB Base to monitor radiosondes, you noticed a while ago that this stopped working. This is due to the sondehub system being separated from habhub. Sondehub has its own http and websocket APIs, different to habhub.

To import from sondehub to HAB Base, you need a Linux or Windows machine with Python 3 and Pip3 installed, onto which you run a small Python script to import filtered telemetry from sondehub and emit locally via UDP.

The following steps are for Raspberry Pi OS:

sudo pip3 install paho-mqtt
sudo pip3 install boto3
git clone https://github.com/projecthorus/pysondehub.git
cd pysondehub
wget hab.daveakerman.com/files/SondehubToUDP.py

Then to run the script, enter a command of the format:

python3 SondehubToUDP.py <latitude> <longitude> <max_distance_in_km> <target IP address> <port>

You can use these parameters to select a central point (e.g. your location) and the radius of a circle around it, so that the script only emits positions of radiosondes that are within that circle.

The “target IP address” is that of your Windows PC that runs HAB Base.

“Port” can be any unused port number; I use the value 12013 which is part of a set that I reserve for HAB communications on my network.

Example:

python3 SondehubToUDP.py 51.95023 -2.54445 1000 192.168.1.172 12013

The script will display the telemetry for each position report that it receives from sondehub and which is within the circle defined.

Once this is running, open HAB Base and create a new Source. Select the source type as “UDP”, fill in the code and name as usual, and set the port to be the same value you used for the script earlier. e.g.:

Finally, click the Save button.

The new source will then run, e.g.:

Note: Remember that HAB Base has its own distance filter, which it applies to this source, and this would normally be set the same as the value used for the script.

UCS Flight – Video Streaming

This was a school flight, where they built the payload and did the launch, I supplied a self-contained radio tracker, and a 3rd party supplied 2 rugged mobile phones to take video during the flight. It gave me a chance to test a live streaming setup that I intend to use on all of my flights from my launch site.

Since the school’s payload weight was already about right for the parachute size, I decided to use a lightweight tracker in a small foam egg. Based on a small AVR, it doesn’t include landing prediction but is a reliable basic LoRa tracker. I set it to mode 1 with a packet sent every 5 seconds, and I enabled calling mode so that receivers could be set to the calling channel.

Live Streaming

I’ve streamed video from the launch site before, but that has been either directly from a Raspberry Pi with a camera (using ffmpeg to stream to YouTube) or with a camcorder connected to a video capture device connected to a laptop.

For this flight I tested a new, more flexible setup. I used the popular and free OBS (Open Broadcaster Software) which is an incredibly capable program for combining various video and other sources into a single video screen which it can record locally and/or stream to various online services, including YouTube.

The basis of my stream was an IP camera in my garden, looking over the area I use for filling the balloon. All that needed to be done was to find the URL for the camera video stream, and enter that as a video source in OBS.

Next I wanted to add telemetry from my tracker. I now run my own internet server which runs a program that collects balloon telemetry from various sources, including my LoRa receivers at home. So I needed a way of displaying this telemetry as a text overlay on top of the IP camera video. One of the OBS options is to feed the contents of any program window into the output video stream, so I wrote a small program to collect the telemetry from my server, write that as text on a green background, add this program as a video source into OBS, and finally add a ChromaKey filter within OBS that removes the green background.

I also wanted to add data from my weather station. That station automatically uploads to various services every few seconds, including Wunderground which has an API for getting the current data from any station. So I added some code to my internet server that polls Wunderground for this data every few seconds, and then sends it my overlay program. This is how the ChromaKey works:

Image

Finally, I added the school’s logo as a fixed transparent bitmap, and set OBS to stream to my YouTube channel. Here’s the resulting stream, just before launch:

The Launch

Predictions for the flight were fairly stable, with the landing position moving steadily SE during the day. The launch was a bit later than planned so it did land further SE than planned, but more on that later.

DCIM\100MEDIA\DJI_0009.JPG

The day itself was very hot, during a week-long UK heatwave with daily temperatures up to 30 degrees C. So hot in fact that the mobile phones used for flight overheated when still on the ground! They were cooled prior to launch by dipping them in a tub of water (I told you they were rugged!).

Here are the team, posing with probably the largest helium balloon they’ve ever seen!

Launch was easy enough, though the excited schoolkids launched the balloon before I’d had a chance to get my drone ready to record the launch; I’m hoping to record or possibly stream drone footage on my next flight. So here instead is the launch captured by my field time-lapse camera:

The Flight

The flight proceeded pretty much as expected, however a combination of factors meant that it landed further south than planned, which could have been unfortunate as that took it into the Forest of Dean. Why are balloons magnetically attracted to trees?? Those factors were that after the initial ascent rate being the planned 5-5.5m/s, the ascent slowed once it entered the stratosphere, resulting in it spending longer in a south-westerly direction.

Later, heading west, it ascended almost 3km above the prediction, bringing it further west. So the net shift was a shift south-west from the planned landing near Longhope:

Note the large expanse of green in that map. And note the high density of (very tall) trees that it successfully managed to avoid by landing in a clearing!

Recovery

We were about 2 miles away in out chase car when it landed, without a radio signal from the tracker due to a hill in the way. After stopping to check the landing position and the route, we approached along that road you can see near the landing spot, turned into the drive and called the other chase cars. At that time I spotted the parachute in the field (see arrow at the right of the image):

Once permission was obtained from the landowner, the team walked across the field to recover their precious payload!

And here they are, checking the footage that they got from their 2 phones – one with a regular camera and the other with an infra-red camera:

Finally, if you want to watch any of the launch stream, it’s here:

Receiving From LoRa High Altitude Balloons

Many high altitude balloons these days use LoRa, because it’s simple and inexpensive to use in the balloon and in the receiver, and because it offers extra features such as uplinks that are difficult to do otherwise.

For other systems such as RTTY and APRS, the receiver can be a software defined radio (SDR) or a ham radio receiver. LoRa however is different, and requires a specific LoRa receiver.

Fortunately LoRa transceiver modules are cheap and easily available. Essentially, they just need connecting to a suitable computer which sets the frequency and some other parameters, connecting to a suitable antenna, then the module does all the hard work of receiving, demodulating and decoding the radio signal, delivery a packet (sequence of bytes) containing telemetry or imagery to the attached computer.

This article is about how to obtain or build such a receiver and what software to use with it.

Types Of Receiver

As explained, the LoRa module does all of the hard work, meaning that the attached computer can be quite simple. As simple in fact as a basic Arduino or similar microcontroller. Add some firmware and a small display, and you have something that can display the current position of the balloon. Add a GPS module and it can display the distance and direction to the balloon. What more could you need?

Well, you might want to see the balloon on a map. You might want to have on-screen and audio navigation to drive to the nearest road to the balloon.

Or you might be receiving from home, where you might want to manage multiple LoRa receivers so you can receive from multiple balloons. You also want to upload the telemetry and imagery to the online servers so th\at you can contribute to the tracking of someone else’s flight.

All of these are possible, using Arduno or ESP32 microcontroller, or Android phones or tablets, or a Windows PC. Below I describe the devices apps and programs that I have built and shared for you to use.

Standalone Arduino LCD Receiver

This is as simple as it gets – an Arduino Mini Pro connected to a good old text-mode 2-line LCD, with GPS for positioning and a Lipo for power, with USB charging. Simplicity is a good thing when chasing a balloon, and something like this will find your payload with very little fuss.

P1090766

That photo is from during the build, before it got an Apple-esque single pushbutton for all functions, including frequency selection.

For more information, see my blog article and the github repository.

I want you to take great care of this equipment, Mr Bond.

If the above is a bit too boxy for you, how about chasing a balloon with a watch?

Image

This is the TTGO TWatch2020, which doesn’t contain a LoRa module (their earlier but bulkier watch did), but does have bluetooth meaning it’s easy to link to a TTGO T-Beam which has LoRa, GPS, ESP32 processor and LiPo battery in one package. So the watch does the user interface stuff, allowing choice of frequency etc., and displaying the position of the balloon and the distance and direction to it, while the T-Beam (pictured in a 3D-printed box and attached to an aerial) does all the radio and GPS stuff.

See my blog post for details, plus the watch firmware and T-Beam firmware.

Raspberry Pi

Using a single or dual channel LoRa expansion board, it’s easy to build a LoRa receiver based on any Raspberry Pi (aside from the Pico). Uputronics sell a single or dual channel board for which I wrote the Pi LoRa Gateway program.

This is a popular choice for fixed receivers. The software is open source and provides the ability to tune in to, receive and upload both telemetry and images (SSDV). This is the oldest and most capable LoRa HAB receiver software available. Also, it can be linked to the HAB Base software below.

USB OTG Receiver

This is a commercial device that integrates a LoRa module with a pre-programmed microcontroller, for connection to an Arduino phone or tablet, or a PC, to provide a complete receiver setup including mapping and uploads to the central map and imaging servers.

The device is available from Uputronics, and by purchasing you are helping to fund development of the supporting software below:

  • HAB Explora for Android Phones
  • HAB PADD for Android Tablets
  • HAB Base for Windows PCs

HAB Explora

Currently this targets Android only; if you are an iOS user then please get in touch. Its aim in life is to make it easier to chase balloons, by showing the position on a map and by providing navigation via phone navigation app.

Data sources (i.e. sources of balloon telemetry/imagery) include the LoRaGo product above, plus a DIY solution using my firmware. The app is free to use, with funding for development coming from sales of LoRaGo and my BuyMeACoffee account.

HAB PADD

Currently this targets Android only; if you are an iOS user then please get in touch. Its aim in life is to make it easier to chase balloons, by showing the position on a map and by providing navigation via phone navigation app.

Data sources (i.e. sources of balloon telemetry/imagery) include the LoRaGo product above, a DIY solution using my firmware, UDP (e.g. from auto_rx for Sondes), and up to two LoRa Pi Gateways (see above). The app is free to use, with funding for development coming from sales of LoRaGo and my BuyMeACoffee account.

HAB Base

This is a Windows program designed to make it easy to manage one or more LoRa receivers at a base station. If you want to use LoRaGo with a PC, this is for you. If you want a nice GUI to manage your Pi LoRa Gateway, this is for you. If you want to centralise control of multiple LoRa receivers, this is definitely for you!

For more information. see this article.

Again, this is free software, so donations are welcomed !

Uplinks

Whilst most high altitude balloons only transmit data (telemetry and sometimes images) down to the ground, there are several applications for sending data to a balloon, for example:

  • Requesting re-send of missing image packets
  • Balloon repeating of other balloon telemetry
  • Commanded cutdowns etc.

My PITS software and LoRa gateway already provide the first option, and I’ve flown a balloon network before. What my released software has lacked up to now is the ability to upload commands. So now, after a lot of work on the various components, I am pleased to announce an uplink system that:

  • Can command a payload to cutdown, switch an output, control a servo or run a script
  • Works with various trackers: Pi In The Sky, FlexTrack (generic AVR and ESP32 tracker code) and FlexTrak (Pi Zero AVR tracker)
  • Works with various ground station software: Pi LoRa Gateway, HAB Explora, HAB PADD, HAB Base
  • Encrypts the radio link to protect the tracker against 3rd party attacks
  • Works with different radio timing schemes e.g. TDM

Commands

The commands implemented so far are:

  • Cutdown the flight now
  • Set cutdown altitude (tracker will cut down when this altitude is reached)
  • Set an output on
  • Set a servo to specified position
  • Run a named script or command

Not all of these are available in all trackers – for example scripting is only implemented on Pi In The Sky.

Timing

is everything.

Pretty obviously, each command has to be sent when the tracker is listening. So both the tracker and the ground transmitter have to use the same timing scheme so that the tracker listens at certain times and the transmitter only transmits during those times.

Where the tracker needs to transmit a lot – which basically means trackers that send image data as well as telemetry, then the recommended scheme is for the tracker to listen for a few seconds each minute. The transmitter then needs to be set to transmit at some point during the listening window. For example the tracker might listen from the 0s mark to 5 seconds past the minute, and the transmitter is then set to transmit beginning at the 2-second mark. Remember that packets take a finite time to transmit (around 1 second in LoRa mode 1) so be sure to arrange the timings to allow for that.

For trackers that only send telemetry, then a better scheme is to set the tracker in TDM (Time Division Multiplex) mode. This specifies a repeat period – say every 10 seconds – and a time slot within those 10 seconds at which the tracker transmits – say slot 5 which would be at 5, 15, 25, 35, 45 and 55 seconds past the minute. An advantage of this method is that you can have multiple trackers using the same frequency and same TDM period but each with a different slot. Remember that transmit times may preclude the use of adjacent slots. The ground transmitter can then be set to transmit at a certain time, or simply transmit immediately after it receives a packet from a balloon.

Tracker Configuration

Pi In The Sky

Timing Settings

If you are using SSDV, then use settings like these in pisky.txt:

LORA_Uplink_Cycle_1=60
LORA_Uplink_Period_1=5

This sets the tracker to listen for the first 5 seconds of each minute. Use “_1” for a module in CE1 position, or “_0” for CE0.

If you are not using SSDV, then set TDM mode instead:

LORA_Cycle_1=10
LORA_Slot_1=2

This example transmits packets once every 10 seconds, at 2, 12, 22 etc seconds past each minute.

Cutdown Settings

Cutdown needs to be configured, minimally with these settings:

Enable_Cutdown=Y
Cutdown_Period=5
Cutdown_Pin=22

Which enables cutdowns, sets the default cutdown period to 5 seconds, and uses Wiring Pi pin 22 for the cutdown output. The output would normally then connect to a power MOSFET gate which then applies external power to a length of nichrome wire or a small low-value resistor.

The Pi In The Sky software also provides settings for automatic cutdowns such as “above altitude of x metres” or “flights longer than y minutes”; see the source or await documentation on these and other options.

Encryption Password

Set this, and to something other than SECRET, or take the huge risk that someone else will deliberately upload commands to your tracker!

Uplink_Code=SECRET

Ground App Usage

HAB Explora

See my blog post on how to use uplinks from HAB Explora.

If you are using SSDV, then use the “Send on n’th second option”, and set the time to be just before the centre of the tracker’s listening window. e.g. 2 seconds for the settings above.

If you are using the TDM option, then use “Send After Rx” instead.

Don’t use “Send Now” for either option, unless you’re feeling brave.

HAB PADD

See my blog post on how to use uplinks from HAB Explora.

If you are using SSDV, and uploading from a USB or Bluetooth device, then use the “Send on n’th second option”, and set the time to be just before the centre of the tracker’s listening window. e.g. 2 seconds for the settings above.

If you are using the TDM option, and uploading from a USB or Bluetooth device, then use “Send After Rx” instead.

If you are uploading via a LoRa Gateway, then the timing is done by the gateway, so the see section below on how to configure that.

HAB Base

First, select the source device that you wish to transmit through. This can be a serial device (USB or Bluetooth) or a LoRa Gateway. If it’s a gateway then you need to set up the timing scheme separately – see the gateway section below.

For gateway sources you will see:

The target payload should be filled in for you, using the last payload received by that gateway, but you can choose a different payload if you wish. Remember to select the correct LoRa channel 0 or 1 to match the device CE0 or CE1.

Choose the command you want to send, with any parameters as appropriate.

For USB or Bluetooth serial sources, you will see a slightly more complicated panel:

This time you also need to enter the encryption password, and when to send. If you are using SSDV then use the “Send on n’th second option”, and set the time to be just before the centre of the tracker’s listening window. e.g. 2 seconds for the settings above.

If you are using the TDM option then use “Send After Rx” instead.

HAB Gateway

Set the timing in gateway.txt to match the tracker settings. e.g. to transmit at 2 seconds past the minute, with our top-secret encryption code:

UplinkTime_0=2
UplinkCycle_0=60
UplinkCode=SECRET

Command Format

The uplink packets begin with ‘*’ which tells the tracker that a command follows. The basic format is:

* <encrypted message>


The encryption is a simple 7-bit XOR with a secret code known to the transmitter (ground station) and receiver (tracker), with the high bit set on each byte.  Decrypted, the message format is:


* <payload ID> / <command> <parameter 1> [,<parameter 2> etc]

Commands are:

  • C = Cutdown
    • CN = Cutdown now.  Parameter = cutdown time in seconds
    • CA = Cutdown at specified altitude; Parameter = Altitude.
  • H = Reserved
  • D = Reserved
  • P = Switch on output pin
    • P <pin>/<seconds>
  • S = Servo output
    • S <pin>/<seconds>/<position>
  • R = Run script
    • R <script>

Subscribe to RSS Feed Follow me on Twitter!