Double Trouble

For this flight I joined forces with Steve Randall – one of the earliest HAB hobbyists in the UK, and the most prolific launcher; between us we’ve flown well over 200 weather balloons. But experience doesn’t mean that things always go to plan, as we shall see …

Balloon

The aim of the flight was to try out one of the new range of balloons from Hwoyee, and see how high they can go. They are relatively large balloons, and are double-skinned: to make them fit within standard size filling rooms they have an outer “auxillary” balloon to maintain a spherical shape when inflated, with the main balloon inside of that, joined to a filling valve at a double neck. For this size of balloon, the outer one bursts at around 12km allowing the inner balloon to take over for the rest of the flight.

Trackers

These balloons are claimed to get as high as 50km, if conditions are right, which is 5km higher than the current amateur record (held by Steve). We didn’t think that altitude was likely this time, nevertheless for my tracker I used a GPS that, unlike the one usually used for HAB, works above 50km. I connected that to a Pi Zero, LoRa radio, Pi camera and 3 AAAs via a boost converter. Steve’s tracker was a new lightweight design of his, with a software mod so that it during advent it sends the highest recent position to transmit.

Filling

Filling these large balloons is a challenging affair. First, that’s a lot of hydrogen – around 11 cubic metres – so Steve wore fireproof clothing and we had fire extinguishers and buckets of water to hand. It took 3 cylinders so we had 2 changes during the fill. Finally, that large a balloon makes a big sail, so we erected a tall custom windbreak first.

Launch

To make the launch a bit easier, we used a relatively short payload line. That proved to be a mistake. As soon as the balloon was launched, the weight of the inner balloon pulled one side downwards leaving the filling neck, with payloads attached, halfway up one side. Further, the fact that both payloads together only weighed 130g, meant that the balloon had little to persuade it to remain upright. Evidence of the precarious arrangement is clearly seen on some of the live images …

LCARS

This was my first flight testing my new Android HAB app, which I had running on a new headunit installed in my chase car (lower device here; upper one is my old Pi-based LCARS unit tucked into a storage compartment).

One of the app functions is to speak interesting events over the car stereo, so we had a funny moment when it announced “Flight P T E 1 had been launched” at high volume, shortly after it had been!

Problem 1 – Steve’s Tracker

Everything aside from the alarming turbulence was going swimmingly well – even the ascent rate which was high enough to prevent a sea landing – when the first problem happened – Steve’s tracker stopped updating its altitude, and started to send incorrect latitude and longitude values. We felt this might correct itself during descent, and besides we had a second tracker, so we weren’t overly concerned.

Meanwhile the live images often included the large balloon – both a novelty and a worry as we don’t want the payloads colliding with the balloon as either could get damaged.

Problem 2 – My Tracker

Then my tracker stopped transmitting. Our assumption is that something broke physically due to the turbulence and short payload line, as that tracker has flown before with no issues. So we now had no updates on the flight position. Not good.  Here’s the last position we knew, with a prediction based on the balloon bursting at that point:

Never Give Up, Never Surrender

We did though have one tracker sending something. You can glean a lot just from the radio signal, so I tuned my radio to Steve’s tracker and just listened to the signal. The burst of a balloon is usual easy enough to hear as the payload the to spin during free fall; the radio signal isn’t omnidirectional so the spinning is clearly heard through a radio speaker. I sat listening and waiting, and wrote down the time when I first heard the payload spinning. Woo, a data point!

Record ?

I also had the (errant) telemetry visible on my Android head unit, and I watched that hoping for the error to fix itself. Well, it almost did – the tracker suddenly transmitted the maximum altitude that it had registered during the flight so far. Woo, another data point!

Also woo – it beats Steve’s record!  However, with no corroborating data – i.e. no GPS history of the flight to that point – it’s not one I think we can claim.

Prediction

We always use the excellent CUSF flight predictor before a flight, to decide what day (and sometimes what time) is best to fly, and then to decide on the best flight path (something which can be adjusted by changing the balloon size, parachute size and gas fill). It has another use too – to help locate otherwise lost flights. To do this, I entered the last position that I knew (from my tracker at around 36km), and the maximum altitude which X2 transmitted. For the ascent rate I started with the average that I saw early, and then adjusted that till the timings matched when I heard the burst. So those data points accurately (I hoped!) profiled the ascent.

Now for the descent. I waited till I lost audio from the tracker, and checked the #highaltitude chat room for when others lost it too.  Mine seemed to be the last anyway, so I used that time. Back on the predictor, I adjusted the landing speed till, at 7.5m/s, the landing time was shortly after the last time I could hear anything. So I now had a prediction to work from, and Julie and I drove there (over 80 miles, and around 100 minutes away) while Steve got on with another launch.  Here’s the final prediction that I made before setting off:

Chase

The landing area was west of the A12, so for convenience we aimed for that road then drive North to take us within 500m of the predicted landing point. I fully expected to spend an hour or so drinking round all they local roads on search of a signal, but amazingly we picked up a loud signal as soon as we got near the prediction! We pulled over into a layby and waited for a decode. Unfortunately that was still showing the wrong position. So…

