UKHAS Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Raspberry Pi Guide =====

The pi is an interesting device though hardly ideal for use as a tracker.  For example:

	* Model B needs about 450mA to run.  That's 5-10 times what a normal complete tracker uses.  Model A is better at 115mA
	* It's a bit large and heavy compared to most Arduinos
	* It has an SD card poking out of the end (delicate)
	* It will take some effort and Linux knowledge to run a real-time kernel on it
	* Unlike the Arduino you don't have a large selection of shields to choose from

However, there are some plusses:

	* It has lots more memory than an Arduino or PIC
	* You don't need a device programmer
	* You can choose from lots of Linux software to run on it
	* You can connect a cheap webcam to capture images or video during the flight

This isn't a tutorial on how to make a tracker with a Pi.  Instead it's an introduction to some things you need to know if you're going to make your own tracker with one.  If you don't know how to get an image onto a pi, or ssh into one, then you should first check the pi web site and Google for all that stuff.  My aim here is to save a bit of time for those following the same path I did; not make it so easy that anyone can do it without understanding what they're doing!  Aside from the information here, you will need to know:

	* How to get the pi up and running
	* How to connect to it with putty or some other client
	* Basic Linux cli stuff
	* How to edit, compile and link a C program
	* How to open and close files and ports
	* How to set the serial port baud rate etc.
	* How to read and write serial data
	* How to parse NMEA
	* How to build a telemetry string
	* How to build a suitable power supply
	* How to connect to a GPS
	* How to connect to an NTX2 radio transmitter



===== GPIO Connector =====


This is a 0.1" pitch connector with 2 rows.  You can find the pinouts on the web.  The important ones are the 5V, 3.3V and GND lines, plus the serial port Tx and Rx pins to connect to the GPS (or you could use i2c with some GPS modules).  You can buy little prototyping boards quite cheaply on ebay, or just buy some pin headers and cut a small piece of Veroboard to fit.

You can put the tracker components on here, but I suggest you put the GPS receiver somewhere else to avoid picking up RFI from the Pi.


===== Power =====


The Pi model B runs from 5V at about 450mA (before you start adding anything).  This can be delivered by the Micro-USB power connector, or to the GPIO connector.  In a payload, this could come from a set of AA lithiums and a suitable regulator.  Remember that you'll need to supply an average of 500mA or so, meaning that those cells will only last about 5 hours unless you parallel them or use plenty in series with a switching regulator.

The Pi has various onboard voltages fed from regulators.  The only one we're interested in is the 3.3V line because that's handy for running the GPS etc.  However there's only supposed to be 50mA spare from this line, so you will probably be better off supplying 3.3V from your own regulator.  If you do this, consider using a switching regulator to supply the GPS etc and the pi (remove the onboard regulator and insert your 3.3V on the GPIO connector).  There's an article on the internet about this.

Unless you're using USB devices, you DO NOT need to supply 5V to the Pi - thee whole thing will run happily from 3.3V and an external regulator.  To do this, remove the existing 3.3V regulator (or just snip off the 2 legs) and apply 3.3V tot he 3.3V AND 5V lines from your regulator.  Your two options then are to use a real LDO (the PI one is rubbish and has a 1.12V dropout) such as the MCP1825S, then run that from 4 Lithium cells.  Second option is to use a switching regulator and more cells (the switchers tend to have a higher dropout).  Either way, calculate your expected run time and then test it.


===== Serial =====

The Pi has a serial port brought out to the GPIO connector.  It has 3.3V logic levels so can be connected directly to a GPS receiver.  However, by default (on Raspbian at least) this port has getty (login) running on it.  To stop that, edit inittab and comment out the line for this serial port (/dev/ttyAMA0).

The port is also used for kernel log output.  You need to turn that off too.  Again, check the web for info.


===== Radio =====

Linux isn't a real time operating system, and therefore does not provide accurate timing that you can use in a tracker application to generate rtty.  If you have a beard and sandals you may scoff at this challenge, muttering about "kernel drivers" and "timer interrupts".  If so, head to the [[guides:raspberrypi_advanced|Advanced]] page and have fun.  For the rest of us, it's possible to cheat and use the serial port to send rtty directly to an NTX2 radio transmitter.  You'll need a series resistor to set the frequency gap, and bias resistors to set the voltage offset, just as you would when using a single pin on an Arduino.

You're now probably wondering how to connect the pi to a GPS now that we've used the serial port for the radio.  The pi does have more than one serial port however (as far as can tell) you can only map one at a time to the GPIO connector.  So without some hardware hackery we only have one port available.  My solution was to share that port between NTX2 and GPS.  i.e. Tx goes to the NTX2 and Rx to the GPS.  This means the GPS cannot be "talked to" so I used a Lassen which needs no initialisation.  You could use a UBlox, but you'd then need to connect Tx to the NTX2 and GPS, meaning that those initialisation strings will go out over the air too.  Not a big problem really.

