Category Archives: Arduino

VirtualWire for UAV telemetry

We have been doing some development work recently involving sending telemetry from Unmanned Aerial Vehicles (UAVs) over 2.4GHz radio links, and have successfully used our Virtual Wire library
(http://www.airspayce.com/mikem/arduino/VirtualWire) as the data protocol.

Our work centred around using the otherwise unused audio channel in a
Audio-Visual (A/V) transmitter/receiver as the channel for data
transmission. We tested 2 different A/V transmitters with Arduino and Flymaple microprocessors, and were able to send data reliably at up to 4000 bits per second over modest bandwidth audio channels.

So why do we need Virtual Wire? Why not just send ordinary async serial data?
The reasons are:
– Ordinary async data is not DC balanced and will cause the average voltage of
an analog data channel to vary greatly.
– Ordinary async data is prone to corruption by the sort of noise you might
get in analog channels.
– For reliability, you also need checksums to verify correct data delivery.

Virtual wire overcomes all these problems for reliable data delivery on a
limited bandwidth, poor quality link.

Digitech AR-1872 2.4GHz Digital Wireless AV Transmitter and Receiver

This is a consumer level, low power 2.4GHz transmitter/receiver pair. Unlike
some other A/V transmitter systems, this one expects to have 2-way
communications between the ‘transmitter’ and the ‘receiver’. This is so that
IR remote control signals can be relayed from the ‘receiver’ to the
‘transmitter’ and presumably to coordinate the frequency hopping/spread
spectrum. It carries a video and 2 (stereo) audio channels.

We measured the following characteristics of the audio channels:
Tx input impedance – 2kohms
Rx output max load ~ 20kohms: greater load results in distortion of the output
Overall gain Tx to Rx ~ 1:1
Max Tx input ~ 3V p-p, resulting in about 3V p-p Rx output
Bandwidth (1/2 voltage) 50Hz to 21kHz
Interestingly, there is some significant buffering between the transmitter and
the receiver, as input to the transmitter audion would only appear about 250ms
later on the receiver output.
Square wave inputs to the transmtter at 5kHz would show evidence of ringing
and overshoot at the receiver, while 10kHz square waves ended up looking more like a sine wave.

We tested this AV link with Arduino Uno
(http://arduino.cc/en/Main/ArduinoBoardUno) as transmitter and receiver running VirtualWire as a transmitter/receiver pair, using the following circuit:

http://www.airspayce.com/mikem/docs/av-transmitter-digitech.pdf

No buffering or level shifting was required for the transmitter input. Although
the output from the Arduino transmitter was 5V p-p digital, this was handled
by the Tx audio input.

An op-amp buffer on the output of the receiver is necessary, because the input
to the receiver Arduino would have been too low in voltage (3V instead of 5V)
and would have loaded the AV receiver too heavily. The op-amp is configured as
a comparator with a voltage clamp preceding it.

With this configuration, we were able to reliably send long messages of 71 octets payload using Virtual Wire at 8000 bits per second.

Lawmate TM-240500 transmitter and RX-2460 receiver

This is a more professional, 2.4GHz 500mw transmitter and receiver, with a
video and single audio channel. However, the quality of the audio channel is
poorer than the Digitech.

We measured the following characteristics of the audio channel:
Tx audio input impedance ~ 4kohm
The gain in the centre of the bandpass region was bout 8, with up to 8Vp-p
output for 1Vp-p input.
Bandwidth (1/ voltage) 15Hz to 4kHz.

If the input to the transmitter exceeds ~ 1.8Vp-p, get intermodulation
distortion of the audio signal.

Tx power consumption @ 12V: 270mA
Rx power consumption @ 12V: 260mA

We tested this AV link with Flymaple boards
(http://www.open-drone.org/flymaple) as transmitter and receiver running VirtualWire as a
transmitter/receiver pair, using the following circuit:

http://www.airspayce.com/mikem/docs/av-transmitters-lawmate.pdf

The Flymaple is a 3.3 V board, therefore we needed some limiting on the
digital input to clamp the input voltage range to 0 to 3.3V. The output of the
transmitter Flymaple needed to be limited to about 1Vp-p, else it would
overmodulate the transmitter.

With this configuration, we were able to get reliable transmission of 36 octet
payloads at 4000 bits per second.

Seeed BlueTooth shields and Linux

This is an expansion of an earlier article originally published at
http://www.seeedstudio.com/forum/viewtopic.php?f=23&t=4586&sid=d813605d07038d3b3593f48e9587a682

After some struggles, we have managed to get an Arduino with the Seed SLD63030P BlueTooth shield:

http://www.seeedstudio.com/wiki/index.php?title=Bluetooth_Shield

and a Linux host to pair up and pass serial data between them. Details follow, since we could not find this detailed process documented anywhere else:

The host computer was OpenSuSE 12.3 32 bit, with Arduino 1.0.2 with the Seeed Studio BT shield plugged in to a Uno. We used a Targus ACB75AU Bluetooth/USB adapter from Harvey-Norman and also tested OK with a Digitech Bluetooth/USB adapter from Jaycar.

The Uno was loaded with the BlueToothShieldDemo Slave sketch, downloaded from Seeed:

http://www.seeedstudio.com/wiki/images/3/30/BluetoothShieldDemoCode.zip

Caution: you need to modify this version of the sketch to make it compile with Arduino 1.0: replace 2 instances of “NewSoftSerial” with “SoftwareSerial”

Steps:

Power up the Uno with the Seeed BT shield and BlueToothShieldDemo slave sketch installed, observe alternate red/green flashing lights on the BT shield. Open the Arduino IDE serial interface to the arduino port, see a startup message:

The slave bluetooth is inquirable!

Insert the BT/USB adapter into the OpenSuSE host. Observe that the Bluetooth icon appears in the dock.

If you open the Bluetooth icon in the dock dock, and select Add Device, a window will open: you should see the name of your BlueTooth shield (SeeedBTSlave) appear there. Dont bother trying to connect that way though, cause it wont work.

Instead open a shell terminal as root.

First, you need the MAC address of your BlueTooth shield. Enter the command:

zulu:/home/mikem # hcitool scan
Scanning ...
    00:13:EF:00:06:80       SeeedBTSlave

Here, 00:13:EF:00:06:80 is the MAC address of the shield you wish to connect to. To pair with the shield, enter the command:

rfcomm connect rfcomm4 00:13:EF:00:06:80 1

(where 00:13:EF:00:06:80 is the MAC address of your shield)
Observe:

Connected /dev/rfcomm4 to 00:13:EF:00:06:80 on channel 1 
Press CTRL-C for hangup

A popup window will appear in the dock from the Bluetooth icon, saying that the device has been paired, and containing a button that says “Intro..”. Click on this button (do it quick; the icon only appears for about 10 secs), you can then enter the PIN for the bluetooth shield (default ‘0000’).

A new device /dev/rfcomm4 will be created, which is connected to the shield and sketch. The Arduino will print some state information to its serial port:

+BTSTATE:3
CONNECT:OK
+BTSTATE:4

Pairing is now complete.

On the Linux host, connect a serial comms program to the new device /dev/rfcomm4, your preference, minicom, cutecom etc. We used cutecom. Select /dev/rfcomm4 as the device to open. Baud rates etc are irrelevant, but we used 9600 8N1.

Now when you Input text in your cutecom terminal it will appear on the Arduino serial output, and when you use the Arduino line input in its window, the text will appear in your cutecom terminal. This proves two-way serial communications between Linux and the Bluetooth equipped Arduino.

Other helpful information:

http://www.piaccess.com/trac/wiki/Linux_BlueZ_Bluetooth_Serial_Setup 
http://www.heatxsink.com/entry/how-to-pair-a-bluetooth-device-from-command-line-on-linux 

Arduino I/O performance

I recently conducted some performance tests on a number of Arduino variants, looking specifically at digital IO speeds. I tested PCDuino, Arduino Uno and Chipkit Uno32. The same basic code was run on each:

void setup() {
pinMode(6, OUTPUT);
}
void loop() {
digitalWrite(6, HIGH);
digitalWrite(6, LOW);
}

which just turns pin 6 on and off as fast as possible, resulting in a square wave output. Speed was measured with a Tektronix TDS220 oscilloscope.

PCDuino

This is a Ubuntu based SBC based on the Winrunner A10 chip running at 1GHz. It contains a full Linux distro including development environment and an Arduino compatible library. You can write C/C++ programs directly on the PCDuino, and link them against the libarduino library. Your program must be run as root, and runs as a normal user process (and is therefore subject to swapping).

Results:

3.3V square wave at 165kHz. There was some jitter in the pulse widths, but importantly, if another process is running, your IO program will stop running occasionally. I observed 10ms gaps in the pulse stream when another compile was running at the same time as the IO program.

165kHz is quite slow considering the chip runs at 1GHz. This is because the digitalWrite commands are passed to the hardware through file IO accesses. It is apparently not possible to talk to the IO hardware directly.

Conclusion:

Moderately fast, but dont use it for hard real-time processing.

Arduino

The well known Arduino microcontrollers include the Uno which was tested here. It runs at 16MHz, programmed in C or C++ from a PC based IDE.

Results:

5V square wave at 97kHz. There was no significant jitter in individual pulses, but I was able to observe occasional events where an individual pulse was not emitted or perhaps delayed. This is quite possibly due to interrupt handling in the Arduino timer core.

Conclusion:

Not too fast but reasonable hard real time behaviour.

ChipKit Uno32

This is an Arduino compatible (mostly) microcontroller using a PIC32MX320F128 processor running at 80Mhz. Programming it requires a custom version of the Arduino IDE which you can get from Digilent.

Results:

3.3V square wave at 355KHz. No significant jitter, but occasional delayed or missing pulses as with Arduino above.

Conclusion:

Good choice for speed and hard real time behaviour.