Triangulation

It’s an old technique from when it wasn’t so easy to encode telemetry on a radio signal. All you have to do is use a directional aerial to get a direction to the radio transmitter, then do the same from another location. We did that, and got a position at the far end of the field we parked next to.

Brambles 1

Walking along the side of the field, radio and aerial in hand, I could tell that the signal was coming from somewhere inside dense woodland. Filled with brambles. I ventured in but couldn’t get a definite position, couldn’t see the payload, and was get scratched at every turn. It seemed that the signal was coming from somewhere close to where the trees stopped next to a railway line, so I retreated and tried in the field the other side of the line. Again, triangulation was showing the payload to be near the edge of the trees, but we still couldn’t see it. With skin and clothes torn, and the light fading, we called Steve and decided to wait till the next day.

Prediction Accuracy

Checking on the map at the hotel, I saw that the payload was a mere 250m from the prediction. Let that sink in.  A 250m error, from a point 36km up in the sky, for a flight that reached 45km and travelled 50km horizontally after the last position till it landed. Stunning accuracy (within 0.5%) from the CUSF predictor!

Brambles 2

Steve got to the area at first light, went through pretty much the same process that I did, and with the same results. We may go back when leaves have fallen and it’s potentially easier to see through the dense undergrowth, but for now the payloads are lost. So close yet so far!

Posted in Weather Balloon | 1 Comment

The Compleat Chase Car

Chasing balloons is often the best part of the entire process, but can be challenging if you don’t have the right kit, or it isn’t accessible.  It’s particularly difficult if, as with many of my flights, you’re chasing alone; a laptop isn’t much use when you’re driving!

My previous car was an old Shogun, which served me well but the list of faults was getting rather long so I traded it in for a Hyundai Santa Fe – a bit smaller and not quite as capable off road, but for HAB use with the odd muddy field it will do just fine.  I chose the 5-seat model as it has a huge under-floor compartment in the boot (where the extra row of seats would have been); I use that to store aerials and other equipment:

Here I have:

  • Chase rucksack with tape, ties, knife, hooks, waterproof bag for phone.
  • Yagi aerials for 434 and 868MHz
  • Torches
  • Wellies
  • Spare magmount aerials
  • Saws
  • SLA 12V battery
  • Raspberry Pi LoRa gateway

The LoRa gateway uses a Pi 3 with 434 and 868MHz modules, and connects to the internet via a 4G MyFi device in the cabin.

The gateway aerial cables run underneath the boot, up through the door trim and out at the roof to magmount aerials which attach to washers inside the car when not in use:

Power for the gateway comes from a 37Ah 12V SLA via a 12 –> 5V adapter.  Power to the adapter is switched via a panel mounted in the side of the boot:

The panel includes a voltmeter and dual USB socket, both switched via the first switch in the panel.  The 3rd switch connects power to a 240VAC inverter via a relay next to the SLA.  All supplies are fused, and for convenience the SLA powers 12V cigar lighter sockets in the boot and cabin.

With all this kit in the underfloor compartment, the boot floor is clear and I wanted to keep it that way, so I mounted the various poles (for removing payloads from trees) to the seat backs, using Velcro straps held by metal plates screwed to the seats:

Up front, I fixed my Yaesu 817 radio to the side of the centre console, using adhesive Velcro tape.  The 817 is kept charged from the car 12V supply.  Other connections include the aerial (another magmount), audio via a transformer to prevent earth loop noise, and a USB power adapter:

Now onto the dashboard.  On top is my old Pi-based LCARS device, and below is a Pumpkin double-DIN head unit running Android 7.1.

The Pi device runs a Python application that I wrote a while ago, emulating the Star Trek LCARS displays.  Here it’s streaming video to YouTube:

As for the head unit,  these are essentially Android tablets with WiFi and GPS, FM radio, amplifier, front panel volume control and some handy buttons, SD card slots, and front and rear USB sockets.  This model also has video in (for a rear-view camera and DVD player for example), video out (for seat-back displays), audio in and a steering wheel audio control input.  Buying last year’s model saved a fair amount of money, but didn’t lose any functionality and it’s plenty quick enough in use.  Here’s a short video showing it in use:

I installed apps for offline navigation and OS mapping, plus my own HAB chase app which I intend to release soon.

That app receives data from the LoRa gateway in the boot so it knows where the balloon is, and uses that plus the head unit’s GPS to provide navigation to the balloon once it lands.  I’ll cover the app in more depth in a separate post.

Posted in Weather Balloon | Leave a comment

RTTY Through LoRa Module

Although the current Pi In The Sky boards include an FM transmitter for use with RTTY, there are some reasons for wanting to transmit RTTY through a LoRa module:

  • You can use 1 aerial for RTTY and LoRa, instead of 2, which makes payload design a lot easier
  • Extra RTTY bandwidth
  • You’re making your own tracker and want to avoid the expense of 2 radio transmitters

