Hi everyone!
Sorry for the wrong category.
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!
73!
Sasha VE3SVF
I’d suggest putting the word out to others in the local community.
Will there be other methods of tracking, e.g. something that ends up on https://amateur.sondehub.org/ ?
Hello Mark!
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!
73!
Sasha VE3SVF
15km is certainly high enough to want tracking, and the live flight-path predictions that using sondehub can give you!
Are you saying that you’re not flying a GNSS receiver on this flight? How are you planning on tracking and recovering it?
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.
73!
Sasha VE3SVF
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.
Hi Mark,
Thank you for your input. I agree with you, it is quite scary to launch something without a GPS. Could you please recommend a good Arduino GPS?
On a seperate note - could you please also provide some technical details for Horus 59’s SSTV transmitter? I’m interested for a future flight.
73!
Sasha VE3SVF
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).
The SSTV transmitter is a Raspberry Pi 3 Model A, with a custom shield on it which has a ‘Dorji DRA818’ FM transmitter module on it. Unfortunately the shield itself is pretty poorly documented, but the source code that drives it all is available here: GitHub - darksidelemm/pi_sstv_shield: Code to drive the Project Horus Raspberry Pi SSTV shield.
For your flight, what are you using to send and receive telemetry? You mentioned 434 MHz, but can you provide more details on this?
One of the GPS modules I was thinking of going for was uBLOX MAX-M8C Pico Breakout with Chip Antenna, as recommended by https://www.instructables.com/The-Easiest-Arduino-High-Altitude-Balloon-Data-Log/. However, this Amazon.ca probably might be better slightly, because personally it’s much easier to order from Amazon!
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.
73!
VE3SVF
That kind of module should be fine.
RTTY is workable for a HAB launch, though not ideal due to lack of forward-error-correction. However, we did launches with RTTY telemetry for many many years.
If you can get the telemetry into the correct format, then it would be receivable using software like my Horus-GUI decoder ( GitHub - projecthorus/horus-gui: Project Horus Telemetry Decoder ) and be uploaded to SondeHub.
There’s some info on the accepted format here: communication:protocol [UKHAS Wiki]
A key point is that you must use the CRC16-CCITT checksum.
An example of a ‘minimal’ telemetry sentence would be:
$$CALLSIGN,sentence_id,time,latitude,longitude,altitude*ABCD
(Where the ABCD is the CRC16 checksum)
Hi Mark!
Thank you for clearing it up. I’ll take a look at those links and try to come up with something.
I’ve already implemented a CRC16 function, I’m using it to confirm sensitive data (i.e telemetry).
What would the $$CALLSIGN field be, given that we’re operating under 434MHz?
@vk5qi It appears that sondehub has very little support for RTTY
@vk5qi It appears that RTTY isn’t supported in sondehub, only in horusGUI. Can this still be uploaded to sondehub?
Horus-GUI will demodulate RTTY, and extract fields from the packets and upload them to SondeHub. RTTY support is fairly rudimentary, so you’ll only get callsign, time, and position.
Your callsign can be whatever you want it to be. Honestly i’d just use your amateur radio callsign.
Hey @vk5qi
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.
73!
VE3SVF
In addition, @vk5qi, how do your cutdown systems work? I’m using an archery release modified with a servo.
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:
Hello!
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.
73!
VE3SVF
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.