There are a couple of good open source options for software-based AFSK APRS modem/TNCs:
Dire Wolf: https://github.com/wb2osz/direwolf
You'll still need a USB sound card though, which adds weight and cabling. I would love to see some open-source SBC hardware a la Beaglebone Black or RasPi that had a high-quality sound card built onto the board and wired through a Molex-type plug that was suitable to the bumps and bounces of flying.
 https://github.com/chrissnell/GoBalloon -- This was my first project in Go and while it works well, it now looks pretty ugly to me with a year and a half of Go experience under my belt.
For your use case, you might want to consider a small external microcontroller that handles TNC functionality, this /might/ be smaller and more lightweight than a USB sound card.
Your payload controller software looks pretty awesome--nearly makes me want to launch a balloon with a full Linux single-board computer!
He approaches the problem at a higher level than a typical modem, for instance, he uses predictable data in the packets as framing instead of the deficient framing provided by the bit level protocol. When confronted with a corrupted packet he also tries to guess the true content by doing a "what if" analysis on the marginal bits to see if flipping them the other way fixes it.
If you'd like to give Octave a try and learn about Machine Learning at the same time, try this excellent and fun free course! https://www.coursera.org/learn/machine-learning
One of the later lessons in that class is a mind-blowing signal processing thing. In that exercise, they show how you can put multiple mics in a room, with multiple people talking over each other, and the computer separates out the different sources of sounds, and outputs a clean wav file for each sound source with the sounds isolated from each other. It blew my mind, and was implemented in Octave. And they teach you exactly how to do it yourself.
All the above concepts can, of course, be done in C++ or NumPy or whatever, they just use Octave to teach the course.
http://m.youtube.com/watch?v=VO0d6EuGpO0 Signal Processing for Machine Learning - YouTube (even though this is for marlab, octave is designed to be compatible)
“Balloon chasing systems also use various hacks used to connect the modem software to mapping software, which in the case of the Horus balloon chasers runs on this legacy operating system called “Windows”. Yeah I’ve never heard of it either. Used to be popular apparently, and I’m told it’s good for games. However it would be nice to do everything in Open Source.”
Honestly, that seems pretty tame to me. Certainly not enough for me to stop reading the article. Perhaps that may just be because I don’t have as much sympathy for Microsoft anymore though, after they released Windows 10.
I could not agree more with the author. From the text:
> Closed source and proprietary chipsets are nasty, a glaring problem in a cool geeky field that is otherwise open source. It’s got to be fixed.
Besides, for modern software development work, vanilla Windows is pretty terrible compared with any of the 'nix variants.
First, to clear up something: I don't dislike Windows, I don't dislike Visual Studio (having used it for over a decade now), and I absolutely think that .NET is better than Java--if you are only deploying on Microsoft platforms!
Windows has a number of technical advantages over most of the 'nix folks (IOCP, for example, is pretty cool), and the documentation is like a thousand times better. The debugging experience can be a hell of a lot better. The drivers story is a hell of a lot better. The graphics and audio stories don't even bear bringing up because of how far behind and fragmented the 'nix ecosystem is. I am not making those complaints.
However, Windows (and again, I noted vanilla Windows, not one with a bodged-on Cygwin or git-bash) was not designed for developers. It's heritage and primary interaction metaphor is not one that a developer uses.
The Unix Way (as popular as it is lately to badmouth) is a powerful notion of composable simple programs. The desktop and GUI metaphor on Windows doesn't support that. The notion of a command-line as a happy little conversation between the user and the system doesn't exist, least of all because the selection of default tools on Windows is so cripplingly tiny that doing meaningful work from the command-line is near impossible (and Powershell only kinda/sorta helps with this).
As TeMPOraL points out, a lot of software on Windows is written by domain experts who don't actually know anything about software engineering. Even a rank noob on 'nix quickly learns basic piping and complexity management. There is no such evolutionary pressure on Windows devs, least of all because of the friendly tools put into place to manage complexity.
As a result, the basic ideas of little helper scripts or small programs or quick hacks to test ideas out are strange to a lot of devs--and when they do decide to play, they end up creating applications that are Winforms or MFC or <Microsoft flavor of decade> hairballs that are hard to update and maintain. They usually end up with nice little apps, but the source is usually closed and the app is large enough (due to boilerplate and IDE bloat) that a casual contributor may have a hard time jumping in (if they can at all).
The mindset is just completely different, and not being exposed to both is pretty bad.
The Unix way is a good engineering approach, but it is not unreasonable to hold that it is not the sole good engineering approach because "good engineering" is only meaningful given a specific set of requirements, goals, and constraints. There is plausible historic evidence that the design of Windows was critical in the wide spread adoption and proliferation of general computing devices into the lives of non-technical people by providing economies of scale that vendors of alternatives did not pursue. If I had to summarize it, I would say that Windows gave us a culture in which software vendors were able to decouple themselves from individual hardware vendors. While Windows was proprietary, the hardware upon which it would run was not and Microsoft was able to make billions by selling operating systems at affordable prices into the mainstream market.
Then again, I don't know too many other people who would open VS just to proof something out as a console app... I wrote a lot of one off .Net console apps over the years. These days if I tend to need solutions that work in Linux, OSX and Windows... and use all three regularly.
This is a relatively recent development, and PowerShell itself is not popularized among Windows user yet. If you've begun programming in the last 5 years then you may get some good habits; those who started earlier probably followed the path 'angersock described.
PowerShell became bundled from Vista SP1, IIRC. All Windows since then has PowerShell intrinsically. So if 2006-7 ish is relatively recent, then I suppose you're correct. Relatively correct, that is ;-)
I'd love to hear your thoughts on the engineering side though. :)
Quoth https://en.wikipedia.org/wiki/Xenix :
''' Microsoft omitted multiuser support from its own MS-DOS operating system because Xenix had it. The company planned to over time improve MS-DOS so it would be almost indistinguishable from single-user Xenix, or XEDOS, which would also run on the 68000, Z8000, and LSI-11; they would be upwardly compatible with Xenix, which Byte in 1983 described as "the multi-user MS-DOS of the future". Microsoft advertised DOS and Xenix together, listing the shared features of its "single-user OS" and "the multi-user, multi-tasking, UNIX-derived operating system", and promising easy porting between them. '''
Engineering in the real world includes deliverability, installation considerations, and the role of technical debt. The proof of Microsoft's engineering has been reflected over nearly thirty years of sales based on creating business value.
Yes, I have spent part of my career porting software between several flavours of UNIX and Windows.
Windows is way closer to the Xerox PARC developer experience than any UNIX.
There is a problem that happens with some hobbies like radios and electronics - a lot of software and techniques was developed by people who were domain-specialists first and programmers second. This means they were disproportionally using Windows, and thus this platform has a lot of de-facto standard software written for the Microsoft's OS. On the other hand, today hobbyist programmers predominantly use Linux/MacOS, so when they want to start writing software for domains mentioned above, they hit a wall.
And yes, Windows is pretty terrible for programming compared with Unixes - and I say that as a person who grew up with Windows, spent most of his programming life in it, and had to code under it for current and previous job. When you get used to working in terminal and to all little small utilities and features, it becomes really annoying to have to code under Windows. Personally, I usually paper over it a bit by using Emacs on both platforms, but sooner or later I always hit a toolchain problem.
The solution isn't to bitch about Windows. It's a very good operating system, especially for everything that is not software development. Which means it's good for radio and electronics. Since software devs used to work under Linux like the myriads of "little things" they get from it, the only thing is for them is to sit down and just port the apps they need. Or port their favourite tools to Windows. Or both.