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 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.