This article is about using the latest Pi In The Sky software to achieve this.

Methods

To transmit RTTY we need to be able to frequency modulate the carrier at a specific rate (e.g. every 20ms for 50 baud).  This timing needs to be accurate.  We could …

  1. Switch the LoRa chip into a mode where it just generates a carrier, and use the RTTY bit stream to set the frequency to one of 2 values every 20ms.
  2. Switch the LoRa chip into a mode where it transmits one of 2 frequencies, with the selection controlled by a DIO pin, and then send the RTTY stream to this pin.
  3. Switch the LoRa chip into FSK (Frequency Shift Keying) mode, with preamble and checksum etc. disabled, and have it send data from a buffer where that data is the RTTY bitstream.

(1) requires accurate timing, which is not so easy with a non-real-time operating system.  I did try this option with a small test program written in Python, and it worked tolerably well at 50 baud, but really isn’t a good option as the timing varies depending on the processor’s workload.

(2) requires an accurately timed bitstream applied to the DIO pin.  This is possible on the Pi using the serial port, but we use that anyway for the standard RTTY radio.  It’s also possible using a software serial port and the Pigpio driver which uses the DMA hardware for timing, but this increases our reliance on a particular external driver and besides, on our LoRa boards the appropriate DIO pin is not connected.

Which leaves us with (3).  There is a difficulty here, which is that the buffer used for FSK is small (64 bytes) and we need to oversample (store the same bit several times) to get the lower baud rates needed for decent range on HAB, but these are just coding challenges.  So this is the option I chose.

Essentially, the code does the following:

  1. Puts the LoRa chip in FSK mode at the desired frequency
  2. Sets the bit rate to a suitable value for the desired baud rate (50 and 300 supported currently).  “Suitable” means a low bit rate (reduces CPU workload refilling the buffer) for which 1 bit in the data results in 1 or more bytes in the FSK buffer (so we don’t need to mess around with individual bits in the buffer, which complicates the code).
  3. Set a buffer warning level so we can quickly sense when to refill the FSK buffer
  4. Tell the chip to transmit
  5. Fill the FSK buffer
  6. Monitor the buffer level and refill as necessary
  7. At the end of the RTTY sentence/packet, allow the buffer to empty

I am indebted to Matt Brejza for the idea, and for providing the code he used to implement this in his tracker, which I then incorporated/mangled to work with the existing PITS software.

Configuration

First, you need the new version of the Pi In The Sky software (released 26th September 2018), or later versions.

To understand the settings, first take note that PITS has a concept of “radio channels” where a channel is a particular radio transmitter not mode (RTTY or LoRa).  We are using one of the LoRa devices (channels) to transmit RTTY.  So our settings are associated with the particular LoRa module (in CE0 or CE1 position).  Essentially we are overriding the normal LoRa functionality by telling the software to transmitt RTTY as well as or instead of the LoRa packets.

These are the new settings (shown for channel 0)

  • LORA_RTTY_Frequency_0=<RTTY Frequency>.  Without this, RTTY will use the same frequency as LoRa.  I recommend that you keep the frequencies apart so that your RTTY receiving software does not try to track the LoRa trransmissions.
  • LORA_RTTY_Baud_0=<baud rate>.  Choose 50 (better range) or 300 (faster, allows for SSDV, easier for dl-fldigi to lock to).
  • LORA_RTTY_Shift_0=<carrier shift in Hz>.  The carrier shift must be numerically greater than the baud rate.  Note that the LoRa chip steps in multiples of 30.5Hz.
  • LORA_RTTY_Count_0=<count>.  This is how many RTTY packets are sent one after the other before transmitting any LoRa packets.  2 is recommended in case the RTTY decoder misses the start of the first packet.
  • LORA_RTTY_Every_0=<count>.  This is how many LoRa packets are sent one after the other before transmitting any RTTY packets.  Set to zero to disable LoRa (and only send RTTY).
  • LORA_RTTY_Preamble_0=<bits>.  Sets the length of preamble (constant carrier) before sending RTTY data.  Default is 8 and seems to be plenty.

Example:

LORA_RTTY_Frequency_0=434.350
LORA_RTTY_Baud_0=300
LORA_RTTY_Shift_0=610
LORA_RTTY_Count_0=2
LORA_RTTY_Every_0=12
LORA_RTTY_Preamble_0=8

 

Limitations

  • Only 50 baud and 300 baud are currently supported.  This may change in future releases.
  • If you choose to interleave RTTY and LoRa, then any SSDV packets are only sent out over LoRa.
  • If you want to transmit SSDV over RTTY, then you need to disable LoRa transmissions on that module, and use 300 baud.
  • You cannot have separate payload IDs for RTTY and LoRa on the same module.

 

Posted in Weather Balloon | Leave a comment

Making a Pi Zero GSM/GPS HAB Backup Tracker

This is an update of a previous post, but post-flight (so I know that it works!) and with instructions on how to make your own tracker, and your own gateway to upload to the live HAB map.

Introduction

