[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Paparazzi-devel] telemetry over wifi...

From: Gerard Toonstra
Subject: [Paparazzi-devel] telemetry over wifi...
Date: Wed, 24 Oct 2012 10:22:33 -0300

Hi all,

I've had a couple of issues with xbees lately and just got tired of it. My explorer board doesn't work anymore, the XBee
shield seems broken and it's a pain "configuring" the xbees just right.

So I decided to put some work into providing support for another method of transport, over wifi. Preliminary support seems there.
This is all written using the new libopencm3 SPI subsystem, which is still undergoing more changes for improvement.

Using this board:
I've put together some support for this w5100 chip in the new SPI implementation branch, mostly done by introducing a new
"transport type" the same way the xbee was added. The chip is connected to the Lisa/M2 using the external SPI connector,
so pretty simple.

Although the datasheet hints at 2.8Mb/s telemetry, actual throughput over SPI is "only" about 0.3Mb/s. The 2.8Mb/s is only valid
for direct interfacing with the MCU. 0.3Mb/s is at least 2x faster than the xbees.

The chip has a hardware-based tcp/ip stack onboard, but no transmitter. The idea is that all data is "prepped" to allow this
to be transmitted over a regular wifi 802.11n transmission for example.  You can get some really interesting "outdoor" transceivers
from here:

"MicroTik" is another that has similar modules.  They offer ranges up to 50km or so and you have a lot of liberty in setting
parameters to provide better reception, reduce modulation settings, etc.  You can get a "bullet" for the ground station.

Regular household transmitters are likely to fail beyond 500m or so due to hardcoded timings in the firmware, so I wouldn't
suggest hacking any one of those you may have available. In these modules, the timeout can be modified and modulation can be
fixed, which has implications for the maximum transfer rate, but should work for anything up to 7Mb/s with great reliability.

The nice thing about the Ubiquiti is that it runs on anything between 12-24V DC and thus doesn't comply with the official PoE standard,
to just putting power on the lines works. I'm using 4S here, so have a safety limit. 3S may have some issues. 
The picostation can be taken apart by removing the sticker, which gets you only a PCB with all the stuff on it, weighing around 80g or so.

The disadvantages of the chip at the moment are:
- The SPI interface uses 4 bytes to write one "data" byte each time. So sending 13 bytes actually transfers 52 bytes over the bus.
- The XBees are simplest to use in the field and require only a USB connector and are thus "battery powered".
  Ground based wifi solutions either require a DC-AC pure sine converter, or use a custom power supply.
- I'm concerned about the CPU time it's consuming for SPI operations. That needs a lot more work to make it better.

The advantages are:
- You can run quite a couple of these stations on the same wifi network (swarming?), connected to the same ground station,
     where each individual endpoint doens't affect the overall bandwidth that much. Xbees only go up to 115k baud, but reliable
    wifi can be guaranteed up to 7Mb/s at lower modulation rates with much larger distance.

- Lab testing can be done by connecting the jack to your lab's router using an ethernet cable and running a multicast rx program on any computer that is connected to the same.

- Higher throughput of data (at least twice?). Limits not yet tested.

- Data is multicast, so you can run multiple laptops on the ground connected through a small router, which allows you to perform different
   kinds of processing without copying telemetry streams.

- You can add more IP-based devices onboard... There are two days to do that:
    * You can use Gumstix overo boards together with a Tobi Duo on top. (haven't tested this myself, but theoretically should work.)
    * You can get a Cyberdata 5V simple router:
       Take apart the case, wrap it into an RF shield (it does generate quite a lot, affecting GPS), then connect both AP+Device with the
      other port going to the wifi transceiver.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]