Introduction
For the past 12 months or so after reading about the exploits of Dave Akerman and his first launching of a Raspberry Pi into near space I've been tinkering with the idea of launching a balloon myself. Although there isn't a huge HAB community in NZ there have been some previous launches, and there is plenty of good information and useful tools available via the UK HAS web site, and #highaltitude IRC channel. The IRC channel in particular has been a great source of information with many friendly people willing to share their experience and knowledge. It's also been very interesting tracking and watching launches live. Even from the other side of the globe it's sometimes possible to watch live video streams of flight preparations at the launch site and from the chase cars as they track balloons across the country-side. When video isn't available it's still possible to track progress via the live updates on the spacenear.us tracking site and running commentary on #highaltitude.
Slowly different aspects of the project have been coming together. Most recently I reached my first major milestone, successfully transmitting and decoding telemetry. I've decided to blog about my exprience with this so far as it may be useful or interesting to others wanting to do something similar.
System Overview
Starting from the payload end and working through to the receiving and decoding end my setup looks like this:
Figure 1 - System Overview.
I'm planning on using a Raspberry Pi Model A for the payload although for development I'm using a Model B as I have a couple of these already on hand purchased from Element 14. As my day job is J2EE development, Java was my preferred choice of language for the payload control software. The Radiometrix NTX2 seemed to be one of the more popular radio transmitters used in Europe and was readily available also from Element 14 (please note it has subsequently been superceded by the NTX2B). The NTX2 also fitted onto an early circuit board designed to interface both a uBLOX GPS receiver and radio transmitter to the PI's UART, kindly supplied by Dave Akerman. Dave generously supplied this board as he has since changed his approach and currently uses the i2c interface to talk to the GPS receiver and the Pi's UART to talk to the transmitter.
On the receiving end, at the moment I'm using a cheap RTL2832/R820T based USB tuner brought off ebay from a Hong Kong based supplier. A FunCube is another option or a dedicated HAM radio or portable scanner, the UK HAS site has recommendations on brands and models. HAB supplies also sell a range of filtered pre-amps that can provide additional gain and sensitivity. I'm using gqrx, a QT based graphical front end to gnu radio on the iMac for interfacing to the USB tuner - more on this later. Jack provides a way to directly connect the audio output from gqrx to the audio input dl-fldigi, this avoids having to use any cables or indirect sample from the external speakers to the mic. It significantly reduces the amount of noise introduced to the signal. Finally I'm using version 3.1 of dl-fldigi available from the UK HAS web site.
Why RXTX instead of WiringPi?
The typical approach for broadcasting telemetry with a Raspberry Pi and NTX2 is to use the built in UART serial interface to generate the signals. This is because the OS on the Pi makes bit banging a a serial interface very difficult as it's not a realtime OS and timing is critical so it becomes a significant challenge. The UART approach utilises the built in hardware to do do all the hard work. Initially I started working with the WiringPi library and Java front end for doing the serial coms. I eventually changed to use RXTX, the main driver for this decision was that RXTX provided control over the serial port flags such as the number of bits, parity, and stop bits whereas the WiringPi Java front end didn't provide an API for this. As it turned out installing RXTX was reasonable straight forward. There are several useful resources on-line that show you how to do it. One thing that did take a little bit of tracking down was that by default RXTX didn't recognise /dev/ttyAMA0 as a serial device but that is easily fixed by setting the gnu.io.rxtx.SerialPorts property before getting the port identifier:
String SerialPortID = "/dev/ttyAMA0";
System.setProperty("gnu.io.rxtx.SerialPorts", SerialPortID);
CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(SerialPortID);
Raspberry Pi to NTX2 Wiring
The following circuit diagram shows how the NTX2 was wired to the Raspberry Pi. This is essentially the same as the schematic on the UK HAS page for linking the NTX2 to an Arduino, the only difference is the value of R1 which has been changed from 47K to 22K as VCC for the Pi is 3.3V instead of 5v for the Arduino. The value of R! influences the carrier shift in Hz when transmitting. A detailed explanation of how to calculate this is provided on the UK HAS site. They also have some good photos of how to assemble the circuit on a breadboard.
Figure 2 - Wiring the NTX2.
Why GQRX instead of SDR#?
Initially I was using my oldish Sony Vaio laptop running Debian Linux as the receiver running SDR# and dl-fldigi. I suspect the laptop was a bit under powered to run buth these applications at the same time, also it was getting quite hot and so the CPU was stepping the clock speed back to reduce heat output. I've since given the laptop a good blast with the vacuum cleaner and dropped the average running temperature by about 25-30 degrees. At some point I may dis-assemble it and give it a proper clean out and replace the thermal paste on the CPU. In the meantime I had switched to using an iMac for the receiver, this is a quad core I7 with 16GB of RAM so it's more than up to the task. The only problem is that SDR# isn't available for the OSX so this prompted a switch to GQRX, the QT based front end to Gnu Radio. As it turns out, I find the GQRX interface much cleaner and simpler than SDR# under Linux. SDR# seemed to have issues with font sizes and the layout of the left hand control panel always seemed to have far too much white space. When I re-visit receiving on the laptop I'll try switching to GQRX and see if that runs better the SDR# in a mono runtime.
Audio Patching
I've used Jack Audio to directly patch the audio output from GQRX to DL-FLDIGI. This eliminates any background noise and makes for a much cleaner signal being passed into dl-fldigi.
You need to start up both gqrx and dl-fldigi and then use the jack configuration tool to wire the out from gqrx to the input for dl-fldigi.
Figure 3 - Jack Configuration
Reciever Screenshots
The first two screen shots show the gqrx and dl-fldigi interfaces while the transmitter is on but not transmitting data. In this case you can see a spike on the FFT plot in gqrx where the carrier signal is. If the transmitter is disconnected or the enable pin low then you won't see a spike on the FFT plot or waterfall below.
Figure 4 - gqrx screen when transmitter is on but not transmitting data.
(Note: We're zoomed in quite a bit here, on the Mac you can zoom using the mouse wheel while hovering over the frequency or db labels)
Figure 5 - dl-fldigi screen when transmitter is on but not transmitting data.
Figure 6 - gqrx screen when transmitter is transmitting data.
Figure 7 - d-fldigi screen when transmitter is transmitting data.
Figure 8 - dl-fldigi RTTY settings.
The settings in Figure 8 need to match the serial port parameters set in your code, i.e. buad rate, bits per character, parity, and stop bits. The value of the custom shift is dependent on the value of the resistor R1, in the example above I have the value slightly lower than what the calculated value should be (~636Hz). The receiver filter bandwidth controls how wide the range for the signals can be, this is displayed graphically in the waterfall the two thick horizontal red lines.
Summary
This post was written to share my experience with getting the Raspberry Pi to transmit RTTY data via a NTX2 radio transmitter. I'm by no means an expert in this, in fact I'm learning most of it as I go, but I thought others trying to do the same may benefit from some of experimentation. If you spot anything glaringly wrong please let me know so I can make corrections. I'm still refining things, experimenting with a more accurate carrier shift, and tweaking the signal gain in particular. Following that will be some range testing to see how far this rig is going to work, and how different aerial configurations are going to impact range. If you have any questions please feel free to add comments and I'll endeavour to answer them.
References
Top Comments