I've been working on open-source balloon control software [1] for my own balloon project that I've been building on/off for about six years. I am hoping to use a software modem to bridge between the RF and my AX.25 packet reader/writer [2] because I wanted to save weight. Payload weight is the name of the game in the balloon hobby--the lighter your payload, the less you have to inflate your balloon and the higher it will fly before it bursts. Even an ounce matters and the competitive altitude record balloons are invariably tiny, single-board, all-in-one payloads that are built around a single low-power microcontroller.
There are a couple of good open source options for software-based AFSK APRS modem/TNCs:
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.
[1] 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.
I've been working on a balloon controller as well, although mine is incredibly bare-bones [1]. It only reports position, altitude, and temperature; but since it's so minimal it only weighs around 2 grams.
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!
I've tested my code with the TNC-Black from Coastal Chipworks and it works well. Weight isn't a huge issue on my flight; I'm focused on high altitude photography. It's just more fun for me to do things in software whenever possible. I'd really love to do the mod/de-mod in pure Go. There is an interesting example of a modem in Go but I have much more learning to do before I could write one of these for AFSK:
Awesome tracker, by the way! I'm super jealous of guys like you with actual engineering skills that can put together a custom integrated package on a PCB like that. Would you consider putting up your schematics and Eagle files on Github or similar?
Definitely! I have a couple issues I need to fix on the hardware so the board runs without mods, but I plan on posting all of the hardware/firmware very soon once I get that wrapped up.
What about using one of the i2s daughterboards for the pi, instead of a usb sound card? The Pi has all-in-one shields that work out of the box, but the bbb will need a tiny bit of wiring to make it work.
It's nice living in 2015 when you can code your modem in Octave, an interpreted numerical computation language, and not put an appreciable dent in your available CPU.
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.
For those that don't know-- although Octave is interpreted, the interpreted part acts as an interface to highly optimized vector operations under the covers. Signal processing and a lot of other tasks come down to manipulating large arrays of data using similar operations across the entire array. Although Octave is interpreted, these kinds of operations execute very nicely inside Octave. Octave also lets you write those kinds of operations at a very high level, like a = b * c, and under the covers it's doing millions of operations.
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.
Going into the article, I was expecting some huge Windows insult, but all I found was this quip:
“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.
You are offended because he makes fun of a proprietary operating system that probably fits the task really badly and himself creates an open implementation?
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.
Really? Visual Studio is widely recognized as one of the best IDEs available, and the .NET platform is leaps and bounds better than, say, vanilla Java at this point. I'd like to know what sort of "modern software development" you do that is so "terrible" on Windows.
I'll expand on both my own experience and that of TeMPOraL here.
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.
Vanilla Windows ships with PowerShell. Since it works at a much higher level of abstraction than byte/text streams, it is reasonable for some people to believe that it is more sensitive to developer needs than standard *nix shells. Since it more fully integrates with Windows services, it is also reasonable to hold the opinion that it is a better tool for system operations than Cygwin in many contexts.
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.
I was mostly windows for most of my developer career... That said, I prefer bash scripts to powershell... with PS, it just feels like I have to type a lot to do anything... the more primitive the task, the more the variance is. TBH, anything much more complex, I'm likely to use node, or maybe perl.
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 ;-)
And Scala was created in 2003, but it wasn't until 10 years later before anyone started using it for anything. Adoption takes time, and popularization tends to follow an exponential curve.
If you want to bring history into it, recall that Microsoft (and to a lesser extent, Unix vendors themselves like Sun and SCO) did a great job of disrupting the adoption of Linux in the 90s and spreading FUD among normal people and IT types.
I'd love to hear your thoughts on the engineering side though. :)
''' Microsoft omitted multiuser support from its own MS-DOS operating system because Xenix had it.[29] 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".[30][31] 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.[32] '''
Whatever effect nineties FUD had on Linux adoption was rounding error on the relative difficulty of setting up a desktop Linux environment compared to setting up Windows. Arch tiday is user friendly by comparison,..even discounting how much more effort went into obtaining Linux before ubiquitous broadband.
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.
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.
You get a lot of those tools (including bash) with msysgit... I find that clover, gitextensions (includes msysgit) and conemu are some of my must haves in windows. And I tend to appreciate having Python, Ruby, Perl and Node everywhere I can. I wish the experience for .Net dev was better outside windows... finally starting to get a lot better recently.
Vanilla Windows + Visual Studio is hands down the best development solution for writing C++ code. For any Web stuff - absolutely, I would go with a Mac or a Linux machine any day. For C++, it's incredibly hard to beat Visual Studio.
There are a couple of good open source options for software-based AFSK APRS modem/TNCs:
Dire Wolf: https://github.com/wb2osz/direwolf minimodem: https://github.com/kamalmostafa/minimodem
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.
[1] 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.
[2] https://github.com/chrissnell/GoBalloon/blob/master/ax25/dec...