Building a Drone

ribun

New Member
Hello,

i am student of the university of applied siences in wildau germany. We have the task to built a small plane, that ist equipped with a videocam an gps-modul. The video and the GPS Data has to be send to a ground station as live-stream (range at least 400m). Video ressolution has to be 640x480. Can someone tell me which hardware is needed to fullfill this task? It has to be as cheap as possible.


thanks for your help
 

MFB

Senior Member
Live video & GPS

The February 2007 issue of Elektor Electronics magazine had a PICAXE based article about sending live video over a 2.4GHz wireless link, whilst also sending data via the transmitters audio channel. Although designed for model rocketry, the design could easily be used to send video and GPS data from an RC aircraft.

You can download a German, French, English or Dutch version of the above article from the Elektor web site.
 

MFB

Senior Member
Live Video & GPS

Just remembered that Elektor also sell blank pcbs for constructing the transmitter board (PICAXE-18X, video transmitter and audio modulator) and the receiver board (video receiver, audio demodulator and PC serial interface.

If you do not need to measure signals from analog or digital sensors, then you could even leave the 18X out and connect the serial output from GPS receiver directly to the audio modem input. However, this mode of operation would limit the transmission rate to 1200bps but that should be fine for your application.
 

moxhamj

New Member
There are packages available to send the video http://www.rctoys.com/rc-products-catalog/RC-PARTS-WIRELESS-VIDEO-KITS.html 50mW for $450

Alternatively type "security camera wireless" into ebay and up will come lots of packages under $50 out of Hong Kong. I have one sending video 100m using two yagi antennas and I'm sure it will go a lot further as it still works with the yagi pointing in completely the wrong direction. The security cameras are usually 10mW.

I did see a picture once of a chap who had stuck a yagi onto his hat - whenever he was looking at the plane the yagi was automatically pointing in the right direction.

For the GPS data send the data out of a picaxe using serout and send it to the audio stage. It might need dividing by 5 as the picaxe is 5V and most audio runs at 1V. Also an AC coupling capacitor would be needed. Some of the ebay cameras have microphones and obviously the input to a microphone amp would need to be divided down a lot further. At the receiver, an op amp would probably be needed to get the signal back up to 0-5V to go into a picaxe serin pin.
 

MFB

Senior Member
live video & data

Dr Acula. When you suggested connecting a digital signal to the audio input channel of a video transmitter, you forgot to mention any form of modulation. The audio channel could not handle raw serial data (e.g. from the GPS unit) for the same reasons that a dial-up telephone line is unable to be used without a modem.

You would have to format the raw data in such a way has to keep the average dc level as near constant as possible. For example, using Manchester encoding (only possible at low data rates using the PICAXE) or by alternately re-transmitting inverted bytes of data and this would involve software development.

The Elektor video-telemetry system employs an FSK modular that will accept raw serial data without re-formatting (no microprocessor chip or software development required!). It is a very robust means of data transmission that is very tolerant of noise and dropouts.
 

ribun

New Member
we had a project meeting, we have decided to transmit the video signal analog, and maybe use picaxe modul to transmit gps data.
 

moxhamj

New Member
MFB - yes you would need to send data in packets and the average number of 1s and 0s would need to be the same. Manchester coding works but sending every other byte as inverted is easier. Simply subtract the byte from 255 to get the inverted byte - eg 00000001 becomes 255-1=254=11111110. And would need preambles of 6-12 "U"s ("01010101") and a checksum word at the end of the packet -eg send 14 bytes and then a two byte word which is the sum of all the bytes in the packet.

An audio channel can still handle raw data without FSK and a telephone can certainly be configured to send data without a modem. It just needs to be configured so a 0-5V AC waveform appears at the other end as the same 0-5V AC waveform. 1200 and 2400 baud data are just audio waveforms the same as sine waves and speech. Generally speaking, if speech comes through clear then data will as well. Most speech data is 300Hz to 3000Hz so baud rates of 300 to 2400 will work directly down a phone line. 4800 and more will not work as they are filtered out. Modems became popular when people wanted to send data faster than 2400 down a phone line and by using clever phase modulation the data rates can go up to 56,000 baud. But with GPS data speed is not the issue.

GPS data will be in small data packets so not much processing will be needed - just add the preamble "U"s, the checksum and add alternate bytes as the inverted bytes. Perfect for a picaxe. FSK can certainly be added as well but nothing beats having a good clear audio link where speech comes through clear.

Ribun - Ich bin in Übereinstimmung mit Sie - video mit analog und picaxe für GPS.
 

hippy

Senior Member
Manchester coding works but sending every other byte as inverted is easier. Simply subtract the byte from 255 to get the inverted byte - eg 00000001 becomes 255-1=254=11111110.
XOR'ing with $FF is better

Edited : I thought Dr-Acula was having an 'off day' with decimal to binary conversion, but that looks like my "D'Oh!" moment :)
 
Last edited:

moxhamj

New Member
Binary maths is good for the soul! n=255-n and n=$FF xor n are the same. XOR truth table is 00=0, 01=1, 10=1, 11=0. Looking at a binary subtraction using one bit, 1-0=1 and 1-1=0 which corresponds to the 10 and 11 of the xor truth table, and the other two conditions of the xor never apply (01 and 00) because the $FF is always a 1. There are no borrows in the subtraction as there is never a 0 minus 1. For an exercise to really induce a headache, try a 32 bit binary division using machine code!

Ribun - if the packet description doesn't make sense I can post some code. The complex bit will be getting the AC waveforms to match and you might need to use op amps. Has your lab got a CRO?
 
Last edited:

ribun

New Member
In the moment i don't need code, we do not have the hardware right now. I will request further help, if needed.

Thanks to all for the quick response....
 

MFB

Senior Member
live video & data

Dr Acula, I think we are in agreement that without an FSK modem it will be necessary to re-format the GPS data before transmission over an audio link. I have tried a number of approaches, like using dedicated Manchester packet encoder chips, but found them less efficient than FSK modulation. For a given bandwidth, Manchester encoding starts by halving the available data rate and then all the overheads associated with preamble, framing etc further reduces the ‘over air’ data rate.

Even though many transmitters/encoder combinations have 9.6kbps input buffers, I have found the continuous data rate to be more like 200bps and that’s if you don’t have to discard complete packets because of short interference glitches. Much depends on your application but, unless you plan to download programmes to a Mars rover, I suggest using simple and robust FSK modulation.
 
Top