A group of friends and I are working on a cubesat. The prototype will be launched on a low altitude balloon (if we can get enough funding, a HAB) to about 15 km. It transmits telemetry and imagery on 434MHz.
If anyone in the Toronto/Lake Huron area is interested (launched at Wasaga Beach), please do receive telemetry!
Thanks for the reply! No, we likely won’t be putting it onto sondehub. We’re running pretty-low altitude (and low-budget!) so hence we’re saving the GPS. Telemetry is mostly beacon data, accelerometer, and uh Space Oddity lyrics! We’re honestly just a bunch of 14 year olds who are interested in this stuff.
At the same time, the primary reason for not going to Sondehub is because of the complexity of getting the telemetry parsing working, uploading, etc. We don’t really have a primary Linux PC as well (we should, I know!), and a lot of the software written is Linux-only. While I do understand the benifits of Sondehub, I feel for this small mission we can skip.
Of course all of that might change in the near future!
Yes, we’re not flying a GPS module. They are fairly expensive, plus it’s a very minimal mission. As recommended by VE6AZX we saved on it, he says theoretically we can recover without it. Indeed when I looked online many successful flights have been done without one.
We don’t have much of a budget, frankly we don’t have much of an “adult supervisor” either, as mentioned it’s my friend (14), my younger brother (12) and myself (14). And mowing lawns and shoveling snow can only bring us so far
I’m looking into a barometer sensor for altitude, let’s see how that goes.
Finally, I feel that we can get pretty accurate with direction-finding and go from there to land. The flight prediction calculator also unfortunately cannot support many balloons, which is what we’re doing for this flight.
I’m sorry, but performing a balloon launch (even a ‘low altitude’ one, and 15km is not what I’d consider low altitude) without reliable positional tracking is a terrible idea.
Direction finding is how they used to do it back in the 70s maybe, but it’s 2023 and the expectations are set a bit higher. GPS modules which are suitable for this kind of thing can be found on eBay, in particular look for the uBlox chipset (e.g. search for ‘uBlox GPS module’). You still need a way to get this positional information down to the ground of course…
You might also want to carefully look into your local regulations for balloon launches. Here in Australia our aviation regulator requires us to be able to report on the balloon/payload’s position at any point during the flight.
How are you planning on tracking the position of the payload? Hopefully with more than just a beacon signal. Once it lands you may not hear it at all, depending on the landing location.
You also mention multiple balloons. What kind of balloons are you planning on using?
I ask these questions because I don’t want you to lose what you’re been working on. I’ve been doing high-altitude balloon launches since 2009, and have seen many, many groups make similar mistakes and be disappointed when they find they lose track of their payloads, or can’t recover them.
It’s difficult to point to a specific module, as it depends where you are going to be able to purchase from.
The search terms you are looking for are ‘uBlox module’. See what you can find from local re-sellers and post some links here, and I should be able to check if they are suitable.
The uBlox GPS modules are the only ones I trust for use on a high-altitude balloon flight. If configured correctly, they will maintain position lock up to 50km altitude (otherwise they will lose lock at 18km, maybe not an issue for your launch).
Good luck on your balloon flight!! I actually have a DRA818V and was thinking about the possibility for a long time (in fact the original payload was an ESP32CAM modulating SSTV into one of the modules - sadly it didn’t work out).
For our mission, the telemetry/beacon is 434MHz RTTY. While I have a callsign, in Canada it’s very unclear as to whether or not you need to get a higher license level to transmit from a HAB (does it count as an “unmanned station” or not?), so I’m playing it safe with 434MHz modules.
An arduino is the workhorse of the payload, it modulates RTTY using interrupt routines that I wrote myself. At the same time, it handles camera snapshots and such.
I discovered that standard 434MHz modules for $6 CAD actually can modulate FM (somehow???), even though they’re rated for FM, so I’m using those. The ones I have are Amazon.ca.
I’ve spent some of my own pocket money; added a NEO-6M GPS. I can get it to work using regular mode, but how can flight mode be enabled? I found this spec, describing that I can turn on flight mode (in here, it’s called “Airborne Dynamic Platform Model,” but the specs are exactly the same) if I send a special header and command over software serial. I’m not sure how to implement this on the Arduino, could you please help? The flight mode header is on page 120.
If you’re not going above 18km, then I wouldn’t worry about configuring the GPS into flight mode, the default settings will work.
Otherwise, you are correct that this is the command you need to send.
I don’t have any simple to look at examples of doing this unfortunately. The closest is this function: FlexTrack-Horus/gps.ino at master · projecthorus/FlexTrack-Horus · GitHub
As for the cutdown, we use a nichrome wire to melt through the string we are using, however I would not necessarily recommend a cutdown for a first flight.
I would certainly not recommend performing a flight where recovery of the payloads is conditional on the cutdown working correctly. It took us multiple flights to get ours working properly, and even now it has some issues. We only use the cutdown to improve the chances of recovery, not to make a flight possible in the first place. We will only launch if the flight path is acceptable if the balloon bursts as usual.
Now that i’ve actually looked at the link to the radio module (I didn’t before, my apologies), those modules may not be a good choice for this application. I had looked into these for cheap flights previously, and found the frequency stability was awful, which is not good when you are trying to receive a narrow-band transmission from them.
I recommend running the following test:
Get your system setup to receive telemetry. (How are you going with this by the way?)
Put the payload in the freezer, and see how the transmit frequency drifts.
Thank you for looking at those radios! Surprisingly, they don’t really drift that much. I was (somehow???) able to get FM out of those, so drift isn’t much of a problem. PLUS here in the block of ice we call Canada we had a nice, large snowstorm a few days ago, so I was able to shove it outside and confirm the radios worked down to -15 C (not sure if they go further, that was the temperature at the time. The drift was about 5KHz).
For telemetry reception, I wrote some pythonic junk to read FLDIGI’s output for RTTY, then parse it. Right now the primary ground station will use a 7el yagi, while the car will probably use a turnstile/V dipole if the turnstile doesn’t work out.
OK, 5 kHz drift is probably more than I would personally prefer, as it means you need to keep track of that throughout the flight. We used to use transmitters with this kind of drift back when we were first using RTTY, but switched to transmitters with much better frequency stability, as the constant compensation for drift got really annoying. Also, if the drift ends up happening quickly (e.g. due to fast temperature variations), this can break decoding completely.
Have you tried receiving telemetry over a long distance? (like, a few km line-of-sight, e.g. hill-to-hill) This is worth doing to test your transmitter and receiver.