GSM-based trackers are quite rightly frowned upon for HAB tracking, mainly because they only work at low altitudes (within range of a mobile phone tower, which aim the signal generally downwards).  So they don’t provide tracking throughout a flight, which is a problem as then you don’t know where the payload is until it lands.

If you’re lucky.

There are 2 problems here – one is that GSM coverage isn’t 100%, and the other is that the popular GSM trackers don’t seem to like high altitudes.  I don’t know if they get confused, or they don’t like the cold, but I’ve tried these things several times and only had one work once.

A GSM/GPS tracker that actually works would be useful though, as a backup to a main tracker.  Having had little success with commercial offerings, I thought I’d make one.  I found a Waveshare model that uses the SIM868 GSM/GPS module, plus supporting electronics on a Pi Zero HAT.  So that plus a Pi Zero and suitable power supply would make a fairly small backup tracker.

The device supports GSM (calls, texts) and GPRS (2G, i.e. slow data).  It also has a GPS receiver.  It seemed attractive to use GPRS to provide internet access (via PPP), but that would lock out the single serial port thus making GPS unavailable.  So I decided to just send SMS from the device instead, using a script that gets the GPS position, then builds and sends an SMS containing that position.  I wrote this in Python using the PyGSM library, which makes things very easy (generally no need to mess around with AT commands).  PyGSM doesn’t know about the SIM868 GPS functions however, but it was simple to add those.  So my test script requests and parses the GPS position, then formulates a text message and ends it to my mobile phone:

Live Map

It would also be useful to have the balloon position automatically uploaded to the live map, so I decided to have the device send a second SMS but this time to a gateway based at home.  This gateway is another Pi with a USB 3G modem attached.  I used the same library, but a different script to poll for new messages, determine whether an incoming message is of the correct format, and if so build a UKHAS telemetry sentence, finally uploading it to habhub for the live map:

Hardware Build

For the tracker, mount the Waveshare GSM/GPS board on a suitable Pi (the Pi Zero is ideal – less power and weight).

For the gateway, use a Pi B+ (V2 or 3 or whatever you have handy), and connect a USB modem (e.g. Huawei E173, which is very common and works well on the Pi).

You can use the software without a gateway if you wish, in which case you will only have texts sent to a smartphone and not uploaded to the live HAB map.

Software Installation

Use the same instructions for both tracker and gateway.  Build a bootable SD card in the usual way, using Raspbian Lite.

Next install git other dependencies:

sudo apt install git apt-get python-setuptools python-pip wiringpi

Install the pygsm library:

git clone https://github.com/adammck/pygsm.git
cd pygsm
sudo python setup.py

and other Python dependencies:

sudo pip install crcmod

Install the tracker software:

cd ~
git clone https://github.com/daveake/GSMTracker.git

Testing

Gateway

First, start the gateway software:

cd ~/GSMTracker
python gateway.py

Assuming the 3G modem is connected and working, with a valid SIM card, you should see something like this:

Modem details ...
Manufacturer = huawei
Model = E173

Phone number = +4476543210

Waiting for messages ...

Take a note of the phone number.

Payload Document

For the tracker to appear on the UKHAS map, it needs to have a payload document.  Create one using the habhub page and with these fields:

Set the payload ID to something meaningful (but please not “GSM” as that’s what I use!) and set the checksum type to “crc16-ccitt”.

Tracker

First, start the GSM/GPS module by pressing the button on the side.

Now run the tracker program, using that phone number and also the number of your smartphone.  The format is:

python gsmtrack.py <payload_ID> <phone_number> [gateway_number]

For example:

python gsmtrack.py GSM 07987654321 07876543210

where the “payload_ID” must exactly match the ID you used in the payload document; the phone number is that for your smartphone, and the optional gateway number is that of your gateway to upload to the map.  You should see something like this:

Texts will be sent to mobile phone 07987654321
Texts will be sent to gateway number 07876543210
GPS/GSM UKHAS Tracker
=====================

Modem details ...
Manufacturer = SIMCOM_Ltd
Model = SIMCOM_SIM868

Switching GPS on ...
['OK']
Position: 16:49:54, 52.12345, -1.23456, 155.611
Send because of timeout
Send because of horizontal movement
Send because of vertical movement
Sending to mobile 07987654321: GSM position: 16:49:54, 51.1....
Sending text to gateway
Sending to gateway 07876543210: HAB:GSM,1,16:49:54,51.1...
Position: 16:50:05, 51.12335, -1.23458, 153.100

Startup

For the tracker, you should have it start up automatically.  This should include automatically starting the GSM/GPS device as it does not start up when power is applied.  Earlier we did that by pressing the button on the board, but we can automate that in a script:

#!/bin/bash
cd /home/pi/GSMTracker

gpio mode 7 output
gpio write 7 0
sleep 1
gpio write 7 1
gpio mode 7 input
sleep 5

while :
do
    python gsmtrack.py GSM 07987654321 07876543210
    sleep 5
done

Start that when Raspbian starts, using your preferred startup method.

Usage

