{"id":5039,"date":"2013-01-24T05:57:57","date_gmt":"2013-01-24T05:57:57","guid":{"rendered":"http:\/\/zerokidz.com\/ideas\/?p=5039"},"modified":"2014-06-24T17:06:01","modified_gmt":"2014-06-24T21:06:01","slug":"how-to-transfer-ssdv-images","status":"publish","type":"post","link":"https:\/\/reactivemusic.net\/?p=5039","title":{"rendered":"How to transfer SSDV images"},"content":{"rendered":"
notes<\/h5>\n

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…<\/p>\n

The usual technique with the NTX2 is to send the \u20191\u2032 and \u20190\u2032 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\u2019re programming a bare-metal AVR or PIC \u2013 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 \u2013 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\u2019t take long to write a small \u2018C\u2019 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\u2019t 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.<\/p>\n

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\u2019t have time to send large images, so there\u2019s 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 \u201cbest\u201d 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 \u2013 4 image packets for each telemetry packet). Here\u2019s the Pi making a self-portrait:<\/p>\n

\"\"<\/a><\/p>\n

Also this is very useful<\/p>\n

Tom Epperly – NS6T<\/a><\/cite>\u00a0says:<\/div>\n
07\/01\/2013 at 9:19 pm<\/a><\/div>\n
\n

Did you connect the Raspberry PI\u2019s 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.<\/p>\n<\/div>\n

Reply<\/a><\/div>\n