Tag: interactive media

How to transfer SSDV images


Here’s Dave Akerman’s explanation of how to write the code to get the Raspberry-Pi to send images via SSDV. It seems kind of impossible…

The usual technique with the NTX2 is to send the ’1′ and ’0′ values in RTTY by waggling a general purpose I/O pin up and down at the correct rate. e.g. every 20ms for the common 50 baud data rate. This is easy when you’re programming a bare-metal AVR or PIC – just use a delay routine or, as in my trackers, a timer interrupt. However the Pi runs a non-real-time operating system, so I could not rely on accurate timing especially if the operating system is busy taking a photo from the webcam. There are other options but I opted for the simplest one – connect the NTX2 to the serial port. RTTY is just normal RS232-style serial marks and spaces and stop bits etc., so why not let the hardware UART do the timing for me? It didn’t take long to write a small ‘C’ program that opened the serial port at 4800 baud, read enough GPS strings to find the longitude, latitude and altitude, then close the port and re-open at 300 baud (I found that switching baud rates without closing and opening wasn’t always reliable) to send out a formatted telemetry string. Of course to do this I had to disable the login prompt on the serial port, and stop the kernel debug messages being sent to it, but all in all it was simple. All of this was done using the standard Debian image on a 4GB SD card.

Now for the live images. I had to apply a patch to Debian after which it happily recognised the webcam as /dev/video0. I tried a few webcams and settled on the Logitech C270 which is reasonable quality, light and cheap (in case the payload goes missing!). I tried several webcam imaging programs and found fswebcam to be the best (worked without fiddling, yet had enough options to tailor the picture taking). Remember that the radio system has low bandwidth and with a typical flight lasting 2 hours or so we don’t have time to send large images, so there’s no point using the very best webcam and the highest resolution. I settled on 432 x 240 pixels with 50% compression as a good compromise between quality and download speed. I measured the webcam current and it went from 50mA at idle to 250mA peak when taking a picture, hence the need to short out the USB fuse (140mA max). A simple shell script took a photo every 30 seconds, saving them on the SD card so that the tracker program could choose the “best” image (largest jpeg!) for transmission. Each chosen image is then converted to the form for download (split into blocks each with FEC) before being sent 1 block at a time. I interspersed the image data with telemetry – 4 image packets for each telemetry packet). Here’s the Pi making a self-portrait:

Also this is very useful

Did you connect the Raspberry PI’s TXD output directly to the Radiometrix TXD line? Or did you use some kind of v3.3 to v5.0 level conversion hardware? If you did level conversion, can you share your design? I am planning to build an APRS transmitter using a cheap USB GPS and a Radiometrix HX1, and I am wondering how complex the connection between the Raspberry Pi and the HX1 needs to be.

  • dave says:

    Connected via some resistors to set the level and bias. This means that the low/high digital outputs from the Pi result in 2 slightly different voltages at the NTX2, which then transmits two frequencies approx 600Hz apart.

    This won’t work for APRS. For that you need an analog output, or PWM.

using a WiFi router as a closed local network

I set up a WiFi router today at school, with no internet connection to use for ssh logins to Raspberry Pi and OSC experiments with Arduino. It has the same SSID as my home router so it will be interesting to see what happens when I go from one place to the other. 

Update: Actually this works great. Have been using it for any situation that requires OSC.

FM Midi Synthesizer with Pd on Raspberry Pi

Here’s a simple FM Midi synthesizer developed in pd running on a Raspberry Pi. The patch was written and tested on a Macbook, then the patch file is uploaded to RPi and run using pd-extended from the command line. For example the command to run this patch is:

pd-extended -nogui -noadc -midiindev 1 piSynth1.pd

[todo: upload patch to this site. Currently in tkzic/rpi/pd/piSynth1.pd]

[udpate]: when trying this again, a few problems came up:

  1. R-Pi didn’t recognize sound card/midi: Solution was to connect the sound card directly to the R-Pi USB port and connect the Midi controller via powered USB hub
  2. Sometimes pd-extended errors out with a device busy message. Seems to run ok if you press ctrl-c and repeat the pd-extended command line. I think this problem may be due to a previous process hanging – and not exiting cleanly




Raspberry Pi with Pd: audio test


In an audio pass-through test using Pd, with a USB sound card (Griffin iMic), the maximum stereo sample rate before ‘breakup’ is 32000.In mono, it sounds “ok” at 44100. Latency seems low enough to use for music but I’m too sleepy to figure out the numbers.

I don’t know enough about Linux audio to say if the performance deficit is due to ALSA drivers, the sound card, background processes, pd, the CPU, or what?Anyway I ‘m guessing R-Pi will spawn interesting synths and lo-fi FX processors. They’re cheap enough you could use them in parallel.

Prediction: They’ll double the speed, and sell a million more by the end of the year. We’ll see a range of ‘Pi’ clones which run the same Linux distributions, but offer various speeds and IO options. It feels like the democratization of manufacturing has taken another huge leap.

pd-extended on Raspberry Pi


Using installation instructions from Pd site:


Installation worked fine. I tried running the GUI under xterm and it was a disaster. Then, using this post, I was able to get a test patch (sine wave with LFO) running in terminal mode:


Note: I changed the actual command to this due to the fact I’m running pd-extended and a USB sound card:

pd-extended -nogui -noadc testPatch.pd

This post from same source has instructions for installing pd-extended (disaster) but a very nice version of the test patch called testPatchExtended.pd


(another update) running Midi:

To run midi you need to specify the device on the command line. First I plugged in the m-audio key station 49 and rebooted RPi

To get a list of devices use:

pd-extended -nogui -listdev

Then to run a patch with midi

pd-extended -nogui -noadc -midiindev 1 testMidi.pd

Here is a page with more information on command line options


(another update) Testing with Griffin iMic. Bad news when doing an ADC->DAC passthrough, sample rates above 32000 don’t work in stereo. However 44100 and 48000 sound fine in mono.

At the higher rates in stereo, the audio breaks up. Oh well. Need to try the Behringer audio box, but I’m assuming there will be no difference. Only possibility would be to somehow devote more system resources to audio.