For flight, package the tracker in a small foam polystyrene container, using a suitable power source.  I used a powerbank that accepts AA cells, populated with Energizer Lithiums; this is the safest option.  Remember to connect the GSM and GPS aerials, and have the latter at the top of the payload.

The tracker will send texts to your phone and gateway when it first gets a position, every 10 minutes thereafter, or more often if it detects horizontal or vertical movement.  The update rates are in the code and can be easily changed.  It will only attempt to send out texts when below 2000m.

Posted in Weather Balloon | 1 Comment

Pi Zero GPS/GSM Tracker and Habitat Gateway

GSM-based trackers are quite rightly frowned upon for HAB tracking, mainly because they only work at low altitudes (within range of a mobile phone tower, which aim the signal generally downwards).  So they don’t provide tracking throughout a flight, which is a problem as then you don’t know where the payload is until it lands.

If you’re lucky.

There are 2 problems here – one is that GSM coverage isn’t 100%, and the other is that the popular GSM trackers don’t seem to like high altitudes.  I don’t know if they get confused, or they don’t like the cold, but I’ve tried these things several times and only had one work once.

A GSM/GPS tracker that actually works would be useful though, as a backup to a main tracker.  Having had little success with commercial offerings, I thought I’d make one.  I found a model that uses the SIM868 GSM/GPS module, plus supporting electronics on a Pi Zero HAT.  So that plus a Pi Zero and suitable power supply would make a fairly small backup tracker, and maybe even one that works.

The device supports GSM (calls, texts) and GPRS (2G, i.e. slow data).  It also has a GPS receiver.  It seemed attractive to use GPRS to provide internet access (via PPP), but that would lock out the single serial port thus making GPS unavailable.  So I decided to just send SMS from the device instead, using a script that gets the GPS position, then builds and sends an SMS containing that position.  I wrote this in Python using the PyGSM library, which makes things very easy (generally no need to mess around with AT commands).  PyGSM doesn’t know about the SIM868 GPS functions however, but it was simple to add those.  So my test script requests and parses the GPS position, then formulates a text message and ends it to my mobile phone:

It would also be useful to have the balloon position automatically uploaded to the live map, so I decided to have the device send a second SMS but this time to a gateway based at home.  This gateway is another Pi with a USB 3G modem attached.  I used the same library, but a different script to poll for new messages, determine whether an incoming message is of the correct format, and if so build a UKHAS telemetry sentence, finally uploading it to habhub for the live map:

UPDATE: Software now uploaded to github: https://github.com/daveake/GSMTracker

Note: Not tested in flight yet so I don’t know if the software and/or hardware chosen will work or not, so user beware!!

Posted in Weather Balloon | Leave a comment

Pi Zero W Streaming Dashcam

Tidying my office a few days ago, I came across some car reversing monitors that I used to use as cheap Pi displays for use in the chase car, to show the distance and direction to the payload; these days I use the official Pi touchscreen as it’s a lot better for that application.  One of the monitors is a flip-up model, and I wondered how much space there was inside.  I use the Pi Zero a lot for balloon trackers, as it’s small and light compared to other Pi models, but perhaps one could fit one inside the base to make a smart dashcam – one that can stream my balloon chases to Youtube as well as record to SD.

About the same time, Michael Horne (author of the excellent Pi Pod blog), posted a picture of a similar-looking model on Twitter, asking how to power it from 5V.  That’s the opposite of what I wanted to do (power the Pi Zero from the 5V rail inside the monitor) but I felt I might be able to help so I opened up my unit to find where the 5V could be tapped.  As it turned out, Michael’s unit had a very different PCB to mine, but the seed was sewn so I decided to start building my dashcam.

Pi Zero to Monitor

First job was to connect the the display to a Pi Zero W (W because I want to be able to stream the camera video). This requires the 5V and GND lines on the GPIO pins, plus the composite video output pin, to be wired to their counterparts in the monitor.  Once I’d used the correct video pin this worked without issue!

I don’t know how much spare current capacity the display has on the 5V rail, but it dropped slightly from 5V to 4.9V which is OK.  The Pi Zero booted and ran continuously overnight with no issues and with nothing on the display PCB getting hot.

I connected the Pi Zero to my LAN via a USB LAN adapter, ssh’d to it, then set the video aspect ratio to match the monitor (16:9).

sdtv_aspect=3

The full set of options is:

I also updated/upgraded Raspbian, and set up the WiFi.

ffmpeg

Next steps were to enable and connect the camera, and to install ffmpeg, which is what I use to stream to YouTube.  I used these instructions to install the library:

cd /usr/src
git clone git://git.videolan.org/x264
cd x264
./configure --host=arm-unknown-linux-gnueabi --enable-static --disable-opencl
make
sudo make install

and then ffmpeg.  This takes several hours to build, so it’s a good time to find something else to do!

cd /usr/src
git clone git://source.ffmpeg.org/ffmpeg.git
cd ffmpeg/
sudo ./configure --arch=armel --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree
make

Aspect Ratio

I then tested the video streaming to YouTube with a command like this:

