The HabHub Predictor website can be used to predict where the balloon is possibly going to land.
You need to enter the folowing informations to compute the prediction:
- Ascent rate
- Burst altitude
- Descent rate
The prediction is displayed on the map, then it’s possible to download the prediction as multiple formats including KML at the top right corner.
KML files can be used with Google Earth which is not Open Source but is running fine on Gnu/Linux.
There is also another tool from the Cambridge University Space Flight which is called the Hourly Predictor.
Code source of these tools is available and I installed the hourly predictor on my Raspberry Pi server, but this will be the topic of a separate post.
The prediction tool use wind data from NOAA / National and Oceanic Athomospheric Administration
Screenshots of the prediction, 1 hour before the flight:
All flight data has been recorded by the Raspberry Pi inside the payload in NMEA.
To use it in Google Earth, we can convert it to KML to keep the ability to view altitude information and see lines from the ground, using open source gpsbabel tool.
gpsbabel -i nmea -f gps_data.nmea -o kml,floating=1,extrude=1 -F out.kml
Tip: you can get the KML of a flight from Habitat server here
Then you can directly paste the resulting URL of the KML, into the “Search” form.. the flight track will be automatically loaded on the map.
It currenlty works for KML files under 10MB. My Flight data from the payload is bigger so I used here the .kml of the flight data that has been uploaded to Habitat server.
I took a screenshot of the flight prediction several days before the flight.
Here is the result:
For the prediction to be the most accurate, it is necessarry to carefully measure all weights, helium quantity etc…
The prediction in yellow and the flight in blue:
Comparing the prediction (even few days before) and the real flight, we can conclude that the prediction tool and NOAA data are very accurate.
According to other UKHAS members, this is quite common to have this kind of accuracy.
The “shape” of the fight is very similar and the landing point was only 6 Km from the prediction… Impressive :)
As we know the prediction is usualy accurate, this give us the opportunity to postpone a launch that would have been landed too far, too close from a city, highway, water etc..
I need to investigate more on OpenStreetMap capabilities to deal with KML et see if it can be used instead of GoogleMaps.
Great job done by UKHAS people managing HABHub and those from Cambridge University Space Flight who created the software who is able of such accurate predictions.
One of the cameras used is a Canon A590IS
- 15€ (second hand)
- 8 MegaPixels / 3264x2448
- Not very light
- Used with 2 Ultimate Lithium Energizer
- Loaded with CHDK firmware
CHDK for Canon Hack Development Kit.
This is an open source alternative firmware installed on the SD card that let the user load custom scripts.
In our case we want an intervalometer script.
Check instructions for your own camera.
What I did:
- Use gparted or similar to create a 16 MB partition
- Use gparted or similar to create another FAT32 partition
echo -n BOOTDISK | sudo dd bs=1 count=8 seek=64 of=/dev/mmcblk0p1
- For dual partition cards, all the files and folders from the CHDK distribution file belong on the large second partition except for the files DISKBOOT.BIN and either PS.FIR or PS.FI2, which belong on the smaller FAT16 bootable partition.
- Enable the "lock" switch of the SD card
Other ramdom useful informations
- Disable RAW
- Disable Flash
- Disable Automatic shutdown
- Change numerotation order
- Set date/time
- Test it in freezer
- Was able to take ~ 1500 pictures with the battery (low temperature)
- Set the script to take a picture every 7 seconds (~ 3 hours)
I reviewed several scripts available on Internet and found the one from Stratodean the easier to understand.
The original Stratodean script is available here.
I modified it a bit with
My script version:
-- Uggy Camera Control for CHDK written in Lua
--Author: Mark Ireland
@title Uggy Camera Control
@param s Interval (seconds)
@default s 10
@param d Initial Delay (seconds)
@default d 10
@param c LCDdisplay (0 se coupera)
@default c 0
--Get the date and time
--Get the time, iteration, temperatures and voltage and print it in a nice string
print("Uggy Camera Control")
--Convert seconds into milliseconds and ensure that params are sensible
if s<1 then s=1 end
if d<1 then d=1 end
if c<0 then c=0 end
if c>1 then c=1 end
s = s*1000
d = d*1000
print("Starting picture capture")
i = 0
--endless loop for picture capture - will run until space full or battery empty
--Take the picture
--Log the info to the file
--Add 1 to iteration
i = i + 1
--Sleep iteration delay