Another option would be to connect to the GPS using a different serial connection - i2c or SPI.  If you use i2c with a UBlox receiver you'll find it doesn't work, because the UBlox does "clock stretching" at arbitrary times, and the Pi ii2c driver doesn't handle that.  You may have to resort, as I did, to using a software "bit-banging" i2c implementation.

Another option would be to use a PL2303 (USB To Serial) device. It's cheap (1€) and quite light. This is working great to discuss with the radio (NTX2) or with the GPS (Ublox). It has been used successfully for UGGY payload with 150 bauds for the radio. For the Ublox that have 3.3V logic, check if your PL2303 is 3.3V or 5V logic and adjust if needed (in case you still power the Pi with 5V). There is a Pin of the chip to unplug from the 5V, and plug to the 3.3V to change the serial logic.

Typically we run the radio at 50 baud.  This is possible on the pi but when I tried it it worked for a few characters only.  I've had better results with 300, 600 and 1200 baud.  The Lassen GPS runs at 4800 baud and the UBlox at 9600 and neither can be reprogrammed down to low speeds, so this means that the tracker program needs to switch baud rates to read the GPS, then switch before transmitting.  And then back again.  So this all imposes some down-time between transmissions.


===== Webcam =====

I had 2 reasons for trying to get a pi working as a tracker.  #1 was "because", and #2 was to be able to use a cheap webcam and run SSDV (Slow Scan Digital Video).  The pi has USB ports which can be used to connect to 1 or 2 webcams, and plenty of memory to hold the image and encode for transmission.

There are issues however.  #1 is that by default, Debian doesn't include the necessary driver, so whilst it will "see" your webcam as a device, it won't install it as a video device.  There's a patch available on the web to sort this.  Or you could try a different distribution (Arch seems favourite for webcam users).

** Update **

Raspbian includes the driver, so the webcam will "just work" if it's a compatible model.

Next, only some webcams work.  Check the rpi hardware compatibility list.  Logitechs should all be OK.

Finally, many webcams need a bit more, or a lot more, than the 140mA allegedly available.  This is because each USB port has a thermal fuse that will limit the current supplied to 140mA.  At this point the 5V at the port will be about 3V, and the webcam is likely to give up or restart.  100mA is probably a more realistic limit.  Of course the fuse can be bypassed with a bit of soldering, which is what I did (my C920 webcam peaks at over 200mA when it focusses).

** Update ** As of September 2012 the model B rev 2 board is being shipped.  The 2 USB thermal fuses have been removed from the board, meaning that high power USB peripherals can be used without any soldering.

Once the webcam is connected it should appear as /dev/video0.  The next step is to install something that can take photos and/or video which can be stored on the SD card and, in the case of jpg images, sent down through the radio link.  I tried uvcconnect, streamer and fswebcam, and can only recommend the latter, and not only because it was written by fsphil of this parish.

If you're storing the images/video, then you'll soon find the SD card fills up.  The default Debian image (and I assume the others) occupy about 2GB, with a partitioning scheme that leaves the rest of your 4/8/16GB card unused.  Check the web for options to either extend the main partition.  In Raspbian this is really easy.

If you want to send live images down to the ground (and if not, why not?), then there is some documentation in the wiki but the simplest option is to use fsphil's SSDV encoder program.  This converts your jpg file to a format which can be sent directly over the rtty link.  Some notes on this:

	* I suggest you send 1 block (256 bytes) at a time, and that after sending you close the port (which in the case of close() in C means waiting for the bytes to get sent), then re-open the port.  Buffering anomalies may happen otherwise.
	* You can send normal telemetry between blocks
	* You probably need a recent dl-fldigi for the decoding to work
	* Choose your image size and compression well.  Large files take a long time to send.  Only about 1 in 4 images will be worth sending, and there's no point spending 15 minutes sending a poor picture when you could spend 5 minutes sending it and then get onto a better one.  Better have a few small pictures than 2 large but poor ones.
	* Make sure the serial port isn't doing NL --> CRNL conversion or similar (otherwise your binary image data is going to get messed up).

** Update **
For those using the PiCAM and Python there is a python module giving access to the camera rather than having to use os.system. This provides a cleaner interface and will potentially be much faster.

Write up on raspberrypi.org can be found at [[http://www.raspberrypi.org/archives/5672]] with installation details at the bottom of the page.

The project details are available on [[https://pypi.python.org/pypi/picamera/|PYPI]] and [[https://github.com/waveform80/picamera/|GitHub]]. The module is also installable via ''apt-get install python-picamera'' or ''apt-get install python3-picamera''

**Update - NEW RASPBERRY PI ADD-ON BOARD**
If this all sounds a bit too much work, you can use Dave & Anthony's [[http://www.pi-in-the-sky.com/|PITS]] add-on board for the Raspberry Pi!