raspivid -o - -t 0 -w 640 -h 360 -fps 25 -b 500000 -g 50 | ffmpeg -re -ar 44100 -ac 2 -acodec pcm_s16le -f s16le -ac 2 -i /dev/zero -f h264 -i - -vcodec copy -acodec aac -ab 128k -g 50 -strict experimental -f flv rtmp://a.rtmp.youtube.com/live2/<stream ID>

which worked to Youtube, however the preview displayed on the monitor was distorted.  I thought that this was to do with Raspbian not correctly applying the screen resolution, but no matter what I did to fix that (specifying the resolution explicitly in config.txt, or specifying the preview window dimensions) fixed it.  Eventually I concluded that the issue was within raspivid, and then I soon found a very relevant forum post, which explained how to modify raspivid:

git clone https://github.com/raspberrypi/userland.git
cd userland
./buildme

Then add these lines near line 116 of RaspiPreview.c:

param.set |= MMAL_DISPLAY_SET_NOASPECT;
param.noaspect= MMAL_TRUE;

then rebuild.  After following these steps, the problem was gone!

Assembly

With the base plate removed, I threaded the flat camera cable up through the back of the base, behind the support that goes up to the top of the display, connected the camera and fixed it in position with Sugru:

I then added a piece of black duct tape covered the cable to stop it snagging and make it look tidy.

Wiring

The Pi Zero has 3 wires connected – 5V, 0V and video, which on my monitor go to a convenient electrolytic capacitor and the back of a PCB socket.  Finally, a switch is mounted near the front of the monitor’s base, and connected to a GPIO pin and GND:

Everything was then insulated with duct tape before screwing on the metal base.

Script

I wanted the dashcam to work in one of 2 modes – to record as a dashcam normally would, and to also live stream to YouTube (via the WiFi connection to a phone or MyFi device, for example).  So I wrote a small script that switches modes according to the position of a switch connected to a GPIO pin.  On startup, or when the switch position changes, the script runs the appropriate shell command for that mode.  For regular dashcam recording, that’s a simple raspivid command; for streaming it pipes the raspivid output through ffmpeg (see command above).  At present I’m not recording the video, so I need to do that using rotating file names, over-writing old files before the SD card fills up, and recording at a high resolution but streaming at a lower resolution.

Results

 

Posted in Weather Balloon | 2 Comments

How To Choose A Tracker

I sometimes receive emails asking which HAB tracker is best to buy, so here I will compare the ones I have direct knowledge of.  First though, if you have or want to have the ability to build and code your own tracker, do that instead!  It’s much more educational to walk that path, rather than take the easy option of buying a ready-made tracker.  It’s also far more rewarding.  Or if you prefer, you could build your own tracker but use existing software, or buy a pre-built tracker and write your own software.

If you want to DIY the electronics and/or software, and if you can you should, then check out these resources:

Now for the comparison, including the PITS (Pi In The Sky) board, PITS Zero and HABDuino:

PITS (Full Size)PITS ZeroHABDuino
Transmits RTTYYesYesOptional
Transmits LoRaOptional (choose from 434, 868 and 915MHz add-on cards)Yes (choose from 434, 868 and 915MHz modules)No
Transmits APRSOptional (choose from 144.390MHz (USA), 144.800MHz (Europe) and 145.175MHz (Australia))NoOptional (choose from 144.390MHz (USA), 144.800MHz (Europe) and 145.175MHz (Australia))
Transmits Live ImagesYes, over RTTY or LoRaYes, over RTTY or LoRaNo
Soldered connections for external DS18B20YesNoNo
Soldered connections for external BMP085/BMP180/BME280YesNoNo
Supports Pi Sense HatYesNoNo
Software Predicts Landing Position During DescentYesYesNo
Posted in Weather Balloon | 1 Comment

I’ve Got No Strings

NASA have given us many iconic photographs, such as “EarthRise” and “Man On The Moon“, but there’s one which is more easily replicated if you’re not NASA or Elon Musk, and that is the image of Bruce McCandless floating freely in space during the first untethered spacewalk:

So several months ago I set about replicating this as best I could, under a high altitude balloon.

Revell Model

Revell USA made an astronat/MMU kit back in 1984; samples now are rare and expensive, but eventually I found an unused kit in the UK on ebay.  It was a good price, complete and original:

The kit arrived late last year, and I assembled it over the Xmas break, in preparation for a launch on (hopefully) February 7th, 34 years to the day after the original flight.

Cameras

I wanted to include several cameras for the flight, both video cameras and still cameras for downloading live to the ground during the flight.  Having tried several different action cameras in the past, my current favourite is the Gitup Git2 camera – reliable, inexpensive and plenty of options in the firmware.  I combined 2 of these (one Git2 with wide-angle lens, and one Git2P with a normal lens) with some AA-powered powerbanks to extend the run time from about 90 minutes to several hours using 64GB SD cards.

