How to transfer SSDV images

notes

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.

Balloon project

notes

Cost estimates rising. I think we’re looking at around $700 possibly more. The balloon, parachute, and helium costs are fixed. Need a source of helium. Might try the sun.

Tracking options:
  • Commercial service like Spot messenger GPS. $100 plus annual service fee of $150
  • Amateur RTTY + GPS – Have built a prototype using arduino. cost will be about $120 – but arduino can be used for many other purposes. Can be tracked by anyone with 70cm receiver. ie., all hams.
  • Amateur APRS – Allows worldwide automatic tracking via APRS network. Cost will run about $250 but provides the most extensive automated tracking network possible. Recommend using Byonics equipment for this.
  • Xbee 900mhz 9600 baud radios (from Sparkfun electronics) These radios provide accurate long range tracking, and interface easily with arduino. Down side is that nobody else can track the flight.
  • Emergency GPS tracker units. Like the ones that skiers use. Haven’t priced these but they would provide a way to find the payload long after it lands.
Sensors:

Recommended sensors would include temperature, pressure, altitude, light levels. These should be fairly inexpensive and can be connected to Arduino

Cameras:

Originally I had wanted to have some kind of live web cam thing, but it appears to require extremely high rate of radio transmission which means live tracking with a mobile unit that has a high gain antenna with programmable azimuth and elevation.

So… logistically, the easiest alternatives then involve the need to recover the payload. These include

  • ordinary camera which is triggered at regular time intervals
  • video camera which runs all the time
  • web cam hooked to a raspberry pi which saves data to SD card
  • web cam/ sd card combo controlled by arduino – more difficult.

 

HAB APRS tracking

Notes on high altitude balloon tracking using APRS.

Byonics TT3 is another option – a separate APRS encoder, to be combined with GPS and transmitter, for example:

What are all the pieces I will need to make a complete TinyTrak APRS tracker?

  • You will need:
    • a TinyTrak3 or TinyTrak4 controller (The primary difference is that the TinyTrak4 can decode incoming stations, so you can monitor others if you connect a computer.)
    • a serial GPS recevier, such as our GPS2. (We sell both TinyTraks as a combo above with a GPS2.)
    • a radio/power interface cable to connect to the mic & speaker or data jacks of the 2 meter mobile or handheld radio you will use. (If you don’t have a radio, consider our Micro-Trak line which include the transmitter.)
    • a F-F null modem cable to connect the TinyTrak to your computer serial port for configuration, and possibily for operations for the TinyTrak4.
    • a USB to serial adapter if your computer doesn’t have a serial port.

RTTY with Arduino

Transmitting on 434.650 MHz.

Successfully ran the configuration described in this article

By Anthony Stirk at UKHAS

http://ukhas.org.uk/guides:linkingarduinotontx2

Have only tried 50 baud – but the beacon ran for over an hour without errors. The receiving   setup was done on a Windows 7 computer:

  • Funcube (software defined radio)
  • FCHID (software to tune the Funcube)
  • Spectraview (demodulate signal from Funcube to SSB)
  • FLDigi (decode RTTY using custom setup)

The bandwidth of the RTTY signal was close to 900 instead of something more reasonable like 50. This can be adjusted by trying various resistor values in the voltage divider circuit.

Next steps include building antennas and increasing the baud rate.

 

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.