I also wanted live images, ideally from different viewpoints.  The only reliable live image cameras I’ve used are the Pi models, and these are one-per-Pi.  So I built a small network with 3 Pi boards using the built-in wireless modules to pass image files between them; a Pi3 as an access point, and Pi Zero Ws as clients.  All live images were then downlinked in squence by one Pi using LoRa.

In the end it wasn’t really feasible to set up vastly different viewpoints as the astronaut model is quite large and the payload would have then been huge (and cumbersome, and delicate), so I had the cameras all quite close to each other.

Payload Build

I decided to place each Pi in its own Hobbycraft box.  The Zeroes are very small of course and even with an AA powerbank there was space to fit a video camera with its own powerbank inside the box:

Next came the main Pi, with its own camera, 3G (later removed due to insufficient power from the powerbank) and UBlox USB GPS, all inside 2 of the same boxes glued together:

Finally, I added a backup tracker in case the main one failed for any reason, and to provide a programmed cutdown to prevent the flight drifting too far:

There was one last thing to do – my Revell model isn’t identical to the version that NASA flew, and most prominently was missing a camera.  Easily fixed with some foam polystyrene and a plastic cap!

Bruce Junior was now ready for flight!

The Flight

The flight predictions for my chosen date were not ideal, but quite good for the time of year.  Initially I was going to have help from another HABber but he couldn’t make it that day, so I launched alone.  To make that task easier I removed some items from the flight, allowing for a smaller balloon and less gas.  I also chose to launch later in the day than planned, which meant I didn’t need to overfill the balloon so much to keep it away from the sea.  Here’s the predicted flight path:

Less gas means less lift which makes it easier to tie the balloon and handle it afterwards. Aside from the cold, it was a very nice day to launch – fairly clear skies and not too much ground wind.  Here’s the partially-inflated balloon:

Meanwhile the payload cameras were recording and transmitting to the other HAB enthusiasts online:

With the balloon fully inflated, tied off and tied to the parachute and payloads, it was time to launch:

I then finished getting aerials set up for the flight, finished filling the car with kit, and then set off on the chase.  I knew that the flight was going to land some time before I arrived, so I wasn’t in as much of a rush as usual.  Meanwhile the payload continued to rise till, at over 30km and just under 100,000 feet, the balloon burst.  Here’s what happens to an aerodynamically asymmetrical payload when a high altitude balloon bursts and gravity takes over!

The flight computer includes its own landing prediction which, as I’ve seen every time before, is more accurate than one that the online map uses.  Here “X” is the last prediction from the tracker, with “O” being the actual landing spot and the red line showing the online prediction:

That last position was from my chase car, which was still on the M5 and over an hour away at the time!  Here’s what happened when I was trying to catch up:

Normally when I get close to a landed balloon the radio signal reappears and I can get the landing position easily.  This time though the landing was on a farm behind some metal cowsheds, blocking the signal from the nearby roads.  After driving past where I thought the signal should reappear, I found a hill, connected a Yagi aerial to my handheld receiver and got a position that way.  Following that target I still didn’t regain the position until I got to the farm, when I could see a row of sheds between me and the landing position.  It’s always fun explaining to farmers why I’ve suddenly turned up, and this time one of them had actually seen it land.  Retrieval was easy, though muddy and rather smelly …

Here you can see the balsa-wood frame (for lightness and deliberate fragility) with pivoting support (again, to help prevent damage to whatever it lands on), with the balsa painted matt black so it disappears against the black sky at altitude.

The payback

The point of the all this effort was to replicate as close as I could those original NASA images, so once home I went through the camera footage to select these …

 

 

Posted in Weather Balloon | 10 Comments

“Untethered” Spacewalk Flight

My next flight is planned for this coming Wednesday, 7th February, to commemorate the first untethered spacewalk by Bruce McCandless on the same day in 1984, by trying to recreate the classic image:

There will be a total of 3 Pi cameras with different viewpoints and different lenses, to best capture images of a Revell model astronaut and MMU (Manned Maneuvering Unit), sending live pictures down to the ground.

The flight will have 2 trackers, one a Pi with 434 and 868 LoRa modules and the other a simple AVR LoRa tracker with cutdown:

  • BRUCE: Pi, LoRa, 869.850MHz, Mode 3, SSDV and telemetry
  • MMU: Pi, LoRa: 434.225MHz, Mode 1, SSDV and telemetry
  • EVA: AVR, LoRa: 434.450MHz, Mode 2, telemetry only

The main tracker is a Pi 3 plus LoRa and UBlox boards.  The SSDV images will cycle between 3 cameras – one on the Pi 3 and 2 more on a pair of Pi ZeroW boards, all connected via wifi (the Pi 3 is an access point).  The cameras are (currently – may change): Pi V2 (Sony) camera, Pi V1 (Omnivision) camera, and a PiHut “fisheye” Omnivision camera.  The cameras are arranged on the payload to get different views, so you will see different views during the flight.  Same applies for both LoRa transmitters, with different images being sent to each.  If for any reason the wireless stops (though it’s been 100% reliable in testing), then the Pi3 will just send its own images.

Both include landing prediction fields, and those from MMU will be re-uploaded by a Python script to appear as “XX” on the map.

The LoRa signals will stop for a few seconds each minute, during which time one of my gateways will be sending a message up to the tracker to request a re-send of missing SSDV packets on the 869.85MHz link.

The Pi 3 also has a USB 3G modem on it, which will attempt to connect while below 2km.  When connected it will:

* Upload telemetry directly to habitat every 1 minute, as payload ID STS41B
* Stream video to YouTube
* Copy images to a web server

The video uses the Pi 3’s camera, so there will be no SSDV from this camera before launch or after landing – all SSDV will be from the other cameras.

The backup tracker will be attached just above the parachute, and will cut the balloon away if the flight gets south of 51.1 latitude (may ehcnage that depending on predictions), or on a specific upload from the ground, to prevent a watery death.

And just because the payload isn’t heavy enough already, and doesn’t have enough trackers on it, we are adding a couple of car GSM/GPRS trackers, both sending messages to Anthony’s traccar server from where a Python script will send them to SNUS, as:

  • HTGSM1 – Upu’s car tracker
  • HTGSM2 – My cheap car tracker

There will be 2 YouTube streams – one from the payload (launch and landing, hopefully) and one at launch only using a camcorder connected to a laptop.  Both streams will appear on a web dashboard – see links below:

 

Posted in Weather Balloon | Leave a comment

Bruce McCandless Spacewalk Commemoration

This is to commemorate the very first untethered spacewalk by Bruce McCandless on 7th February 1984, as part of Space Shuttle mission STS-41B, when he used an MMU (Mobile Maneuvering Unit) to fly up to 300′ away from the Challenger Space Shuttle, and to replicate as best I can the famous photograph of him floating in space …

Sadly, Mr McCandless died late last year.

Of course the “untethered” aspect can’t be repeated under a balloon, gravity being what it is, but careful use of black supports against a black sky will make it look untethered.

The Kit

Fortunately, Revell USA made a combined astronaut and MMU kit in 1984.  Unfortunately they soon stopped making it, and examples are expensive and fairly rare.  I watched listings on ebay for a few months, but all were in the USA with expensive postage, until one popped up in the UK.  Not only was this the least expensive I’d seen, with reasonable postage, but also it was a completely original sample with the parts still in sealed plastic wrappers.

It’s probably 45 years or more since I assembled a plastic kit, so I had to buy the glue, paints and brushes before I started.  Assembly wasn’t difficult though the plastic in general was much thinner than the small Airfix kits that I remember from my childhood.

Live Cameras

The flight will include 2 LoRa downlinks – one in the 868MHz ISM band (more bandwidth for larger images) and 434MHz ISM band (better range).

I want to be able to take photographs from different viewpoints, ideally:

  1. Straight shot from distance
  2. Side shot
  3. Close-up

One option would be to move the camera around with motors, but that would be delicate and likely to fail during flight.  Instead I’ve opted for 3 separate cameras.  This could possibly be done from a single Pi using USB cameras, but those aren’t reliable in my testing.  Webcams tend to be much more reliable but not as good quality as a Pi camera.

Another idea is to use a separate Pi for each camera.  I could then build 3 separate trackers, but for them all to use the 868MHz band I would need to have them take turns transmitting.  All do-able but a bit messy, plus there would be a lot of aerials!

Airborne Network

So instead, I decided to have one central Pi that has a camera, GPS and radio transmitters, plus 2 extra Pi boards just with cameras.  Networking 3 Pis could be done with a network switch and cabling, but a wireless is a lighter option.  Recent Pis have built-in wireless networking (saves a bit more weight, and is more reliable in my experience) so I settled on a Pi 3 as the tracker and access point, and 2 Pi Zero W boards as clients.  So that’s 3 Pi boards in total and 3 cameras.

Setting up a Pi 3 as an access point takes quite a few steps, especially when bridging the wireless LAN to the wired LAN, but there are clear instructions on the RPi web site.

Software

I needed to modify my PITS software to cope with 3 cameras.  Normally, the tracker program (which is the one transmitting image packets) requests new images periodically according to the schedule in the configuration file, and then chooses the “best” image and requests a conversion from JPG to SSDV format shortly before it finishes transmitting the current image.  One option I had was for this code to be modified to request 3 photos instead of 1, with 2 of those being on the Pi Zeroes, plus of course to cycle between the cameras for conversion and transmission.  Separately, a bash script takes photos and does the conversions.

I felt it would be simpler to remove some of this responsibility from the tracker, so that it just chooses which photo to send, choosing each time from a different camera.  So this means that we need a simple script to take photographs, and a simple script to do the conversion to SSDV.  The first of these scripts is run on each Pi, with the Pi Zero scripts also copying the photo files to the Pi 3.

Here’s the SSDV page showing the result, on the 434MHz channel (smaller images), with the Pi 3 cycling through all 3 cameras:

Weather permitting, I’ll fly this on February 7th, 34 years to the day after the original flight.

Posted in Weather Balloon | 2 Comments