PaparazziUAV - User contributions [en]

Pixhawk

2019-10-07T19:00:53Z

Jkg: fix github link to iris airframe

<div style="float: right; width: 45%; overflow: hidden">[[File:Pixhawk 1 v2.4.jpg|thumb|Pixhawk 1 v2.4]]</div>

=Paparazzi on Pixhawk=

The Pixhawk is an open hardware autopilot that was originally developed by ETHZ in the [https://pixhawk.ethz.ch/ PIXHAWK project]. Paparazzi now supports the Pixhawk and the firmware can be uploaded through the orignal PX4 custom bootloader, which happens directly through the USB port of the Pixhawk. This means that it is possible to easily switch between the Paparazzi AP and other projects that support the Pixhawk hardware (i.e. PX4 and APM).

It is also possible to directly upload to the Pixhawk by means of the JTAG port, but this is not recommended as it involves soldering and permanently removes the PX4 bootloader (which means reverting to PX4 or APM firmware is complicated). Therefor, this wiki focuses on flashing through the PX4 bootloader.

An step-by-step example on flying Paparazzi with a Pixhawk can be found on the [[Iris]] page.

=Intro=

This page is intended as a guide on how to get the Paparazzi autopilot running on a Pixhawk board. For the specifications and pin-out details we recommend to look at the [https://pixhawk.org/modules/pixhawk Pixhawk site]. Details on how to flash the board with Paparazzi can be found [[#Flashing|below]]. A complete step by step example on how to get a drone flying with Paparazzi + Pixhawk is provided with the [[Iris]] drone. A list of features that are currently (not) supported in Paparazzi can be found [[#Features|here]].

The Pixhawk consists of the PX4IO (designed around a stm32f1) and the PX4FMU (designed around a stm32f4), which are glued together in one pcb. Uploading of the autopilot (which runs only on the PX4FMU) happens directly from computer over USB to the PX4FMU, by means of the PX4 bootloader. In the original PX4 and APM Pixhawk software, the compiled PX4IO code (which runs the Fly By Wire) is embedded with the PX4FMU code, and the PX4FMU code would flash the PX4IO board at startup. But, in Paparazzi, the PX4IO is flashed from the computer --> USB -> PX4FMU --> internal UART --> PX4IO, directly from Paparazzi Center. This means PX4IO board can be flashed without changing the autopilot, and vice versa.

=Getting started=

In short, the steps you'll need to run through are roughly the following:

*1. Define your aircraft and settings for the Pixhawk (e.g. see the [https://github.com/paparazzi/paparazzi/blob/master/conf/airframes/tudelft/iris_indi.xml Iris airframe] )
*2. Connect the Pixhawk via USB to your computer, and upload the AP firmware
*3. Replug the USB, and upload the FBW code. Replug USB again.

Details on steps 2 and 3 can be found in [[#Flashing|Flashing]]. Details on step 1 can be found [[#Airframe config|further below]].

=Flashing=
[[File:Build AP.jpg|thumb|Figure 2; building the AP]]
[[File:Upload AP.jpg|thumb|Figure 3; flashing the AP]]
[[File:Build FBW.jpg|thumb|Figure 4; building the FBW]]
[[File:Upload FBW.jpg|thumb|Figure 5; flashing the FBW]]

In order to flash the Pixhawk, both the AP (AutoPilot on the PX4FMU) and the FBW (Fly By Wire on the PX4IO) have to be flashed. Paparazzi uses the default PX4 bootloader to upload and flash the code in both systems, but the FBW is flashed through the AP. This means that at least for the first time, the AP has to be flashed with Paparazzi first.

* To flash the AP (See figure 2 and 3):
** Select your aircraft (1).
** Select the AP (2).
** Click the build button (3).
** After the compilation was completed successfully (4), plug in the USB cable to computer and the Pixhawk.
** After 5 seconds click upload (5).
** You should see "upload successful" (6).

* To flash the FBW (See figure 4 and 5):
** Select FBW (7).
** Click the build button (8).
** After the compilation was completed successfully (9), plug in the USB cable to computer and the Pixhawk.
** Between 10 to 20 seconds after replugging, click upload (10).
** You should see "upload successful" (11).

Notes:
* After flashing the FBW, it is required to re-power the Pixhawk.
* The flashing of the FBW is disabled 20 seconds after power up. Re-power to reset the time.
* If the Pixhawk is in view, one can monitor the system (B/E) led of the autopilot (left, FMU side). After 10 seconds, the system led will blink slower, meaning the autopilot has booted and the FBW can be flashed. After 20 second, the system led will blink slow (1Hz), meaning the FBW cannot be flashed any more.
* Whether the current code is APM, PX4 or Paparazzi, the flashing steps remain the same.
* In case of problems such as in figure 6, most of the time it can be solved by re-powering the Pixhawk (e.g. re-plugging the USB, and removing the battery), wait for 10 seconds for the computer to recognize the USB device, and click the upload button again.

[[File:Upload problems.jpg|thumb|Figure 6; upload problems]]

=Airframe config=

In order to fly a drone with the Pixhawk system in paparazzi, some Pixhawk specific configuration is required.

* Define seperate <firmware>'s for both the fbw and the ap:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<target name="ap" board="px4fmu_2.4" />
</source>}}
And:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<target name="fbw" board="px4io_2.4" />
</source>}}

*Configure the interMCU communication to use UART 6 at the AP:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<module name="intermcu" type="uart">
<configure name="INTERMCU_PORT" value="UART6" />
<configure name="INTERMCU_BAUD" value="B1500000" /> 
</module>
</source>}}
And at the FBW:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<define name="INTERMCU_LOST_CNT" value="100" />
<module name="intermcu" type="uart">
<configure name="INTERMCU_PORT" value="UART2" />
<configure name="INTERMCU_BAUD" value="B1500000" />
</module>
</source>}}
Configuration of the baud at 1500000 is strongly recommended, as this will remain backwards compatible with the PX4 code and bootloader. However, in Paparazzi the baud rate is slowed down to 230400 10s after start up, as the Pixhawk hardware actually does not seem to support flawless data transfers at those speeds. At least not in Paparazzi.
*Define the IMU to be:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<module name="imu" type="px4fmu_v2.4"/>
</source>}}
Which uses the l3gd20 gyro and the lsm303d accelero. The Pixhawk has two IMU's, so alternatively you can also use the MPU6000 IMU:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<module name="imu" type="mpu6000"/>
</source>}}

*Add the px4_flash module:
{{Box Code|conf/airframes/<yourairframe>.xml|<source lang="xml">
<modules main_freq="512">
<module name="px4_flash">
<configure name="PX4IO_UART" value="uart6"/>
</module>
...
</source>}}
This enables uploading through the PX4 bootloading and activates the usb-serial device after startup.

=Features=

The features that are currently supported by Paparazzi are the following:
*The dual processor setup (main stm32f4 and co stm32f1 processor), in a AP (AutoPilot) + FBW (Fly By Wire)
*Dual IMU (selectable from airframe config)
**MPU6000, 3axis acc + gyro + magneto
**LSM303 3-axis acc + magneto, L3G 3-axis gyro
*External GPS + Magneto
*8+6 pwm outputs (8 on FBW, 6 on AP)
*Arm button led denotes mode info
*Spektrum RC, including binding through software
*PPM RC

The features that are not yet supported by Paparazzi are the following:
*The multicolor LED
*The buzzer
*The on-board arm button
*The SD card SDIO
*RC downlink (e.g. gps info, battery info)

=Videos=
Paparazzi UAV Pixhawk tutorial videos - by the [http://mavlab.lr.tudelft.nl/ TU Delft MAVLab] <br>
{{#ev:youtubeplaylist|PL_KSX9GOn2P-CVsy-lRSHAnUwVF9wI_pZ}}
<br style="clear:both">

Installation/MacOSX

2015-09-22T21:04:04Z

Jkg: /* Installing from Source (Homebrew/Opam) */ added explicit link to directions for getting source code from github

Installation/MacOSX

2015-09-22T02:06:24Z

Jkg: /* Installing from Source (Homebrew/Opam) */ typo

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Installation</categorytree>
__TOC__

'''Update on OS X installation: Currently, arm-none-eabi-gdb on 10.6 should be broken (gcc-arm-embedded can be compiled by hand if required without python support, or installing python2.7 as a framework from a dmg might work).'''

'''(Feb. 1, 2014) Current OS X limitations:'''
* '''10.6.* requires some manual effort to properly install gcc-arm-embedded, email the mailing list if help required (gcc-arm-embedded can be compiled by hand if required without python support, or installing python2.7 as a framework from a dmg might work)'''
* '''There is no cross compiler for the ARDrone2.'''

= Intro =
Would it not be great to also be able to run Paparazzi from your shiny Apple Mac? Well, this page explains how you can manage to do just that.

The task of supporting Paparazzi on Apple MacOS X is ongoing as the project evolves and the more people adapt it the process will be streamlined. Presently it is known that Paparazzi will install on OSX versions 10.6.*, 10.7.*, 10.8.*, and 10.9.*. Support on 10.6.* requires some additional effort.

= Basic Install (Binary Installer) =
Depending on the version of Mac OS you have installed on your computer the installation process will vary slightly. Also this install process is only recommended for beginners. If you want to be able to use more up to date Paparazzi and be able to track the development more closely, you should consider installing Paparazzi tools using the source solution described in the next chapter.

== Installation Video Tutorials (On OS X 10.9.* '''Mavericks''') ==

{{#ev:youtubehd|s5KFZqxqAr4}} {{#ev:youtubehd|lXB1y0Dv2y0}}

== Basic Install (Binary Installer) (On OS X 10.9.* '''Mavericks''') ==
If your Apple Mac operation system is OSX Mavericks or newer then the easiest way to get started with Paparazzi on your Apple Mac is to start with the following Basic install. If you have an older version you want to follow the slightly longer Basic install, below.

The steps you need to take to enjoy Paparazzi are:
# Install XQuartz from [http://xquartz.macosforge.org MacOSForge]. (You can alternatively use the X11.app if it is available for your version of Mac OS X.)
# Open the Terminal.app
# Install the command line tools by executing: <source lang="bash">xcode-select --install</source> and clicking on the "Install" button in the dialog that will pop up.
# Install the Paparazzi Tools installer for your OS version from [http://download.paparazziuav.org/darwin/ paparazziuav.org]
## You might get an error saying: "paparazzi-tools-xxxxxx.mpkg can't be opened because it is from an unidentified developer." To get rid of this error you will need to:
### Open "System Preferences"->"Security&Privacy" and change the "Allow apps downloaded from:" setting to "Anywhere". (The option might be greyed out. To activate the selection you will need to authenticate yourself as system administrator. Click on the lock in the left lower corner of the "System Preferences" window, to open the authentication window.)
# Set up your environment variables and Python appropriately using the pprz-env-set script:
## Get the script: <source lang="bash">curl https://raw.githubusercontent.com/paparazzi/paparazzi-portability-support/master/darwin/install/Contents/Resources/pprz-env-set >~/Desktop/pprz-env-set</source>
## Move script to right location: <source lang="bash">sudo mv ~/Desktop/pprz-env-set /opt/paparazzi/bin/pprz-env-set</source>
## Change script permissions: <source lang="bash">sudo chmod 755 /opt/paparazzi/bin/pprz-env-set</source>
## Run the script: <source lang="bash">sudo /opt/paparazzi/bin/pprz-env-set</source>
## Close the terminal. (Do that before you try to move on to the next step. Otherwise the newly set environment will not take effect and you will end up with compilation errors.)
# That's it! To run Paparazzi you need to open the Terminal app and build and run Paparazzi.
## In spotlight type Terminal and then open the Terminal App
## then type: <source lang="bash">cd ~/paparazzi && make && ./paparazzi</source> (The first time you start paparazzi it might take several minutes to show a window. It is because GTK is indexing the fonts the first time it starts up.) (If you get the error: "Fatal error: exception Gtk.error("GtkMain.init: initialization failed ml_gtk_init: initialization failed")" the most likely source of the issue is the lack of X11 server. Install either X11.app or XQuartz as mentioned in step 1.)

Notes:
* the binary installer will check if ~/paparazzi exists on your system. If it does, then the installer does nothing. If this directory does NOT already exist, the installer will automatically clone the Paparazzi Git repository into that directory.
* the binary installer will add a few lines to your ~/.profile for PATH modification and for default PAPARAZZI_HOME and PAPARAZZI_SRC env vars. If you have something other than the default ~/paparazzi installation, please edit your ~/.profile and comment out the env var exports.
* the binary installer creates a symbolic link between the available /opt/paparazzi/bin/python2.7 and /opt/paparazzi/bin/python. Combined with the PATH modification, this will cause <source lang="bash">python something.py</source> to call /opt/paparazzi/bin/python2.7 instead of any system pythons.

== Basic Install (Binary Installer) (Support: 10.7.* '''Lion''', 10.8.* '''Mountain Lion''') ==
If your Apple Mac operation system is OSX Snow Leopard or Lion or newer then the easiest way to get started with Paparazzi on your Apple Mac is to start with the Basic install.

The steps you need to take to enjoy Paparazzi are:
# Install XQuartz from [http://xquartz.macosforge.org MacOSForge]. (You alternatively can install the X11.app from Apple. If it is available for your version of Mac OS X.)
# Install the latest available [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Xcode] development tool for your OS, we had good success with [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Xcode] v4.2 on Snow Leopard and v4.3.2 on Lion. For Snow Leopard, Xcode 3.2.6 also works and is still available as a [https://developer.apple.com/downloads/ free download] with an Apple ID (search for ''xcode 3.2.6'').
## With Xcode 4.3 and above you need to install the command line tools. Xcode --> Preferences --> Downloads --> Components --> Command line tools
## Check that the correct version of Xcode is being used for compilation <source lang=bash>/usr/bin/xcodebuild -version</source> It should return the version of Xcode that has been installed, e.g. 4.2. In the rare case you need to change your XCode version run the following command in your terminal: <source lang=bash>sudo /usr/bin/xcode-select -switch /Applications/Xcode.app/Contents/Developer</source>
# Install the Paparazzi Tools installer for your OS version from [http://download.paparazziuav.org/darwin/ paparazziuav.org]
# Set up your environment variables and Python appropriately using the pprz-env-set script:
## Get the script: <source lang="bash">curl https://raw2.github.com/paparazzi/paparazzi-portability-support/master/darwin/install/Contents/Resources/pprz-env-set > ~/Desktop/pprz-env-set</source>
## Move script to right location: <source lang="bash">sudo mv ~/Desktop/pprz-env-set /opt/paparazzi/bin/pprz-env-set</source>
## Change script permissions: <source lang="bash">sudo chmod 755 /opt/paparazzi/bin/pprz-env-set</source>
## Run the script: <source lang="bash">sudo /opt/paparazzi/bin/pprz-env-set</source>
## Close the terminal. (Do that before you try to move on to the next step. Otherwise the newly set environment will not take effect and you will end up with compilation errors.)
# That's it! To run Paparazzi you need to open the Terminal app and build and run Paparazzi.
## In spotlight type Terminal and then open the Terminal App
## then type: <source lang="bash">cd ~/paparazzi && make && ./paparazzi</source> (The first time you start paparazzi it might take several minutes to show a window. It is because GTK is indexing the fonts the first time it starts up.) (If you get the error: "Fatal error: exception Gtk.error("GtkMain.init: initialization failed ml_gtk_init: initialization failed")" the most likely source of the issue is the lack of X11 server. Install either X11.app or XQuartz as mentioned in step 1.)

Notes:
* the binary installer will check if ~/paparazzi exists on your system. If it does, then the installer does nothing. If this directory does NOT already exist, the installer will automatically clone the Paparazzi Git repository into that directory.
* the binary installer will add a few lines to your ~/.profile for PATH modification and for default PAPARAZZI_HOME and PAPARAZZI_SRC env vars. If you have something other than the default ~/paparazzi installation, please edit your ~/.profile and comment out the env var exports.
* the binary installer creates a symbolic link between the available /opt/paparazzi/bin/python2.7 and /opt/paparazzi/bin/python. Combined with the PATH modification, this will cause <source lang="bash">python something.py</source> to call /opt/paparazzi/bin/python2.7 instead of any system pythons.

== Basic Uninstall ==
In the case you would like to uninstall Paparazzi after completing a basic installation, one must type the following in your terminal prompt:

'''Warning''' This first step removes your paparazzi source code, including any changes you may have made yourself locally. If you want to keep your git repository intact, skip this first step and only use the following two steps.

<source lang="bash">rm -rf ~/paparazzi</source>

<source lang="bash">
sudo pprz-env-set -u
</source>

<source lang="bash">
sudo rm -rf /opt/paparazzi
</source>

Note that pprz-env-setup -u removes the entry from ~/.profile and also removes the /opt/paparazzi/bin/python symlink.

== Using Luftboot and PyUSB ==

'''UPDATE:''' The lastest binary installer should have PyUSB included by default, no need to install it separately.

If you are planning on loading code onto a Luftboot-equipped STM32 board, you will need to have a Python version on your machine that is active and with [http://sourceforge.net/apps/trac/pyusb/ PyUSB] installed for that version.

To install PyUSB, execute
<source lang="bash">
sudo python setup.py install
</source>
from inside the unzipped PyUSB source directory.

To test which Python version is the default and whether this Python version can find the PyUSB module, in Terminal simply type:
<source lang="bash">
python
</source>
To start the default Python. At the Python prompt (>>>) type:
<source lang="bash">
import usb
</source>
If another prompt line comes up, PyUSB is installed correctly and you will be able to use Luftboot. If an error is thrown, then your configuration is not correct.

== MacPorts and PyUSB ==
If you have MacPorts installed, you can install either <code>py26-pyusb</code>, <code>py26-pyusb-devel</code> or <code>py27-pyusb-devel</code>, depending on which Python(s) you have installed already, or wish to install. For example:
<source lang="bash">
sudo port selfupdate
sudo port install py27-pyusb-devel
</source>

To find out what versions of Python are available on your system (via MacPorts):
<source lang="bash">
port select --list python
</source>
Default Apple Python versions have a -apple ending.

Select a different version of python to be the active version if desired. For example:
<source lang="bash">
sudo port select --set python python27
</source>

A good, working configuration would be to have MacPorts installed, and install <code>py27-pyusb-devel</code>, then ensure that python27 is the active version.

== Adjusting your PATH and Troubleshooting ==

There are sometimes path issues with OS X if you have MacPorts or a similar (Homebrew, Fink) system installed. The reason for this is there may be multiple copies of a binary required for Paparazzi in different places, and depending on the path, the desired instance is not correctly called. This often presents itself as an error when building the main Paparazzi source code. A typical error may involve the <code>pkg-config</code> program. This can often be corrected by checking and adjusting your PATH environment variable.

To check the currently configured default PATH:
<source lang="bash">
echo $PATH
</source>
Ideally, the Paparazzi binary paths (<code>/opt/paparazzi/bin</code> and <code>/opt/paparazzi/sbin</code>) should come first. To move the Paparazzi paths to the highest search priority:
<source lang="bash">
export PATH=/opt/paparazzi/bin:/opt/paparazzi/sbin:$PATH
</source>
This will only be active in the current terminal session. If you wish to manually modify the path permanently, you can edit ~/.profile and add the above line to the bottom of the file.

= Installing from source (MacPorts) =
Note: This is known to work for Mac OS X MountainLion. For newer Mac OS versions you should try the Homebrew based install.

The tools that are required to work with paparazzi on a Mac are installed from MacPorts. All of the commands are given by terminal commands, please open your terminal first.

In case you '''already have MacPorts installed''', it is advised to run the following steps before proceeding:

# check that /opt/local/bin is the first entry in your PATH, easy to check by giving the following command <source lang="bash">echo $PATH</source>
# Then give the following command to make sure your ports are up-to-date <source lang="bash">sudo port selfupdate && sudo port upgrade outdated</source>
..great, you now can run the installation steps starting from step '''4''' below.

If you don't already have MacPorts installed run the following steps:

# Install the latest [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 XCode]. If you are using 10.9 (Mavericks) or newer you just need to run <source lang="bash">xcode-select --install</source>
# If you are using Mountain Lion, X11 is no longer included by default, use the [http://xquartz.macosforge.org/landing/ XQuartz project] to install it.
# Install [http://www.macports.org/install.php MacPorts]
# Edit the file <source lang="bash">/opt/local/etc/macports/sources.conf</source> and above the <source lang="bash">rsync://...</source> line add <source lang="bash">rsync://rsync.paparazziuav.org/macports/ports/</source> It is important that this line comes before the path to the standard ports as some of the Paparazzi ports are intended to replace the standard versions. The file is write protected so it will be necessary to be root in order to edit it. The simplest way is to open a terminal window and use nano thus: <source lang="bash">sudo nano /opt/local/etc/macports/sources.conf</source>
# Now update the available ports with the command: <source lang="bash">sudo port selfupdate</source>
# To install all of the paparazzi prerequisites: <source lang="bash">sudo port install paparazzi-tools</source>
# ...Then go and have lunch, get a coffee, get some sleep. This will probably take a long time.
# After installation, we need to set the correct python to override the default OS X python: <source lang="bash">sudo port select --set python python27</source>
# You can also [[#Changing the GTK look and feel|change the GTK theme]]

Now you can follow the generic instructions for [[Installation|installing the paparazzi source]].

'''NOTE:''' If you had previously used MacPorts to install Paparazzi, you may need to manually uninstall arm-none-eabi-binutils, arm-none-eabi-gcc-linaro, and arm-none-eabi-gdb prior to upgrading paparazzi-tools. libcmsis, libopenstm32 and libopencm3 ports may need to be uninstalled as well. For example:
<source lang="bash">sudo port uninstall -f libcmsis libopenstm32 libopencm3 arm-none-eabi-gdb arm-none-eabi-gcc-linaro arm-none-eabi-binutils</source>

== Lion and XCode 4.3 or newer notes ==

After installing Xcode 4.3 you will need to install the command line tools by opening the XCode preferences pane, Downloads and selecting Command Line Tools for isnstallation. Otherwise you will not find GCC in your unix path.

Also if macports is complaining about xcodebuild and that you should run

<source lang="bash"> sudo xcode-select -switch /Applications/Xcode.app </source>

You should actually run

<source lang="bash"> sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer</source>

so that xcodebuild can find the needed executables for you.

== Troubleshooting ==
If you continually experience problems installing paparazzi or paparazzi-tools then it may be that you have some other conflicting software installed. i.e. an old version of a library in /usr.

One way to work around issues relating to prior MacPort installs that has been found is to clean out everything MacPorts has installed and install from scratch using the latest MacPorts
# <source lang="bash">sudo port -f uninstall installed</source>
# <source lang="bash">sudo port clean --all uninstalled</source>
# <source lang="bash">sudo port selfupdate</source>
# <source lang="bash">sudo port install paparazzi-tools</source>
This was in fact the process used to check that the code installed on a clean machine.

== Upgrading to Lion ==
If you already have MacPorts and Paparazzi installed and running and you then upgrade to Lion you'll probably find that some things are broken. (make can't be found for example)
To remedy this situation you need to do the following:
# Upgrade Xcode to the Lion version. (App Store --> Search for Xcode and install)
# Install the Lion version of [http://www.macports.org/install.php MacPorts]
# <source lang="bash">sudo port -f uninstall installed</source>
# <source lang="bash">sudo port clean --all uninstalled</source>
# <source lang="bash">sudo port selfupdate</source>

Now here you have the opportunity to use the binary installer method detailed above or if installing from source then Macports can be used to build from source thus:

# <source lang="bash">sudo port install paparazzi-tools</source>

If you use a USB to serial converter that isn't based on the FTDI chipset then you may also find that your USB to Serial driver needs to be updated.
# Start console
# Plug in your USB to serial converter
You may get a message similar to this <source lang="bash">Jul 26 23:14:48 Bernies com.apple.kextd[10]: Can't load /System/Library/Extensions/osx-pl2303.kext - no code for running kernel's architecture.</source>

If you are fortunate enough to have a USB to serial converter that is using the PL2303 chipset then the [http://www.prolific.com.tw/eng/downloads.asp?id=31 Prolific] driver should sort you out. Installation instructions are included in the readme.txt and are well worth following.

== Keeping source files for debugging ==
If you wish to debug code using the source install then you'll find that many of the source files for the libraries are missing.

This is because MacPorts cleans up the build artifacts and source files after the installation is complete. This behaviour can be changed by adding the -k option to the port command.

For example:
sudo port -k install paparazzi-tools
This will result in all of the source and build artefact files being left on the hard disk.

Should you later wish to clean up these files you can do so with the clean command.

For example:
sudo port clean installed

== Mavericks Notes ==

'''Q:''' Can not find the command line tools package in XCode any more.

'''A:''' Since Mavericks (10.9) it is not necessary to install xcode to install the command line tools package that is needed for macports and paparazzi. Just run in the command line:
xcode-select --install

'''Q:''' libgcc is not compiling with error:
:info:build The directory that should contain system headers does not exist:
:info:build /usr/include

'''A:''' You probably upgraded from older OS X and are using old command line tools. Make sure to run '''xcode-select --install''' command. This should fix the libgcc compilation error.

= Installing from Source (Homebrew/Opam) =

Note: This is work in progress. This process will hopefully resolve some of the issues we are having with MacPorts on Mavericks and Yosemite.
Note: Macports used to conflict with homebrew. According to the homebrew website it is not the case any more as homebrew overrides the environment variables to have a pristine environment as if macports or fink were not installed on the system. It is not confirmed that opam does the same, so it probably is still a good idea to not have macports or fink installed simultanously with homebrew.

# Install [http://xquartz.macosforge.org/landing/ XQuartz].
# Add XQuartz libraries to pkg-config search path by adding the following line:
<source lang="bash">export PKG_CONFIG_PATH=/opt/X11/lib/pkgconfig</source>
to your ~/.profile, ~/.bashrc, ~/.zshrc.local or similar. Note: You have to restart your terminal for the variable to be set, or you execute the export manually in your terminal by pasting the line and pressing enter.
# Install [http://brew.sh/ homebrew].
# Not all packages are yet part of the official homebrew repository (like ivy-c or jsbsim) this is why you might want to run the installation in two steps using the official repository and then [paparazzi homebrew tap https://github.com/paparazzi/homebrew-paparazzi].
## Install the packages included in homebrew: <source lang="bash">brew install git coreutils gnu-sed gtk+ libglade libgnomecanvas sdl libusb libusb-compat gsl opam wget dfu-util</source>
## Add paparazzi tap: <source lang="bash">brew tap paparazzi/homebrew-paparazzi</source>
## Install the remaining packages: <source lang="bash">brew install ivy-c jsbsim</source> Note: We provide these packages as a tap but the hope is to eventually include them in the official homebrew repository.
# <source lang="bash">opam init</source>
# <source lang="bash">opam pin add paparazzi-dev https://github.com/paparazzi/paparazzi-portability-support.git</source>
# Install [https://launchpad.net/gcc-arm-embedded GCC ARM embedded].
## Download the gcc-arm-none-eabi-version.tar.bz2 from the website.
## Extract it into your home directory: <source lang="bash">cd ~/</source><source lang="bash">tar xfvj ~/Downloads/gcc-arm-none-eabi-*.tar.bz2</source>
## Add the bin directory to your PATH environment variable by adding an export to your .profile or .bashrc or .zshrc.local or similar. <source lang="bash">echo export PATH=$(echo ~/gcc-arm-none-eabi-* | tr ' ' '\n' | sort -r | head -n 1 )/bin:\$PATH >> ~/.profile</source>
# Now you should be able to go into the cloned paparazzi repository and run make, and execute ./paparazzi

This process is tested and is working on Mac OS Yosemite 10.10.2 ( [[User:Esden|Esden]] ([[User talk:Esden|talk]]) 16:16, 16 March 2015 (PDT) )

Note: If you are getting the error "Fatal error: exception Gtk.Error("GtkMain.init: initialization failed\nml_gtk_init: initialization failed")", try starting ./paparazzi inside of the XQuartz X11 terminal.

=Running Paparazzi=

Please see [[Installation]] for details on running Paparazzi, downloading source code from GitHub and updating software.

Paparazzi can be started in the usual way
cd ~/paparazzi
./paparazzi

=== Changing the GTK look and feel ===

Run /opt/local/bin/switch2 to select a different theme.
More detailed instructions can be found at http://gtk.php.net/manual/en/html/tutorials/tutorials.installation.macosx-stepbystep.html

Additional themes can be downloaded from http://art.gnome.org/themes/gtk2

A good choice is:
<source lang="bash">switch2 /opt/local/share/themes/ClearlooksClassic/</source>

Another theme selector with a little bit better preview option is "gtk-chtheme"

=== USB Drivers for Telemetry ===

No drivers need to be installed in order to program either the STM32 based or LPC2148 based autopilot boards (ie TINY, TWOG, Booz, Lisa/L, Lisa/M) using a USB port. However telemetry between the vehicle and ground control station requires a modem. On an Apple Mac this will generally be connected to a USB port. Whatever modem is used it will be necessary to load drivers that allow Paparazzi to communicate with the modem. It is not possible to describe all possible modems and their configuration. However the most commonly used chipset for USB to serial communication is produced by FTDI. Below is described the installation of the FTDI drivers. This can be used as a guide for installing drivers for modems using other chipsets.

FTDI drivers can be downloaded from [http://www.ftdichip.com/Drivers/VCP.htm FTDI]

The device will probably become available as something like /dev/tty.usbserial-000013FD when connected. Note that different USB ports get different addresses. When connecting to another port the same device came up as /dev/tty.usbserial-000014FA

Since Paparazzi is currently configured to use /dev/ttyUSB0 it's easiest to just create a link to the required device.
# Remove all USB devices from the computer and run the command <code>ls -l /dev/*usb* /dev/*USB*</code> hopefully this will not list anything
# Plug in your radio and repeat the command <code>ls -l /dev/*usb* /dev/*USB*</code> this should now list the serial port that the radio has been connected to. In my case I get
#: <pre> ls -l /dev/*usb* /dev/*USB*
#: crw-rw-rw- 1 root wheel 11, 27 20 Jan 14:38 /dev/cu.usbserial-000013FD
#: crw-rw-rw- 1 root wheel 11, 26 20 Jan 14:38 /dev/tty.usbserial-000013FD</pre>
# Next we need to create a symbolic link to the tty.usbserial device listed to /dev/ttyUSB0 in my case the command is <code>sudo ln -s /dev/tty.usbserial-000013FD /dev/ttyUSB0</code>
# To check that everything is correct run the first command again <code>ls -l /dev/*usb* /dev/*USB*</code> and you should get something like this
#: <pre> ls -l /dev/*usb* /dev/*USB*
#: crw-rw-rw- 1 root wheel 11, 27 20 Jan 14:38 /dev/cu.usbserial-000013FD
#: crw-rw-rw- 1 root wheel 11, 26 20 Jan 14:38 /dev/tty.usbserial-000013FD
#: lrwxr-xr-x 1 root wheel 0 20 Jan 14:42 /dev/ttyUSB0 -> /dev/tty.usbserial-000013FD</pre>

Once the FTDI driver (kernel extension) is loaded it takes over for all FTDI connections. This means that it will not be possible to program the Lisa/L or Lisa/M boards while the driver is loaded.

To unload the driver use the command
sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext
This should not give an error. if it does then try again a few times after quitting programs that may have used the connection. If the driver still fails to unload then a reboot may be required.

When it comes time to connect the modem again you'll again need the driver loaded. This can be done with the complementary command
sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext

=== Workaround for Issues with errors (Device busy) when trying to program a Lisa/L ===
====Programming the Lisa on OS X====

The problem:
The "default" vendor id and product id for the ftdi device on Lisa is the same one used by all the manufacturers of clone usb-serial interfaces. This isn't an issue on Linux because of the udev rules file we use does not load the ftdi drivers for lisas programming interface. Windows and Mac OS X don't use this file so they can only use vendor id and product id.
So as soon as you plug in Lisa they load USB->serial port drivers for the two ports they believe are on Lisa causing a conflict. The programming of Lisa happens through a different mechanism and does not want the programming interface of Lisa to be taken by the FTDI driver which has already been loaded. For OS X there is a hack we can do that makes it better until we can get vendor and product ids sorted out. It involves modifying the /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist file. We change it so only the first of the two serial interfaces is loaded. The second is not as it is the programming interface.

The File (edit with a text editor):
/System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist

Here is a diff between a "vanilla OS X" and one that has been modified (Essentially below was removed):
quadzilla:Contents root# diff ~/Info.plist Info.plist
<source lang="diff">
1784,1805d1783
< <key>FT2232C_B</key>
< <dict>
< <key>CFBundleIdentifier</key>
< <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
< <key>ConfigData</key>
< <dict>
< <key>LatencyTimer</key>
< <integer>2</integer>
< </dict>
< <key>IOClass</key>
< <string>FTDIUSBSerialDriver</string>
< <key>IOProviderClass</key>
< <string>IOUSBInterface</string>
< <key>bConfigurationValue</key>
< <integer>1</integer>
< <key>bInterfaceNumber</key>
< <integer>1</integer>
< <key>idProduct</key>
< <integer>24592</integer>
< <key>idVendor</key>
< <integer>1027</integer>
< </dict>
1830,1853d1807
< <key>FT2232H_B</key>
< <dict>
< <key>CFBundleIdentifier</key>
< <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
< <key>ConfigData</key>
< <dict>
< <key>LatencyTimer</key>
< <integer>2</integer>
< </dict>
< <key>IOClass</key>
< <string>FTDIUSBSerialDriver</string>
< <key>IOProviderClass</key>
< <string>IOUSBInterface</string>
< <key>bConfigurationValue</key>
< <integer>1</integer>
< <key>bInterfaceNumber</key>
< <integer>1</integer>
< <key>bcdDevice</key>
< <integer>1792</integer>
< <key>idProduct</key>
< <integer>24592</integer>
< <key>idVendor</key>
< <integer>1027</integer>
< </dict>
</source>

Once you have edited the file
- sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
- sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
To reload the driver or you can just reboot.

It is expected as Paparazzi moves to supporting more operating systems that unique product and vendor ids will be obtained thus removing the need for this step.

==Installing FlightGear==
FlightGear has been packaged for use on OS X. This package can be downloaded from:
http://www.flightgear.org/download/

There are several packages available. Recently, FlightGear 3.0 was released. A binary for OS X is available, and seems to work properly on Maverics (OS X 10.9.2). Follow the directions [http://www.flightgear.org/download/main-program/ here] for installation. Additional documentation can be found [http://macflightgear.sourceforge.net/home/documents/ here].

[[Image:Flightgear_launchgui_OSX_pprzoptions.png|thumb|350px|Screenshot of FlightGear launch gui in OS X with options for visualizing Paparazzi simulations]]
Once FlightGear is installed, the GUI launcher can be used to set common options. By clicking on the Advanced Features arrow, one can gain access to many more options as well as an interface to specify command line options (the Others tab). This is where one can specify the flight dynamics model and network connectivity required for visualizing Paparazzi simulations as described on the [[Simulation]] page.

* In Paparazzi Center, add to the simulator command the <tt>--fg</tt> option plus the IP address of the machine running flightgear in this case the loopback interace is used as Flightgear and Paparazzi are running on the same machine:
.../sw/simulator/pprzsim-launch --aircraft TJ1 -t sim --boot --norc --fg_host 127.0.0.1
Note TJ1 is the name of the aircraft you must substitute this with the name of your aircraft.
* Launch Flight Gear with the following set in the others tab under advanced settings:
--fdm=null --native-gui=socket,in,30,,5501,udp

For Flight Gear visualization, version 3.0 or greater with Rembrand switched on is best. If you wish to use version 2.4 or lower, you must add the following to the firmware section of your airframe file:

<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<define name="FG_2_4" value="1"/>
...
</firmware>
</source>

[[Image:Flightgear_pprz_sim_OSX.png|thumb|right|350px|Screenshot of Flightgear visualizing the default Microjet simulation in OS X (not the default Muret, FR location)]]

==Simulations Using JSBSim==
[http://jsbsim.sourceforge.net/index.html JSBSim] is an open-source flight dynamics and control software library. It can provide a more realistic simulation environment over the basic built-in Paparazzi simulator. See the [[Simulation|Simulation]] page for background information and how to run a normal simulation. After this can be done in a satisfactory manner, follow the steps below to utilize the JSBSim flight dynamics model.

Please see [[JSBSim]] for installation instructions and [[Simulation#JSBSim]] for instructions on how to use the JSBSim FDM in simulations.

==Differences with the Linux version==
This section is intended to document all the subtle differences between Linux and Mac OS X versions of Paparazzi.
===Change of text editor===
The default editor in Linux is gedit, but in OS X, it is open, which simply uses whatever the default program for opening .xml files is setup.

===Ivy subnet mask===
On Linux, the Ivy submask is 127.255.255.255

On Mac OS X, the Ivy submask is 224.255.255.255

In C applications, such as tmtc/c_ivy_client_example_1.c, this should be set adaptively by something like:

#ifdef __APPLE__
printf("Mac OS, network submask: 224.255.255.255\n");
IvyStart("224.255.255.255");
#else
printf("NO Mac OS, network submask: 127.255.255.255\n");
IvyStart("127.255.255.255");
#endif

Is there a better way to do this?

[[Category:Software]] [[Category:User_Documentation]] [[Category:Installation]]

TCP Aircraft Server

2014-06-11T01:07:58Z

Jkg: /* Usage */ formatting

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Tools</categorytree>
__TOC__

The <tt>tcp aircraft server</tt> (in <tt>sw/tools/tcp_aircraft_server/</tt>) is an agent that re-broadcasts the ivy telemetry stream from a specified vehicle over tcp to a specified remote ip which hosts its own local ground segment ivy network. This allows the broadcast of a vehicle telemetry stream over the internet to a remote party without the need for VPNs.

== Usage ==

=== Broadcast Ground Station ===

If you have not done so already, set your Paparazzi src and home directories:

export PAPARAZZI_SRC=~/path/to/paparazzi
export PAPARAZZI_HOME=~/path/to/paparazzi

Then, from your Paparazzi directory, run:
./sw/ground_segment/tmtc/ivy_tcp_aircraft -id <ac_id_number> -h <remote IP>

=== Recipient Computer ===

Run:
./sw/tools/tcp_aircraft_server/tcp_aircraft_server.py

Then open [http://wiki.paparazziuav.org/wiki/Paparazzi_Center Paparazzi Center] using the -n option for the [http://wiki.paparazziuav.org/wiki/Server Server] unless you wish to log messages locally, and use the tools within Paparazzi Center as you would do normally.

The recipient side of the setup broadcasts locally over the default Paparazzi ivy bus 127.255.255.255:2010

[[Category:Tools]] [[Category:User_Documentation]]

Lisa

2014-06-03T22:11:59Z

Jkg: added photos and wiki links

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree>
__TOC__
Lisa ( the Lost Illusions Serendipitous Autopilot) is a new range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why Lisa comes in different flavors for different usages.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a design focusing on cost and simplicity.
*Lisa/S, a design focusing on size and weight.

==Lisa/L==

=== Description ===

Lisa/L is a dual processor board autopilot designed to allow the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

=== Documentation ===

The documentation for Lisa/L is broken into several parts due to board complexity and Gumstix [[Overo]] integration.
* [[Lisa/L|Main Documentation]] - primary hardware documentation and intro to software
* [[Dev/LisaL|Additional Developer Documentation]] - additional advanced hardware and software documentation and notes
* [[LisaL_Gallery|Lisa/L Gallery]] - nice pictures of Lisa/L
* [[User/LisaL/Tutorial/Quadrocopter|Unfinished Rotorcraft Tutorial]] - rotorcraft tutorial, needs considerable work
* [[User/LisaL/Tutorial/FixedWing|Unfinished Fixedwing Tutorial]] - fixedwing tutorial, needs considerable work
* [[OMAP|Gumstix Integration Intro]] - intro and documentation listing for integrating a Gumstix Overo with Lisa/L, including for USB devices and cameras

== Lisa/M ==

=== Description ===

Lisa/M is a great general purpose small-footprint autopilot. There are currently two versions that have been produced. Detailed documentation can be found here:
* [[Lisa/M_v2.0|Lisa/M v2.0 (current) Documentation]]

[[Image:LisaM_V2_0_TopView.JPG|360px|Lisa/M v2.0 Top View]]

* [[Lisa/M_v1.0|Lisa/M v1.0 Documentation]]

[[Image:lisa_m_top_small.png|360px|Lisa/M v1.0 Top View]]

=== Usage scenarios ===

There are many potential applications for the small, relatively inexpensive and flexible Lisa/M. For regular Autopilot boards a full Lisa/M board is needed. For some scenarios just a basic Lisa/M without [[Inertial_Measurement_Units|IMU]] and barometric pressure sensor is needed, which reduces board cost. Here are some ideas (not all have yet been implemented):

* As a basic Autopilot
** To use the Lisa/M as an autopilot, we need to attach a GPS receiver. A nice [[GPS#u-Blox_LEA_Series_Receivers|uBlox LEA-5H]] or newer will perform great.
* As an advanced Autopilot
** Additional sensors for measuring airspeed, current, etc. would enhance a fixed-wing airframe.
* As a servo extender
** Sometimes being able to control seven actuators is just not enough. Large airframes may require flaps or an airbrake and automatic landing facilities. Maybe special ACL/Nav lights, or four cameras with zoom. By using a coupled second basic Lisa/M and connecting this to the master AP board we can extend the amount of servos. Large airframes can also benefit from remote and/or redundant servo drivers.
* As a Safety Pilot Device
** To provide an extra safety level required in some UAS challenges. A second Lisa board can make it easy to adhere to the rules for such a challenge.
* As a Data Logger
** Maybe you have a need only to log all kinds of data, like temperature, volts, amps, height, airspeed, and not control the aircraft. For this we can setup a Lisa/M board. Collecting this data can be to a storage medium like an micro SD card. Sometimes there is no need for realtime data collection through telemetry but just for storing a huge dataset.
* As a Camera controller
** On some models that do not require many servos (for example - flying wing with only 3 channels used), spare channels can be used for camera control. In addition, it could be used as an independent pan-tilt unit (PTU) controller.
* As a Airframe Tracker
** Tracking an airframe for an antenna or camera on a tripod is one of the many options to use a Lisa/M Board.

== Lia ==

Lia is a lower-cost variant of Lisa/M 2.0. The microcontroller, basic layout, servo outputs, and mounting holes are the same. Major differences:
* 0.1" through-hole connections for non-servo I/O instead of Molex picoblade
** PCB size increased slightly to (58x34mm) to accomodate throughholes
* CAN transceiver removed on initial units; populated on later units (see [http://paparazzi.enac.fr/wiki/Lia documentation])
* barometer removed
* I2C level shifter removed
* 5V voltage regulator removed
* Added provisions for multiple BEC input balancing on servo connectors

[[Image:Lia_1.1_top.jpg|360px|Lia v1.1 Top View]]

[[Lia|Lia documentation]]

== Lisa/S ==

Lisa/S is very small AP board. The focus for this design is size, weight and power consumption. It's an autopilot suited for the smallest airframes.

[[Image:Lisa_S_V0_1_r2_on_finger.jpg|360px]]

* [[Lisa/S|Lisa/S Documentation]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

Lisa

2014-06-03T22:04:08Z

Jkg: /* Lia */ clarified CAN status

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree>
__TOC__
Lisa ( the Lost Illusions Serendipitous Autopilot) is a new range of autopilots based on [http://www.st.com/mcu/inchtml-pages-stm32.html STM32] microcontrollers ( CortexM3@72Mhz ) designed to run Paparazzi.
There's no such thing as a perfect autopilot, only autopilots adapted to a particular purpose. This is the reason why Lisa comes in different flavors for different usages.

The first members of the family are:

*Lisa/L, a design where the STM32 is associated to a gumstix [http://www.gumstix.net/Setup-and-Programming/cat/Overo-Setup-and-Programming/111.html Overo].
*Lisa/M, a design focusing on cost and simplicity.
*Lisa/S, a design focusing on size and weight.

==Lisa/L==

=== Description ===

Lisa/L is a dual processor board autopilot designed to allow the possibility of using Linux for Paparazzi airborne code.

[[Image:lisa_l_bloc_diag_simple.png|360px]]
[[Image:lisa_l_top.png|360px]] [[Image:lisa_l_bot.png|360px]]

=== Documentation ===

The documentation for Lisa/L is broken into several parts due to board complexity and Gumstix [[Overo]] integration.
* [[Lisa/L|Main Documentation]] - primary hardware documentation and intro to software
* [[Dev/LisaL|Additional Developer Documentation]] - additional advanced hardware and software documentation and notes
* [[LisaL_Gallery|Lisa/L Gallery]] - nice pictures of Lisa/L
* [[User/LisaL/Tutorial/Quadrocopter|Unfinished Rotorcraft Tutorial]] - rotorcraft tutorial, needs considerable work
* [[User/LisaL/Tutorial/FixedWing|Unfinished Fixedwing Tutorial]] - fixedwing tutorial, needs considerable work
* [[OMAP|Gumstix Integration Intro]] - intro and documentation listing for integrating a Gumstix Overo with Lisa/L, including for USB devices and cameras

== Lisa/M ==

=== Description ===

Lisa/M is a great general purpose small-footprint autopilot. There are currently two versions that have been produced. Detailed documentation can be found here:
* [[Lisa/M_v2.0|Lisa/M v2.0 (current) Documentation]]
* [[Lisa/M_v1.0|Lisa/M v1.0 Documentation]]

[[Image:lisa_m_top_small.png|360px|Lisa/M v1.0 Top View]]

=== Usage scenarios ===

There are many potential applications for the small, relatively inexpensive and flexible Lisa/M. For regular Autopilot boards a full Lisa/M board is needed. For some scenarios just a basic Lisa/M without [[Inertial_Measurement_Units|IMU]] and barometric pressure sensor is needed, which reduces board cost. Here are some ideas (not all have yet been implemented):

* As a basic Autopilot
** To use the Lisa/M as an autopilot, we need to attach a GPS receiver. A nice [[GPS#u-Blox_LEA_Series_Receivers|uBlox LEA-5H]] or newer will perform great.
* As an advanced Autopilot
** Additional sensors for measuring airspeed, current, etc. would enhance a fixed-wing airframe.
* As a servo extender
** Sometimes being able to control seven actuators is just not enough. Large airframes may require flaps or an airbrake and automatic landing facilities. Maybe special ACL/Nav lights, or four cameras with zoom. By using a coupled second basic Lisa/M and connecting this to the master AP board we can extend the amount of servos. Large airframes can also benefit from remote and/or redundant servo drivers.
* As a Safety Pilot Device
** To provide an extra safety level required in some UAS challenges. A second Lisa board can make it easy to adhere to the rules for such a challenge.
* As a Data Logger
** Maybe you have a need only to log all kinds of data, like temperature, volts, amps, height, airspeed, and not control the aircraft. For this we can setup a Lisa/M board. Collecting this data can be to a storage medium like an micro SD card. Sometimes there is no need for realtime data collection through telemetry but just for storing a huge dataset.
* As a Camera controller
** On some models that do not require many servos (for example - flying wing with only 3 channels used), spare channels can be used for camera control. In addition, it could be used as an independent pan-tilt unit (PTU) controller.
* As a Airframe Tracker
** Tracking an airframe for an antenna or camera on a tripod is one of the many options to use a Lisa/M Board.

== Lia ==

Lia is a lower-cost variant of Lisa/M 2.0. The microcontroller, basic layout, servo outputs, and mounting holes are the same. Major differences:
* 0.1" through-hole connections for non-servo I/O instead of Molex picoblade
** PCB size increased slightly to (58x34mm) to accomodate throughholes
* CAN transceiver removed on initial units; populated on later units (see [http://paparazzi.enac.fr/wiki/Lia documentation])

* barometer removed
* I2C level shifter removed
* 5V voltage regulator removed
* Added provisions for multiple BEC input balancing on servo connectors

[http://paparazzi.enac.fr/wiki/Lia Lia current documentation]

== Lisa/S ==

Lisa/S is very small AP board. The focus for this design is size, weight and power consumption. It's autopilot suited for the smallest airframes.

A picture of the first batch just ready to upload code and test.

[[Image:Lisa_S_V0_1_r2_on_finger.jpg|360px]]

[[Category:Lisa]] [[Category:User_Documentation]] [[Category:Autopilots]]

Installation/MacOSX

2014-05-02T21:43:24Z

Jkg: /* Basic Uninstall */ typo in script name

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Installation</categorytree>
__TOC__

'''Update on OS X installation: Currently, arm-none-eabi-gdb on 10.6 should be broken (gcc-arm-embedded can be compiled by hand if required without python support, or installing python2.7 as a framework from a dmg might work).'''

'''(Feb. 1, 2014) Current OS X limitations:'''
* '''10.6.* requires some manual effort to properly install gcc-arm-embedded, email the mailing list if help required (gcc-arm-embedded can be compiled by hand if required without python support, or installing python2.7 as a framework from a dmg might work)'''
* '''There is no cross compiler for the ARDrone2.'''

= Intro =
Would it not be great to also be able to run Paparazzi from your shiny Apple Mac? Well, this page explains how you can manage to do just that.

The task of supporting Paparazzi on Apple MacOS X is ongoing as the project evolves and the more people adapt it the process will be streamlined. Presently it is known that Paparazzi will install on OSX versions 10.6.*, 10.7.*, 10.8.*, and 10.9.*. Support on 10.6.* requires some additional effort.

= Basic Install (Binary Installer) =
Depending on the version of Mac OS you have installed on your computer the installation process will vary slightly. Also this install process is only recommended for beginners. If you want to be able to use more up to date Paparazzi and be able to track the development more closely, you should consider installing Paparazzi tools using the source solution described in the next chapter.

== Installation Video Tutorials (On OS X 10.9.* '''Mavericks''') ==

{{#ev:youtubehd|s5KFZqxqAr4}} {{#ev:youtubehd|lXB1y0Dv2y0}}

== Basic Install (Binary Installer) (On OS X 10.9.* '''Mavericks''') ==
If your Apple Mac operation system is OSX Mavericks or newer then the easiest way to get started with Paparazzi on your Apple Mac is to start with the following Basic install. If you have an older version you want to follow the slightly longer Basic install, below.

The steps you need to take to enjoy Paparazzi are:
# Install XQuartz from [http://xquartz.macosforge.org MacOSForge]. (You can alternatively use the X11.app if it is available for your version of Mac OS X.)
# Open the Terminal.app
# Install the command line tools by executing: <source lang="bash">xcode-select --install</source> and clicking on the "Install" button in the dialog that will pop up.
# Install the Paparazzi Tools installer for your OS version from [http://download.paparazziuav.org/darwin/ paparazziuav.org]
## You might get an error saying: "paparazzi-tools-xxxxxx.mpkg can't be opened because it is from an unidentified developer." To get rid of this error you will need to:
### Open "System Preferences"->"Security&Privacy" and change the "Allow apps downloaded from:" setting to "Anywhere". (The option might be greyed out. To activate the selection you will need to authenticate yourself as system administrator. Click on the lock in the left lower corner of the "System Preferences" window, to open the authentication window.)
# Set up your environment variables and Python appropriately using the pprz-env-set script:
## Get the script: <source lang="bash">curl https://raw2.github.com/paparazzi/paparazzi-portability-support/master/darwin/install/Contents/Resources/pprz-env-set > ~/Desktop/pprz-env-set</source>
## Move script to right location: <source lang="bash">sudo mv ~/Desktop/pprz-env-set /opt/paparazzi/bin/pprz-env-set</source>
## Change script permissions: <source lang="bash">sudo chmod 755 /opt/paparazzi/bin/pprz-env-set</source>
## Run the script: <source lang="bash">sudo /opt/paparazzi/bin/pprz-env-set</source>
## Close the terminal. (Do that before you try to move on to the next step. Otherwise the newly set environment will not take effect and you will end up with compilation errors.)
# That's it! To run Paparazzi you need to open the Terminal app and build and run Paparazzi.
## In spotlight type Terminal and then open the Terminal App
## then type: <source lang="bash">cd ~/paparazzi && make && ./paparazzi</source> (The first time you start paparazzi it might take several minutes to show a window. It is because GTK is indexing the fonts the first time it starts up.) (If you get the error: "Fatal error: exception Gtk.error("GtkMain.init: initialization failed ml_gtk_init: initialization failed")" the most likely source of the issue is the lack of X11 server. Install either X11.app or XQuartz as mentioned in step 1.)

Notes:
* the binary installer will check if ~/paparazzi exists on your system. If it does, then the installer does nothing. If this directory does NOT already exist, the installer will automatically clone the Paparazzi Git repository into that directory.
* the binary installer will add a few lines to your ~/.profile for PATH modification and for default PAPARAZZI_HOME and PAPARAZZI_SRC env vars. If you have something other than the default ~/paparazzi installation, please edit your ~/.profile and comment out the env var exports.
* the binary installer creates a symbolic link between the available /opt/paparazzi/bin/python2.7 and /opt/paparazzi/bin/python. Combined with the PATH modification, this will cause <source lang="bash">python something.py</source> to call /opt/paparazzi/bin/python2.7 instead of any system pythons.

== Basic Install (Binary Installer) (Support: 10.7.* '''Lion''', 10.8.* '''Mountain Lion''') ==
If your Apple Mac operation system is OSX Snow Leopard or Lion or newer then the easiest way to get started with Paparazzi on your Apple Mac is to start with the Basic install.

The steps you need to take to enjoy Paparazzi are:
# Install XQuartz from [http://xquartz.macosforge.org MacOSForge]. (You alternatively can install the X11.app from Apple. If it is available for your version of Mac OS X.)
# Install the latest available [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Xcode] development tool for your OS, we had good success with [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 Xcode] v4.2 on Snow Leopard and v4.3.2 on Lion. For Snow Leopard, Xcode 3.2.6 also works and is still available as a [https://developer.apple.com/downloads/ free download] with an Apple ID (search for ''xcode 3.2.6'').
## With Xcode 4.3 and above you need to install the command line tools. Xcode --> Preferences --> Downloads --> Components --> Command line tools
## Check that the correct version of Xcode is being used for compilation <source lang=bash>/usr/bin/xcodebuild -version</source> It should return the version of Xcode that has been installed, e.g. 4.2. In the rare case you need to change your XCode version run the following command in your terminal: <source lang=bash>sudo /usr/bin/xcode-select -switch /Applications/Xcode.app/Contents/Developer</source>
# Install the Paparazzi Tools installer for your OS version from [http://download.paparazziuav.org/darwin/ paparazziuav.org]
# Set up your environment variables and Python appropriately using the pprz-env-set script:
## Get the script: <source lang="bash">curl https://raw2.github.com/paparazzi/paparazzi-portability-support/master/darwin/install/Contents/Resources/pprz-env-set > ~/Desktop/pprz-env-set</source>
## Move script to right location: <source lang="bash">sudo mv ~/Desktop/pprz-env-set /opt/paparazzi/bin/pprz-env-set</source>
## Change script permissions: <source lang="bash">sudo chmod 755 /opt/paparazzi/bin/pprz-env-set</source>
## Run the script: <source lang="bash">sudo /opt/paparazzi/bin/pprz-env-set</source>
## Close the terminal. (Do that before you try to move on to the next step. Otherwise the newly set environment will not take effect and you will end up with compilation errors.)
# That's it! To run Paparazzi you need to open the Terminal app and build and run Paparazzi.
## In spotlight type Terminal and then open the Terminal App
## then type: <source lang="bash">cd ~/paparazzi && make && ./paparazzi</source> (The first time you start paparazzi it might take several minutes to show a window. It is because GTK is indexing the fonts the first time it starts up.) (If you get the error: "Fatal error: exception Gtk.error("GtkMain.init: initialization failed ml_gtk_init: initialization failed")" the most likely source of the issue is the lack of X11 server. Install either X11.app or XQuartz as mentioned in step 1.)

Notes:
* the binary installer will check if ~/paparazzi exists on your system. If it does, then the installer does nothing. If this directory does NOT already exist, the installer will automatically clone the Paparazzi Git repository into that directory.
* the binary installer will add a few lines to your ~/.profile for PATH modification and for default PAPARAZZI_HOME and PAPARAZZI_SRC env vars. If you have something other than the default ~/paparazzi installation, please edit your ~/.profile and comment out the env var exports.
* the binary installer creates a symbolic link between the available /opt/paparazzi/bin/python2.7 and /opt/paparazzi/bin/python. Combined with the PATH modification, this will cause <source lang="bash">python something.py</source> to call /opt/paparazzi/bin/python2.7 instead of any system pythons.

== Basic Uninstall ==
In the case you would like to uninstall Paparazzi after completing a basic installation, one must type the following in your terminal prompt:

'''Warning''' This first step removes your paparazzi source code, including any changes you may have made yourself locally. If you want to keep your git repository intact, skip this first step and only use the following two steps.

<source lang="bash">rm -rf ~/paparazzi</source>

<source lang="bash">
sudo pprz-env-set -u
</source>

<source lang="bash">
sudo rm -rf /opt/paparazzi
</source>

Note that pprz-env-setup -u removes the entry from ~/.profile and also removes the /opt/paparazzi/bin/python symlink.

== Using Luftboot and PyUSB ==

'''UPDATE:''' The lastest binary installer should have PyUSB included by default, no need to install it separately.

If you are planning on loading code onto a Luftboot-equipped STM32 board, you will need to have a Python version on your machine that is active and with [http://sourceforge.net/apps/trac/pyusb/ PyUSB] installed for that version.

To install PyUSB, execute
<source lang="bash">
sudo python setup.py install
</source>
from inside the unzipped PyUSB source directory.

To test which Python version is the default and whether this Python version can find the PyUSB module, in Terminal simply type:
<source lang="bash">
python
</source>
To start the default Python. At the Python prompt (>>>) type:
<source lang="bash">
import usb
</source>
If another prompt line comes up, PyUSB is installed correctly and you will be able to use Luftboot. If an error is thrown, then your configuration is not correct.

== MacPorts and PyUSB ==
If you have MacPorts installed, you can install either <code>py26-pyusb</code>, <code>py26-pyusb-devel</code> or <code>py27-pyusb-devel</code>, depending on which Python(s) you have installed already, or wish to install. For example:
<source lang="bash">
sudo port selfupdate
sudo port install py27-pyusb-devel
</source>

To find out what versions of Python are available on your system (via MacPorts):
<source lang="bash">
port select --list python
</source>
Default Apple Python versions have a -apple ending.

Select a different version of python to be the active version if desired. For example:
<source lang="bash">
sudo port select --set python python27
</source>

A good, working configuration would be to have MacPorts installed, and install <code>py27-pyusb-devel</code>, then ensure that python27 is the active version.

== Adjusting your PATH and Troubleshooting ==

There are sometimes path issues with OS X if you have MacPorts or a similar (Homebrew, Fink) system installed. The reason for this is there may be multiple copies of a binary required for Paparazzi in different places, and depending on the path, the desired instance is not correctly called. This often presents itself as an error when building the main Paparazzi source code. A typical error may involve the <code>pkg-config</code> program. This can often be corrected by checking and adjusting your PATH environment variable.

To check the currently configured default PATH:
<source lang="bash">
echo $PATH
</source>
Ideally, the Paparazzi binary paths (<code>/opt/paparazzi/bin</code> and <code>/opt/paparazzi/sbin</code>) should come first. To move the Paparazzi paths to the highest search priority:
<source lang="bash">
export PATH=/opt/paparazzi/bin:/opt/paparazzi/sbin:$PATH
</source>
This will only be active in the current terminal session. If you wish to manually modify the path permanently, you can edit ~/.profile and add the above line to the bottom of the file.

= Installing from source =
The tools that are required to work with paparazzi on a Mac are installed from MacPorts. All of the commands are given by terminal commands, please open your terminal first.

In case you '''already have MacPorts installed''', it is advised to run the following steps before proceeding:

# check that /opt/local/bin is the first entry in your PATH, easy to check by giving the following command <source lang="bash">echo $PATH</source>
# Then give the following command to make sure your ports are up-to-date <source lang="bash">sudo port selfupdate && sudo port upgrade outdated</source>
..great, you now can run the installation steps starting from step '''4''' below.

If you don't already have MacPorts installed run the following steps:

# Install the latest [http://itunes.apple.com/us/app/xcode/id448457090?mt=12 XCode]. If you are using 10.9 (Mavericks) or newer you just need to run <source lang="bash">xcode-select --install</source>
# If you are using Mountain Lion, X11 is no longer included by default, use the [http://xquartz.macosforge.org/landing/ XQuartz project] to install it.
# Install [http://www.macports.org/install.php MacPorts]
# Edit the file <source lang="bash">/opt/local/etc/macports/sources.conf</source> and above the <source lang="bash">rsync://...</source> line add <source lang="bash">rsync://rsync.paparazziuav.org/macports/ports/</source> It is important that this line comes before the path to the standard ports as some of the Paparazzi ports are intended to replace the standard versions. The file is write protected so it will be necessary to be root in order to edit it. The simplest way is to open a terminal window and use nano thus: <source lang="bash">sudo nano /opt/local/etc/macports/sources.conf</source>
# Now update the available ports with the command: <source lang="bash">sudo port selfupdate</source>
# To install all of the paparazzi prerequisites: <source lang="bash">sudo port install paparazzi-tools</source>
# ...Then go and have lunch, get a coffee, get some sleep. This will probably take a long time.
# After installation, we need to set the correct python to override the default OS X python: <source lang="bash">sudo port select --set python python27</source>
# You can also [[#Changing the GTK look and feel|change the GTK theme]]

Now you can follow the generic instructions for [[Installation|installing the paparazzi source]].

'''NOTE:''' If you had previously used MacPorts to install Paparazzi, you may need to manually uninstall arm-none-eabi-binutils, arm-none-eabi-gcc-linaro, and arm-none-eabi-gdb prior to upgrading paparazzi-tools. libcmsis, libopenstm32 and libopencm3 ports may need to be uninstalled as well. For example:
<source lang="bash">sudo port uninstall -f libcmsis libopenstm32 libopencm3 arm-none-eabi-gdb arm-none-eabi-gcc-linaro arm-none-eabi-binutils</source>

== Lion and XCode 4.3 or newer notes ==

After installing Xcode 4.3 you will need to install the command line tools by opening the XCode preferences pane, Downloads and selecting Command Line Tools for isnstallation. Otherwise you will not find GCC in your unix path.

Also if macports is complaining about xcodebuild and that you should run

<source lang="bash"> sudo xcode-select -switch /Applications/Xcode.app </source>

You should actually run

<source lang="bash"> sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer</source>

so that xcodebuild can find the needed executables for you.

== Troubleshooting ==
If you continually experience problems installing paparazzi or paparazzi-tools then it may be that you have some other conflicting software installed. i.e. an old version of a library in /usr.

One way to work around issues relating to prior MacPort installs that has been found is to clean out everything MacPorts has installed and install from scratch using the latest MacPorts
# <source lang="bash">sudo port -f uninstall installed</source>
# <source lang="bash">sudo port clean --all uninstalled</source>
# <source lang="bash">sudo port selfupdate</source>
# <source lang="bash">sudo port install paparazzi-tools</source>
This was in fact the process used to check that the code installed on a clean machine.

== Upgrading to Lion ==
If you already have MacPorts and Paparazzi installed and running and you then upgrade to Lion you'll probably find that some things are broken. (make can't be found for example)
To remedy this situation you need to do the following:
# Upgrade Xcode to the Lion version. (App Store --> Search for Xcode and install)
# Install the Lion version of [http://www.macports.org/install.php MacPorts]
# <source lang="bash">sudo port -f uninstall installed</source>
# <source lang="bash">sudo port clean --all uninstalled</source>
# <source lang="bash">sudo port selfupdate</source>

Now here you have the opportunity to use the binary installer method detailed above or if installing from source then Macports can be used to build from source thus:

# <source lang="bash">sudo port install paparazzi-tools</source>

If you use a USB to serial converter that isn't based on the FTDI chipset then you may also find that your USB to Serial driver needs to be updated.
# Start console
# Plug in your USB to serial converter
You may get a message similar to this <source lang="bash">Jul 26 23:14:48 Bernies com.apple.kextd[10]: Can't load /System/Library/Extensions/osx-pl2303.kext - no code for running kernel's architecture.</source>

If you are fortunate enough to have a USB to serial converter that is using the PL2303 chipset then the [http://www.prolific.com.tw/eng/downloads.asp?id=31 Prolific] driver should sort you out. Installation instructions are included in the readme.txt and are well worth following.

== Keeping source files for debugging ==
If you wish to debug code using the source install then you'll find that many of the source files for the libraries are missing.

This is because MacPorts cleans up the build artifacts and source files after the installation is complete. This behaviour can be changed by adding the -k option to the port command.

For example:
sudo port -k install paparazzi-tools
This will result in all of the source and build artefact files being left on the hard disk.

Should you later wish to clean up these files you can do so with the clean command.

For example:
sudo port clean installed

== Mavericks Notes ==

'''Q:''' Can not find the command line tools package in XCode any more.

'''A:''' Since Mavericks (10.9) it is not necessary to install xcode to install the command line tools package that is needed for macports and paparazzi. Just run in the command line:
xcode-select --install

'''Q:''' libgcc is not compiling with error:
:info:build The directory that should contain system headers does not exist:
:info:build /usr/include

'''A:''' You probably upgraded from older OS X and are using old command line tools. Make sure to run '''xcode-select --install''' command. This should fix the libgcc compilation error.

=Running Paparazzi=

Please see [[Installation]] for details on running Paparazzi, downloading source code from GitHub and updating software.

Paparazzi can be started in the usual way
cd ~/paparazzi
./paparazzi

=== Changing the GTK look and feel ===

Run /opt/local/bin/switch2 to select a different theme.
More detailed instructions can be found at http://gtk.php.net/manual/en/html/tutorials/tutorials.installation.macosx-stepbystep.html

Additional themes can be downloaded from http://art.gnome.org/themes/gtk2

A good choice is:
<source lang="bash">switch2 /opt/local/share/themes/ClearlooksClassic/</source>

=== USB Drivers for Telemetry ===

No drivers need to be installed in order to program either the STM32 based or LPC2148 based autopilot boards (ie TINY, TWOG, Booz, Lisa/L, Lisa/M) using a USB port. However telemetry between the vehicle and ground control station requires a modem. On an Apple Mac this will generally be connected to a USB port. Whatever modem is used it will be necessary to load drivers that allow Paparazzi to communicate with the modem. It is not possible to describe all possible modems and their configuration. However the most commonly used chipset for USB to serial communication is produced by FTDI. Below is described the installation of the FTDI drivers. This can be used as a guide for installing drivers for modems using other chipsets.

FTDI drivers can be downloaded from [http://www.ftdichip.com/Drivers/VCP.htm FTDI]

The device will probably become available as something like /dev/tty.usbserial-000013FD when connected. Note that different USB ports get different addresses. When connecting to another port the same device came up as /dev/tty.usbserial-000014FA

Since Paparazzi is currently configured to use /dev/ttyUSB0 it's easiest to just create a link to the required device.
# Remove all USB devices from the computer and run the command <code>ls -l /dev/*usb* /dev/*USB*</code> hopefully this will not list anything
# Plug in your radio and repeat the command <code>ls -l /dev/*usb* /dev/*USB*</code> this should now list the serial port that the radio has been connected to. In my case I get
#: <pre> ls -l /dev/*usb* /dev/*USB*
#: crw-rw-rw- 1 root wheel 11, 27 20 Jan 14:38 /dev/cu.usbserial-000013FD
#: crw-rw-rw- 1 root wheel 11, 26 20 Jan 14:38 /dev/tty.usbserial-000013FD</pre>
# Next we need to create a symbolic link to the tty.usbserial device listed to /dev/ttyUSB0 in my case the command is <code>sudo ln -s /dev/tty.usbserial-000013FD /dev/ttyUSB0</code>
# To check that everything is correct run the first command again <code>ls -l /dev/*usb* /dev/*USB*</code> and you should get something like this
#: <pre> ls -l /dev/*usb* /dev/*USB*
#: crw-rw-rw- 1 root wheel 11, 27 20 Jan 14:38 /dev/cu.usbserial-000013FD
#: crw-rw-rw- 1 root wheel 11, 26 20 Jan 14:38 /dev/tty.usbserial-000013FD
#: lrwxr-xr-x 1 root wheel 0 20 Jan 14:42 /dev/ttyUSB0 -> /dev/tty.usbserial-000013FD</pre>

Once the FTDI driver (kernel extension) is loaded it takes over for all FTDI connections. This means that it will not be possible to program the Lisa/L or Lisa/M boards while the driver is loaded.

To unload the driver use the command
sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext
This should not give an error. if it does then try again a few times after quitting programs that may have used the connection. If the driver still fails to unload then a reboot may be required.

When it comes time to connect the modem again you'll again need the driver loaded. This can be done with the complementary command
sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext

=== Workaround for Issues with errors (Device busy) when trying to program a Lisa/L ===
====Programming the Lisa on OS X====

The problem:
The "default" vendor id and product id for the ftdi device on Lisa is the same one used by all the manufacturers of clone usb-serial interfaces. This isn't an issue on Linux because of the udev rules file we use does not load the ftdi drivers for lisas programming interface. Windows and Mac OS X don't use this file so they can only use vendor id and product id.
So as soon as you plug in Lisa they load USB->serial port drivers for the two ports they believe are on Lisa causing a conflict. The programming of Lisa happens through a different mechanism and does not want the programming interface of Lisa to be taken by the FTDI driver which has already been loaded. For OS X there is a hack we can do that makes it better until we can get vendor and product ids sorted out. It involves modifying the /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist file. We change it so only the first of the two serial interfaces is loaded. The second is not as it is the programming interface.

The File (edit with a text editor):
/System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist

Here is a diff between a "vanilla OS X" and one that has been modified (Essentially below was removed):
quadzilla:Contents root# diff ~/Info.plist Info.plist
<source lang="diff">
1784,1805d1783
< <key>FT2232C_B</key>
< <dict>
< <key>CFBundleIdentifier</key>
< <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
< <key>ConfigData</key>
< <dict>
< <key>LatencyTimer</key>
< <integer>2</integer>
< </dict>
< <key>IOClass</key>
< <string>FTDIUSBSerialDriver</string>
< <key>IOProviderClass</key>
< <string>IOUSBInterface</string>
< <key>bConfigurationValue</key>
< <integer>1</integer>
< <key>bInterfaceNumber</key>
< <integer>1</integer>
< <key>idProduct</key>
< <integer>24592</integer>
< <key>idVendor</key>
< <integer>1027</integer>
< </dict>
1830,1853d1807
< <key>FT2232H_B</key>
< <dict>
< <key>CFBundleIdentifier</key>
< <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
< <key>ConfigData</key>
< <dict>
< <key>LatencyTimer</key>
< <integer>2</integer>
< </dict>
< <key>IOClass</key>
< <string>FTDIUSBSerialDriver</string>
< <key>IOProviderClass</key>
< <string>IOUSBInterface</string>
< <key>bConfigurationValue</key>
< <integer>1</integer>
< <key>bInterfaceNumber</key>
< <integer>1</integer>
< <key>bcdDevice</key>
< <integer>1792</integer>
< <key>idProduct</key>
< <integer>24592</integer>
< <key>idVendor</key>
< <integer>1027</integer>
< </dict>
</source>

Once you have edited the file
- sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
- sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
To reload the driver or you can just reboot.

It is expected as Paparazzi moves to supporting more operating systems that unique product and vendor ids will be obtained thus removing the need for this step.

==Installing FlightGear==
FlightGear has been packaged for use on OS X. This package can be downloaded from:
http://www.flightgear.org/download/

There are several packages available. Recently, FlightGear 3.0 was released. A binary for OS X is available, and seems to work properly on Maverics (OS X 10.9.2). Follow the directions [http://www.flightgear.org/download/main-program/ here] for installation. Additional documentation can be found [http://macflightgear.sourceforge.net/home/documents/ here].

[[Image:Flightgear_launchgui_OSX_pprzoptions.png|thumb|350px|Screenshot of FlightGear launch gui in OS X with options for visualizing Paparazzi simulations]]
Once FlightGear is installed, the GUI launcher can be used to set common options. By clicking on the Advanced Features arrow, one can gain access to many more options as well as an interface to specify command line options (the Others tab). This is where one can specify the flight dynamics model and network connectivity required for visualizing Paparazzi simulations as described on the [[Simulation]] page.

* In Paparazzi Center, add to the simulator command the <tt>-fg</tt> option plus the IP address of the machine running flightgear in this case the loopback interace is used as Flightgear and Paparazzi are running on the same machine:
.../sw/simulator/launchsitl -a TJ1 -fg 127.0.0.1 -boot -norc
Note TJ1 is the name of the aircraft you must substitute this with the name of your aircraft.
* Launch Flight Gear with the following set in the others tab under advanced settings:
--fdm=null --native-gui=socket,in,30,,5501,udp

For Flight Gear visualization, version 3.0 or greater with Rembrand switched on is best. If you wish to use version 2.4 or lower, you must add the following to the firmware section of your airframe file:

<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<define name="FG_2_4" value="1"/>
...
</firmware>
</source>

[[Image:Flightgear_pprz_sim_OSX.png|thumb|right|350px|Screenshot of Flightgear visualizing the default Microjet simulation in OS X (not the default Muret, FR location)]]

==Simulations Using JSBSim==
[http://jsbsim.sourceforge.net/index.html JSBSim] is an open-source flight dynamics and control software library. It can provide a more realistic simulation environment over the basic built-in Paparazzi simulator. See the [[Simulation|Simulation]] page for background information and how to run a normal simulation. After this can be done in a satisfactory manner, follow the steps below to utilize the JSBSim flight dynamics model.

Please see [[JSBSim]] for installation instructions and [[Simulation#JSBSim]] for instructions on how to use the JSBSim FDM in simulations.

==Differences with the Linux version==
This section is intended to document all the subtle differences between Linux and Mac OS X versions of Paparazzi.
===Change of text editor===
The default editor in Linux is gedit, but in OS X, it is open, which simply uses whatever the default program for opening .xml files is setup.

===Ivy subnet mask===
On Linux, the Ivy submask is 127.255.255.255

On Mac OS X, the Ivy submask is 224.255.255.255

In C applications, such as tmtc/c_ivy_client_example_1.c, this should be set adaptively by something like:

#ifdef __APPLE__
printf("Mac OS, network submask: 224.255.255.255\n");
IvyStart("224.255.255.255");
#else
printf("NO Mac OS, network submask: 127.255.255.255\n");
IvyStart("127.255.255.255");
#endif

Is there a better way to do this?

[[Category:Software]] [[Category:User_Documentation]] [[Category:Installation]]

Talk:Lisa/Bone

2014-04-14T19:07:18Z

Jkg: added questions about power supply, Lia vs Lisa/M

JKG Questions:
*Do we need a power supply on the cape? It will increase cost quite a bit. If Lisa/M is still connected directly to peripherals it may as well get power from off-board, most vehicles already have a 5-6V servo bus
* fully-populated Lia vs Lisa/M?
** Allows (almost) all connections to be broken out through the cape and BBB -- 0.1" header pins on Lia and sockets on cape with screws to lock boards together
*** much less wire nest
** no header pin access to ANALOG1 or ANALOG2

RT Paparazzi

2014-01-11T22:49:15Z

Jkg: /* Debugging with an Eclipse IDE */ text/image wrap

== Real Time (RT) Paparazzi with ChibiOS/RT ==
RT Paparazzi is another step towards safer flight and more reliable autopilot. In a real time operating system (RTOS) [http://en.wikipedia.org/wiki/Real-time_operating_system] are multiple threads, which are doing specific jobs (e.g. a telemetry thread, a radio thread, a failsafe thread) at a defined rate. Unlike ''bare-metal'' application which uses interrupt driven timers for timing tasks, real time OS has a kernel which takes care of scheduling and running the threads. Having kernel, it is possible to set priority of each thread, how much memory it takes etc. which gives the developer more control over timing and resource managment.

Besides kernel, a typical RTOS also has a harware abstraction layer (HAL) which stands between user application and actual hardware, so the application developer doesn't have to worry about drivers.

There is a couple of RT based autopilots already, for example a very good Pixhawk autopilot [https://pixhawk.ethz.ch/px4/en/start] or trunetcopter [https://github.com/trunetcopter/trunetcopter].

Main strength of Paparazzi is its modularity - combining that with precise timing, scheduling and resource management that brings RTOS, Paparazzi can match if not exceed leading uav autopilots (potentially not only open-source), for example the aforementioned Pixhawk.

== ChibiOS/RT ==
RT Paparazzi is based on ChibiOS/RT [http://chibios.org/dokuwiki/doku.php]. ChibiOS/RT supports basically all architectures that standard Paparazzi does (see [http://chibios.org/dokuwiki/doku.php?id=chibios:architectures]), which makes both systems compatible. Since RTOS makes handling multiple I/O easier, but comes with some extra overhead (context switching, kernel code), it gives most leverage to to STM32 F1xx and F4xx based autopilots ([[Lisa/M_v20]], [[Lisa/S]], [[STM32F4_Discovery]], [[KroozSD]]...).

RT Paparazzi is mainly developed by AggieAir team [http://aggieair.usu.edu/] at Utah State University. A different flavor of RT paparazzi (without ChibiOS/RT HAL) is developed by [[ENAC_UAV_Laboratory]].

== Getting the code ==
Most recent code is available under ''rt_paparazzi'' branch from Paparazzi Git repo [https://github.com/paparazzi/paparazzi], however you can check these two repositories too ([https://github.com/podhrmic/ChibiOS-RT] and [https://github.com/podhrmic/paparazzi])

== Debugging with an Eclipse IDE ==
Having a good development and debugging environment is a must for developing RT embedded system. The steps of setting up Eclipse IDE are described here [http://chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse1] and here [http://chibios.org/dokuwiki/doku.php?id=chibios:guides:eclipse2].

An alternative guide is for example here [http://embeddedprogrammer.blogspot.com/2012/09/stm32f4discovery-development-with-gcc.html]

Just a few notes to the process:
* install GCC Arm Embedded toolchain [https://launchpad.net/~terry.guo/+archive/gcc-arm-embedded] (recommended anyway for Paparazzi since v 5.0)
* get Black Magic probe from Blacksphere [http://www.blacksphere.co.nz/main/blackmagic], it will make your life easier
* in '''Creating a GDB Debug Configuration''' use the following commands for Black Magic Probe:
target extended-remote /dev/ttyACM0
monitor jtag_scan
attach 1
monitor vector_catch disable hard
set mem inaccessible-by-default off
monitor option erase
set print pretty
(for [[Lisa/M_v2.0#Lisa.2FLia_F4 | Lisa/Lia F4]] board use '' swdp_scan'' instead of ''jtag_scan'')
* if you are using luftboot, don't forget to add image offset into the debug configuration:
[[File:Rt_paparazzi_eclipse_setup_2.png]]
* don't forget in "Eclipse->Window->Preferences->Run/Debug->Launching->Default Launchers->GDB Hardware Debugging" set preferred launcher to "Standard GDB" (otherwise the ChibiOS/RT plugin won't work, tested in Eclipse Kepler Service Release 1):
[[File:Rt_paparazzi_eclipse_setup_1.png]]
* to use ChibiOS/RT debug module for Eclipse, download ChibiStudio (it is for Windows only) from SourceForge [http://sourceforge.net/projects/chibios/files/ChibiStudio/], extract it and from ''ChibiStudio/eclipse/plugins'' copy
org.chibios.tools.eclipse.config_1.2.1.jar
org.chibios.tools.eclipse.debug_1.0.8.jar
to your ''eclipse/plugins'' directory. Restart Eclipse and in "Help->About Eclipe->Installation Details->Plugins" you should see both chibios plugins. Enable the plug-in while in the "Debug" view under: Window->Show View->Other...->ChibiOS/RT->ChibiOS/RT" (see [http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=140] for details)

Modems

2014-01-10T23:13:25Z

Jkg: /* Frequencies */ typo

The Paparazzi autopilots generally feature a TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Telemetry_.28Modem.29|Airframe Configuration]] and [[XBee_configuration|XBee Configuration]] pages.

==General comparison==
'''This is ONLY a comparison between modules which work acceptably'''

All modules listed here work without issue and are generally available.
{| border="1" cellspacing="0" style="text-align:center" cellpadding="2%"
| align="center" style="background:#f0f0f0;"|'''Feature'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_DigiMesh_.2F_802.15.4_.28.22Series_1.22.29|XBee Series 1]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_DigiMesh_.2F_802.15.4_.28.22Series_1.22.29|XBee Pro Series 1]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_ZB_.2F_ZNet_2.5_.28.22Series_2.22.29|XBee Series 2]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_ZB_.2F_ZNet_2.5_.28.22Series_2.22.29|XBee Pro Series 2]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_868LP|XBee 868LP]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_900HP|XBee Pro 900HP]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_XSC_900MHz|XBee Pro XSC 900]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Digi_9XTend|Digi 9XTend]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#SiLabs_Si1000_SoC_based_modems|SiLabs Si1000]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#AC4790-200|Aerocom AC4790-200]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#AC4790-1000|Aerocom AC4790-1000]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Laird_RM024|Laird RM024 50mW]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#Laird_RM024|Laird RM024 125mW]]'''
| align="center" style="background:#f0f0f0;"|'''[[Modems#RN-41_Bluetooth_module.28Sparkfun.27s_WRL-08497.29|RN-41 Bluetooth]]'''
|-
| style="background:#f0f0f0;"|'''frequency'''||2,4GHz||2,4GHz||2,4GHz||2,4GHz||868MHz||900MHz||900MHz||900MHz, 2.4GHz||240-960MHz||900MHz||900MHz||2,4GHz||2,4GHz||2,4GHz
|-
| style="background:#f0f0f0;"|'''output power'''||1mW||63mW (US) 10 mW (Int'l)||2mW||63mW||5mW||250mW||250mW||1mW-1W||max 100mW||5-200mW||5-1000mW||2,5-50mW||2,5-125mW||32mW
|-
| style="background:#f0f0f0;"|'''RF speed'''||250kbps||250kbps||250kbps||250kbps||10kbps, 80kbps||10 or 200kbps||10, 20kbps||9.6, 115.2kbps|| ||76.8kbps||76.8kbps||280, 500kbps||280, 500kbps||300kbps
|-
| style="background:#f0f0f0;"|'''antenna'''||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||external required||wire, rpsma, u.fl||wire, rpsma, u.fl||rpsma, MMCX||external required||MMCX, internal Antenna||MMCX||u.fl, chip, both||u.fl, chip, both||pcb trace
|-
| style="background:#f0f0f0;"|'''pinout'''||XBee||XBee||XBee||XBee||SMD||XBee||XBee||20 pin 2,54mm/USB||SMD (42 pin LGA)||20 pin mini connector||20 pin mini connector||XBee/SMD||XBee/SMD||SMD
|-
| style="background:#f0f0f0;"|'''price'''||16€||26€||14€||28€||18€||32€||32€||150€||4€||52€||64€||30€||30€||20€
|-
| style="background:#f0f0f0;"|'''for Country'''||Worldwide||Worldwide||Worldwide||Worldwide||Europe|| || ||Worldwide||Worldwide||North America, Australia||North America, Australia||Europe||North America||Worldwide
|}

==Frequencies==
'''please add your country !'''<br/>
analog and digital (video and modem) can NOT be done over the same frequency !!!<br/>
This list is for private persons only, with a extra licence more power or other frequencies can be used, but this list is not about this.

{| border="1" cellspacing="0" style="text-align:center" cellpadding="2%"
| align="center" style="background:#f0f0f0;"|'''Frequency\Country'''
| align="center" style="background:#f0f0f0;"|'''Germany'''
| align="center" style="background:#f0f0f0;"|'''Austria'''
| align="center" style="background:#f0f0f0;"|'''Swiss'''
|-
| style="background:#f0f0f0;"|'''5.8 GHz'''||30-1000mW||25-1000mW||25-1000mW
|-
| style="background:#f0f0f0;"|'''5.8 GHz Video'''||25mW||25mW||maybe NO/25mW
|-
| style="background:#f0f0f0;"|'''2.4 GHz'''||100mW||10mW||100mW
|-
| style="background:#f0f0f0;"|'''2.4 GHz Video'''||10mW||10mW||
|-
| style="background:#f0f0f0;"|'''1.2 GHz'''||NO||NO||NO
|-
| style="background:#f0f0f0;"|'''900 MHz'''||NO||NO||NO
|}

If there is a range (e.g. 20-1000mW) given, it depends on several factors(frequency band, power control, frequency hopping, inform yourself !

NO --> Do NOT use this frequency, it is maybe used by military or cell phones, you will get serious troubles if you use this !!!

2.4GHz Video & 5.8GHz Video--> these are analog Video signals which have other limitations than digital ones.

== Digi XBee modules ==

Digi (formerly Maxstream) offers an increasing variety of Zigbee protocol modems well suited for Paparazzi in 2.4 GHz, 900MHz and 868Mhz frequencies. The "Pro" series are long range, up to 40km! Standard series are slightly smaller/lighter/lower power consumption and very short range. All versions are all pin compatible and weigh around 2 grams with wire antennas. All Digi modems can be operated in transparent mode (as a serial line replacement) or in "API mode" with hardware addressing, managed networking, and RSSI (signal strength) data with the Paparazzi "Xbee" option.

Four antenna options are offered: RP-SMA, U-FL, wire antenna, chip antenna

* XBee (PRO) ZB (the current series)
* XBee (PRO) ZNet 2.5 (formerly Series 2) (only legacy -> use XBee-PRO ZB)
The XBee & XBee-PRO ZB share hardware (ember stack) with XBee & XBee-PRO ZNet 2.5. As a result, modules can be "converted" from one platform to another by loading different firmware onto a given module.

These two also share the same hardware and can be converted from one to another by flashing a different firmware:
* XBee-PRO 802.15.4 (formerly Series 1)
* XBee-PRO DigiMesh 2.4

'''Note: Modules based on Freescale chipset (formerly Series 1) are not compatible with Ember chipset based modules (Series 2).'''

If only point to point or point to multipoint communication is required 802.15.4 will do the job. These are designed for high data rates and low latency.<br/>
Modules with Zigbee firmware are needed for mesh functionality(communication between the UAV's)

See the [[XBee_configuration|XBee Configuration]] page. This [http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee tutorial] is also good to configure and get started with XBee Pro.

=== Module Comparison ===
{|border="1"
|-valign="top"
||'''Module'''||'''Point-to-Multipoint'''||'''ZigBee/Mesh'''||'''Chipset'''|||'''Software stack'''||'''Frequency'''||'''TX Power normal/PRO'''||'''Notes'''
|-
|'''XBee ZB'''
|
|yes
|Ember
|EmberZNet PRO 3.1 (ZigBee 2007)
|2.4 GHz
|2mW/50mW
|coordinator needed
|-
|'''XBee ZNet 2.5'''
|
|yes
|Ember
|EmberZNet 2.5 ZigBee
|2.4 GHz
|2mW/50mW
|(only legacy -> use XBee-PRO ZB) coordinator needed
|-
|'''XBee DigiMesh 2.4'''
|
|yes
|Freescale
|
|2.4 GHz
|
|all nodes equal (no special coordinators/routers/end-devices)
|-
|'''XBee 802.15.4'''
|yes
|
|Freescale
|
|2.4 GHz
|
|
|-
|'''XBee-PRO 868'''
|yes
|
|?
|
|868 MHz
|500mW
|Only High Power Frequency allowed in the UK. 2.4GHz limited to 10mW
|}

==== Pinout ====

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

The image view is from above, top, thus NOT at the side where the connector pins come out

Note : DTR and RTS need to be wired for upgrading firmware

=== GCS Adaptation ===

There are several vendors of hardware to connect the ground XBee radio modem to the GCS computer.

====Adafruit====

[[Image:xbeeadapter_LRG.jpg|thumb|left|Adafruit XBee adapter board]][[Image:xbeeadapterftdi_LRG.jpg|thumb|Adafruit XBee adapter with FTDI cable]]
[http://www.adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126 Adafruit] offers a great adapter board kit for the Xbee modules that includes a 5-3.3V voltage regulator, power and activity LEDs, and pins to connect directly to your FTDI cable for $10! Some assembly required.

<br style="clear:both">

====Droids====

[[Image:XBee_Simple_Board.jpg|thumb|left|XBee Simple Board]]

[[Image:XBee_USB_Board.jpg|thumb|left|XBee USB Board]]

[http://www.droids.it/cmsvb4/content.php?143-990.001-XBee-Simple-Board XBee Simple Board]

Simpler, lighter, smaller footprint, bit more expensive, comes assembled and tested. --GR

[http://www.droids.it/cmsvb4/content.php?152-990.002-XBee-USB-Board XBee USB Board]

For direct connection to USB (no FTDI cable required)

<br style="clear:both">

====PPZUAV====

[[Image:FTDI_Utility_Board.jpg|thumb|left|FTDI Utility Board 1.0‎]]

[https://www.ppzuav.com/osc/product_info.php?cPath=13&products_id=111&osCsid=upcl59vp10vdvno35ejl453442 ppzuav.com product link]

FTDI Utility Board 1.0 with FTDI232RL<br/>
On board XBEE connector and molex picoblade connectors.

<br style="clear:both">

====Sparkfun====

[[Image:XBee_Explorer_USB.jpg|thumb|left|XBee Explorer USB]]

[http://www.sparkfun.com/products/8687 sparkfun.com]

XBee Explorer USB with FTDI232RL

<br style="clear:both">

=== Digi XBee Pro DigiMesh / 802.15.4 ("Series 1") ===
*Note: Products based on XBee ZNet 2.5 (formerly Series 2) modules do not communicate with products based on XBee DigiMesh / 802.15.4 (formerly Series 1) modules.

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices. For the plane, get the whip antenna version if you are not planning to build a custom antenna.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4GHz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* Price: 16€, Pro 26€
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}
Mouser: [http://au.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMtJacPDJcUJYzVn8vIv7g2fIpf5DCzJqko%3d 888-XBP24-PKC-001-UA]<br>
NOTE: If you wish to use this unit with another XBee type other than the 802.15.4 (i.e. XBee-PRO ZB) then purchase a modem with the U.fl connector.

==== Documentation ====

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]
* To program your Xbee you need X-CTU you can download it [http://www.digi.com/support/productdetl.jsp?pid=3352&osvid=57&tp=5&s=316 here]. (only windows)
* explanation on X-CTU [http://www.ladyada.net/make/xbee/configure.html here].
* [http://ftp1.digi.com/support/firmware/update/xbee/ Drivers for XB24 and XBP24 modules]

=== Digi XBee Pro ZB / ZNet 2.5 ("Series 2") ===

The low-power XBee ZB and extended-range XBee-PRO ZB use the ZigBee PRO Feature Set for advanced mesh networking.

{|
|-valign="top"
|[[Image:XBee_Pro_2SB.jpg|thumb|left|Digi XBee Pro ZB]]
|
* Low-cost, low-power mesh networking
* Interoperability with ZigBee PRO Feature Set devices from other vendors*
* Support for larger, more dense mesh networks
* 128-bit AES encryption
* Frequency agility
* Over-the-air firmware updates (change firmware remotely)
* ISM 2.4 GHz operating frequency
* XBee: 2 mW (+3 dBm) power output (up to 400 ft RF LOS range)
* XBee-PRO: 50 mW (+17 dBm) power output (up to 1 mile RF LOS range)
* RPSMA connector, U.FL connector, Chip antenna, or Wired Whip antenna
* price : 14€, Pro 28€
|
|}
These are available from Mouser:<br>
[http://au.mouser.com/Search/Refine.aspx?Keyword=888-XBP24-Z7WIT-004 888-XBP24-Z7WIT-004] XBee-PRO ZB with whip antenna<br>
[http://au.mouser.com/Search/Refine.aspx?Keyword=XBP24-Z7SIT-004 888-XBP24-Z7SIT-004] XBee-PRO ZB with RPSMA

See [[XBee_configuration|XBee Configuration]] for setup.

==== Documentation ====
* [http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp]

=== Digi XBee Pro 868 ===

'''WARNING - THESE MODEMS HAVE A 10% DUTY CYCLE, AND CURRENTLY HAVE SEVERE ISSUES WITH PAPARAZZI'''

868MHz is a limited band. Please read the [[868MHz Issues]]

XBee-PRO 868 modules are long range embedded RF modules for European applications. Purpose-built for exceptional RF performance, XBee-PRO 868 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.

{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro 868]]
|
* 868 MHz short range device (SRD) G3 band for Europe
* Software selectable Transmit Power
* 40 km RF LOS w/ dipole antennas
* 80 km RF LOS w/ high gain antennas (TX Power reduced)
* Simple to use peer-to-peer/point-to-mulitpoint topology
* 128-bit AES encryption
* 500 mW EIRP
* 24 kbps RF data rate
* price : ~70 USD
|
|}

See [[XBee_configuration#XBee_Pro_868_MHZ|XBee Configuration]] for setup.

==== Documentation ====
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp]

=== Digi XBee 868LP ===

XBee 868LP modules are a low-power 868 MHz RF module for use in Europe. The range is shorter than it's brother the XBee PRO-868, but it can use the 868 G4 band with hopping which does not have restrictions on it's duty cycle. This is a big advantage if one want to have a good stream of telemetry data

{|
|-valign="top"
|[[Image:868lp.jpg|thumb|left|XBee 868LP]]
|
* 868 MHz short range device (SRD) G4 band for Europe
* 4 km RF LOS w/ u.fl antennas
* 5 mW EIRP
* 10 or 80 kbps RF data rate
* price : 18€
|
|}

==== Documentation ====
* [http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview]

==== Trial ====

With a quickly crafted and not optimal positioned antenna on the airframe we managed to get the advertised 4000 meter range. Data throughput was not high and the Iridium Telemetry XML configuration document was therefore used. All in all, cheap, easy to setup, pin compatible with regular modules and quite a range and usable in Europe without hassle.

=== Digi XBee Pro 900HP ===
* Frequency band 900Mhz
* RF rate 10 or 200 kbps
* up to 250mW output power
* 5 to 8 gramm
* price: 32€

==== Documentation ====
[http://ftp1.digi.com/support/documentation/90002173_H.pdf http://ftp1.digi.com/support/documentation/90002173_H.pdf]

=== Digi XBee Pro XSC 900MHz ===

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4 GHz video compatibility of their high end 900 MHz models. Sounds like the perfect modem for anyone who can use 900 MHz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900 MHz
* Output Power 100 mW (+20 dBm)
* Sensitivity -100 dBm
* RF Rate: 10 or 20 kbps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : 32€
|
|}

==== Documentation ====
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

==== Trials ====
Tested one today and it worked great. Going to try a multiUAV test with it soon
--Danstah
<br>
<br>
MultiUAV tests concluded this is probably not the best module to use. Even though it says you can change the baudrate inside x-ctu that is not the case, it is fixed at 9600 bps. This is a great modem however for single UAV's and I do recommend.
--Danstah
<br>
<br>
Why would the European (868 MHz) be good to 24kbps and this only to 9600? When I was altering my XBees (2.4Ghz Pro's) I had this problem altering baud rates until I read you have to send a "commit and reboot" type command after setting the baud rate. Could this be the case? --GR

=== Digi 9XTend ===

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable transmit power settings from 100mW to 1W. Testing has shown range up to 5.6km (3.5 Miles) with XTend set to 100mW with small 3.1dB dipole antenna.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector or USB
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : 150€
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

==== Pinout ====

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||2 (5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||2||This pin must be connected to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

==== Documentation ====

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

==== Configuration ====

These modems need to be carefully configured based on your usage scenario to obtain the best possible range and link quality. In addition, it is always good to make sure the firmware is up to date.

Some typical configurations that may work well, but can still depend your particular situation, are given below. For further details, be sure to consult the XTend users manual. Your application may need a different or modified configuration. The radiomodems do not need identical settings and can in fact be optimized with different settings. A good example is delays and retries: if each radio has the same number of retries and no delay, when a collision occurs each will continuously try to re-transmit, locking up the transmission for some time with no resolution or successful packet delivery. Instead, it is best to set the module whose data should have a lower latency to have no delay and a lower number of retries, while the other module has a delay set (RN > 0) and a greater number of retries. See acknowledged mode example below.

* Acknowledged Polling Mode ('''Recommended'''):
** This causes one radio to be the base and the other(s) to be the remote(s). It eliminates collisions because remotes do not send data unless requested by the base. It can work in acknowledged mode (RR>0), basic reliable mode (MT>0) or in basic mode (no acknowledgement or multiple packets). It is recommended that the lower latency and/or higher data rate side be configured as the base (i.e. if you are sending lots of telemetry then the air module configured as the base is probably a good idea, but if you are using datalink joystick control, the ground side might be better as the base. It may require some experimentation).
* Acknowledged Point-to-(Multi)Point Mode:
** Each radio sends a packet and requests and acknowledgement that the packet was sent from the receiving side. The retries and delays must be set appropriately to ensure packet collisions are dealt with appropriately. It can also work without acknowledgements in basic reliable mode (MT>0) without any acknowledgements (RR=0, MT=0). Some experimentation may be required.

{| border="1"
|-valign="top"
||'''''Setting Name'''''||colspan="2"|'''''Acknowledged Mode'''''||colspan="2"|'''''Polling Mode (Acknowledged)'''''||'''''Notes'''''
|-
|| ||'''''Airside Module'''''||'''''Groundside Module'''''||'''''Base Module'''''||'''''Remote Module'''''||
|-
||BD||6||6||6||6||Adjust to match your configured autopilot and ground station baud rates (default for these is 57600bps)
|-
||DT||default||default||0x02||0x01||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||MD||default||default||3 (0x03)||4 (0x04)||
|-
||MT||0||0||0||0||Use this to enable Basic Reliable transmission, link bandwidth requirement increases (see manual)
|-
||MY||default||default||0x01||0x02||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PB||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PD||default||default||default||default||Can be adjusted to increase polling request rate and DI buffer flush timeout (see manual)
|-
||PE||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PL||default||default||default||default||''Transmit power level should be reduced for lab testing!!''
|-
||RN||0 (0x00)||8 (0x08)||default||default||
|-
||RR||6 (0x06)||12 (0x0C)||6 (0x06)||12 (0x0C)||
|}

'''Note:''' All settings are assumed to be default except those listed. Those listed are in decimal unless hex 0x prefix included. Depending on your firmware version, slight modifications may be necessary.

Here is some additional information and alternative instructions to configure the polling mode from the Digi site: [http://www.digi.com/support/kbase/kbaseresultdetl?id=2178 Polling Mode for the 9XTend Radio Modem]

== SiLabs Si1000 SoC based modems ==

The Si1000 radio System on Chip (SOC) produced by SiLabs is found in a number of radio modules, for example the cheap and widely used HopeRf module. There is [https://github.com/tridge/SiK open source firmware] for these radios which makes them suitable for use in MAVs.

Note that (unlike some XBee modules) the SiK firmware does not support mesh topologies, it is strictly a point-to-point link. If you are working with swarming vehicles they may not be the best choice.

Online documentation for the Sik firmware shows how to configure it for various jurisdictions. The firmware supports 433 MHz, 470 MHz, 868 MHz and 900 MHz radios, if you are aware of any hardware supporting the European spectrum licences (868 MHz) please add them to this wiki.

Note: When using a SiK firmware radio with paparazzi, you should set "ATS6=0" (MavLink packing off) and configure paparazzi for transparent serial mode.

[http://www.rfdesign.com.au/index.php/rfd900 This module] is well proven and supports antenna diversity. A combination of 6dbi Yagi plus a dipole on the ground station, with a pair of orthogonality oriented dioples in the airframe, has been extensively tested and proven reliable at >8km range (theoretical range of ~40km).

Alternatively, for shorter range a pair of cheap generic HopeRF-based modems [http://rctimer.com/index.php?gOo=goods_details.dwt&goodsid=815 such as these]

The RFD900 can be paired with cheap generic (single front-end) modules, if for example you use a small short range airframe with a ground station that's also used for long range operations.

== Laird (ex Aerocom) ==
Lairds's API mode is already implemented but some system integration is required. Full API more with addressed packets works well and was tested with AC4790-1x1 5mW low power modules. Maximim range achieved with a whip quater-wave antenna was 1Km.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

See folder paparazzi3 / trunk / sw / aerocomm. It has all the required files to use this modem on the airborne and ground station side. The link.ml file is a direct replacement of the "main" link.ml file of the ground sttaion and will be merged into it in the future.. or you can do it as well.

{|
|
=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : 52€
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|
=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : 64€
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Laird AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Laird AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Laird AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny v1.1 Serial-1'''''||'''''Tiny v2.11 Serial'''''||'''''Notes'''''
|-
||2||Tx||green||7||7||''(Note 1)''
|-
||3||Rx||blue||8||8||''(Note 1)''
|-
||5||GND||black||1||1|| -
|-
||10+11||VCC||red||2||3||+3.3v ''(Note 2)''
|-
||17||C/D||white||3||?||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

''Note 2 : AC4790-1000 needs pins 10 and 11 jumped to work properly''

=== Laird RM024 ===
[[Image:Laird_LT2510_RM024-P125-C-01-side.jpg|thumb|RM024 P125]]
[[Image:Lt2510_prm123.jpg|thumb|LT2510 Modem]]
The RM024 replaces the discontinued LT2510 (they are backwards compatible).

General features:
* Frequency Band 2.4GHz
* Output Power 2,5mW - 125mW
* Sensitivity -98dbm @ 280kbps/-94 dBm @ 500kbps
* RF Data Rate 280/500 kbps
* UART up to 460800 baud
* Power Draw 90mA - 180mA TX / 10mA RX
* Supply Voltage 3.3v
* Range up to 4000m
* Dimensions 26 x 33 x 4mm
* Weight 4 grams
* Interface 20-pin mini connector (smd solder pad or XBee compatible pin header)
* Chip antenna, U.FL antenna connector or both
* Price: 29-31€ @ mouser (SMD / XBEE header)

Two different mounting/pinuts are available:<br/>
* smd version: can be soldered on a pcb<br/>
* pin header: standard XBEE pinout (this is the SMD version mounted on a seperate pcb with male pin headers)

Available in two different output power versions:
{|border="1"
|-valign="top"
||''value''||''50mW version''||''125mW version''
|-
|output power
| 2,5 mW - 50 mW
| 2,5 mW - 125 mW
|-
|output power dbm
|4 dbm - 17 dbm
|4 dbm - 21 dbm
|-
|TX drain
|90mA
|<180mA
|-
|max range (280kbps with 2 dbi antenna)
|2400m
|4000m
|-
|approval
|CE for EU, FCC/IC for USA,
Canada PRM122/123 also for Japan
|FCC/IC for USA, Canada
|}

The RM024 uses frequency hopping (FHSS) which needs a client/server model. That means that one modem (most appropriately the ground station modem) needs to be set to server mode. It will transmit a beacon message and have all client modems synchronize to that in a time and frequency hopping scheme manner. For that all modems need to have the same channel (in fact the hopping scheme) and system-id. Clients can be set to auto-channel and auto-system-id to follow any/the first visible server.

====Documentation====
[http://www.lairdtech.com/WorkArea/DownloadAsset.aspx?id=2147488576 RM024 User Manual]<br/>
[http://www.lairdtech.com/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=4379 LT2510 User Manual]<br/>
[http://www.lairdtech.com/zips/Developer_Kit.zip Windows configuration tool]

'''Setup'''

Look at the [[Laird_Setup page]]

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== RN-41 Bluetooth module(Sparkfun's WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : 20€
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

either make a virtual connection to a Bluetooth serial port each time you connect

sudo rfcomm bind 0 00:06:66:00:53:AD

or configure it once in /etc/bluetooth/rfcomm.conf

rfcomm0 {
bind yes;
device 00:06:66:00:53:AD;
}

now you can use Bluetooth as '''/dev/rfcomm0''' with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Telemetry via Video Transmitter==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, an analog video transmitter can be used. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.

It is possible to use the audio channel to send simple telemetry data to the groundstation. Uploading telemetry not possible via analog audio transmitter only.
<br style="clear:both">

== Telemetry via Internet / Raspberry Pi==
Not ready yet...

The main link works over the internet and mobile internet.

Most UMTS sticks don't have a own public IP adress and can't be used as a server. The ssh connection must be reversed(ssh server runs on the gcs, not on the uav)

How to:
*Establish the connection between a UMTS stick and the Raspberry PI, search for each programm for seperate instructions, these on instructables aren't complete ! [http://www.instructables.com/id/Raspberry-Pi-as-a-3g-Huawei-E303-wireless-Edima/#step1 Instructables site]

A android smartphone is another way to provide the Raspberry pi with a internet connection. [http://www.therasberrypi.com/how-to-usb-tether-android-to-your-raspberry-pi Android USB thetering setup]

*set up ser2net
*set up static ip adress (public) of your gcs [http://www.cyberciti.biz/tips/howto-ubuntu-linux-convert-dhcp-network-configuration-to-static-ip-configuration.html static IP Ubuntu]
*set up reverse ssh tunnel [http://www.tunnelsup.com/tup/2013/05/08/raspberry-pi-phoning-home-using-a-reverse-remote-ssh-tunnel ssh reverse serial tunnel]

*connect Raspberry PI with AP over UART (Raspberry Pi's UART Pins are only 3.3v and not 5v tollerant)
== Old / not supported ==
Modules in these cathegory have issues with paparazzi are discontinued by the manufacturer.
Maybe hey will be deleted soon.

=== Laird / Aerocom AC4868-250 ===
'''This module was discontinued by the manufacturer'''
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
* Frequency Band 868MHz (For Europe). 868MHz is a limited band. Please read the [[868MHz Issues]]
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : 64€

=== Radiotronix ===
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise as connected RTS/CTS sporadically leads to a reprogramming of the modem. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions. Note that a 1/2 wave dipole antenna works best on-board as it doesn't require a ground-plane and has a reasonably omnidirectional radiation pattern.
{|
|
==== WI232EUR ====
'''This Module has been discontinued by the manufacturer'''
* Frequency Band: 868 MHz (for Europe)
* Output Power: 32 mW
* RF Data Rate: Up to 76.8 kbps
* Interface Data Rate: up to 115.2 kbps
* Power Draw (typical): 65 mA TX / 20 mA RX
* Supply Voltage: 3.3v
* Range (typical, depends on antenna & environment): 500 meters line-of-sight
* Dimensions: 24 x 21 x 4mm
* Weight: ~2 grams
* Interface: solder connector
* Antenna: solder connector
* Price: ~25$
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem (picture shows connection to Tiny 1.1)]]

==== Pinout ====

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny v1.1
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}

==== Documentation ====
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

=== Digi XBee Pro 900 ===
'''These modules have been discontinued by the manufacturer, new version is XBee Pro 900HP'''

XBee Pro 900 modules are long range embedded RF modules for US applications. Purpose-built for exceptional RF performance, XBee-Pro 900 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.

==== Documentation ====
* [ftp://ftp1.digi.com/support/documentation/90000903_a.pdf ftp://ftp1.digi.com/support/documentation/90000903_a.pdf]

=== Coronis WaveCard ===

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

==== Documentation ====

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]
== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

This wiki page might give some ideas about antennas: http://en.wikipedia.org/wiki/Dipole_antenna

[[Category:Hardware]]

Lia

2013-11-21T19:32:32Z

Jkg: /* Differences from Lisa/M */

'''Lia''' is a lower cost version of [[Lisa/M]] first developed for inclusion with the [http://wiki.thequadshot.com/wiki/The_Mocha Quadshot Mocha].

== Differences from Lisa/M ==

* 0.1" pitch through-holes instead of molex picoblade
* No CAN transceiver (footprint still present just not populated) on [http://www.transition-robotics.com Transition Robotics]serial numbers LI1-001 through LI1-200 (populated on serial numbers ≥LI1-201)
* No I2C2 level shifter (footprint still present just not populated)
* No 5V voltage regulator (footprint still present just not populated)
* No JTAG connector (footprint still present just not populated)
* Added servo power inline resistors (by default 0 ohm but can be changed to higher value for balancing the linear voltage regulators of the motor controllers)

== Pictures ==

<gallery>
Image:Lia_1.1_top.jpg|Lia V1.1 top side
Image:Lia_1.1_bottom.jpg|Lia V1.1 bottom side
Image:Lia_1.1_aspirin_bottom.jpg|Lia V1.1 bottom side with Aspirin 2.1 nomag nobaro placed.
</gallery>

== Jumper Configuration ==
There are a number of jumpers on Lia used to configure voltage levels and power input. Their locations and functions are identical to those on the Lisa/M v2.0.<br/>
See the [[Lisa/M_v2.0#Jumper_Configuration|Jumper Configuration section on the Lisa/M v2.0 page]].

Note that the default states of JP8 and JP9 are reversed with respect to the defaults of Lisa/M v2.0; that is:

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Lia UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||OPEN||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

[[Category:Lisa]]

DSM

2013-10-29T18:40:45Z

Jkg: added link to deviation thread

== What is DSM (DSM2/DSMX) ==
DSM2 and DSMX are widely used radio protocols for 2.4GHz spektrum RC transmitters and receivers. It is also used in the [[SuperbitRF]] project as datalink. The protocol makes it possible to have multiple receiver/transmitters in the 2.4GHz spektrum without much interference.

=== The difference between DSM2 and DSMX ===
There is only a small difference between DSM2 and DSMX, which is the way they hop between different channels. In the DSM2 protocol the transmitter will choose two random channels, where the transmitter will look for the two best channels in the optimal case. In the DSMX protocol the transmitter and receiver both use the transmitter radio chip ID,which is send during the binding process, for generating 23 channels. Each time the transmitter transmits a packet or the receiver receives a packet they will hop to the next channel.

From this information you can conclude that when you use DSM2, and both the channels that were chosen are getting used by a lot of other users your reception will drop enormously. In the DSMX protocol this problem was solved and makes it possible to have a lot more transmitters/receivers at the same bandwidth.

== How does it work ==
''Note that this is reverse engineered and will contain errors.''

In general you have three phases, the binding procedure, the syncing procedure and the normal transfer procedure. The transmitter doesn't have a syncing procedure, because it determines the timing for the receiver.

=== The binding procedure ===
At the binding procedure both the transmitter and receiver will change to [[DSM#Definitions|SDR (Single Data Rate) mode]], a data code of 64 bits, a [[DSM#Definitions|SOP (Start Of Packet) Code]] of 64 bits and disable the [[DSM#Definitions|CRC Checksum]]. The transmitter will then choose a random odd channel and starts sending the [[DSM#Binding packet|binding packet]] at a very high rate. The receiver will start at the first odd channel and waits a bit longer then the rate the transmitters sends at. When it does receive a packet, it will check if it is a valid bind packet and goes to syncing mode. When it doesn't receive a valid packet it will go to the next channel and will repeat this.

During the binding procedure the transmitter also sends the amount of RC channels that it has and in which amount of packets this channels will fit. They will either transmit all the channels in one packet or in two packets after each other.

=== The syncing procedure ===
Because the transmitter doesn't have a syncing procedure, the transmitter is already in the transfer procedure. The receiver on the other hand needs to synchronise itself with the transmitter.

TODO

=== The transfer procedure ===
TODO

== References ==
Some general information about the DSM2/DSMX protocol.

=== Definitions ===
* '''Channel''': The channel in the 2.4GHz band(2.400GHz to 2.483GHz) which is used to transmit or receive. Each channel is 100mHz higher then the previous one starting by 0, and the 2.4GHz band is divided into 98 channels.
* '''(Transmission) Mode''': The mode at which the transmitter, or receiver is sending/receiving. There are four different modes the transmitter/receiver could be in: GFSK(Gaussian Frequency Shift Keying), 8DR(Octal Data Rate), DDR(Double Data Rate), SDR(Single Data Rate). The ones used are 8DR and SDR, in SDR mode one bit is encoded in each derived code symbol transmitted. In 8DR mode eight bits are encoded in each derived code symbol transmitted.
* '''GFSK''': Gaussian Frequency Shift Keying Transfer mode. CYRF6936 in this mode data is transmitted at 1 Mbps, without any DSSS.
* '''8DR''': Octal Data Rate. CYRF6936 in this mode eight bits are encoded in each derived code symbol transmitted.
* '''DDR''': Double Data Rate. CYRF6936 in this mode two bits are encoded in each derived code symbol transmitted.
* '''SDR''': Single Data Rate. CYRF6936 in this mode one bit is encoded in each derived code symbol transmitted.
* '''SOP code''': Start Of Packet code, are one or two bytes which are added at the start of the packet by the radio chip. These bytes are used to identify if a packet is received at a certain channel.
* '''Packet length''': The packet length(one byte) is send after the SOP code, and only includes the length of the payload data. Because it is one byte the limit of the payload length is 255, but because 8DR and SDR only transmit 16byte packets they will be automatically split up into multiple packets.
* '''CRC (Checksum)''': The CRC Checksum are two bytes which are send at the end of the packet to check if the received packet was valid. It can detect the following errors: any one bit error, any two bits error, any odd number of bits in error and an error burst as wide as the checksum itself.
* '''CYRF6936''': A radio chip used in several transmitters and the SuperbitRF project.

=== Packet example ===
Here is an image of an example packet including the Preamble, SOP, Length, Payload Data and the CRC.

[[File:DSM_packet_example.png|600px]]

=== Binding packet ===
The binding packet has a length of 16 bytes, the exact size the SDR mode can send at once.
[00] radio chip ID byte 0 (inverted)
[01] radio chip ID byte 1 (inverted)
[02] radio chip ID byte 2 (inverted)
[03] radio chip ID byte 3 (inverted)
[04] radio chip ID byte 0 (inverted)
[05] radio chip ID byte 1 (inverted)
[06] radio chip ID byte 2 (inverted)
[07] radio chip ID byte 3 (inverted)
[08] (sum 00->07 + 384 - 16) MSB
[09] (sum 00->07 + 384 - 16) LSB
[10] 0x01 (not known yet)
[11] number of RC channels
[12] protocol used (0x01:DSM2 1packet, 0x02: DSM2 2packets, 0x10: DSM2 SuperbitRF, 0x11: DSMX SuperbitRF, 0xA2: DSMX 1packet, 0xB2: DSMX 2packets)
[13] 0x00 (not known yet)
[14] (sum 00->13 + 384 - 16) MSB
[15] (sum 00->13 + 384 - 16) LSB

=== Transfer packet ===
The transfer packet has a length of 16 bytes, the exact size 8DR mode can send at once.
[00] radio chip ID byte 2
[01] radio chip ID byte 3 (+packet loss bit in SuperbitRF)
[02-15] data

==Raw DSM data capture files==

To aid the understanding of the various DSM protocols, data was captured using the following hardware:

*Main receiver: Spektrum AR9020
*Satellite receivers: 2x Spektrum 9645 connected to Ant B and Ant R ports
*[http://www.saleae.com/logic Saleae Logic] set to capture signal wires of satellite receivers:
**Channel 0 = Ant B
**Channel 1 = Ant R
**GROUND = ground of Ant R

The capture data has been split into separate runs to abide by the file size limits of this wiki :-)

The Mac/Win/Linux software to read/parse/export the data is downloadable from the Saleae [http://www.saleae.com/downloads website].

===DSM data 1===
[[File:DSM_data_1_-_DX7s.zip]]

Transmitter: Spektrum DX7s

Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
*TX switched off
*power down RXes
*stop capture

===DSM data 2===
[[File:DSM_data_2_part_1_-_DX18.zip‎]] (DSM2 runs)

[[File:DSM_data_2_part_2_-_DX18.zip‎]] (DSMX runs)

Transmitter: Spektrum DX18

Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX
*22ms DSM2 Xplus
*22ms DSMX Xplus

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
**aux3 (7)
**aux4 (8)
**aux5 (9)
*TX switched off
*power down RXes
*stop capture

===DSM data 3===
[[File:DSM_data_3_-_DX18_Xplus_channels.zip]]

Transmitter: Spektrum DX18

Data capture runs @ 500 KHz:
*22ms DSM2 Xplus
*22ms DSMX Xplus

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0) mixed with X+1
**X+2
**X+3
**X+4
**X+5
**X+6
**X+7
**X+8

*TX switched off
*power down RXes
*stop capture
===DSM data 4===
[[File:DSM_data_4_part_1_-_DX18_Xplus_channels_12_MHz_capture.zip‎]] (DSM2 run)

[[File:DSM_data_4_part_2_-_DX18_Xplus_channels_12_MHz_capture.zip‎]] (DSMX run)

Transmitter: Spektrum DX18

Data capture runs @ 12 MHz:
*22ms DSM2 Xplus
*22ms DSMX Xplus

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0) mixed with X+1
**X+2
**X+3
**X+4
**X+5
**X+6
**X+7
**X+8

*TX switched off
*power down RXes
*stop capture
===DSM data 5===
[[File:DSM_data_5_part_1_-_DX18_RSSI.zip‎]] (DSM2 runs)

[[File:DSM_data_5_part_2_-_DX18_RSSI.zip]] (DSMX runs)

Transmitter: Spektrum DX18 in range test mode

Data capture runs @ 1 MHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX
*22ms DSM2 Xplus
*22ms DSMX Xplus

RSSI test:

*Logic set to trigger on rising edge.
*TX switched on and set to range test mode
*Power on RXes/start capture
*Press range test button (reduce TX power)
*Move TX away from RX while moving elevator (2) channel repeatedly until servo no longer moves/satellite LEDs are out
*release range test button (normal TX power)
*stop capture

== External References ==
* [http://www.cypress.com/?docID=28606 CYRF6936 Data Sheet]
* [http://www.deviationtx.com/ Deviation Firmware]
* [https://sites.google.com/site/mrdunk/interfacing-cypress-cyrf6936-to-avr-microcontrollers Interfacing with the CYRF6936]
* [http://www.rcgroups.com/forums/showthread.php?t=1759502 RCGroups: DSMX Hacking]
* [http://www.deviationtx.com/forum/7-development/2088-18-channels-for-dsm2-dsmx Deviation forum: 18 channel thread]

RotorcraftMixing

2013-10-09T21:04:24Z

Jkg: typo

This page describe how to compute "mixing" for an arbitrary multirotors configuration.

[[Image:hexa_3D.png|800px]]

== Introduction ==

"Mixing" consist in converting rotational accelerations commands computed by the autopilot into throttle commands for each of the motor controllers.

Let us consider a vehicle comprising a set of <math>N</math> identical fixed pitch rotors <math>R_i, i \in[1:N]</math> located at coordinates <math>(X_i,Y_i, 0), i\in[1:N]</math> and spinning in the same plane in the direction <math>D_i, i\in[1:N], D_i\in[-1;1]</math> at a rotational speed <math>\omega_i, i\in[1:N]</math>.

Assuming a quasi hovering regime, the force produced by each rotor can be considered normal to the rotor plane and proportional to the square of its rotational speed. Expressed in body frame ( front, right, down ), this leads to
<math>
\overrightarrow{F}_{i}^{B} = \begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix}
</math>

Under the same assumption, the torque produced by each rotor can also be assumed to be in the same direction and proportional to the square of the rotational speed.

The torque produced by each rotor around the CG, expressed in body frame can then be writen

<math>
\overrightarrow{M}_{i}^{B} = \begin{pmatrix}X_i\\Y_i\\0\end{pmatrix}\wedge\begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix} + \begin{pmatrix}0\\0\\D_i C_m \omega_i^2\end{pmatrix}
</math>

<math>
\overrightarrow{M}_{i}^{B} = C_t \omega_i^2 \begin{pmatrix}-Y_i \\X_i \\D_i \frac{C_m}{C_t}\end{pmatrix}
</math>

Where <math>C_t</math> is a "thrust" coefficient and <math>Cm</math> is a "torque" coefficient. It has been measured experimentally that <math>\frac{Ct}{Cm} \approx 10</math> on a mikrokopter.

As a first approximation we can consider that the rotational speed of the propeller is proportional to the square root of the applied command <math>u_i</math>

<math>
\omega_i^2 = K u_i
</math>

This allows us to express the torque produced by the set of rotors as

<math>
\overrightarrow{M}^{B} = \sum_{i=1}^{N} \overrightarrow{M}_{i}^{B} = K C_t
\begin{pmatrix}
-\sum_{i=1}^{N} Y_i u_i\\
\sum_{i=1}^{N} X_i u_i\\
\frac{C_m}{C_t} \sum_{i=1}^{N} D_i u_i
\end{pmatrix}
</math>

which can be rewriten as a matrix vector product

<math>
\overrightarrow{M}^{B} =
K C_t
\begin{pmatrix}
-Y_1&-Y_2&\ldots&-Y_n\\
X_1& X_2&\ldots& X_n\\
\frac{C_m}{Ct}D_1&\frac{C_m}{Ct}D_2&\ldots&\frac{C_m}{Ct}D_n
\end{pmatrix}
\begin{pmatrix}
u_1\\
u_2\\
\vdots\\
u_n
\end{pmatrix}
</math>

<math>
\overrightarrow{M}^{B} = A \overrightarrow{U}
</math>

<math>A</math> is a <math>3*N</math> matrix describing the geometric positions of our rotors and <math>U</math> is the vector of throttle commands for our set of motor controllers.

In order to express the command applied to each power train as a function of the momentum we want to apply to our vehicle, we need to find <math>B</math>, a <math>N*3</math> matrix such as

<math>
\overrightarrow{U} = B \overrightarrow{M}^B
</math>

If <math>A</math> has rank 3, we know that such a matrix exists (yeah, we can't do 2 rotors or have all rotors aligned), and in this case, we have the relationship

<math>
AB = \mathcal{I}_3
</math>

We know that one solution of this equation is the Moore-Penrose pseudoinverse of <math>A</math>.
Furthermore, this solution is the one leading to the power train command vector having the smallest euclidian norm, which is interesting as it optimizes the repartion of our control effort across our power trains.

== Example ==

Let's consider the following H hexarotors configuration.

[[Image:hexa_h.png|200px]]

<math>
A =
\begin{pmatrix}
-0.17 & 0.17 &-0.25& 0.25&-0.33 & 0.33 \\
-0.35 &-0.35 & 0 & 0 & 0.35 & 0.35 \\
-0.1 & 0.1 & 0.1 &-0.1 &-0.1 & 0.1
\end{pmatrix}
</math>

The first two lines of the <math>A</math> matrix represent the coordinates of each rotor in the <math>X,Y</math> plane, and the third line the direction in which they spin. Note that in this example the X axis is vertical, and the Y coordinates are in the top row of <math>A</math>.

<math>
B =
\begin{pmatrix}
-0.24 & -0.71 & -1.47 \\
0.241 & -0.71 & 1.47 \\
-0.93 & 0. & 2.44 \\
0.93 & 0. & -2.44 \\
-0.69 & 0.71 & -1.09 \\
0.69 & 0.71 & 1.09
\end{pmatrix}
</math>

Normalizing columns of <math>B</math> yelds

<math>
\tilde{B} =
\begin{pmatrix}
-67 & -256 & -154 \\
67 & -256 & 154 \\
-256 & 0 & 256 \\
256 & 0 & -256 \\
-189 & 256 & -115 \\
189 & 256 & 115 \\
\end{pmatrix}
</math>

which in turns yelds the following supervision section

<pre>
<section name="SUPERVISION" prefix="SUPERVISION_">
<define name="MIN_MOTOR" value="3"/>
<define name="MAX_MOTOR" value="200"/>
<define name="TRIM_A" value="0"/>
<define name="TRIM_E" value="0"/>
<define name="TRIM_R" value="0"/>
<define name="NB_MOTOR" value="6"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ -67, 67, -256, 256, -189, 189}"/>
<define name="PITCH_COEF" value="{ -256, -256, 0, 0, 256, 256}"/>
<define name="YAW_COEF" value="{ -154, 154, 256, -256, -115, 115}"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256}"/>
</section>
</pre>

The above computation can be performed using the following simple octave script (sudo apt-get install octave3.2)
octave
copy the flowing commands in the terminal: (ncol is the number of col from matrix B. in this example = 3 )
exit

<pre>
A = [
-0.17 0.17 -0.25 0.25 -0.33 0.33
-0.35 -0.35 0. 0. 0.35 0.35
-0.1 0.1 0.1 -0.1 -0.1 0.1
];

B = pinv(A)

m = max(abs(B))

[nrow,ncol] = size(B)

for i=1:ncol
Btilde(:,i) = B(:,i)/m(i);
end

Btilde = round(256*Btilde)

</pre>

[[Category:Software]] [[Category:User_Documentation]]

RotorcraftMixing

2013-10-09T21:03:48Z

Jkg: clarified axes for example

This page describe how to compute "mixing" for an arbitrary multirotors configuration.

[[Image:hexa_3D.png|800px]]

== Introduction ==

"Mixing" consist in converting rotational accelerations commands computed by the autopilot into throttle commands for each of the motor controllers.

Let us consider a vehicle comprising a set of <math>N</math> identical fixed pitch rotors <math>R_i, i \in[1:N]</math> located at coordinates <math>(X_i,Y_i, 0), i\in[1:N]</math> and spinning in the same plane in the direction <math>D_i, i\in[1:N], D_i\in[-1;1]</math> at a rotational speed <math>\omega_i, i\in[1:N]</math>.

Assuming a quasi hovering regime, the force produced by each rotor can be considered normal to the rotor plane and proportional to the square of its rotational speed. Expressed in body frame ( front, right, down ), this leads to
<math>
\overrightarrow{F}_{i}^{B} = \begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix}
</math>

Under the same assumption, the torque produced by each rotor can also be assumed to be in the same direction and proportional to the square of the rotational speed.

The torque produced by each rotor around the CG, expressed in body frame can then be writen

<math>
\overrightarrow{M}_{i}^{B} = \begin{pmatrix}X_i\\Y_i\\0\end{pmatrix}\wedge\begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix} + \begin{pmatrix}0\\0\\D_i C_m \omega_i^2\end{pmatrix}
</math>

<math>
\overrightarrow{M}_{i}^{B} = C_t \omega_i^2 \begin{pmatrix}-Y_i \\X_i \\D_i \frac{C_m}{C_t}\end{pmatrix}
</math>

Where <math>C_t</math> is a "thrust" coefficient and <math>Cm</math> is a "torque" coefficient. It has been measured experimentally that <math>\frac{Ct}{Cm} \approx 10</math> on a mikrokopter.

As a first approximation we can consider that the rotational speed of the propeller is proportional to the square root of the applied command <math>u_i</math>

<math>
\omega_i^2 = K u_i
</math>

This allows us to express the torque produced by the set of rotors as

<math>
\overrightarrow{M}^{B} = \sum_{i=1}^{N} \overrightarrow{M}_{i}^{B} = K C_t
\begin{pmatrix}
-\sum_{i=1}^{N} Y_i u_i\\
\sum_{i=1}^{N} X_i u_i\\
\frac{C_m}{C_t} \sum_{i=1}^{N} D_i u_i
\end{pmatrix}
</math>

which can be rewriten as a matrix vector product

<math>
\overrightarrow{M}^{B} =
K C_t
\begin{pmatrix}
-Y_1&-Y_2&\ldots&-Y_n\\
X_1& X_2&\ldots& X_n\\
\frac{C_m}{Ct}D_1&\frac{C_m}{Ct}D_2&\ldots&\frac{C_m}{Ct}D_n
\end{pmatrix}
\begin{pmatrix}
u_1\\
u_2\\
\vdots\\
u_n
\end{pmatrix}
</math>

<math>
\overrightarrow{M}^{B} = A \overrightarrow{U}
</math>

<math>A</math> is a <math>3*N</math> matrix describing the geometric positions of our rotors and <math>U</math> is the vector of throttle commands for our set of motor controllers.

In order to express the command applied to each power train as a function of the momentum we want to apply to our vehicle, we need to find <math>B</math>, a <math>N*3</math> matrix such as

<math>
\overrightarrow{U} = B \overrightarrow{M}^B
</math>

If <math>A</math> has rank 3, we know that such a matrix exists (yeah, we can't do 2 rotors or have all rotors aligned), and in this case, we have the relationship

<math>
AB = \mathcal{I}_3
</math>

We know that one solution of this equation is the Moore-Penrose pseudoinverse of <math>A</math>.
Furthermore, this solution is the one leading to the power train command vector having the smallest euclidian norm, which is interesting as it optimizes the repartion of our control effort across our power trains.

== Example ==

Let's consider the following H hexarotors configuration.

[[Image:hexa_h.png|200px]]

<math>
A =
\begin{pmatrix}
-0.17 & 0.17 &-0.25& 0.25&-0.33 & 0.33 \\
-0.35 &-0.35 & 0 & 0 & 0.35 & 0.35 \\
-0.1 & 0.1 & 0.1 &-0.1 &-0.1 & 0.1
\end{pmatrix}
</math>

The first two lines of the <math>A</math> matrix represent the coordinates of each rotor in the <math>X,Y</math> plane, and the third line the direction in which they spin. Note that in this example the Y axis is vertical, and the Y coordinates are in the top row of <math>A</math>.

<math>
B =
\begin{pmatrix}
-0.24 & -0.71 & -1.47 \\
0.241 & -0.71 & 1.47 \\
-0.93 & 0. & 2.44 \\
0.93 & 0. & -2.44 \\
-0.69 & 0.71 & -1.09 \\
0.69 & 0.71 & 1.09
\end{pmatrix}
</math>

Normalizing columns of <math>B</math> yelds

<math>
\tilde{B} =
\begin{pmatrix}
-67 & -256 & -154 \\
67 & -256 & 154 \\
-256 & 0 & 256 \\
256 & 0 & -256 \\
-189 & 256 & -115 \\
189 & 256 & 115 \\
\end{pmatrix}
</math>

which in turns yelds the following supervision section

<pre>
<section name="SUPERVISION" prefix="SUPERVISION_">
<define name="MIN_MOTOR" value="3"/>
<define name="MAX_MOTOR" value="200"/>
<define name="TRIM_A" value="0"/>
<define name="TRIM_E" value="0"/>
<define name="TRIM_R" value="0"/>
<define name="NB_MOTOR" value="6"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ -67, 67, -256, 256, -189, 189}"/>
<define name="PITCH_COEF" value="{ -256, -256, 0, 0, 256, 256}"/>
<define name="YAW_COEF" value="{ -154, 154, 256, -256, -115, 115}"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256}"/>
</section>
</pre>

The above computation can be performed using the following simple octave script (sudo apt-get install octave3.2)
octave
copy the flowing commands in the terminal: (ncol is the number of col from matrix B. in this example = 3 )
exit

<pre>
A = [
-0.17 0.17 -0.25 0.25 -0.33 0.33
-0.35 -0.35 0. 0. 0.35 0.35
-0.1 0.1 0.1 -0.1 -0.1 0.1
];

B = pinv(A)

m = max(abs(B))

[nrow,ncol] = size(B)

for i=1:ncol
Btilde(:,i) = B(:,i)/m(i);
end

Btilde = round(256*Btilde)

</pre>

[[Category:Software]] [[Category:User_Documentation]]

RotorcraftMixing

2013-10-09T20:53:28Z

Jkg: fixed signs of first row of matrix A code to correspond to pretty-printed A values; added absolute value to max function to handle case where longest motor arm is negative

This page describe how to compute "mixing" for an arbitrary multirotors configuration.

[[Image:hexa_3D.png|800px]]

== Introduction ==

"Mixing" consist in converting rotational accelerations commands computed by the autopilot into throttle commands for each of the motor controllers.

Let us consider a vehicle comprising a set of <math>N</math> identical fixed pitch rotors <math>R_i, i \in[1:N]</math> located at coordinates <math>(X_i,Y_i, 0), i\in[1:N]</math> and spinning in the same plane in the direction <math>D_i, i\in[1:N], D_i\in[-1;1]</math> at a rotational speed <math>\omega_i, i\in[1:N]</math>.

Assuming a quasi hovering regime, the force produced by each rotor can be considered normal to the rotor plane and proportional to the square of its rotational speed. Expressed in body frame ( front, right, down ), this leads to
<math>
\overrightarrow{F}_{i}^{B} = \begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix}
</math>

Under the same assumption, the torque produced by each rotor can also be assumed to be in the same direction and proportional to the square of the rotational speed.

The torque produced by each rotor around the CG, expressed in body frame can then be writen

<math>
\overrightarrow{M}_{i}^{B} = \begin{pmatrix}X_i\\Y_i\\0\end{pmatrix}\wedge\begin{pmatrix}0\\0\\-C_t \omega_i^2\end{pmatrix} + \begin{pmatrix}0\\0\\D_i C_m \omega_i^2\end{pmatrix}
</math>

<math>
\overrightarrow{M}_{i}^{B} = C_t \omega_i^2 \begin{pmatrix}-Y_i \\X_i \\D_i \frac{C_m}{C_t}\end{pmatrix}
</math>

Where <math>C_t</math> is a "thrust" coefficient and <math>Cm</math> is a "torque" coefficient. It has been measured experimentally that <math>\frac{Ct}{Cm} \approx 10</math> on a mikrokopter.

As a first approximation we can consider that the rotational speed of the propeller is proportional to the square root of the applied command <math>u_i</math>

<math>
\omega_i^2 = K u_i
</math>

This allows us to express the torque produced by the set of rotors as

<math>
\overrightarrow{M}^{B} = \sum_{i=1}^{N} \overrightarrow{M}_{i}^{B} = K C_t
\begin{pmatrix}
-\sum_{i=1}^{N} Y_i u_i\\
\sum_{i=1}^{N} X_i u_i\\
\frac{C_m}{C_t} \sum_{i=1}^{N} D_i u_i
\end{pmatrix}
</math>

which can be rewriten as a matrix vector product

<math>
\overrightarrow{M}^{B} =
K C_t
\begin{pmatrix}
-Y_1&-Y_2&\ldots&-Y_n\\
X_1& X_2&\ldots& X_n\\
\frac{C_m}{Ct}D_1&\frac{C_m}{Ct}D_2&\ldots&\frac{C_m}{Ct}D_n
\end{pmatrix}
\begin{pmatrix}
u_1\\
u_2\\
\vdots\\
u_n
\end{pmatrix}
</math>

<math>
\overrightarrow{M}^{B} = A \overrightarrow{U}
</math>

<math>A</math> is a <math>3*N</math> matrix describing the geometric positions of our rotors and <math>U</math> is the vector of throttle commands for our set of motor controllers.

In order to express the command applied to each power train as a function of the momentum we want to apply to our vehicle, we need to find <math>B</math>, a <math>N*3</math> matrix such as

<math>
\overrightarrow{U} = B \overrightarrow{M}^B
</math>

If <math>A</math> has rank 3, we know that such a matrix exists (yeah, we can't do 2 rotors or have all rotors aligned), and in this case, we have the relationship

<math>
AB = \mathcal{I}_3
</math>

We know that one solution of this equation is the Moore-Penrose pseudoinverse of <math>A</math>.
Furthermore, this solution is the one leading to the power train command vector having the smallest euclidian norm, which is interesting as it optimizes the repartion of our control effort across our power trains.

== Example ==

Let's consider the following H hexarotors configuration.

[[Image:hexa_h.png|200px]]

<math>
A =
\begin{pmatrix}
-0.17 & 0.17 &-0.25& 0.25&-0.33 & 0.33 \\
-0.35 &-0.35 & 0 & 0 & 0.35 & 0.35 \\
-0.1 & 0.1 & 0.1 &-0.1 &-0.1 & 0.1
\end{pmatrix}
</math>

The first two lines of the <math>A</math> matrix represent the coordinates of each rotor in the <math>X,Y</math> plan, and the third line the direction in which they spin.

<math>
B =
\begin{pmatrix}
-0.24 & -0.71 & -1.47 \\
0.241 & -0.71 & 1.47 \\
-0.93 & 0. & 2.44 \\
0.93 & 0. & -2.44 \\
-0.69 & 0.71 & -1.09 \\
0.69 & 0.71 & 1.09
\end{pmatrix}
</math>

Normalizing columns of <math>B</math> yelds

<math>
\tilde{B} =
\begin{pmatrix}
-67 & -256 & -154 \\
67 & -256 & 154 \\
-256 & 0 & 256 \\
256 & 0 & -256 \\
-189 & 256 & -115 \\
189 & 256 & 115 \\
\end{pmatrix}
</math>

which in turns yelds the following supervision section

<pre>
<section name="SUPERVISION" prefix="SUPERVISION_">
<define name="MIN_MOTOR" value="3"/>
<define name="MAX_MOTOR" value="200"/>
<define name="TRIM_A" value="0"/>
<define name="TRIM_E" value="0"/>
<define name="TRIM_R" value="0"/>
<define name="NB_MOTOR" value="6"/>
<define name="SCALE" value="256"/>
<define name="ROLL_COEF" value="{ -67, 67, -256, 256, -189, 189}"/>
<define name="PITCH_COEF" value="{ -256, -256, 0, 0, 256, 256}"/>
<define name="YAW_COEF" value="{ -154, 154, 256, -256, -115, 115}"/>
<define name="THRUST_COEF" value="{ 256, 256, 256, 256, 256, 256}"/>
</section>
</pre>

The above computation can be performed using the following simple octave script (sudo apt-get install octave3.2)
octave
copy the flowing commands in the terminal: (ncol is the number of col from matrix B. in this example = 3 )
exit

<pre>
A = [
-0.17 0.17 -0.25 0.25 -0.33 0.33
-0.35 -0.35 0. 0. 0.35 0.35
-0.1 0.1 0.1 -0.1 -0.1 0.1
];

B = pinv(A)

m = max(abs(B))

[nrow,ncol] = size(B)

for i=1:ncol
Btilde(:,i) = B(:,i)/m(i);
end

Btilde = round(256*Btilde)

</pre>

[[Category:Software]] [[Category:User_Documentation]]

Modems

2013-10-07T22:18:40Z

Jkg: typos, corrected xBee pro S1 power

The Paparazzi autopilots generally feature a TTL serial port to interface with any common radio modem. The bidirectional link provides real-time telemetry and in-flight tuning and navigation commands. The system is also capable overlaying the appropriate protocols to communicate thru non-transparent devices such as the Coronis Wavecard or Maxstream API-enabled products, allowing for hardware addressing for multiple aircraft or future enhancements such as data-relaying, inter-aircraft communication, RSSI signal monitoring and automatic in-flight modem power adjustment. Below is a list of some of the common modems used with Paparazzi, for details on configuring your modem see the [[Airframe_Configuration#Telemetry_.28Modem.29|Airframe Configuration]] and [[XBee_configuration|XBee Configuration]] pages.

==General comparison==
'''This is ONLY a comparison between modules which work acceptably'''

All modules listed here work without issue and are generally available.
{| border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="100%"
| align="center" width="16%" style="background:#f0f0f0;"|'''Feature'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_DigiMesh_.2F_802.15.4_.28.22Series_1.22.29|XBee Series 1]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_DigiMesh_.2F_802.15.4_.28.22Series_1.22.29|XBee Pro Series 1]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_ZB_.2F_ZNet_2.5_.28.22Series_2.22.29|XBee Series 2]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_ZB_.2F_ZNet_2.5_.28.22Series_2.22.29|XBee Pro Series 2]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_868LP|XBee 868LP]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_900HP|XBee Pro 900HP]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_XBee_Pro_XSC_900MHz|XBee Pro XSC 900]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Digi_9XTend|Digi 9XTend]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#SiLabs_Si1000_SoC_based_modems|SiLabs Si1000]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#AC4790-200|Aerocom AC4790-200]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#AC4790-1000|Aerocom AC4790-1000]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Laird_.28ex_Aerocomm.29|Laird LT2510 50mW]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#Laird_.28ex_Aerocomm.29|Laird LT2510 125mW]]'''
| align="center" width="7%" style="background:#f0f0f0;"|'''[[Modems#RN-41_Bluetooth_module.28Sparkfun.27s_WRL-08497.29|RN-41 Bluetooth]]'''
|-
| style="background:#f0f0f0;"|'''frequency'''||2,4GHz||2,4GHz||2,4GHz||2,4GHz||868MHz||900MHz||900mHz||900MHz, 2.4GHz||240-960MHz||900MHz||900MHz||2,4GHz||2,4GHz||2,4GHz
|-
| style="background:#f0f0f0;"|'''output power'''||1mW||63mW (US) 10 mW (Int'l)||2mW||63mW||5mW||250mW||250mW||1mW-1W||max 100mW||5-200mW||5-1000mW||2,5-50mW||2,5-125mW||32mW
|-
| style="background:#f0f0f0;"|'''RF speed'''||250kbps||250kbps||250kbps||250kbps||10kbps, 80kbps||10 or 200kbps||10, 20kbps||9.6, 115.2kbps|| ||76.8kbps||76.8kbps||280, 500kbps||280, 500kbps||300kbps
|-
| style="background:#f0f0f0;"|'''antenna'''||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||chip, wire, rpsma, u.fl||external required||wire, rpsma, u.fl||wire, rpsma, u.fl||rpsma, MMCX||external required||MMCX, internal Antenna||MMCX||u.fl, chip||u.fl, chip||pcb trace
|-
| style="background:#f0f0f0;"|'''pinout'''||XBee||XBee||XBee||XBee||SMD||XBee||XBee||20 pin 2,54mm/USB||SMD (42 pin LGA)||20 pin mini connector||20 pin mini connector||XBee/SMD||XBee/SMD||SMD
|-
| style="background:#f0f0f0;"|'''price'''||16€||26€||14€||28€||18€||32€||32€||150€||4€||52€||64€||30€||30€||20€
|-
| style="background:#f0f0f0;"|'''for Country'''||Worldwide||Worldwide||Worldwide||Worldwide||Europe|| || ||Worldwide||Worldwide||North America, Australia||North America, Australia||Europe||North America||Worldwide
|}

== Digi XBee modules ==

Digi (formerly Maxstream) offers an increasing variety of Zigbee protocol modems well suited for Paparazzi in 2.4 GHz, 900MHz and 868Mhz frequencies. The "Pro" series are long range, up to 40km! Standard series are slightly smaller/lighter/lower power consumption and very short range. All versions are all pin compatible and weigh around 2 grams with wire antennas. All Digi modems can be operated in transparent mode (as a serial line replacement) or in "API mode" with hardware addressing, managed networking, and RSSI (signal strength) data with the Paparazzi "Xbee" option. Three antenna options are offered: the SMA version is ideal for ground modems, wire antennas for aircraft, and chip antennas for those with very limited space.

* XBee (PRO) ZB (the current series)
* XBee (PRO) ZNet 2.5 (formerly Series 2) (only legacy -> use XBee-PRO ZB)
The XBee & XBee-PRO ZB share hardware (ember stack) with XBee & XBee-PRO ZNet 2.5. As a result, modules can be "converted" from one platform to another by loading different firmware onto a given module.

These two also share the same hardware and can be converted from one to another by flashing a different firmware:
* XBee-PRO 802.15.4 (formerly Series 1)
* XBee-PRO DigiMesh 2.4

'''Note: Modules based on Freescale chipset (formerly Series 1) are not compatible with Ember chipset based modules (Series 2).'''

See the [[XBee_configuration|XBee Configuration]] page. This [http://pixhawk.ethz.ch/tutorials/how_to_configure_xbee tutorial] is also good to configure and get started with XBee Pro.

=== Module Comparison ===
{|border="1"
|-valign="top"
||'''Module'''||'''Point-to-Multipoint'''||'''ZigBee/Mesh'''||'''Chipset'''|||'''Software stack'''||'''Frequency'''||'''TX Power normal/PRO'''||'''Notes'''
|-
|'''XBee ZB'''
|
|yes
|Ember
|EmberZNet PRO 3.1 (ZigBee 2007)
|2.4 GHz
|2mW/50mW
|coordinator needed
|-
|'''XBee ZNet 2.5'''
|
|yes
|Ember
|EmberZNet 2.5 ZigBee
|2.4 GHz
|2mW/50mW
|(only legacy -> use XBee-PRO ZB) coordinator needed
|-
|'''XBee DigiMesh 2.4'''
|
|yes
|Freescale
|
|2.4 GHz
|
|all nodes equal (no special coordinators/routers/end-devices)
|-
|'''XBee 802.15.4'''
|yes
|
|Freescale
|
|2.4 GHz
|
|
|-
|'''XBee-PRO 868'''
|yes
|
|?
|
|868 MHz
|500mW
|Only High Power Frequency allowed in the UK. 2.4GHz limited to 10mW
|}

==== Comparison Conclusion ====

(Copied from DIGI manual)

''If the application strictly needs to communicate in a point-to-point or a point-to-multipoint
fashion, 802.15.4 will be able handle all the communications between your devices and will
be simpler to implement than trying to use a module with ZigBee firmware to accomplish the
same goal. ZigBee is necessary if you need to use repeating or the mesh networking
functionality.''

-Interpretation for paparazzi: if inter-aircraft communication is required one should go for the zigbee ZB series 2 modules.

==== Pinout ====

[[Image:Maxstream_Xbee_pinout.jpg|left|thumb|Maxstream XBee pinout]]
<br style="clear:both">

{|border="1"
|-valign="top"
||''Xbee 20-pin Header''||''Name''||''Notes''||''Suggested Color''||
|-
|1
| +3.3v
| Power
|Red
|-
|2
|DOUT
|Tx output - connect to Autopilot Rx
|Green
|-
|3
|DIN
|Rx input - connect to Autopilot Tx
|Blue
|-
|10
|GND
| Ground
|Black
|}

The image view is from above, top, thus NOT at the side where the connector pins come out

Note : DTR and RTS need to be wired for upgrading firmware

=== GCS Adaptation ===

There are several vendors of hardware to connect the ground XBee radio modem to the GCS computer.

====Adafruit====

[[Image:xbeeadapter_LRG.jpg|thumb|left|Adafruit XBee adapter board]][[Image:xbeeadapterftdi_LRG.jpg|thumb|Adafruit XBee adapter with FTDI cable]]
[http://www.adafruit.com/index.php?main_page=product_info&cPath=29&products_id=126 Adafruit] offers a great adapter board kit for the Xbee modules that includes a 5-3.3V voltage regulator, power and activity LEDs, and pins to connect directly to your FTDI cable for $10! Some assembly required.

<br style="clear:both">

====Droids====

[[Image:XBee_Simple_Board.jpg|thumb|left|XBee Simple Board]]

[[Image:XBee_USB_Board.jpg|thumb|left|XBee USB Board]]

[http://www.droids.it/cmsvb4/content.php?143-990.001-XBee-Simple-Board XBee Simple Board]

Simpler, lighter, smaller footprint, bit more expensive, comes assembled and tested. --GR

[http://www.droids.it/cmsvb4/content.php?152-990.002-XBee-USB-Board XBee USB Board]

For direct connection to USB (no FTDI cable required)

<br style="clear:both">

====PPZUAV====

[[Image:FTDI_Utility_Board.jpg|thumb|left|FTDI Utility Board 1.0‎]]

[https://mini.ppzuav.com/osc/product_info.php?cPath=13&products_id=111 ppzuav.com]

FTDI Utility Board 1.0 (no FTDI cable required)

<br style="clear:both">

====Sparkfun====

[[Image:XBee_Explorer_USB.jpg|thumb|left|XBee Explorer USB]]

[http://www.sparkfun.com/products/8687 sparkfun.com]

XBee Explorer USB (no FTDI cable required)

<br style="clear:both">

=== Digi XBee Pro DigiMesh / 802.15.4 ("Series 1") ===
*Note: Products based on XBee ZNet 2.5 (formerly Series 2) modules do not communicate with products based on XBee DigiMesh / 802.15.4 (formerly Series 1) modules.

These relatively cheap and light modules implement the [http://www.zigbee.org/en/index.asp ZigBee/IEEE 802.15.4] norm. They allow up to 1.6km (1 mile) range (Paparazzi tested to 2.5km (1.5 miles)). The main drawback of using such 2.4Ghz modules for datalink is that it will interfere with the 2.4Ghz analog video transmitters and a inevitable decrease in range when in proximity to any wifi devices. For the plane, get the whip antenna version if you are not planning to build a custom antenna.

{|
|-valign="top"
|[[Image:Xbee_Pro_USB_RF_Modem.jpg|thumb|left|XBee Pro USB Stand-alone Modem (XBP24-PKC-001-UA)]]
|
* Frequency Band 2.4Ghz
* Output Power 100mW (Xbee Pro)
* Sensitivity -100 dBm
* RF Data Rate Up to 250 Kbps
* Interface data rate Up to 115.2 Kbps
* Power Draw (typical) 214 mA TX / 55 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) Up to 1500m line-of-sight
* Dimensions 24 x 33mm
* Weight 4 grams
* Interface 20-pin mini connector
* Chip antenna, ¼ monopole integrated whip antenna or a U.FL antenna connector (3 versions)
* Price: 16€, Pro 26€
|
[[Image:XBee_pro.jpg|thumb|left|XBee Pro OEM Modem]]
|}
Mouser: [http://au.mouser.com/Search/ProductDetail.aspx?qs=sGAEpiMZZMtJacPDJcUJYzVn8vIv7g2fIpf5DCzJqko%3d 888-XBP24-PKC-001-UA]<br>
NOTE: If you wish to use this unit with another XBee type other than the 802.15.4 (i.e. XBee-PRO ZB) then purchase a modem with the U.fl connector.

==== Documentation ====

* [http://www.maxstream.net/products/xbee/xbee-pro-oem-rf-module-zigbee.php product page]
* [http://www.maxstream.net/products/xbee/datasheet_XBee_OEM_RF-Modules.pdf datasheet]
* [http://www.maxstream.net/products/xbee/product-manual_XBee_OEM_RF-Modules.pdf user manual]
* To program your Xbee you need X-CTU you can download it [http://www.digi.com/support/productdetl.jsp?pid=3352&osvid=57&tp=5&s=316 here]. (only windows)
* explanation on X-CTU [http://www.ladyada.net/make/xbee/configure.html here].
* [http://ftp1.digi.com/support/firmware/update/xbee/ Drivers for XB24 and XBP24 modules]

=== Digi XBee Pro ZB / ZNet 2.5 ("Series 2") ===

The low-power XBee ZB and extended-range XBee-PRO ZB use the ZigBee PRO Feature Set for advanced mesh networking.

{|
|-valign="top"
|[[Image:XBee_Pro_2SB.jpg|thumb|left|Digi XBee Pro ZB]]
|
* Low-cost, low-power mesh networking
* Interoperability with ZigBee PRO Feature Set devices from other vendors*
* Support for larger, more dense mesh networks
* 128-bit AES encryption
* Frequency agility
* Over-the-air firmware updates (change firmware remotely)
* ISM 2.4 GHz operating frequency
* XBee: 2 mW (+3 dBm) power output (up to 400 ft RF LOS range)
* XBee-PRO: 50 mW (+17 dBm) power output (up to 1 mile RF LOS range)
* RPSMA connector, U.FL connector, Chip antenna, or Wired Whip antenna
* price : 14€, Pro 28€
|
|}
These are available from Mouser:<br>
[http://au.mouser.com/Search/Refine.aspx?Keyword=888-XBP24-Z7WIT-004 888-XBP24-Z7WIT-004] XBee-PRO ZB with whip antenna<br>
[http://au.mouser.com/Search/Refine.aspx?Keyword=XBP24-Z7SIT-004 888-XBP24-Z7SIT-004] XBee-PRO ZB with RPSMA

See [[XBee_configuration|XBee Configuration]] for setup.

==== Documentation ====
* [http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp http://www.digi.com/products/wireless/zigbee-mesh/xbee-zb-module.jsp]

=== Digi XBee Pro 868 ===

'''WARNING - THESE MODEMS HAVE A 10% DUTY CYCLE, AND CURRENTLY HAVE SEVERE ISSUES WITH PAPARAZZI'''

868MHz is a limited band. Please read the [[868MHz Issues]]

XBee-PRO 868 modules are long range embedded RF modules for European applications. Purpose-built for exceptional RF performance, XBee-PRO 868 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.

{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro 868]]
|
* 868 MHz short range device (SRD) G3 band for Europe
* Software selectable Transmit Power
* 40 km RF LOS w/ dipole antennas
* 80 km RF LOS w/ high gain antennas (TX Power reduced)
* Simple to use peer-to-peer/point-to-mulitpoint topology
* 128-bit AES encryption
* 500 mW EIRP
* 24 kbps RF data rate
* price : ~70 USD
|
|}

See [[XBee_configuration#XBee_Pro_868_MHZ|XBee Configuration]] for setup.

==== Documentation ====
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-868.jsp]

=== Digi XBee 868LP ===

XBee 868LP modules are a low-power 868 MHz RF module for use in Europe. The range is shorter than it's brother the XBee PRO-868, but it can use the 868 G4 band with hopping which does not have restrictions on it's duty cycle. This is a big advantage if one want to have a good stream of telemetry data

{|
|-valign="top"
|[[Image:868lp.jpg|thumb|left|XBee 868LP]]
|
* 868 MHz short range device (SRD) G4 band for Europe
* 4 km RF LOS w/ u.fl antennas
* 5 mW EIRP
* 10 or 80 kbps RF data rate
* price : 18€
|
|}

==== Documentation ====
* [http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-868lp#overview]

==== Trial ====

With a quickly crafted and not optimal positioned antenna on the airframe we managed to get the advertised 4000 meter range. Data throughput was not high and the Iridium Telemetry XML configuration document was therefore used. All in all, cheap, easy to setup, pin compatible with regular modules and quite a range and usable in Europe without hassle.

=== Digi XBee Pro 900HP ===
* Frequency band 900Mhz
* RF rate 10 or 200 kbps
* up to 250mW output power
* 5 to 8 gramm
* price: 32€

==== Documentation ====
[http://ftp1.digi.com/support/documentation/90002173_H.pdf http://ftp1.digi.com/support/documentation/90002173_H.pdf]

=== Digi XBee Pro XSC 900MHz ===

Maxstream has recently announced a promising new line of modems combining the small size and low cost of their popular Xbee line with the long range and 2.4 GHz video compatibility of their high end 900 MHz models. Sounds like the perfect modem for anyone who can use 900 MHz. Give them a try and post your results here!
{|
|-valign="top"
|[[Image:xbeeproxsc-rpsma.jpg|thumb|left|Maxstream XBee Pro XSC]]
|
* Frequency Band 900 MHz
* Output Power 100 mW (+20 dBm)
* Sensitivity -100 dBm
* RF Rate: 10 or 20 kbps
* Range (typical, depends on antenna & environment) Up to 24km (15 miles) line-of-sight
* Interface 20-pin mini connector (Xbee compatible pinout)
* RPSMA, integrated whip antenna or U.FL antenna connector (3 versions)
* price : 32€
|
|}

==== Documentation ====
* [http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp http://www.digi.com/products/wireless/point-multipoint/xbee-pro-xsc.jsp]

==== Trials ====
Tested one today and it worked great. Going to try a multiUAV test with it soon
--Danstah
<br>
<br>
MultiUAV tests concluded this is probably not the best module to use. Even though it says you can change the baudrate inside x-ctu that is not the case, it is fixed at 9600 bps. This is a great modem however for single UAV's and I do recommend.
--Danstah
<br>
<br>
Why would the European (868 MHz) be good to 24kbps and this only to 9600? When I was altering my XBees (2.4Ghz Pro's) I had this problem altering baud rates until I read you have to send a "commit and reboot" type command after setting the baud rate. Could this be the case? --GR

=== Digi 9XTend ===

These larger units have been tested on the 900Mhz band, but are also available in 2.4Ghz. They are a bit on the heavy side, about 20 grams, but give good performance at range. They have adjustable transmit power settings from 100mW to 1W. Testing has shown range up to 5.6km (3.5 Miles) with XTend set to 100mW with small 3.1dB dipole antenna.

{|
|-valign="top"
|
[[Image:XTend_USB_RF_Modem.jpg|frame|left|9XTend USB Modem]]
|
* Frequency Band 900Mhz and 2.4Ghz (2 versions)
* Output Power 1mW to 1W software selectable
* Sensitivity -110 dBm (@ 9600 bps)
* RF Data Rate 9.6 or 115.2 Kbps
* Interface data rate up to 230.4 Kbps
* Power Draw (typical) 730 mA TX / 80 mA RX
* Supply Voltage 2.8 to 5.5v
* Range (typical, depends on antenna & environment) Up to 64km line-of-sight
* Dimensions 36 x 60 x 5mm
* Weight 18 grams
* Interface 20-pin mini connector or USB
* RF connector RPSMA (Reverse-polarity SMA) or MMCX (2 versions)
* price : 150€
|
[[Image:Xtend_module.jpg|frame|left|9XTend OEM Modem]]
|}

==== Pinout ====

[[Image:Maxstream_9XTend_Pinout.gif|thumb|left|Maxstream 9XTend Pinout]]

{| border="1"
|-valign="top"
||'''''9XTend 20-pin Header'''''||'''''Name'''''||'''''Tiny Serial-1 Header'''''||'''''Notes'''''
|-
||1||GND||1 (GND)||Ground
|-
||2||VCC||2 (5V)||5V power (150mA - 730mA Supplied from servo bus or other 5V source)
|-
||5||RX||8 (TX)||3-5V TTL data input - connect to Tiny TX
|-
||6||TX||7 (RX)||5V TTL data output - connect to Tiny RX
|-
||7||Shutdown||2||This pin must be connected to the 5V bus for normal operation
|}
Notes:<br>
* 9XTend can run on voltages as low as 2.8V but users are strongly advised against connecting any modem (especially high power models) to the sensitive 3.3V bus supplying the autopilot processor and sensors.
<br style="clear:both">

==== Documentation ====

* [http://www.maxstream.net/products/xtend/oem-rf-module.php product page]
* [http://www.maxstream.net/products/xtend/datasheet_XTend_OEM_RF-Module.pdf datasheet]
* [http://www.maxstream.net/products/xtend/product-manual_XTend_OEM_RF-Module.pdf user manual]

==== Configuration ====

These modems need to be carefully configured based on your usage scenario to obtain the best possible range and link quality. In addition, it is always good to make sure the firmware is up to date.

Some typical configurations that may work well, but can still depend your particular situation, are given below. For further details, be sure to consult the XTend users manual. Your application may need a different or modified configuration. The radiomodems do not need identical settings and can in fact be optimized with different settings. A good example is delays and retries: if each radio has the same number of retries and no delay, when a collision occurs each will continuously try to re-transmit, locking up the transmission for some time with no resolution or successful packet delivery. Instead, it is best to set the module whose data should have a lower latency to have no delay and a lower number of retries, while the other module has a delay set (RN > 0) and a greater number of retries. See acknowledged mode example below.

* Acknowledged Polling Mode ('''Recommended'''):
** This causes one radio to be the base and the other(s) to be the remote(s). It eliminates collisions because remotes do not send data unless requested by the base. It can work in acknowledged mode (RR>0), basic reliable mode (MT>0) or in basic mode (no acknowledgement or multiple packets). It is recommended that the lower latency and/or higher data rate side be configured as the base (i.e. if you are sending lots of telemetry then the air module configured as the base is probably a good idea, but if you are using datalink joystick control, the ground side might be better as the base. It may require some experimentation).
* Acknowledged Point-to-(Multi)Point Mode:
** Each radio sends a packet and requests and acknowledgement that the packet was sent from the receiving side. The retries and delays must be set appropriately to ensure packet collisions are dealt with appropriately. It can also work without acknowledgements in basic reliable mode (MT>0) without any acknowledgements (RR=0, MT=0). Some experimentation may be required.

{| border="1"
|-valign="top"
||'''''Setting Name'''''||colspan="2"|'''''Acknowledged Mode'''''||colspan="2"|'''''Polling Mode (Acknowledged)'''''||'''''Notes'''''
|-
|| ||'''''Airside Module'''''||'''''Groundside Module'''''||'''''Base Module'''''||'''''Remote Module'''''||
|-
||BD||6||6||6||6||Adjust to match your configured autopilot and ground station baud rates (default for these is 57600bps)
|-
||DT||default||default||0x02||0x01||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||MD||default||default||3 (0x03)||4 (0x04)||
|-
||MT||0||0||0||0||Use this to enable Basic Reliable transmission, link bandwidth requirement increases (see manual)
|-
||MY||default||default||0x01||0x02||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PB||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PD||default||default||default||default||Can be adjusted to increase polling request rate and DI buffer flush timeout (see manual)
|-
||PE||default||default||0x02||default||Can be adjusted if consistency maintained across addressing functionalities (see manual)
|-
||PL||default||default||default||default||''Transmit power level should be reduced for lab testing!!''
|-
||RN||0 (0x00)||8 (0x08)||default||default||
|-
||RR||6 (0x06)||12 (0x0C)||6 (0x06)||12 (0x0C)||
|}

'''Note:''' All settings are assumed to be default except those listed. Those listed are in decimal unless hex 0x prefix included. Depending on your firmware version, slight modifications may be necessary.

Here is some additional information and alternative instructions to configure the polling mode from the Digi site: [http://www.digi.com/support/kbase/kbaseresultdetl?id=2178 Polling Mode for the 9XTend Radio Modem]

== SiLabs Si1000 SoC based modems ==

The Si1000 radio System on Chip (SOC) produced by SiLabs is found in a number of radio modules, for example the cheap and widely used HopeRf module. There is [https://github.com/tridge/SiK open source firmware] for these radios which makes them suitable for use in MAVs.

Note that (unlike some XBee modules) the SiK firmware does not support mesh topologies, it is strictly a point-to-point link. If you are working with swarming vehicles they may not be the best choice.

Online documentation for the Sik firmware shows how to configure it for various jurisdictions. The firmware supports 433 MHz, 470 MHz, 868 MHz and 900 MHz radios, if you are aware of any hardware supporting the European spectrum licences (868 MHz) please add them to this wiki.

Note: When using a SiK firmware radio with paparazzi, you should set "ATS6=0" (MavLink packing off) and configure paparazzi for transparent serial mode.

[http://www.rfdesign.com.au/index.php/rfd900 This module] is well proven and supports antenna diversity. A combination of 6dbi Yagi plus a dipole on the ground station, with a pair of orthogonality oriented dioples in the airframe, has been extensively tested and proven reliable at >8km range (theoretical range of ~40km).

Alternatively, for shorter range a pair of cheap generic HopeRF-based modems [http://rctimer.com/index.php?gOo=goods_details.dwt&goodsid=815 such as these]

The RFD900 can be paired with cheap generic (single front-end) modules, if for example you use a small short range airframe with a ground station that's also used for long range operations.

== Laird (ex Aerocom) ==
Lairds's API mode is already implemented but some system integration is required. Full API more with addressed packets works well and was tested with AC4790-1x1 5mW low power modules. Maximim range achieved with a whip quater-wave antenna was 1Km.

How to use this modem on ground station side? [http://paparazzi.enac.fr/wiki/index.php/User:SilaS#SDK-AC4868-250_ground_modem_part]

See folder paparazzi3 / trunk / sw / aerocomm. It has all the required files to use this modem on the airborne and ground station side. The link.ml file is a direct replacement of the "main" link.ml file of the ground sttaion and will be merged into it in the future.. or you can do it as well.

{|
|
=== AC4790-200 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-200mW
* Sensitivity (@ full RF data rate) -110dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 68 mA
* Supply Voltage 3.3v & 5.5V
* Range (typical, depends on antenna & environment) Up to 6.4 kilometers line-of-sight
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector or internal
* price : 52€
|
[[Image:ac4868_transceiver.jpg|thumb|left|AC4868 OEM Modem]]
|
|-
|
=== AC4790-1000 ===
* Frequency 902-928MHz (North America, Australia, etc).
* Output Power 5-1000mW
* Sensitivity (@ full RF data rate) -99dB
* RF Data Rate up to 76.8 Kbps
* INterface Data Rate Up to Up to 115.2 Kbps
* Power Draw (typical) 650 mA
* Supply Voltage 3.3V only
* Range (typical, depends on antenna & environment) Up to 32 kilometers with high-gain antenna
* Dimensions 42 x 48 x 5mm
* Weight < 20 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : 64€
|}

=== Pinout ===

[[Image:Aerocomm_AC4868_pinout.jpg|thumb|left|Laird AC4868 modem pinout]]
[[Image:Aerocomm_AC4490-200_wired.jpg|thumb|left|Laird AC4490 wiring example]]
<br style="clear:both">

{| border="1"
|+ Wiring the Laird AC4868 to the Tiny
|-valign="top"
||'''''AC4868 20-pin Header'''''||'''''Name'''''||'''''Color'''''||'''''Tiny v1.1 Serial-1'''''||'''''Tiny v2.11 Serial'''''||'''''Notes'''''
|-
||2||Tx||green||7||7||''(Note 1)''
|-
||3||Rx||blue||8||8||''(Note 1)''
|-
||5||GND||black||1||1|| -
|-
||10+11||VCC||red||2||3||+3.3v ''(Note 2)''
|-
||17||C/D||white||3||?||Low = Command High = Data
|}
''Note 1 : names are specified with respect to the AEROCOMM module''

''Note 2 : AC4790-1000 needs pins 10 and 11 jumped to work properly''

=== Laird LT2510 ===
[[Image:Laird_LT2510_RM024-P125-C-01.jpg‎|thumb|LT2510 P125]]
[[Image:Laird_LT2510_RM024-P125-C-01-side.jpg|thumb|LT2510 P125]]
[[Image:Lt2510_prm123.jpg|thumb|LT2510 Modem]]

Two different power versions are available:<br/>
* 50mW version: 4 dbm to 17 dbm (2,5 mW to 50mW)<br/>
* 125mW version: 4 dbm to 21 dbm (2,5 mW to 125mW)

Two different mounting/pinuts are available:<br/>
* smd version: can be soldered on a pcb<br/>
* pin header: standard xbee (or BEE) pinout with header (this is the SMD version mounted on a seperate pcb with male pin headers)

General features:
* Frequency Band 2.4GHz
* Output Power 2,5mW - 125mW
* Sensitivity -98dbm @ 280kbps/-94 dBm @ 500kbps
* RF Data Rate 280/500 kbps
* UART up to 460800 baud
* Power Draw 90mA - 180mA TX / 10mA RX
* Supply Voltage 3.3v
* Range up to 4000m
* Dimensions 26 x 33 x 4mm
* Weight 4 grams
* Interface 20-pin mini connector (smd solder pad or XBee compatible pin header)
* Chip antenna, or a U.FL antenna connector
* Price: 29-31€ @ mouser (smd or tht version)

There are following differences between both versions:
{|border="1"
|-valign="top"
||''value''||''50mW version''||''125mW version''||
|-
|output power
| 2,5mW - 50mW
| 2,5mW - 125mW
|-
|maximum radiated power
|20dbm
|30dbm
|-
|TX drain
|90mA
|<180mA
|-
|max range
|2400m
|4000m
|-
|approval
|CE for EU, FCC/IC for USA,
Canada PRM122/123 also for Japan
|FCC/IC for USA, Canada
|}

The LT2510 uses frequency hopping which needs a client/server model. That means that one modem (most appropriately the ground station modem) needs to be set to server mode. It will transmit a beacon message and have all client modems synchronize to that in a time and frequency hopping scheme manner. For that all modems need to have the same channel (in fact the hopping scheme) and system-id. Clients can be set to auto-channel and auto-system-id to follow any/the first visible server.

All acknowledged messages transmitted need to be adressed to the non-changeable MAC address of the destination modem. There are is a way to automatically set destination adresses but this procedure does have drawbacks (see below).

Make sure you short circuit "D1" if you use the Sparkfun WRL-09132 "XBee Explorer Regulated" adapter. The Laird does not have a pull-up resistor on DIN that Sparkfun assumes.
====Documentation====
[http://www.lairdtech.com/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=4379 User Manual (PDF)]
==== Basic setup ====

You can download a Windows configuration utility from [http://www.lairdtech.com/zips/Developer_Kit.zip here].

Set client to client mode (default).
Set server to server mode.

Set speed on both modems to 57600 baud, the Paparazzi standard.

Choose RF profile with low speed (280kbps) for long range (default).

===== Transparent mode =====

The transparent mode is different from the XBee modems transparent mode. It will only allow two modems to communicate with each other.

====== Transparent mode with hard coded address ======

In this mode the destination MAC address is permanently set in the EEPROMs of the modems. Only these two modems can communicate with each other. The advantage of this mode is that other modems can not confuse the communication. You have to read out both modems MAC adresses as they are not printed on the case.

Set server MAC address in client
Set client MAC address in server

====== Transparent mode with auto-address ======

The server will start emitting beacon messages and the client locks to these, starting to send messages to the servers MAC address. The server will then respond to that clients data messages. In this mode only one server can talk to one client. Any appearance of another server or client modem will confuse/disrupt the communication.

Set server to auto-destination.
Set client to auto-destination and auto-destination-beacons-only.

===== API mode =====

We need at least a simple form of address resolution as the modems own (MAC) address can not be changed. This makes the ground station link and on-board software a little more complicated than the XBee API mode.

tbd

== Bluetooth ==
These modems do not give you a great range but Bluetooth can be found in a lot of recent laptops built-in. Maybe not useful for fixed wing aircrafts it might be used for in-the-shop testing or quadcopters. Make sure you get a recent Class 1 EDR 2.0 stick if you buy one for your computer.
{|
|
=== RN-41 Bluetooth module(Sparkfun's WRL-08497) ===
* Frequency Band 2.4GHz
* Output Power 32 mW
* RF Data Rate up to ~300 kbps in SPP
* Interface Data Rate up to 921 kbps
* Power Draw (typical) 50 mA TX / 40 mA RX
* Supply Voltage 3.3v
* Range (typical, depends on antenna & environment) 100 meters line-of-sight
* Dimensions 26 x 13 x 2mm
* Weight ~1.5 grams
* Interface solder connector
* price : 20€
|
[[Image:roving_nw_wiring.jpg|thumb|Roving Networks modem wiring]]
|-
|

To connect to it, get the MAC address of the bluetooth modem

me@mybox:~$ hcitool scan
Scanning ...
00:06:66:00:53:AD FireFly-53AD

either make a virtual connection to a Bluetooth serial port each time you connect

sudo rfcomm bind 0 00:06:66:00:53:AD

or configure it once in /etc/bluetooth/rfcomm.conf

rfcomm0 {
bind yes;
device 00:06:66:00:53:AD;
}

now you can use Bluetooth as '''/dev/rfcomm0''' with the Paparazzi 'link'. You might need to restart 'link' in case you get out of range and it disconnects (tbd). Set the Tiny serial speed to 115200 as the modules come preconfigured to that.
|}

== Telemetry via Video Transmitter==

[[Image:video_tx_small.jpg|thumb|2.4GHz Video Transmitter]]
In order for the UAV to transmit video from an onboard camera, an analog video transmitter can be used. These vary in power, and thus range, and run normally on 2.4Ghz. Small UAVs can get about 600m of range from the 50mW version, and extended range can be achieved using units up to 1W. Weight for these units varies from a couple grams to about 30 for the 1W with shielding. Please check for your countries regulations on 2.4Ghz transmission, as each is different.

It is possible to use the audio channel to send simple telemetry data to the groundstation. Uploading telemetry not possible via analog audio transmitter only.
<br style="clear:both">

== Telemetry via Internet / Raspberry Pi==
Not ready yet...

The main link works over the internet and mobile internet.

Most UMTS sticks don't have a own public IP adress and can't be used as a server. The ssh connection must be reversed(ssh server runs on the gcs, not on the uav)

How to:
*Establish the connection between a UMTS stick and the Raspberry PI, search for each programm for seperate instructions, these on instructables aren't complete ! [http://www.instructables.com/id/Raspberry-Pi-as-a-3g-Huawei-E303-wireless-Edima/#step1 Instructables site]

A android smartphone is another way to provide the Raspberry pi with a internet connection. [http://www.therasberrypi.com/how-to-usb-tether-android-to-your-raspberry-pi Android USB thetering setup]

*set up ser2net
*set up static ip adress (public) of your gcs [http://www.cyberciti.biz/tips/howto-ubuntu-linux-convert-dhcp-network-configuration-to-static-ip-configuration.html static IP Ubuntu]
*set up reverse ssh tunnel [http://www.tunnelsup.com/tup/2013/05/08/raspberry-pi-phoning-home-using-a-reverse-remote-ssh-tunnel ssh reverse serial tunnel]

*connect Raspberry PI with AP over UART (Raspberry Pi's UART Pins are only 3.3v and not 5v tollerant)
== Old / not supported ==
Modules in these cathegory have issues with paparazzi are discontinued by the manufacturer.
Maybe hey will be deleted soon.

=== Laird / Aerocom AC4868-250 ===
'''This module was discontinued by the manufacturer'''
[[Image:ConnexLink_USB_RF_Modem.jpg|thumb|Aerocomm USB Stand-alone Modem]]
* Frequency Band 868MHz (For Europe). 868MHz is a limited band. Please read the [[868MHz Issues]]
* Output Power (w/ 2dBi antenna) 250 mW
* Sensitivity (@ full RF data rate) -103 dB
* RF Data Rate Up to 28.8 Kbps
* INterface Data Rate Up to 57.6 Kbps
* Power Draw (typical) 240 mA TX / 36 mA RX
* Supply Voltage 3.3v & 5V or 3.3v only
* Range (typical, depends on antenna & environment) Up to 15 kilometers line-of-sight
* Dimensions 49 x 42 x 5mm
* Weight < 21 grams
* Interface 20-pin mini connector
* Antenna MMCX jack Connector
* price : 64€

=== Radiotronix ===
These Radiotronix modems are used in transparent mode. Use the WI232EUR Evaluation Software for configuring the modems for the set speed. Connect /CMD and CTS for programming. The DTS version for the US market might cause severe interference with GPS reception, it is not recommended. For a nice ground station modem just add a FTDI232 USB->serial cable, a 3.3V regulator with 100nF capacitors from supplies to ground, solder a SMA cable/connector and put it in a nice case. Make sure you only connect RTS to /CMD if you want to reprogram the modem with the Evaluation software (see the open jumper connection in the picture, green wire) and leave it floating otherwise as connected RTS/CTS sporadically leads to a reprogramming of the modem. The ANT-GXD105-FME/F from [http://www.roundsolutions.com Roundsolutions] was used as a ground station antenna at many competitions. Note that a 1/2 wave dipole antenna works best on-board as it doesn't require a ground-plane and has a reasonably omnidirectional radiation pattern.
{|
|
==== WI232EUR ====
'''This Module has been discontinued by the manufacturer'''
* Frequency Band: 868 MHz (for Europe)
* Output Power: 32 mW
* RF Data Rate: Up to 76.8 kbps
* Interface Data Rate: up to 115.2 kbps
* Power Draw (typical): 65 mA TX / 20 mA RX
* Supply Voltage: 3.3v
* Range (typical, depends on antenna & environment): 500 meters line-of-sight
* Dimensions: 24 x 21 x 4mm
* Weight: ~2 grams
* Interface: solder connector
* Antenna: solder connector
* Price: ~25$
[[Image:Wi232eur_wiring.jpg|thumb|WI232EUR Modem (picture shows connection to Tiny 1.1)]]

==== Pinout ====

<br style="clear:both">

{| border="1"
|+ Wiring the WI232EUR to the Tiny v1.1
|-valign="top"
||'''''WI232 pins'''''||'''''Name'''''||'''''Tiny Serial-1'''''||'''''Notes'''''
|-
||6||TxD||7||''(Note 1)''
|-
||5||RxD||8||''(Note 1)''
|-
||15-18||GND||1|| -
|-
||19||VCC||2||+3.3v
|-
||4||/CMD||-||''(Note 2)''
|-
||7||CTS||-||''(Note 3)''
|}
''Note 1 : names are specified with respect to the Radiotronix module''

''Note 2 : connect to RTS to program device with Evaluation software''

''Note 3 : connect to CTS to program device with Evaluation software''

|
[[Image:Wi232eur_bopla.jpg|thumb|WI232EUR Modem in BOPLA case]]
|-
|
|}

==== Documentation ====
* [http://www.radiotronix.com/datasheets/new/eur_um.pdf WI232EUR data sheet]
* [http://www.radiotronix.com/datasheets/new/rk-eur_um.pdf WI232EUR user's manual]
* [http://www.radiotronix.com/downloads/software/EUR/setup.exe Evaluation software]

=== Digi XBee Pro 900 ===
'''These modules have been discontinued by the manufacturer, new version is XBee Pro 900HP'''

XBee Pro 900 modules are long range embedded RF modules for US applications. Purpose-built for exceptional RF performance, XBee-Pro 900 modules are ideal for applications with challenging RF environments, such as urban deployments, or where devices are several kilometers apart.

==== Documentation ====
* [ftp://ftp1.digi.com/support/documentation/90000903_a.pdf ftp://ftp1.digi.com/support/documentation/90000903_a.pdf]

=== Coronis WaveCard ===

These relatively inexpensive and light modules implement a Coronis proprietary protocol. Low power consumption - high latency - I would not recommend these modules mostly because of the low quality of the distribution and support. The documentation is rather poor and not easily available.

'''Suport for these modems has been removed from the airborne code on Dec 10th, 2007.'''
{|
|-valign="top"
|
* Frequency Band 400MHz, 868Mhz and 915MHz (3 versions)
* Output Power 25mW and 500mW (2 versions)
* Sensitivity -110 dBm (@ 9600 bps)
* Data Rate 100 Kbps
* Power Draw (typical) 45mA (25mW), 450mA (500mW) TX / 15 mA RX
* Supply Voltage ...
* Range (typical, depends on antenna & environment) Up to 1km (25mW) , 5km (500mW) line-of-sight
* Dimensions 30 x 28 x 7mm (25mW), 37 x 30 x 7mm (500mW)
* 50 ohm RF port for antenna connection
|
[[Image:wavecard.jpg|Coronis Wavecard]]
|}

==== Documentation ====

* [http://www.coronis-systems.com/produit.php?lang=EN&id=WCA www.coronis-systems.com]
* [[Media:CS-COM-SPRD-WAVECARD-E03B.pdf|Wavecard datasheet]]
== Antennas ==

Here are some examples of lightweight and efficient 868MHz antennas developped by the RF laboratory at ENAC.
[[Image:868mhz_twinstar_antenna_1.jpg|thumb|left|868MHz copper foil antenna attached to the aircraft tail]]
[[Image:868mhz_twinstar_antenna_2.jpg|thumb|left|868MHz copper foil antenna bottom view]]
[[Image:868mhz_ground_antenna.jpg|thumb|left|868MHz ground antenna]]
<br style="clear:both">

This wiki page might give some ideas about antennas: http://en.wikipedia.org/wiki/Dipole_antenna

[[Category:Hardware]]

DSM

2013-10-04T19:29:09Z

Jkg: formatting, links

DSM

2013-10-03T22:01:39Z

Jkg: formatting

== What is DSM (DSM2/DSMX) ==
DSM2 and DSMX are widely used radio protocols for 2.4GHz spektrum RC transmitters and receivers. It is also used in the [[SuperbitRF]] project as datalink. The protocol makes it possible to have multiple receiver/transmitters in the 2.4GHz spektrum without much interference.

=== The difference between DSM2 and DSMX ===
There is only a small difference between DSM2 and DSMX, which is the way they hop between different channels. In the DSM2 protocol the transmitter will choose two random channels, where the transmitter will look for the two best channels in the optimal case. In the DSMX protocol the transmitter and receiver both use the transmitter radio chip ID,which is send during the binding process, for generating 23 channels. Each time the transmitter transmits a packet or the receiver receives a packet they will hop to the next channel.

From this information you can conclude that when you use DSM2, and both the channels that were chosen are getting used by a lot of other users your reception will drop enormously. In the DSMX protocol this problem was solved and makes it possible to have a lot more transmitters/receivers at the same bandwidth.

== How does it work ==
''Note that this is reverse engineered and will contain errors.''

In general you have three phases, the binding procedure, the syncing procedure and the normal transfer procedure. The transmitter doesn't have a syncing procedure, because it determines the timing for the receiver.

=== The binding procedure ===
At the binding procedure both the transmitter and receiver will change to [[DSM#Definitions|SDR (Single Data Rate) mode]], a data code of 64 bits, a [[DSM#Definitions|SOP (Start Of Packet) Code]] of 64 bits and disable the [[DSM#Definitions|CRC Checksum]]. The transmitter will then choose a random odd channel and starts sending the [[DSM#Binding packet|binding packet]] at a very high rate. The receiver will start at the first odd channel and waits a bit longer then the rate the transmitters sends at. When it does receive a packet, it will check if it is a valid bind packet and goes to syncing mode. When it doesn't receive a valid packet it will go to the next channel and will repeat this.

During the binding procedure the transmitter also sends the amount of RC channels that it has and in which amount of packets this channels will fit. They will either transmit all the channels in one packet or in two packets after each other.

=== The syncing procedure ===
Because the transmitter doesn't have a syncing procedure, the transmitter is already in the transfer procedure. The receiver on the other hand needs to synchronise itself with the transmitter.

TODO

=== The transfer procedure ===
TODO

== References ==
Some general information about the DSM2/DSMX protocol.

=== Definitions ===
* '''Channel''': The channel in the 2.4GHz band(2.400GHz to 2.483GHz) which is used to transmit or receive. Each channel is 100mHz higher then the previous one starting by 0, and the 2.4GHz band is divided into 98 channels.
* '''(Transmission) Mode''': The mode at which the transmitter, or receiver is sending/receiving. There are four different modes the transmitter/receiver could be in: GFSK(Gaussian Frequency Shift Keying), 8DR(Octal Data Rate), DDR(Double Data Rate), SDR(Single Data Rate). The ones used are 8DR and SDR, in SDR mode one bit is encoded in each derived code symbol transmitted. In 8DR mode eight bits are encoded in each derived code symbol transmitted.
* '''GFSK''': Gaussian Frequency Shift Keying Transfer mode. CYRF6936 in this mode data is transmitted at 1 Mbps, without any DSSS.
* '''8DR''': Octal Data Rate. CYRF6936 in this mode eight bits are encoded in each derived code symbol transmitted.
* '''DDR''': Double Data Rate. CYRF6936 in this mode two bits are encoded in each derived code symbol transmitted.
* '''SDR''': Single Data Rate. CYRF6936 in this mode one bit is encoded in each derived code symbol transmitted.
* '''SOP code''': Start Of Packet code, are one or two bytes which are added at the start of the packet by the radio chip. These bytes are used to identify if a packet is received at a certain channel.
* '''Packet length''': The packet length(one byte) is send after the SOP code, and only includes the length of the payload data. Because it is one byte the limit of the payload length is 255, but because 8DR and SDR only transmit 16byte packets they will be automatically split up into multiple packets.
* '''CRC (Checksum)''': The CRC Checksum are two bytes which are send at the end of the packet to check if the received packet was valid. It can detect the following errors: any one bit error, any two bits error, any odd number of bits in error and an error burst as wide as the checksum itself.
* '''CYRF6936''': A radio chip used in several transmitters and the SuperbitRF project.

=== Packet example ===
Here is an image of an example packet including the Preamble, SOP, Length, Payload Data and the CRC.

[[File:DSM_packet_example.png|600px]]

=== Binding packet ===
The binding packet has a length of 16 bytes, the exact size the SDR mode can send at once.
[00] radio chip ID byte 0 (inverted)
[01] radio chip ID byte 1 (inverted)
[02] radio chip ID byte 2 (inverted)
[03] radio chip ID byte 3 (inverted)
[04] radio chip ID byte 0 (inverted)
[05] radio chip ID byte 1 (inverted)
[06] radio chip ID byte 2 (inverted)
[07] radio chip ID byte 3 (inverted)
[08] (sum 00->07 + 384 - 16) MSB
[09] (sum 00->07 + 384 - 16) LSB
[10] 0x01 (not known yet)
[11] number of RC channels
[12] protocol used (0x01:DSM2 1packet, 0x02: DSM2 2packets, 0x10: DSM2 SuperbitRF, 0x11: DSMX SuperbitRF, 0xA2: DSMX 1packet, 0xB2: DSMX 2packets)
[13] 0x00 (not known yet)
[14] (sum 00->13 + 384 - 16) MSB
[15] (sum 00->13 + 384 - 16) LSB

=== Transfer packet ===
The transfer packet has a length of 16 bytes, the exact size 8DR mode can send at once.
[00] radio chip ID byte 2
[01] radio chip ID byte 3 (+packet loss bit in SuperbitRF)
[02-15] data

==Raw DSM data capture files==

To aid the understanding of the various DSM protocols, data was captured using the following hardware:

*Main receiver: Spektrum AR9020
*Satellite receivers: 2x Spektrum 9645 connected to Ant B and Ant R ports
*Saleae Logic set to capture signal wires of satellite receivers:
**Channel 0 = Ant B
**Channel 1 = Ant R
**GROUND = ground of Ant R

The capture data has been split into separate runs to abide by the file size limits of this wiki :-)

===DSM data 1===
[[File:DSM_data_1_-_DX7s.zip]]

Transmitter: Spektrum DX7s
Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
*TX switched off
*power down RXes
*stop capture

===DSM data 2===
[[File:DSM_data_2_part_1_-_DX18.zip‎]] (DSM2 runs)

[[File:DSM_data_2_part_2_-_DX18.zip‎]] (DSMX runs)

Transmitter: Spektrum DX18
Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX
*22ms DSM2 Xplus
*22ms DSMX Xplus

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
**aux3 (7)
**aux4 (8)
**aux5 (9)
*TX switched off
*power down RXes
*stop capture

===DSM data 3===
[[File:DSM_data_3_-_DX18_Xplus_channels.zip]]

Transmitter: Spektrum DX18
Data capture runs @ 500 KHz:
22ms DSM2 Xplus
22ms DSMX Xplus

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0) mixed with X+1
**X+2
**X+3
**X+4
**X+5
**X+6
**X+7
**X+8

*TX switched off
*power down RXes
*stop capture
===DSM data 4===
[[File:DSM_data_4_part_1_-_DX18_Xplus_channels_12_MHz_capture.zip‎]] (DSM2 run)

[[File:DSM_data_4_part_2_-_DX18_Xplus_channels_12_MHz_capture.zip‎]] (DSMX run)

Transmitter: Spektrum DX18
Data capture runs @ 12 MHz:
22ms DSM2 Xplus
22ms DSMX Xplus

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0) mixed with X+1
**X+2
**X+3
**X+4
**X+5
**X+6
**X+7
**X+8

*TX switched off
*power down RXes
*stop capture
===DSM data 5===
[[File:DSM_data_5_part_1_-_DX18_RSSI.zip‎]] (DSM2 runs)

[[File:DSM_data_5_part_2_-_DX18_RSSI.zip]] (DSMX runs)

Transmitter: Spektrum DX18 in range test mode
Data capture runs @ 1 MHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX
*22ms DSM2 Xplus
*22ms DSMX Xplus

RSSI test:

*Logic set to trigger on rising edge.
*Power on RXes/start capture
*Press range test button (reduce TX power)
*Move TX away from RX while moving elevator (2) channel repeatedly until servo no longer moves/satellite LEDs are out
*release range test button (normal TX power)
*stop capture

== External References ==
* [http://www.cypress.com/?docID=28606 CYRF6936 Data Sheet]
* [http://www.deviationtx.com/ Deviation Firmware]
* [https://sites.google.com/site/mrdunk/interfacing-cypress-cyrf6936-to-avr-microcontrollers Interfacing with the CYRF6936]
* [http://www.rcgroups.com/forums/showthread.php?t=1759502 RCGorups: DSMX Hacking]

DSM

2013-10-03T21:57:15Z

Jkg: added raw DSM data and descriptions

== What is DSM (DSM2/DSMX) ==
DSM2 and DSMX are widely used radio protocols for 2.4GHz spektrum RC transmitters and receivers. It is also used in the [[SuperbitRF]] project as datalink. The protocol makes it possible to have multiple receiver/transmitters in the 2.4GHz spektrum without much interference.

=== The difference between DSM2 and DSMX ===
There is only a small difference between DSM2 and DSMX, which is the way they hop between different channels. In the DSM2 protocol the transmitter will choose two random channels, where the transmitter will look for the two best channels in the optimal case. In the DSMX protocol the transmitter and receiver both use the transmitter radio chip ID,which is send during the binding process, for generating 23 channels. Each time the transmitter transmits a packet or the receiver receives a packet they will hop to the next channel.

From this information you can conclude that when you use DSM2, and both the channels that were chosen are getting used by a lot of other users your reception will drop enormously. In the DSMX protocol this problem was solved and makes it possible to have a lot more transmitters/receivers at the same bandwidth.

== How does it work ==
''Note that this is reverse engineered and will contain errors.''

In general you have three phases, the binding procedure, the syncing procedure and the normal transfer procedure. The transmitter doesn't have a syncing procedure, because it determines the timing for the receiver.

=== The binding procedure ===
At the binding procedure both the transmitter and receiver will change to [[DSM#Definitions|SDR (Single Data Rate) mode]], a data code of 64 bits, a [[DSM#Definitions|SOP (Start Of Packet) Code]] of 64 bits and disable the [[DSM#Definitions|CRC Checksum]]. The transmitter will then choose a random odd channel and starts sending the [[DSM#Binding packet|binding packet]] at a very high rate. The receiver will start at the first odd channel and waits a bit longer then the rate the transmitters sends at. When it does receive a packet, it will check if it is a valid bind packet and goes to syncing mode. When it doesn't receive a valid packet it will go to the next channel and will repeat this.

During the binding procedure the transmitter also sends the amount of RC channels that it has and in which amount of packets this channels will fit. They will either transmit all the channels in one packet or in two packets after each other.

=== The syncing procedure ===
Because the transmitter doesn't have a syncing procedure, the transmitter is already in the transfer procedure. The receiver on the other hand needs to synchronise itself with the transmitter.

TODO

=== The transfer procedure ===
TODO

== References ==
Some general information about the DSM2/DSMX protocol.

=== Definitions ===
* '''Channel''': The channel in the 2.4GHz band(2.400GHz to 2.483GHz) which is used to transmit or receive. Each channel is 100mHz higher then the previous one starting by 0, and the 2.4GHz band is divided into 98 channels.
* '''(Transmission) Mode''': The mode at which the transmitter, or receiver is sending/receiving. There are four different modes the transmitter/receiver could be in: GFSK(Gaussian Frequency Shift Keying), 8DR(Octal Data Rate), DDR(Double Data Rate), SDR(Single Data Rate). The ones used are 8DR and SDR, in SDR mode one bit is encoded in each derived code symbol transmitted. In 8DR mode eight bits are encoded in each derived code symbol transmitted.
* '''GFSK''': Gaussian Frequency Shift Keying Transfer mode. CYRF6936 in this mode data is transmitted at 1 Mbps, without any DSSS.
* '''8DR''': Octal Data Rate. CYRF6936 in this mode eight bits are encoded in each derived code symbol transmitted.
* '''DDR''': Double Data Rate. CYRF6936 in this mode two bits are encoded in each derived code symbol transmitted.
* '''SDR''': Single Data Rate. CYRF6936 in this mode one bit is encoded in each derived code symbol transmitted.
* '''SOP code''': Start Of Packet code, are one or two bytes which are added at the start of the packet by the radio chip. These bytes are used to identify if a packet is received at a certain channel.
* '''Packet length''': The packet length(one byte) is send after the SOP code, and only includes the length of the payload data. Because it is one byte the limit of the payload length is 255, but because 8DR and SDR only transmit 16byte packets they will be automatically split up into multiple packets.
* '''CRC (Checksum)''': The CRC Checksum are two bytes which are send at the end of the packet to check if the received packet was valid. It can detect the following errors: any one bit error, any two bits error, any odd number of bits in error and an error burst as wide as the checksum itself.
* '''CYRF6936''': A radio chip used in several transmitters and the SuperbitRF project.

=== Packet example ===
Here is an image of an example packet including the Preamble, SOP, Length, Payload Data and the CRC.

[[File:DSM_packet_example.png|600px]]

=== Binding packet ===
The binding packet has a length of 16 bytes, the exact size the SDR mode can send at once.
[00] radio chip ID byte 0 (inverted)
[01] radio chip ID byte 1 (inverted)
[02] radio chip ID byte 2 (inverted)
[03] radio chip ID byte 3 (inverted)
[04] radio chip ID byte 0 (inverted)
[05] radio chip ID byte 1 (inverted)
[06] radio chip ID byte 2 (inverted)
[07] radio chip ID byte 3 (inverted)
[08] (sum 00->07 + 384 - 16) MSB
[09] (sum 00->07 + 384 - 16) LSB
[10] 0x01 (not known yet)
[11] number of RC channels
[12] protocol used (0x01:DSM2 1packet, 0x02: DSM2 2packets, 0x10: DSM2 SuperbitRF, 0x11: DSMX SuperbitRF, 0xA2: DSMX 1packet, 0xB2: DSMX 2packets)
[13] 0x00 (not known yet)
[14] (sum 00->13 + 384 - 16) MSB
[15] (sum 00->13 + 384 - 16) LSB

=== Transfer packet ===
The transfer packet has a length of 16 bytes, the exact size 8DR mode can send at once.
[00] radio chip ID byte 2
[01] radio chip ID byte 3 (+packet loss bit in SuperbitRF)
[02-15] data

==Raw DSM data capture files==

To aid the understanding of the various DSM protocols, data was captured using the following hardware:

Main receiver: Spektrum AR9020
Satellite receivers: 2x Spektrum 9645 connected to Ant B and Ant R ports
Saleae Logic set to capture signal wires of satellite receivers:
- Channel 0 = Ant B
- Channel 1 = Ant R
- GROUND = ground of Ant R

The capture data has been split into separate runs to abide by the file size limits of this wiki :-)

===DSM data 1===
[[File:DSM_data_1_-_DX7s.zip]]

Transmitter: Spektrum DX7s
Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
*TX switched off
*power down RXes
*stop capture

===DSM data 2===
[[File:DSM_data_2_part_1_-_DX18.zip‎]]

[[File:DSM_data_2_part_2_-_DX18.zip‎]]

Transmitter: Spektrum DX18
Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX
*22ms DSM2 Xplus
*22ms DSMX Xplus

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
**aux3 (7)
**aux4 (8)
**aux5 (9)
*TX switched off
*power down RXes
*stop capture

===DSM data 3===
[[File:DSM_data_3_-_DX18_Xplus_channels.zip]]
DSM data 3:

Transmitter: Spektrum DX18
Data capture runs @ 500 KHz:
22ms DSM2 Xplus
22ms DSMX Xplus

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0) mixed with X+1
**X+2
**X+3
**X+4
**X+5
**X+6
**X+7
**X+8

*TX switched off
*power down RXes
*stop capture
===DSM data 4===
[[File:DSM_data_4_part_1_-_DX18_Xplus_channels_12_MHz_capture.zip‎]]

[[File:DSM_data_4_part_2_-_DX18_Xplus_channels_12_MHz_capture.zip‎]]

Transmitter: Spektrum DX18
Data capture runs @ 12 MHz:
22ms DSM2 Xplus
22ms DSMX Xplus

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0) mixed with X+1
**X+2
**X+3
**X+4
**X+5
**X+6
**X+7
**X+8

*TX switched off
*power down RXes
*stop capture
===DSM data 5===
[[File:DSM_data_5_part_1_-_DX18_RSSI.zip‎]]

[[File:DSM_data_5_part_2_-_DX18_RSSI.zip]]

Transmitter: Spektrum DX18 in range test mode
Data capture runs @ 1 MHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX
*22ms DSM2 Xplus
*22ms DSMX Xplus

RSSI test:

*Logic set to trigger on rising edge.
*Power on RXes/start capture
*Press range test button (reduce TX power)
*Move TX away from RX while moving elevator (2) channel repeatedly until servo no longer moves/satellite LEDs are out
*release range test button (normal TX power)
*stop capture

== External References ==
* [http://www.cypress.com/?docID=28606 CYRF6936 Data Sheet]
* [http://www.deviationtx.com/ Deviation Firmware]
* [https://sites.google.com/site/mrdunk/interfacing-cypress-cyrf6936-to-avr-microcontrollers Interfacing with the CYRF6936]
* [http://www.rcgroups.com/forums/showthread.php?t=1759502 RCGorups: DSMX Hacking]

File:DSM data 5 part 2 - DX18 RSSI.zip

2013-10-03T21:56:48Z

Jkg:

File:DSM data 5 part 1 - DX18 RSSI.zip

2013-10-03T21:56:04Z

Jkg:

File:DSM data 4 part 2 - DX18 Xplus channels 12 MHz capture.zip

2013-10-03T21:52:46Z

Jkg:

File:DSM data 4 part 1 - DX18 Xplus channels 12 MHz capture.zip

2013-10-03T21:52:16Z

Jkg:

File:DSM data 3 - DX18 Xplus channels.zip

2013-10-03T21:49:26Z

Jkg:

File:DSM data 2 part 2 - DX18.zip

2013-10-03T21:45:26Z

Jkg:

File:DSM data 2 part 1 - DX18.zip

2013-10-03T21:44:39Z

Jkg:

DSM

2013-10-03T21:43:04Z

Jkg:

== What is DSM (DSM2/DSMX) ==
DSM2 and DSMX are widely used radio protocols for 2.4GHz spektrum RC transmitters and receivers. It is also used in the [[SuperbitRF]] project as datalink. The protocol makes it possible to have multiple receiver/transmitters in the 2.4GHz spektrum without much interference.

=== The difference between DSM2 and DSMX ===
There is only a small difference between DSM2 and DSMX, which is the way they hop between different channels. In the DSM2 protocol the transmitter will choose two random channels, where the transmitter will look for the two best channels in the optimal case. In the DSMX protocol the transmitter and receiver both use the transmitter radio chip ID,which is send during the binding process, for generating 23 channels. Each time the transmitter transmits a packet or the receiver receives a packet they will hop to the next channel.

From this information you can conclude that when you use DSM2, and both the channels that were chosen are getting used by a lot of other users your reception will drop enormously. In the DSMX protocol this problem was solved and makes it possible to have a lot more transmitters/receivers at the same bandwidth.

== How does it work ==
''Note that this is reverse engineered and will contain errors.''

In general you have three phases, the binding procedure, the syncing procedure and the normal transfer procedure. The transmitter doesn't have a syncing procedure, because it determines the timing for the receiver.

=== The binding procedure ===
At the binding procedure both the transmitter and receiver will change to [[DSM#Definitions|SDR (Single Data Rate) mode]], a data code of 64 bits, a [[DSM#Definitions|SOP (Start Of Packet) Code]] of 64 bits and disable the [[DSM#Definitions|CRC Checksum]]. The transmitter will then choose a random odd channel and starts sending the [[DSM#Binding packet|binding packet]] at a very high rate. The receiver will start at the first odd channel and waits a bit longer then the rate the transmitters sends at. When it does receive a packet, it will check if it is a valid bind packet and goes to syncing mode. When it doesn't receive a valid packet it will go to the next channel and will repeat this.

During the binding procedure the transmitter also sends the amount of RC channels that it has and in which amount of packets this channels will fit. They will either transmit all the channels in one packet or in two packets after each other.

=== The syncing procedure ===
Because the transmitter doesn't have a syncing procedure, the transmitter is already in the transfer procedure. The receiver on the other hand needs to synchronise itself with the transmitter.

TODO

=== The transfer procedure ===
TODO

== References ==
Some general information about the DSM2/DSMX protocol.

=== Definitions ===
* '''Channel''': The channel in the 2.4GHz band(2.400GHz to 2.483GHz) which is used to transmit or receive. Each channel is 100mHz higher then the previous one starting by 0, and the 2.4GHz band is divided into 98 channels.
* '''(Transmission) Mode''': The mode at which the transmitter, or receiver is sending/receiving. There are four different modes the transmitter/receiver could be in: GFSK(Gaussian Frequency Shift Keying), 8DR(Octal Data Rate), DDR(Double Data Rate), SDR(Single Data Rate). The ones used are 8DR and SDR, in SDR mode one bit is encoded in each derived code symbol transmitted. In 8DR mode eight bits are encoded in each derived code symbol transmitted.
* '''GFSK''': Gaussian Frequency Shift Keying Transfer mode. CYRF6936 in this mode data is transmitted at 1 Mbps, without any DSSS.
* '''8DR''': Octal Data Rate. CYRF6936 in this mode eight bits are encoded in each derived code symbol transmitted.
* '''DDR''': Double Data Rate. CYRF6936 in this mode two bits are encoded in each derived code symbol transmitted.
* '''SDR''': Single Data Rate. CYRF6936 in this mode one bit is encoded in each derived code symbol transmitted.
* '''SOP code''': Start Of Packet code, are one or two bytes which are added at the start of the packet by the radio chip. These bytes are used to identify if a packet is received at a certain channel.
* '''Packet length''': The packet length(one byte) is send after the SOP code, and only includes the length of the payload data. Because it is one byte the limit of the payload length is 255, but because 8DR and SDR only transmit 16byte packets they will be automatically split up into multiple packets.
* '''CRC (Checksum)''': The CRC Checksum are two bytes which are send at the end of the packet to check if the received packet was valid. It can detect the following errors: any one bit error, any two bits error, any odd number of bits in error and an error burst as wide as the checksum itself.
* '''CYRF6936''': A radio chip used in several transmitters and the SuperbitRF project.

=== Packet example ===
Here is an image of an example packet including the Preamble, SOP, Length, Payload Data and the CRC.

[[File:DSM_packet_example.png|600px]]

=== Binding packet ===
The binding packet has a length of 16 bytes, the exact size the SDR mode can send at once.
[00] radio chip ID byte 0 (inverted)
[01] radio chip ID byte 1 (inverted)
[02] radio chip ID byte 2 (inverted)
[03] radio chip ID byte 3 (inverted)
[04] radio chip ID byte 0 (inverted)
[05] radio chip ID byte 1 (inverted)
[06] radio chip ID byte 2 (inverted)
[07] radio chip ID byte 3 (inverted)
[08] (sum 00->07 + 384 - 16) MSB
[09] (sum 00->07 + 384 - 16) LSB
[10] 0x01 (not known yet)
[11] number of RC channels
[12] protocol used (0x01:DSM2 1packet, 0x02: DSM2 2packets, 0x10: DSM2 SuperbitRF, 0x11: DSMX SuperbitRF, 0xA2: DSMX 1packet, 0xB2: DSMX 2packets)
[13] 0x00 (not known yet)
[14] (sum 00->13 + 384 - 16) MSB
[15] (sum 00->13 + 384 - 16) LSB

=== Transfer packet ===
The transfer packet has a length of 16 bytes, the exact size 8DR mode can send at once.
[00] radio chip ID byte 2
[01] radio chip ID byte 3 (+packet loss bit in SuperbitRF)
[02-15] data

==Raw DSM data capture files==

To aid the understanding of the various DSM protocols, data was captured using the following hardware:

Main receiver: Spektrum AR9020
Satellite receivers: 2x Spektrum 9645 connected to Ant B and Ant R ports
Saleae Logic set to capture signal wires of satellite receivers:
- Channel 0 = Ant B
- Channel 1 = Ant R
- GROUND = ground of Ant R

The capture data has been split into separate runs to abide by the file size limits of this wiki :-)

===DSM data 1===
[[File:DSM_data_1_-_DX7s.zip]]

Transmitter: Spektrum DX7s
Data capture runs @ 500KHz:
*11ms DSM2
*11ms DSMX
*22ms DSM2
*22ms DSMX

Bind:
*Logic set to trigger on rising edge.
*RXes powered on with bind plug in place
*TX switched on while holding down bind button
*wait for satellite LEDs to go solid on
*TX switched off
*power down RXes
*stop capture

Channel movement:
*Logic set to trigger on rising edge.
*RXes powered on
*TX switched on
*wait for satellite LEDs to power on/servos to center
*each channel individually moved (DSM channel #)
**throttle (0)
**aileron (1)
**elevator (2)
**rudder (3)
**gear (4)
**aux1/flap (5)
**aux2 (6)
*TX switched off
*power down RXes
*stop capture

== External References ==
* [http://www.cypress.com/?docID=28606 CYRF6936 Data Sheet]
* [http://www.deviationtx.com/ Deviation Firmware]
* [https://sites.google.com/site/mrdunk/interfacing-cypress-cyrf6936-to-avr-microcontrollers Interfacing with the CYRF6936]
* [http://www.rcgroups.com/forums/showthread.php?t=1759502 RCGorups: DSMX Hacking]

DSM

2013-10-03T21:36:46Z

Jkg: link syntax

DSM

2013-10-03T21:36:14Z

Jkg: added raw data captures (in progress)

File:DSM data 1 - DX7s.zip

2013-10-03T21:28:53Z

Jkg: DSM2 and DSMX data captured from satellite receivers

DSM2 and DSMX data captured from satellite receivers

Radio Control

2013-09-13T22:42:55Z

Jkg: fixed MHz --> GHz

== PPM Radio Configuration ==

This XML file, usually located in the <tt>conf/radios</tt> directory, contains a description of the radio control transmitter PPM signal. It should follow the grammar described in <tt>radio.dtd</tt>. <b>This is only used for PPM transmitters so it does not apply to DSM/DSM2/FASST/FHSS or other 2.4Ghz radios.</b>

The contents are an '''ordered''' sequence of elements describing each channel with its name and its range:

<tt><source lang="xml"><!DOCTYPE radio SYSTEM "radio.dtd">
<radio name="cockpitMM" data_min="900" data_max="2100" sync_min ="5000" sync_max ="15000" pulse_type="POSITIVE">
<channel ctl="D" function="ROLL" min="2000" neutral="1498" max="1000" average="0"/>
...
<channel ctl="E" function="MODE" min="2000" neutral="1500" max="1000" average="1"/>
...
</radio></source></tt>

The order of the channels must be the order of the pulses in the PPM signal.

Among the top attributes, we find

* <tt>name</tt>: used only in debug traces.
* <tt>data_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) used to code one channel of the PPM signal.
* <tt>sync_min</tt> (resp. <tt>_max</tt>): the minimum (resp. max) width (in microseconds) between two impulses set of the PPM signal.
* <tt>pulse_type</tt>: the polarity of the PPM pulse. Can be either <tt>POSITIVE</tt> (FUTABA, Hitec, Multiplex etc) or <tt>NEGATIVE</tt> (JR, Graupner etc.).<br/>With <tt>POSITIVE</tt> it will trigger on the rising flank to measure the time of the positive pulse, with <tt>NEGATIVE</tt> on the falling flank (for a negative pulse width).

Each channel is described with its transmitter name (<tt>ctl</tt>), its <tt>function</tt> name, its range in microseconds and its neutral value in microseconds.
These values are used by the autopilot to compute a normalized input from the PPM signal (this file is preprocessed and the produced code is included in the airborne code). Note that the <tt>min</tt> and <tt>max</tt> attributes can be exchanged to reverse the direction of the command.

'''Wrong attributes of the "radio" element will prevent the decoder to recognize any PPM frame; same for a wrong number or channels.'''

=== Number of channels ===

Note that the number of channels in your radio file <b>must exactly match</b> the number of channels in the ppm sum signal the autopilot receives.<br>
Also the ''function'' names must be unique.

* in case of analog 35MHz receivers it is the RC - TRANSMITTER that makes the pulse train (receiver only does RF part)
** radio file depends on transmitter, you could swap to another receiver (and e.g. you can use a 4channel receiver to receive 9 pulses :-) )
* in case of digital receivers it is not the transmitter but the receiver that makes the pulses
** e.g. Futaba Fasst 6017: you can use any compatible transmitter without need to change the radio file
* in case of an encoder it is the encoder that makes the summed pulse
** if the encoder software makes 8 pulses, even with a 5 channel RC connected paparazzi will get 8: so the radio file should read 8

This means if your transmitter sends for example a PPM18 (Graupner/JR) signal you have nine (9) different servo channels. Even if you use a receiver with less channels you must set up <b>all</b> transmitting servos, even if you do not use them then you must use "bogus switches" related to functions. For example a six (6) servo channels out receiver with five (5) functions used in combination with a nine (9) servo channels transmitter would need four (4) bogus entries. (5 + 4 = 9)

<source lang="xml">
...
<channel ctl="NoneA" function="NOTUSEDA" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneB" function="NOTUSEDB" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneC function="NOTUSEDC" min="1100" neutral="1500" max="1900" average="0"/>
<channel ctl="NoneD" function="NOTUSEDD" min="1100" neutral="1500" max="1900" average="0"/>
...
</source>

=== Averaging ===

The <tt>average</tt> attribute must be set to '''1..x''' for ''discrete'' channels for which a trivial averaging filter will be applied. The neutral of a discrete channel need to be halfway through the min and max values. Otherwise it won't be mapped properly by the filter. Note that averaging a channel gives the output an additional small delay.

== Direction ==

The following signs have been used in the radio configuration files distributed in <tt>conf/radios</tt>:

* '''ROLL''': The <tt>min</tt> attribute value stands for the right position of the stick (turning right)
* '''PITCH''': The <tt>max</tt> attribute value stands for the up position of the stick (pitching up)

''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''
* '''ROLL''': The <tt>max</tt> attribute value stands for the right position of the roll stick (banking right)
* '''PITCH''': The <tt>max</tt> attribute value stands for the "up" position of the pitch stick pulled towards you (pitching up)
* '''YAW''': The <tt>max</tt> attribute value stands for the right position of the yaw stick (yawing clock-wise)

=== Practical test ===
In the RC message:
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to -MAX_PPRZ (-9600) in the ROLL channel
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel

''' From "v3.9" on this has been changed to follow standard aerospace conventions:'''
* when the ROLL stick is pulled to the right (aircraft banks right), you should see a value close to MAX_PPRZ (9600) in the ROLL channel
* When the PITCH stick is pulled (aircraft pitches up), you should see a value close to MAX_PPRZ (9600) in the PITCH channel
* When the YAW stick is pulled to the right (aircraft yawing clock-wise), you should see a value close to MAX_PPRZ (9600) in the YAW channel

This works with all kind of radios (PPM, USB, 2.4GHz)

== Example ==

Below you find an example of a radio file.

<source lang="xml">
<?xml version="1.0"?>





<radio name="GraupnerMC20" data_min="950" data_max="2150" sync_min="5000" sync_max="15000" pulse_type="NEGATIVE">
<channel ctl="A" function="THROTTLE" min="1100" neutral="1100" max="1900" average="0"/> 
<channel ctl="B" function="ROLL" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="C" function="PITCH" min="1900" neutral="1500" max="1100" average="0"/> 
<channel ctl="D" function="YAW" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="E" function="MODE" min="1100" neutral="1500" max="1900" average="1"/> 
<channel ctl="F" function="GAIN1" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="G" function="GAIN2" min="1100" neutral="1500" max="1900" average="0"/> 
<channel ctl="H" function="SWITCH1" min="1100" neutral="1500" max="1900" average="1"/> 
<channel ctl="I" function="UNUSED" min="1100" neutral="1500" max="1900" average="1"/> 
</radio>
</source>

== PPM input to output chain ==
The chain from ppm input to servo output has intermediate steps and roughly looks like this:

ppm input --(radio.xml)--> ppm_pulses[] --(radio.xml)--> radio_control.values[] --([[Fixedwing_Configuration#Manual|rc_commands]])--> commands[] --([[Fixedwing_Configuration#Servos|command_laws,servos]])--> actuators_pwm_values[] ppm out

Written in parenthesis is where you configure how to transform one value into the other.

So in a simple case without fancy mixing, e.g. looking at the roll command / aileron servo while in MANUAL mode:
#PPM sum signal is read and split into channels as specified in your radio xml file.<br/>It does some sanity checking on the pulse length and frame lenght according to the top attributes in that file.<br/>This is written to the ppm_pulses array, where you now have the length of the pulse in system ticks.
#Now these get converted to radio_control.values array according to the channels in your radio xml file.<br/>They get scaled to MAX_PPRZ (9600), meaning what you specified as max is 9600, neutral is 0, etc.<br/>radio_control.values[RADIO_ROLL] now has the value 9600 if the pulse width of that channels was "max"
#Mapping of RC commands to the actual commands as specified in rc_commands section.<br/>In your case simply copy radio_control.values[RADIO_ROLL] to commands[COMMAND_ROLL]
#Applying command_laws (mixing) to get the commands for each servo.<br/>Again just copying in your case...
#Scaling from commands with MAX_PPRZ scale to the actual pwm output signal according to the servos section.

== Measuring the PPM time values ==

[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|R/C receiver timing diagram]]

There are two common ways to measure the time characteristics of the PPM signal:
# Using an oscilloscope: easy to achieve with a high level digital scope with capture and measure facilities.
# Using the telemetry of the autopilot: the '''PPM''' message (defined in <tt>conf/messages.xml</tt>) contains the sequence of a (recently) received PPM signal.

With the default telemetry configuration file (<tt>conf/telemetry/default_fixedwing.xml</tt>), this message is '''not''' sent in the '''default''' fbw telemetry mode (numbered 0).

There are two ways to enable this message:
* Use the settings mechanism to change the FBW telemetry mode while the autopilot is already running:<br/>In the GCS: Settings -> telemetry -> tele_FBW -> set to debug (1)
* This mode can be permanently changed to '''debug''' (numbered 1) in the airframe file by setting the '''TELEMETRY_MODE_FBW''' constant in your firmware section:
<source lang="xml"><define name="TELEMETRY_MODE_FBW" value="1"/></source>

'''Since "v3.9" the values in the PPM message are in µs.'''

Before "v3.9" the time unit used in this '''PPM''' message was hardware dependent:
* On the obsolete AVR hardware, 1 microsecond = 16 units (because the crystal is running at 16MHz)
* on the LPC hardware, 1 microsecond = 15 units (because the cristal is running at 12MHz)
*:(<tt>conf/autopilot/tiny.h</tt>), the CPU clock is 5 times more, the peripheral bus is 4 times less, and the timer is not prescaled (<tt>sw/airborne/arch/lpc21/mcu_periph/sys_time_arch.h</tt>) !!!)

== Tips ==

If one has a good servo tester the output values at the receiver side can be measured

[[Category:Software]] [[Category:User_Documentation]]

SuperbitRF

2013-08-21T06:40:21Z

Jkg: minor cleanup, wording, typos

[[File:tudelft_logo.jpg|left|150px|link=http://tudelft.nl/en/]]
[[File:SuperbitRF_usb_modem.jpg|300px|right]]

== What is '''SuperbitRF'''? ==
SuperbitRF is a project to design our own datalink/radio receiver. The ultimate goal is to get the receiver to work with our own datalink modem and also normal DSM2/DSMX transmitters. However, the main focus is to get a very small datalink which will be integrated in the autopilot PCB.

== Components ==
=== Superbit CYRF ===
[[Image:Cyrf_v1_0_r1_back.jpg|300px]]
[[Image:Cyrf_v1_0_r1_front.jpg|300px]]

=== Superbit USBRF ===
[[Image:Usbrf_v1_0_back.jpg|300px]]
[[Image:Usbrf_v1_0_front.jpg|300px]]

== How it works ==
In general you will have either a USB datalink modem or a DSM2/DSMX transmitter which can be bound to the datalink/radio receiver on the autopilot. During the binding process, the receiver will know if it is binding to a USB datalink (in DSMX or DSM2 mode), DSM2 transmitter or a DSMX transmitter. After binding, the receiver tries to keep in sync with the USB datalink or transmitter and will forward the packets received to either the paparazzi datalink or the radio control.

The SuperbitRF USB modem uses the normal DSM2/DSMX protocol, which can be chosen inside the firmware. For more information on how the DSM2 and the DSMX protocol works, see [[DSM]].

== The source code ==
The firmware for the SuperbitRF USB modem is open source and can be found at [https://github.com/fvantienen/superbitrf-firmware Github SuperbitRF Firmware].
As of this writing (Aug 2013), the source code for the datalink receiver (which will run on the autopilot) is not finished yet.

== SuperbitRF in depth ==
The SuperbitRF firmware for the USB dongle consists of 3 different build targets: Transmitter, Man In The Middle (MITM), and Receiver.
* The Transmitter (used for GCS) target is capable of sending Paparazzi joystick commands in DSM2 or DSMX to normal DSM2/DSMX receivers and the SuperbitRF receiver. It is also capable of receiving downlink messages and sending uplink messages to a SuperbitRF module.
* The MITM target (used for GCS) is only capable of receiving downlink messages and sending uplink messages to a SuperbitRF module, but this is possible in combination with a normal DSM2 or DSMX transmitter.
* The Receiver target (used for airborne) is capable of receiving DSM2 and DSMX commands from a normal DSM2/DSMX transmitter or the SuperbitRF transmitter, and is also capable of transmitting downlink messages and receiving uplink messages from a SuperbitRF module.
The SuperbitRF always takes PPRZ messages as input and also always outputs PPRZ messages.

Next to the firmware of the SuperbitRF USB dongle we also have a integration of only the CYRF6936 chip inside Paparazzi. This part can do the exact same as the Receiver target from the SuperbitRF dongle, except that this time all the processing is done directly inside Paparazzi.

=== Transmitter USB Dongle ===
This was functional in the beginning, but now probably doesn't work anymore. It doesn't have the normal DSM2/DSMX transmission part in it yet and only has the PPRZ uplink and downlink.

=== MITM USB Dongle ===
This is functional now with DSMX, but there are still some timing problems. The up- and downlink works and keep workings when the transmitter is shut down. When the transmitter is down the receiver (the USB dongle on the airframe or the integrated cyrf code in Paparazzi) is capable of sending downlink messages at a higher rate because the receiver timing of the syncing mode is used to transmit and receive packets to the MITM. When the transmitter is on the receiver is in transfer mode and the transmitter sets the timing for the receiver and thus also for the MITM. So the timing between the MITM and the receiver is very hard to tune, because the MITM doesn't know when the receiver is in transfer mode or not, and each transmitter is sending at a different timing. This is why getting the timing right is so difficult.

=== Receiver USB Dongle ===
This part receives the DSM2 and DSMX packets, but doesn't receive the data packets from the SuperbitRF dongle yet. It also doesn't parse the DSM2 and DSMX packets to normal PPRZ packets yet. This is mainly used for debugging a transmitter to see what the timing is and see if it is properly working. This is also the basis for the integrated CYRF6936 receiver inside paparazzi.

=== SuperbitRF receiver software (inside Paparazzi) ===
This consists of two parts, the radio_control subsystem and the telemetry subsystem. The radio_control subsystem works independently from the telemetry subsystem, but uses the same code. The telemetry subsystem isn't tested without the radio_control subsystem, but it works when the transmitter is not sending (not in a optimised way because it is also continuously synchronising to get back the radio control signal). But for now everything seems to work in DSMX mode(because DSM2 still has some timing issues and is harder to debug) in combination with the MITM usb dongle.

== Getting started ==
For now I only have a small explanation on how to bind the MITM, the integrated CYRF6936 paparazzi and a normal DSMX or DSM2 transmitter with each other, later I will add more information when it is working.

To MITM USB dongle automatically starts in binding mode, so you don't need to do anything besides plugging it in. When you have done that you start your autopilot with the bind plug, like a normal Spektrum receiver. Both the MITM and the autopilot are now in binding mode and waiting for the transmitter to send binding packets. Next, power on your transmitter in binding mode. When the MITM is done binding the yellow LED will go on. When the autopilot is done binding you don't see anything until it's synchronised with the transmitter, then the normal RC led will go on. It doesn't matter if you bind the autopilot and the MITM not at the same time, it only matters that they are bound to the exact same transmitter. When the binding is done everything should work!

== Progress ==
* 19/07/2013 - We now have the MITM working in combination with a normal transmitter in DSMX mode (DSM2 mode still has some problems) and also have the receiver part inside Paparazzi working. The transmitter and the receiver target of the superbitRF aren't fully functional yet, but the main focus was the MITM target. There are still some strange things happening in the timing, but we need to look more into the timings of different RC transmitters because that affects the MITM timing.
* 09/07/2013 - Also got the downlink working!
* 03/07/2013 - Got a fully working RC!
* 02/07/2013 - After some simple logic analysing we figured out the faults and now we have a working SPI connection between the superbitRF and the Lisa M. Already implemented the binding procedure inside Paparazzi and we are receiving packets, but we didn't implement the handling of the binding packet.
* 01/07/2013 - We connected a cyrf6936 chip directly to the spi bus of a Lisa M and are trying to receive the MFG id, manufacturer id, from the cyrf6936. Having some problems with that so we are going to sniff the spi connection and the reset pin with a logic analyser.
* 28/06/2013 - We sniffed a normal dsm2 receiver spi bus connection to the cyrf6936 chip and found the errors in our own protocol. We are now able to bind to a normal DSM2 and DSMX transmitter trough DSM2 and receive the channels. The next step is to implement DSMX and make our own datalink work together with a normal transmitter. (We used saleae logic with a simple php script to analyze the cyrf6936 spi connection)
* 20/06/2013 - Hacked the SITL(NPS) of paparazzi to enable a hardware datalink and tested the Quad Lisa M simulator with normal telemetry. Everything worked great, tweaked some of the timings of the receiver and transmitter, and we now have a reliable datalink!
* 19/06/2013 - Made the datalink more reliable, and both the receiver and transmitter know when a packet is lost and resends it. Als did manage to get a simple datalink with an AR.Drone 2.
* 18/06/2013 - We currently have a datalink working between two SuperbitRF usb modems. It isn't that reliable yet, but we are working on improving it. We can already bind to a normal DSM2/DSMX transmitter, but can't get the syncing to work. We are also working on testing the datalink transfer rate and testing how paparazzi handles the packet loss you have with a unreliable radio datalink.
* 11/06/2013 - Received the SuperbitRF usb modems and did some simple testing with blinking light and receiving the radio chip ID.

== The contributors ==
* Piotr (working on the hardware)
* Bart Remes
* Freek van Tienen (working on the software)

Installation/VirtualBox

2013-08-14T00:59:55Z

Jkg: added troubleshooting section for enabling virtualization

==Introduction==

Running through a virtual machine (in this case [http://www.virtualbox.org Virtualbox]) allows you to use Paparazzi from many different operating systems, including Windows. It is also good way to 'get your feet wet' with Paparazzi without having to get things up and running yourself.

==Installation==
#Download the Virtualbox installer for your host OS from https://www.virtualbox.org/wiki/Downloads and install.
##If you plan to program autopilots, also download the VirtualBox Extension Pack on the same page. This gives the virtual Linux machine access to your computer's USB ports.
#Download the Paparazzi virtual machine hard disk image from [http://google.com a secret location]. Decompress the file to a convenient place - a good place is a folder called 'VirtualBox VMs' in your user folder (Linux, MacOS) or the My Documents folder (Windows).
#Open Virtualbox
#To enable USB support, install the VirtualBox Extension Pack by going to File->Preferences and clicking Extensions. Hit the 'add package' button widget (diamond w yellow triangle) on the right and choose the Extension Pack file. Click OK to close settings.
#Choose 'Add..' from the Machine menu and choose the file 'Ubuntu 12 64bit.vbox' from inside the Ubuntu 12 64bit folder you downloaded in step 3.
#A new VM should appear in the left column of the VM manager.
#Hit the big green start arrow and it should start booting. If you are running Virtualbox in Windows, MAKE SURE TO READ THE POPUPS that tell you about which key lets you jump OUT of the virtual machine - otherwise you can be 'stuck' inside since Windows hides Virtualbox the menu bar.
##In Windows 7, the default host key to 'escape' from Linux is the right CTRL key, so you press for example rctrl-C to toggle scaled view on/off, rctrl-F to toggle fullscreen, etc.
#For now you don't want to be in either of those modes since it hides the Virtualbox menu bar - so if it says its entering scaled mode, follow the directions to exit it. You should now see a grey menubar along the top that has Machine, View, Devices, and Help menus.
#Once the machine is booted up, log in with the username 'pprz' and password 'password'.
#Once at the desktop, choose 'Install Guest Additions' from the Devices menu. Note that this is a host OS menu, not the virtual Linux OS. If you can't find this menubar, see the steps above for toggling the view.
#Click Run on the box that comes up to install guest additions - this is driver software that allows the Linux install run faster on your specific machine.

==Troubleshooting==
#(Linux/Windows host OS) If you receive an error stating that VT-x/AMD-V hardware acceleration is not operational, you may need to turn on those feature(s) in your computer's BIOS. Refer to the manual for your motherboard and look for directions relating to virtualization. For example, here is the setting in the [http://i.stack.imgur.com/5x3YW.png Award BIOS].

Installation/VirtualBox

2013-08-14T00:45:49Z

Jkg: reformatted/cleaned up some

Installation/VirtualBox

2013-08-14T00:25:37Z

Jkg: created page and added first pass directions for installation

==Introduction==

Running through a virtual machine (in this case [http://www.virtualbox.org Virtualbox]) allows you to use Paparazzi from many different operating systems, including Windows. It is also good way to 'get your feet wet' with Paparazzi without having to get things up and running yourself.

Installation:
<ul>
<li>Download the Virtualbox installer for your host OS from https://www.virtualbox.org/wiki/Downloads and install.
<li>If you plan to program autopilots, you'll also need to download the VirtualBox Extension Pack on the same page.
<li>Download the virtual machine hard disk image from [http://google.com a secret location]. Decompress the file to a convenient place - a good place is a folder called 'VirtualBox VMs' in your user folder (Linux, MacOS) or the My Documents folder (Windows).
<li>Open Virtualbox, and install the extension pack by going to File->Preferences and clicking Extensions. Hit the 'add package' button widget (diamond w yellow triangle) on the right and choose the Extension Pack file. Click OK to close settings.
<li>Choose 'Add..' from the Machine menu and choose the file 'Ubuntu 12 64bit.vbox' from inside the Ubuntu 12 64bit folder you downloaded in step 3.
<li>A new VM should appear in the left column of the VM manager.
<li>Hit the big green start arrow and it should start booting. If you are running Virtualbox in Windows, MAKE SURE TO READ THE POPUP WINDOWS that come up telling you about which key is the magic one that lets you jump OUT of the VM - otherwise you can be 'stuck' inside the virtual Linux machine since Windows likes to hide the menu bar.
<li>In Windows 7, the default host key to 'escape' from Linux is the right CTRL key, so you press for example rctrl-C to toggle scaled view on/off, rctrl-F to toggle fullscreen, etc.
<li>for now you don't want to be in either of those modes since it hides the Virtualbox menu bar - so if it says its entering scaled mode or something just follow the directions to exit it, so you see a grey menubar along the top that has Machine/View/Devices/Help
<li>if not try hitting the keys I mentioned above
<li>Once the machine is booted up, log in with the username 'pprz' and password 'password'. You are now running Linux inside your OS!
<li> Once at the desktop, choose 'Install Guest Additions' from the Devices menu. Note that this is a menu from your host OS, not the Linux OS. If you can't find this menubar, see the steps above for toggling the view.
<li>Run on the box that comes up to install guest additions - this is software that helps the Linux install run faster on your specific machine.
</ul>

Subsystem/ahrs

2013-07-02T06:26:01Z

Jkg: added wolfram alpha link for computing local mag field and made it clearer where to put the resulting values in the airframe file

<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
== AHRS subsystem ==
The '''A'''ttitude and '''H'''eading '''R'''eference '''S'''ystem subsystem specifies which attitude estimation filter you are using.

Currently possible AHRS subsystem types are
* ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''
* ''[[Subsystem/ahrs#Complementary_Quaternion.2FRotation_Matrix_.28floating_point.29|float_cmpl]]''
* ''[[Subsystem/ahrs#DCM_.28floating_point.29|float_dcm]]''
* ''[[Subsystem/ahrs#Complementary_Euler_.28fixed_point.29|int_cmpl_euler]]''
* ''[[Subsystem/ahrs#Infrared|infrared]]''

e.g. for the latest complementary filter:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
</firmware>
</source>
}}

== Implementations ==

There is a test program ( sw/airborne/test/ahrs/compare_ahrs.py ) to compare different AHRS implementations on simple test cases.

'''Please also see [https://github.com/paparazzi/paparazzi/issues/93 issue 93] about proper handling of BODY_TO_IMU in all AHRS algorithms.'''

=== Complementary Quaternion (fixed point) ===
* Estimates the gyro bias.
* By default uses magnetometer for heading.
* In v3.9 and later:
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130

Other flags of interest are:
*AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity
*AHRS_MAG_UPDATE_ALL_AXES : '''available since v3.9''' use mag to also update roll/pitch and not only yaw (not recommended in most cases)
*AHRS_MAG_UPDATE_YAW_ONLY : '''removed in v3.9, default behaviour since''' only update the yaw instead of all axes

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_quat"/>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

=== Complementary Quaternion/Rotation Matrix (floating point) ===
* Estimates the gyro bias.
* By default uses magnetometer for heading.
* You need to define either ''AHRS_PROPAGATE_RMAT'' or ''AHRS_PROPAGATE_QUAT'' (select if the propagation is done in rotation matrix or quaternion representation).
* In v3.9 and later:
** Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).<br/>Enabled with AHRS_GRAVITY_UPDATE_COORDINATED_TURN which is set by default for a fixedwing firmware.
** GPS based heading estimation: https://github.com/paparazzi/paparazzi/issues/130
Other flags of interest are:
* AHRS_PROPAGATE_LOW_PASS_RATES : apply a low pass filter on rotational velocity
* AHRS_MAG_UPDATE_ALL_AXES : use mag to also update roll/pitch and not only yaw (not recommended in most cases)
* AHRS_GRAVITY_UPDATE_NORM_HEURISTIC: lower the gain of the gravity update based on a acceleration norm heuristic (e.g. good for bungee takeoff)

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft or fixedwing">
...
<subsystem name="ahrs" type="float_cmpl_rmat">
<define name="AHRS_PROPAGATE_QUAT"/>
</subsystem>
</firmware>

<section name="AHRS" prefix="AHRS_">
<define name="H_X" value=" 0.51562740288882"/>
<define name="H_Y" value="-0.05707735220832"/>
<define name="H_Z" value=" 0.85490967783446"/>
</section>
</source>
}}

Also see the [[Subsystem/ahrs#Local_Magnetic_Field|Local Magnetic Field]] section.

=== DCM (floating point) ===
* No direct gyro bias estimation, but also compensates for attitude drift.
* Uses GPS speed for heading.
* Compensation of centrifugal force via GPS speed (to fly in circles with a fixedwing).
* '''Careful, it doesn't handle all BODY_TO_IMU rotations (mounting positions) correctly!'''

The algorithm was developed by William Premerlani and Paul Bizard. The theory can be found here: [[Media:DCMDraft2.pdf|DCMDraft2.pdf]] The algorithm is also used in the AHRS systems of the AdruIMU.
The name DCM for the algorithm is really a misnomer, as that just means that the orientation is represented as a '''D'''irection'''C'''osine'''M'''atrix (rotation matrix). But since people already know it under that name, we kept it.

Other flags of interest are:
*USE_MAGNETOMETER : use magnetometer to update yaw (untested ? The magnetometer code has to be improved, since ferromagnetic materials affect the magnetic field. This is currently not implemented.)

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="rotorcraft or fixedwing">
...
<subsystem name="ahrs" type="float_dcm"/>
</firmware>
</source>
}}

=== Complementary Euler (fixed point) ===
* Not recommended for fixedwings, as this filter doesn't compensate for centrifugal force when flying turns.
* Magnetometer is always only used for heading (yaw).
* '''Does not handle the accel and mag updates correctly if BODY_TO_IMU is used for more than just adjustment by a few degrees.'''
* In general, rather use ''[[Subsystem/ahrs#Complementary_Quaternion_.28fixed_point.29|int_cmpl_quat]]''

Optional flags/defines are:
* FACE_REINJ_1 : defaults to 1024
* IMU_MAG_OFFSET : offset to subtract from the heading calculated by the magnetometer
* USE_NOISE_FILTER : apply a simple filter on the rate and accel inputs
* USE_NOISE_CUT : cut rate input at 1 rad/s and accel input at 20m/s²

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
...
<subsystem name="ahrs" type="int_cmpl_euler"/>
</firmware>

<section name="MISC">
<define name="FACE_REINJ_1" value="1024"/> 
</section>
</source>
}}

=== Infrared ===
For use with infrared sensors that detect aircraft attitude and the [[Module/infrared| infrared module]].

== Local Magnetic Field ==
If you are using a magnetometer, calculate the normalised local magnetic field by inserting your location coordinates [http://www.ngdc.noaa.gov/geomag-web/#igrfwmm here]and clicking calculate.

<gallery widths=200px heigths=300px>
Image:Noaa_mag_data.png|Screenshot of noaa page.
Image:Normalised_mag_fields.png|Screenshot of scilab page.
</gallery>

Copy the north(x), east(y), and vertical(z) component values into scilab and execute "X/norm(X)" or run this in ipython:

<source lang=python>
from scipy import *
from numpy.linalg import norm
x = array([20875.1, 8480.2, -51279.8])
x/norm(x)
</source>

or enter this into [http://wolframalpha.com Wolfram Alpha]:
<source lang=python>
{20875.1, 8480.2, -51279.8}/Norm[{20875.1, 8480.2, -51279.8}]
</source>
[[Category:User_Documentation]] [[Category:Subsystems]]

Lastly, enter the results into your airframe file as H_X, H_Y, and H_Z:

{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="AHRS" prefix="AHRS_">
<define name="H_X" value="0.372692"/>
<define name="H_Y" value="0.151401"/>
<define name="H_Z" value="-0.915521"/>
</section>
</source>
}}

AspirinIMU

2013-06-25T18:25:05Z

Jkg: fixed url

<div style="float: right; width: 45%; overflow: hidden">[[Image:Aspirin_2.1_imu_front.jpg|right|200px|Aspirin V2.1 top view]]</div>
__TOC__

== Aspirin IMU ==

The next generation flat multi degree of freedom inertial measurement unit. It uses digital 3-axis sensors which allow for a very small size and price. Other features include onboard voltage regulators, EEPROM for storing calibration data and extra sensors such as a barometer.

== Hardware Revision History ==

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
!''Version #''!!''Release Date''!!''Release Notes''
|-
|v2.2(current)||09/2012||2nd Gen Revision
|-
|v2.1r1||08/2012||2nd Gen Minor Revision
|-
|v2.1||03/2012||2nd Gen Production Release
|-
|v2.0||11/2011||2nd Gen Prototype
|-
|v1.5||04/2011||Updated Production Release
|-
|v1.4||03/2011||Prototype Update
|-
|v1.3||08/2010||Initial Production Release
|-
|v1.2||07/2010||Prototype Update
|-
|v1.1||07/2010||Prototype Update
|-
|v1.0||07/2010||Initial Prototype
|}

== Features ==

* 3-axis accelerometer
* 3-axis gyroscope
* 3-axis magnetometer
* Onboard voltage regulation
* Onboard I2C EEPROM
* Onboard barometer (''v2.1'')
* Standard footprint across versions
* Single PCB flat form-factor
* Fits directly onto [[Lisa/M]], carriers for [[Booz]] and [[Lisa/L]], or for [[Autopilots|LPC21xx]] integration

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Aspirin Feature Matrix'''
!width="6%"|''Version''!!width="10%"|''Accelerometer''!!width="10%"|''Gyroscope''!!width="10%"|''Magnetometer''!!width="10%"|''Barometer''!!width="15%"|''Regulators''!!width="10%"|''EEPROM''!!''Comments''
|-
|v2.2||MPU-6000||MPU-6000||HMC5883||MS5611||1x 3.3V (LP2992)||yes||MS5611 is connected directly to the SPI bus
|-
|v2.1||MPU-6000||MPU-6000||HMC5883||MS5611||1x 3.3V (LP2992)||yes||MS5611 is connected to the aux I2C of the MPU6000
|-
|v2.0||MPU-6000||MPU-6000||HMC5883||none||1x 3.3V (LP2992)||yes||
|-
|v1.5||ADXL345||IMU-3000||HMC5883||none||2x 3.3V (LP2992)||yes||
|-
|v1.4||ADXL345||IMU-3000||HMC5883||none||2x 3.3V (LP2992)||yes||
|-
|v1.3||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||
|-
|v1.2||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||
|-
|v1.1||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||
|-
|v1.0||ADXL345||ITG-3200||HMC5843||none||2x 3.3V (LP2992)||yes||Also has SC18IS600 SPI-I2C interface
|}

'''Note:''' Aspirin 2.1 comes in several population versions. The current version available at http://transition-robotics.com has the MPU-6000, HMC5843, and MS5611-01BA03 mounted. You can find the list of fitted sensors on Aspirin 2.1 in the eeprom block 4.

<gallery widths=170px heights=120px>
Image:Aspirin imu front.jpg|Aspirin V1.3 IMU front

Image:Aspirin imu back.jpg|Aspirin V1.3 IMU back
Image:Aspirin imu on carrier.JPG|Aspirin V1.3 IMU on [[Lisa/L]] compatible carrier board
Image:LisaL_Aspirin_Flat_Carrier.jpg|Aspirin flat carrier board for [[Lisa/L]] (without IMU mounted)
</gallery>

<gallery widths=220px heights=150px>
Image:Aspirin_2.1_bottom.jpg|Aspirin IMU 2.1 bottom side
Image:Aspirin_2.1_top.jpg|Aspirin IMU 2.1 top side
Image:Aspirin_2.1_nobaro_top.jpg|Aspirin IMU 2.1 top side no barometer mounted
Image:Aspirin_2.1_nomag_nobaro_top.jpg|Aspirin IMU 2.1 top side no barometer and no magnetometer mounted
</gallery>

== Pinout ==

Note that Aspirin uses a standard footprint and pinout across all versions, with certain exceptions. The chip select (CS) and interrupt (Int) pins are not always assigned to the same devices. A good example is with the introduction of the MPU-6000 device. Check the schematics for details.

'''Warning:''' When mounting Aspirin on Lisa/M note that the pin labeled GND on Aspirin (in the right upper corner on the following picture) is connected on Lisa/M to GYRO_SS. To prevent a software error induced shorting of the Lisa/M GYRO_SS pin to ground, remove the castellation or remove the connection on that pad.

In the v2.1r1 versions of Aspirin ("R1" silkscreened onto PCB) the right upper GND pad was changed to Not Connected, (marked RESV in the below image), resolving the issue.

[[Image:Aspirin IMU documented.jpg|300px|Aspirin IMU with documented IO connections.]]
[[Image:Aspirin_booz_carrier_legend.jpg|300px|Aspirin IMU on booz/breakout carrier with documented IO connections.]]
[[Image:Aspirin_flat_carrier_legend.jpg|300px|Aspirin IMU on flat carrier with documented IO connections.]]

Note that the 12-pin connector pinout of the Booz/breakout carrier (center) is reversed with respect to the Lisa/L flat carrier (right). This is because the Booz carrier mounts to Lisa/L with the Aspirin underneath the carrier (e.g., Z axis pointing toward Lisa/L), and the flat carrier mounts to Lisa/L with the Aspirin on top (e.g., Z axis pointing away from Lisa/L).

== Block Diagrams ==

<gallery widths=300px heights=300px>
Image:Aspirin-1_x-stm32-block_diagram.png|Aspirin 1.x to STM32 protocol connections
Image:Aspirin-2_x-stm32-slave_i2c-block_diagram.png|Aspirin 2.x to STM32 default protocol connections (MPU-6000 slave I2C)
Image:Aspirin-2_x-stm32-direct_i2c-block_diagram.png|Aspirin 2.x to STM32 alternative protocol connections (STM32 direct I2C)
</gallery>

== Schematics ==

Schematics are available under {{CC-BY-SA-3.0}} license. For additional intermediate schematics see [[AspirinIMU#Downloads|Downloads]].

<gallery widths=200px heights=137px>
Image:Aspirin_imu_schematic_V1_3.png|Aspirin IMU V1.3 schematic
Image:Aspirin_imu_schematic_V1_5.png|Aspirin IMU V1.5 schematic
Image:Aspirin_imu_schematic_V2_1.png|Aspirin IMU V2.1 schematic
Image:Aspirin_imu_schematic_V2_2.png|Aspirin IMU V2.2 schematic
</gallery>

== Drivers and Support ==

Please see the [[Subsystem/imu|IMU subsystem]] page for details on configuring Paparazzi for using an Aspirin IMU.

The drivers for this IMU are available in the [https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/subsystems/imu/imu_aspirin.c Paparazzi GitHub repository].

== PCB and assembled boards suppliers ==

Aspirin IMU is available in the [http://thequadshot.com/collections/all Transition Robotics/Quadshot Online Shop].

There are three options of Aspirin IMU:
* [http://thequadshot.com/products/aspirin-imu Without a carrier board]
* [http://thequadshot.com/products/aspirin-imu With Booz carrier board]
* [http://thequadshot.com/products/aspirin-imu With next generation flat carrier board]
** [http://thequadshot.com/products/lisa-l-aspirin-flat-carrier The flat carrier board can be purchased separately as well]

== Mechanical Dimensions ==

[[Image:Aspirin_top_mechanical.png|500px|Aspirin Footprint Mechanical Dimensions]]

The overall height of the board is about 3mm.

== Downloads ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/sensors/imu/aspirin Aspirin IMU and Carrier Board Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Aspirin Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Aspirin Bill Of Material

[[Category:Hardware]] [[Category:User_Documentation]]

Get Hardware

2013-05-10T19:59:54Z

Jkg: /* u-Blox GPS receivers */ added location for CSGshop

As an open-source project, all source code and hardware plans are [https://github.com/paparazzi/paparazzi-hardware freely available on GitHub] for anyone to produce, use, modify, and redistribute in accordance with the [http://www.gnu.org/licenses/gpl.txt GPL License Agreement] which requires only that the open-source nature of the project be maintained by all who redistribute it.

We encourage the distribution of hardware for profit or otherwise and invite any users with paparazzi-related hardware to post links and purchasing information on this page. Please use the [[Talk:Get_Hardware&action=edit|Discussion Tab]] to describe your experiences with any of these vendors.

<hr>

<br style="clear:both">
<br style="clear:both">

= [http://aerofu.com [[image:aerofu_logo.png]] Aerofu.com ] =

Low cost Paparazzi hardware from Australia.
Licenced to export to [http://aerofu.com/index.php?main_page=page&id=2 33 countries], including Europe and North America. Recentry restocked with:
<ul>
<li>
[http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=30 Tiny]
and
[http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=31 TWOG]
autopilots.
</li>
<li>
Complete Kits ([http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=48 Tiny] or [http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=49 TWOG] based).
</li>
<li>
[http://www.aerofu.com/index.php?main_page=product_info&cPath=10&products_id=20 PPM Encoders] and [http://www.aerofu.com/index.php?main_page=product_info&cPath=8&products_id=44 IR Sensors] from the Paparazzi project.
</li>
<li>
Inexpensive [http://www.aerofu.com/index.php?main_page=product_info&cPath=7&products_id=12 uBlox LEA-5H GPS units].
</li>
<li>various PCBs</li>
</ul>

<br style="clear:both">

= [http://www.ppzuav.com/ [[Image:Ppzuav.jpg]]] www.ppzuav.com [[Image:All ppz autopilots med.jpg|thumb|400px|Paparazzi controllers]] =
<h2>Providing professionally assembled and tested hardware and PCBs for your Paparazzi Projects since 2007</h2>
<span style="background:#00C000">NEW:</span> Yes we have [[SUMO]] bundles and [[SUMO/prepare_electronics|SUMO electronics]].
<b>eMail to:</b> sales@ppzuav.com for details.
<p>
We want to help you get your Paparazzi project off the ground. We have helped hundreds of projects become successful. Confused what to buy? Just give us an email and we will help you decide ('''sales@ppzuav.com''').
</p>
<p>Whatever the part we make all the Paparazzi hardware available either via bare PCBs or fully assembled ready to program. TWOG, Tiny2.11, Umarim, YAPA2 we can make them all in any quantity you require.</p>
<p>
If you do not see what you need just ask. Please eMail with any questions or special requests before you place your orders. We return emails as quickly as possible.
</p>
<p>
Visit the PPZUAZ [https://www.ppzuav.com WebStore] to see the latest offerings.
</p>
<p><b>NEW BUNDLE->:</b>[https://www.ppzuav.com/osc/product_info.php?cPath=2&products_id=144 UmarimLite v2 Bundle]</p>
<h4>Need Just PCBs? We have them. Click [https://www.ppzuav.com/osc/index.php?cPath=1 here] to see them.</h4>
<br style="clear:both">
<br style="clear:both">

= [http://transition-robotics.com [[Image:Transition_Robotics_Logo.png|100px]] Transition Robotics Inc.] [[Image:LisaM_V2_0_TopView.JPG|thumb|Lisa/M V2.0 top view]][[Image:LisaM_V2_0_BottomView.JPG|thumb|Lisa/M V2.0 bottom view]] =

Transition Robotics Inc. is a young company developing new solutions for and with the Paparazzi UAV platform. Their core product is the [[Image:Quadshot_Logo.jpg|100px|link=http://thequadshot.com|Quadshot]], a VTOL transitioning aircraft.

Beside the Quadshot itself they develop and provide hardware and software that is especially optimized for Paparazzi, such as the Lisa Autopilots, Aspirin IMUs and associated accessories.

They have a shop on their [http://transition-robotics.com Quadshot product page].

As of February 2012, Transition Robotics, Inc. has acquired all IP and Paparazzi related inventory from Joby Robotics. We are thankful to Joby Robotics for their important and faithful support of Paparazzi related hardware projects, and hope to carry on this tradition. Hardware formerly supplied by Joby Robotics may now be purchased at the [http://transition-robotics.com/collections/all Transition Robotics/Quadshot webstore.]

The [http://transition-robotics.com/collections/all TRI/Quadshot Webstore] also stocks pre-crimped Molex Picoblade wires and connector housings.

<br style="clear:both">

= Other =

==[http://www.olimex.com/pcb/ Olimex]==
[[image:pcb-green.jpg|thumb|250px|Olimex PCBs]]
*Fast PCB Prototypes [http://www.olimex.com/pcb/ www.olimex.com/pcb]
*Development Boards [http://www.olimex.com/dev/index.html www.olimex.com/dev/]

<br style="clear:both">
<br style="clear:both">

==[http://www.sparkfun.com Sparkfun]==
[[image:P1030095.jpg|thumb|250px|Sparkfun]]
Sparkfun is a great source of miscellaneous electronics like:
* Development boards
* GPS
* Gyros
* Accelerometers
* Pressure sensors
* Ultrasonic distance sensors
* Temperature/humidity sensors
* USB to Serial converters
* LEDs
* Etc.
They also have an inexpensive PCB service, [http://batchpcb.com/index.php/Products BatchPCB].

<br style="clear:both">
<br style="clear:both">

'''Sparkfun distributors in Europe'''

Incomplete list.
*http://www.lipoly.de/index.php?main_page=index&cPath=880_883&language=en
*http://www.watterott.com/en/SparkFun

== [https://store.diydrones.com/ DIYDrones] ==
Mainly focused on ArduPilot hardware. But carries Paparazzi compatible Telemetry and sensor boards.

'''DIYDrones distributors in Europe'''
*http://www.lipoly.de/index.php?main_page=index&cPath=880_1912 [DE]
*http://www.unmannedtechshop.co.uk/ [UK]
*http://www.buildyourowndrone.co.uk/ [UK]

==u-Blox GPS receivers==

There seems to be a few alternative source of u-Blox GPS out there. They are considerably cheaper then the samples u-Blox offers

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:

*[http://www.navilock.de/produkte/gruppen/13/Boards_und_Module Navilock] (also available on [http://www.amazon.de Amazon.de] by searching for Navilock)
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp (Also [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/u-blox-5-Modules.asp u-blox 5] and [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/u-blox-6-Modules.asp u-blox 6] modules avialable)
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error, you can find them in this list: http://www.comet.srl.ro/shop/statements.html?Type=MOD&Subtype=GPS )
*http://www.expedienttech.com/ ( Singapore )
*http://www.csgshop.com/category.php?id_category=16 (US UBLOX MAX-6Q) ( Lithuania )

==Airspeed Sensors==

Eagle Tree Systems makes a small standalone airspeed sensor that can be connected via i2c. They also sell pitot tubes standalone for other differential pressure sensors. For integration, please see [[Sensors/Airspeed]].
*[http://www.eagletreesystems.com/Standalone/standalone.htm Eagle Tree Systems] (Also available from a number of distributors)

[[Category:Hardware]] [[Category:User_Documentation]]

== DIGI XBee telemetry modules ==
For detailed shopping guide see [Modems]
*http://www.watterott.com/en/Digi (DE EU)
*https://store.diydrones.com/ (US See above for local distributors)
*http://unmannedtechshop.co.uk/UAV-Components/UAV-telemetry (UK)
*http://mouser.com/ (AU and other regions)

= Old vendors =

Here is a list of former paparazzi hardware vendors for reference. They were providing a great service to the Paparazzi community.

* [http://chebuzz.com/paparazzi Chebuzz Pprz] had to move back to US and close his store, [http://aerofu.com/ AeroFu] is carrying on his business.
* [http://jobyrobotics.com Joby Robotics] stock and IP was bought by [http://transition-robotics.com Transition Robotics] that is carrying on their business.

Module/Airspeed ETS

2013-04-30T18:03:32Z

Jkg: added directions to enable i2c

__NOTOC__
[[Image:Ets_airspeed_v3.jpg|thumb|right|Eagletree Airspeed v3]]
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Modules</categorytree>
== Overview ==

The EagleTree Airspeed Sensor is a low cost module and comes with a good pitot tube (Prandtl style, pitot-static tube) that includes static and dynamic ports. It has an I²C interface that connects directly to the Autopilot I²C port. The paparazzi autopilot code is able to regulate the throttle in order to keep the airspeed constant (and a minimum ground speed).

{|border="1"
|-valign="top"
||Module name||sensors/airspeed_ets
|-
|Sensor type
|air speed
|-
|Range
|4m/s .. 150m/s
|-
|Resolution
|0.3m/s
|-
|Refresh rate
|10Hz
|-
|I2C address
|0xEA
|}

[http://www.eagletreesystems.com/Support/manuals/airspeed-v3.pdf Product data sheet]

== Hardware ==

The sensor directly interfaces to the 3.3V I2C port of the autopilots and is supplied by +5V. When you buy the airspeed sensor it is set to operate in the default mode. Make sure you did not set it somehow to 3rd party mode.

=== Wiring ===

{|border="1"
|-valign="top"
||'''Autopilot I2C pin'''||'''Autopilot I2C'''||'''ETS Airspeed wire colour'''
|-
|1
|GND
|white
|-
|2
| +5V
|red
|-
|3
|
|
|-
|4
|SDA
|yellow
|-
|5
|SCL
|brown
|}

== Usage ==

To use it load the airspeed_ets module:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
...
<load name="airspeed_ets.xml"/>
</modules>
</source>
}}

and enable I2C0 if you are not using it already:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware>
...
<define name="USE_I2C0"/>
</firmware>
</source>
}}

=== Configuration ===

You can also set some '''optional parameters to change the default configuration'''. For example to use i2c1 instead of i2c0, a scale of 2 (default is 1.8) and offset of 50 (default is 0):
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
<load name="airspeed_ets.xml">
<define name="AIRSPEED_ETS_SCALE" value="2"/>
<define name="AIRSPEED_ETS_OFFSET" value="50"/>
<define name="AIRSPEED_ETS_I2C_DEV" value="i2c1"/>
</load>
</modules>
</source>
}}

== Usage as sensor for speed control==

To use the sensor to control the speed of your aircraft add the aggressive climb flag, define which I2C device you are enabling and enable airspeed control:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<target name="ap" board="twog_1.0">
<define name="AGR_CLIMB"/>
<define name="USE_I2C0"/>
<define name="USE_AIRSPEED"/>
</target>
</source>
}}

=== Airframe configuration ===

Now to use real airspeed values for adjusting your aircraft autopilot behavior, add the following to the end of the "VERTICAL CONTROL" section of your airframe file:
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<section name="VERTICAL_CONTROL" prefix="V_CTL_">
....

<define name="AUTO_AIRSPEED_SETPOINT" value="13.0" unit="m/s"/>
<define name="AUTO_AIRSPEED_PGAIN" value="0.060"/>
<define name="AUTO_AIRSPEED_IGAIN" value="0.050"/>

<define name="AUTO_GROUNDSPEED_SETPOINT" value="7.0" unit="m/s"/>
<define name="AUTO_GROUNDSPEED_PGAIN" value="0.75"/>
<define name="AUTO_GROUNDSPEED_IGAIN" value="0.25"/>
</section>
</source>
}}

Note that the SETPOINT values may need to be adjusted to suit your aircraft.

Note that depending on whether you set the AIRSPEED setpoint or the GROUNDSPEED setpoint higher, either constant airspeed or constant groundspeed, respectively, will be the goal of the controller.

See paparazzi/conf/airframes/easystar_ets_example.xml for an example airframe configuration.

=== Seeing the speed values ===
To debug or log the raw values from the ETS airspeed sensor define SENSOR_SYNC_SEND in your airframe file to send the message AIRSPEED_ETS on every sensor reading. Note that defining this sends the AIRSPEED_ETS message at the sensor read rate as defined in conf/modules/airspeed_ets.xml. This does not have any bearing on the AIRSPEED message (if both SENSOR_SYNC_SEND and USE_AIRSPEED are defined, then both messages are sent).
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
<load name="airspeed_ets.xml">
<define name="SENSOR_SYNC_SEND"/>
</load>
</modules>
</source>
}}

The general airspeed can be displayed in the Messages tool by adding the AIRSPEED message to the telemetry file as follows:
{{Box Code|conf/telemetry/default.xml|
<source lang="xml">
<process name="Ap">
<mode name="default">
<message name="AIRSPEED" period="1.0"/>
...
</source>
}}

The AIRSPEED_ETS message does NOT need to be added to the telemetry configuration since it is sent directly by the module if SENSOR_SYNC_SEND is defined.

NOTES
# In the GCS, the strip displays ground speed and '''not''' airspeed by default. In order to display airspeed, drag-and-drop the airspeed message field from the Messages tool onto the 2D map of the GCS.
# The telemetry name AIRSPEED" should actually be called SPEED and contains Groundspeed and airspeed return values.

== Usage as sensor for air speed measurement only ==

To see the sensors data in the log file set the SENSOR_SYNC_SEND in your airframe file. Every time new data is available it will be sent directly.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<modules>
<load name="airspeed_ets.xml">
<define name="SENSOR_SYNC_SEND"/>
</load>
</modules>
</source>
}}

===Result message===

The raw data (adc), estimated offset at init time (offset) and the converted result (scaled) is written to the log file.
{{Box Code|conf/messages.xml|
<source lang="xml">
<message name="AIRSPEED_ETS" id="57">
<field name="adc" type="uint16"/>
<field name="offset" type="uint16"/>
<field name="scaled" type="float"/>
</message>
</source>
}}

Sample log file lines
149.529 123 AIRSPEED_ETS 1626 1606 8.024844
149.633 123 AIRSPEED_ETS 1626 1606 8.024844
149.730 123 AIRSPEED_ETS 1627 1606 7.942226
149.841 123 AIRSPEED_ETS 1628 1606 7.942226

[[Category:User_Documentation]] [[Category:Modules]]

Lisa/M v2.0

2013-04-27T01:27:51Z

Jkg: hopefully improved I2C bus description clarity

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div>
<div style="float: right; width: 40%">__TOC__</div>

Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on a STM32 processor for extensive peripheral connection and faster processing.

A number of tutorials are being prepared for getting started with Lisa/M:
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]

Please join us in our quest to make the getting started information even more, eh... informative, by adjusting those pages with your own improvements.

== Features ==

Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].

* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)
* 7 x Analog input channels
* 3 x Generic digital in-/out-puts
* 2 x 3.3V TTL UART (5V tolerant)
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)
* 1 x CAN bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)
* 1 x Micro USB
* 4 x status LEDs with attached test point
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)
* ~34mm x ~60mm x ~10mm
* 4 layers PCB design

With mounted Aspirin IMU has the following additional sensors on board:

* 3 Axis Gyroscope
* 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer MS5611 (as of Aspirin v2.1)

NOTE:
'''Lisa/M has pads for the BMP085 pressure sensor. Lias/M 2 boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1 which has the new MS5611-01BA03 barometric pressure sensor.'''

The drivers for the MS5611-01BA03 are work in progress and are available in the master branch of the Paparazzi codebase. All help with testing and improving the driver are very welcome!

So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.

<gallery widths=200px heights=200px>
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view
</gallery>

== Pinout ==
Pins Name and Type are specified with respect to the Autopilot Board.

<div style="float: right; width: 100%">
[[Image:LisaM_V2_0_top_labeled.png|900px]]
[[Image:LisaM_warning_label.png|200px]]
</div>

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SERVO1/2/3/4/5/6/7/8'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow
|-
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red
|-
|3||GND||PWR||common ground||style="background:black; color:white"|Black
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''JTAG'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|-
|4||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''GPIO'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan
|-
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta
|-
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink
|-
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1 CAN'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red
|-
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red
|-
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange
|-
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow
|-
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green
|-
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange
|-
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow
|-
|5||SCK||Out||SCK||style="background:green; color:white"|Green
|-
|6||SS||Out||SS||style="background:blue; color:white"|Blue
|-
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green
|-
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue
|-
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green
|-
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue
|}

'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. Therefore one has to choose, either use SERVO7 and SERVO8 '''OR''' have the I2C1 bus available, if that one needs to be used for whatever reason alongside the I2C2 bus. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. For this to work one must make sure to have the latest Paparazzi sourcecode.

=== LEDs ===
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).
By default the LEDs are use for:
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok
; LED_5, green : not set to anything by default

=== Jumper Configuration ===
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.

The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.

<gallery widths=380px heights=205px>
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers
</gallery>
<br style="clear:both">

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Power Jumper Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP1||SERVO_BUS to V_IN||OPEN||Connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail
|-
|JP2||V_BATT to V_IN||OPEN||Connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail
|-
|JP3||V_IN to +5V||OPEN||Connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail
|-
|JP7||UART3_VCC to +3V3||OPEN||Connects UART3 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''

'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP4||UART2_VCC to V_IN||OPEN||Connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''
|-
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART2 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).

'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||OPEN||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.

=== Powering the Board ===

[[Image:LisaM_warning_label.png|right|200px]]

The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice.

The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.

When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is

<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math>

If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).

== Schematic ==
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3
</gallery>
<br style="clear:both">

== Examples of Airborne Equipment Electrical Connections ==

=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===

[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]

This configuration assumes the ESCs have a battery eliminator circuit (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].

=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===

[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]

This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.

=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Fixedwing, Spektrum Satellite Receivers ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===

[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]

The ESCs have BECs and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example

== R/C Receivers ==

One can use Spektrum DSM2 or compatible receivers as well as traditional PPM receivers. It is even possible to connect two Spectrum or compatible satellite receivers for better redundancy or to improve RC signal reception. Connecting a RC receiver for flying your aircraft in manual mode during setup and test phase is 99% of the cases a must. Therefore the Paparazzi team made it easy to connect one.

=== Using a Spectrum DSM receiver ===

==== Physically connecting ====

Wiring up a Spektrum or compatible satellite receiver is not to difficult to do. It is very important to make absolutley sure the connectors are properly made. Not being precise in this step can mean full RC loss and loss of airframe in the first tuning testflights.

The spektrum satellite receiver should be connected to the UART1 connector on the autopilot board. Make sure the voltage on the AP board UART1 + pin is not to high, or to low for your receiver.

Steps:
# Connect the minus(-) of the receiver to GND of UART1
# The receiver plus(+) to the UART1 Plus(+)
# Data out signal of the receiver to the RX pin on the UART1

==== Binding ====

To get a receiver and transmitter to work together you must perform a binding process.

It is important to '''bind''' your Spectrum DSM receiver to your transmitter '''via''' your '''Lisa board''', not in any other way!

The way to bind is by temporary connecting via fiddly small molex pins. It is advised to make a small bind plug out of a molex connector for this purpose. Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable.

The bind procedure:

# On the connector ANALOG1 have a wire between the GND pin ADC1, located in the middle of the board
# Power up your autopilot board
# Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter
#:Wait.. all light of receiver blink then go steady
# Let go of your transmitter bind button
# Power off your Lisa Board
# remove the wire between GND and ADC1 pins
# Repower your board, if you have servos connected and wiggle the RC transmitter sticks some servos should move

That all, you are done. Only needs to be done '''once''' for your receiver.

=== Using a PPM receiver ===

Using a PPM receiver, a so called '''PPM sum stream''' input is possible. [[RC_Receivers_and_Radios#PPM_Based_Systems | To make it work, you need a PPM sum stream out capable receiver. Find out more following this link]]

==== Connecting ====

Connect the PPM out signal to the RX pin of UART1.

Make sure put this in your airframe file in your AP target section.

...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>
</subsystem>
...

===== Alternative =====

However if in the case you want to use the UART1 port for something else, there is an option to connect the receiver to a servo pin. Yes, that's right, a servo connector is used for receiving a PPM stream '''input'''. If you want to walk that path, the default pin number to capture the PPM sum stream is via servo connector SERVO6

If you connect the PPM ou capable receiver that way make sure to put this in your airframe file in your AP target section:

...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="SERVO6"/>
</subsystem>
...

If you do not have or cannot modify a receiver to a ''PPM out'' able receiver, a [[PPM_Encoder | PPM encoder board]] can be used to avoid opening your receiver for PPM out modification.

== Extras ==

=== UART I/O ===

UART pins can also be used as general purpose I/O, this might come in handy in case all other inputs or your AP board are in use.

=== USB as UART1TX + hardware flow control===

[[File:Lisam-usb-uart1.jpg]]

The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respactively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line.

If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level treshold of the microcontroller, causing strange behaviour.

For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)
CTS, most blue, on pin 9 of the Xtend

<gallery widths=380px heights=205px>
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.
</gallery>

== PCB ==

=== Gerber & Drill Files ===

'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

== Assembly ==

To create and assemble a board oneself is possible. It ake some skills ofcouse. In case you wan to follow that path you need the desing. You came to the right place here is the info to get the needed files;

===Components Layout===

''[[Lisa/M_v2.0#Get the design|Get the design]]''

Need some top and bottom of board images and line drawings here.

=== Bill Of Material ===

'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

== PCB and assembled boards suppliers ==

To difficult to creat your own AP board, understandable, thus pre made board available via [[Get_Hardware|Get Hardware]] page... hopefully :)

== Mechanical Dimensions ==

[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]

The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).

== Get the design ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material

== Uploading new software ==
New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain the [[Luftboot]] bootloader. All Lisa/M 2.0 from Transition Robotics Inc. come with luftboot already in the board.

An alternative to get your firmware in the board is by using a JTAG connector connected via the 10-pin Samtec connector that is available on the board.

See the [[FirmwareFlashing]] page for an overview of different methods to upload new software to your autopilot.

=== Using luftboot ===
'''This is the default FLASH_MODE for Lisa/M v2.0''', it could be explicitly selected by adding
:<source lang="xml"><configure name="FLASH_MODE" value="DFU"/></source>
to the firmware section of your airframe file. Make sure to set Lisa/M 2.0 as it's target board.

Once USB is plugged in, the board automatically goes to bootloader mode and the status LEDs cycle up and down:

[[File:Luftboot.gif|320px]]

If you have trouble entering the bootloader mode or want to upload/update the bootloader itself, see the [[Luftboot]] page.

=== Using JTAG ===
You still can use a [[JTAG|JTAG adapter]] for [[FirmwareFlashing#JTAG|flashing]] and [[DevGuide/JTAG-Debug|debugging]] your paparazzi firmware. To use [[FirmwareFlashing#JTAG|JTAG flashing]] configure the ''FLASH_MODE'' in your firmware section:
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source>
Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source>

Then press upload as normal...

=== Serial Firmware Upload ===
Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten [[Luftboot]] accidentally and don´t have access to [[JTAG]].<br/>
Either set the flash mode in the target section of the airframe configuration:
:<source lang="xml"><configure name="FLASH_MODE" value="SERIAL"/></source>
or add it to the commandline invocation:
make AIRCRAFT=<aircraftname> ap.upload FLASH_MODE=SERIAL

Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads

Now a boot sequence works as follows:
#BOOT1 has to be set to 3.3V by use of a jumper cable
#Connect a 3,3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS
#Power the board and activate the bootloader program

== Detailed Hardware Revision History ==

=== Changes Between LISA v1.1 and v2.0 ===

* Lots of silkscreen improvements
* Added attributes to all parts to make the usage of bom-ex ulp possible.
* Improved routing to allow teardropping
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.
* Added pullups on all UART RX lines to prevent undesired floatation.
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.
* ...

== Hardware Change Requests ==

If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.

* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain.
** A: Using a MS5611 is possible through using a Aspirin v2.1 board

* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.

* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.

* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.
[[Category:Lisa]] [[Category:User_Documentation]]

RC Receivers and Radios

2013-04-26T19:40:56Z

Jkg: typos

= Introduction=

To be able to test your airframe before it flies fully autonomous a regular RC transmitter in combination with a receiver can be used. This is essentioal for testing and tuning your airframe. For this to work the received steering commands have to leave the receiver. Only then with this flow of command data the autopilot when flown in manual mode can do something you tell it to. This page is to give you information of how to connect various receivers. Also how to modify receiver so they can talk to the autopilot.

=Setup=

Once you have physically connected your receiver we need to setup the transmitter and receiver combination correctly. This can be an complex task due to the overwhelming amount of options. [[rc_transmitter_and_receiver_setup| To assist you in this setup quest a specific wiki page]] is available to help you out.

=2.4GHz Receivers=

If using a Lisa/M or Lisa/L autopilot board the whole range of Spektrum/JR/Hobbyking satellite receivers can be used directly connected to the AP board. If you come across the term "Satellite Receiver", it has nothing to do with satellites in earth orbit. It is just a term to describe an auxiliary receiver normally used to improve reception by plugging into the 'main' receiver.

For other autopilot boards to use a 2.4 GHz system a few requirements are necessary

# Must have combined PPM pulsetrain out or use [[PPM_Encoder | PPM Encoder]] board. See the [[Get_Hardware| Get Hardware]] page for links to suppliers)
# At least one extra channel beyond those needed to control the servos and motor. (throttle-roll-pitch-mode)

==OrangeRX==

[[Image:Orangerx_satellite_receiver.jpg|thumb|left|OrangeRx R100 Receiver]]

OrangeRx R100 Satellite Receiver [http://www.hobbyking.com/hobbyking/store/__13418__OrangeRx_R100_Satellite_Receiver.html| R100SAT]. Works well, simple to connect, do not expect long range wonders however.

==Spektrum 9645==

[[Image:Spektrum_9645_satellite_receiver.jpg|thumb|left|Spektrum 9645 satellite receiver]]

[http://www.spektrumrc.com/Products/Default.aspx?ProdID=SPM9645| Spektrum 9645 satellite receiver]. Works well, simple to connect. the DSMX mode is not used, it is used in the DSM2 mode, the receiver is backards compatible with that protocol.

==Futaba FASST 7-channel receiver==

[[Image:rs617fasst.jpg|thumb|right]]

* Pin 8 (upper right corner in picture) of the small IC on the right contains 5 PPM pulses and can go directly to paparazzi. Pulse 6 and 7 go directly to the servos.
* Best is to remove the resistors of one of the channels and connect a small wire to pin 8 to get the combined 5 pulses on the robust 1/10th inch header.
* Do not forget to use channel 3 (only failsafe channel) as mode switch with fail safe "throttle off" as mode 2.

==Robbe RASST 7 & 8 channel receivers==

Robbe has produced line of Futaba FASST compatible receivers that can output only PPM which results ablility to plug into autopilot without encoder.
* [http://www.robbe.de/empfaenger-r-6007-sp-2-4-g-rasst.html R6007SP 2,4 GHz RASST] - 7 channel, for small aircraft
* [http://www.robbe.de/empf-r6107sp-2-4-ghz-rasst.html R6107SP 2,4 GHz RASST] - 7 channel, >1000m range
* [http://www.robbe.de/empf-r6008sp-2-4-ghz-rasst.html R6008SP 2,4 GHz RASST] - 8 channel, upto 3000m range

===Switch Assignment===

To assign the three position switch to any other channel but channel 7 follow these steps:
# Set up aux2(refers to aux2 on rx not the switch on the tx. aka ch7) with its input selected as 3 pos switch.
# Set up this mix - Gear to Gear (Up=-100, Down=-100, Offset =0). This inhibits the gear switch.
# Set up another mix - Aux2 to Gear (Up=100, Down=100, Offset = 0).
Notes:
#Gear on a DX-7 Air is Channel 5 and AUX2 is CH7. Once again i am referring to the inputs which are labeled on the RX not what the switches are named on the TX. If your using a DX-7 heli please substitute the names for what the rx channels are named into this guide
# DX7 Heli the 3-pos switch is named "flight mode"
# DX7 Air the 3-pos switch is named "flaps"

===Failsafe Setup===

To set up the mode channel (3 pos switch) to default to auto2 if connection is lost between rx and tx follow these steps:
# Put 3 position Switch into AUTO2 Position
# Put in bind plug
# Power up
# REMOVE the bind plug
# Power up Tx while pushing bind button
# Wait until light becomes steady and not blinking (it may become steady right off but will then start blinking again so let it go at least 5 seconds)

==Jeti Duplex 2.4 GHz Receiver Rsat 2==

[[Image:Jeti_Duplex_Rsat2.jpg|thumb|left|Jeti RSat 2]]
* Outputs PPM, no soldering or PPM board required
* Only 12 gramms
* Full duplex technology provides safe radio link and redundant telemetry to standard paparazzi telemetry.
* [http://www.jetimodel.cz/index.php?page=products&old=0&category=4 Transmitter module] can be installed in any receiver.

More information can be found a the [http://www.jetimodel.cz/index.php?page=product&id=165 Homepage of Jeti] and the [http://www.mikrokopter.de/ucwiki/JetiDuplex MikroKopter Wiki].

=PCM Receivers=

Most of the known PCM transmitter also can be set to PPM mode. If this is set, then the regular description for PPM applies since the PCM receiver like a JR/Gaupner SMC16 Scan can output PPM perfectly.

However if setting up you transmitter to PPM out then the following applies:

# Must use ppm encoder board. (See [[Get_Hardware|Get Hardware]] page for suppliers)
# At least one extra channel beyond those needed to control the servos and motor.

= PPM Receivers =

== Requirements ==

To use a 26/27/35/40/41/72/ MHz receiver a few requirements are necessary

# At least one extra channel beyond those needed to control the servos and motor.
# A receiver or modified receiver which outputs a full ppm signal.

== R/C Receiver Interface==

All versions of the Paparazzi autopilot include a connector to interface with a standard R/C receiver for manual or semi-autonomous control during the testing and tuning phases. Two interface options exist:
# Tap into the PPM signal running between the RF section and the servo driver of your receiver and route it to the Paparazzi. Let the Paparazzi generate individual servo signals and connect all servos directly to the autopilot. This method requires only 3 wires to the receiver (power and PPM), is compatible with all Paparazzi autopilots, and provides 8 manual R/C channels and the potential for more autonomous channels regardless of the capability of the R/C receiver.
# Cut the PPM trace and route it thru the autopilot and back to the receiver, using the servo driver IC on your R/C receiver to drive the servos. This option requires 4 wires (Ground, PPM-in, PPM-out, Reset) and your receiver must have a supported servo driver IC. This allows you to use the large servo connectors on your R/C receiver and does not require any modification to your servos or ESC but does require you to cut a trace on your R/C receiver and limits the number of servos to the capacity of your receiver. Compatible with Classix and Tiny 1.1.
# Note that on the Classix the PPM_in pin is FOO2...
[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|left|PPM Timing Diagram<small>Note 1: Exact value not critical. Depending on RC Transmitter type & Manufacturer.<br>Note 2: Depending on Transmitter number of Channels and t,,n,, durations.<br>Note 3: Not critical. Depending on Synchro detection method.</small>]]
[[Image:RC_Receiver_Tiny.jpg|thumb|left|3-Wire setup, driving servos from the autopilot]]
[[Image:RC_Receiver_classix.jpg|thumb|left|4-Wire setup, driving servos from the R/C receiver]]

=== Common demux chips ===

Typical used chips are the cmos [http://www.doctronics.co.uk/4015.htm 4015] and [http://www.doctronics.co.uk/4017.htm 4017].

The 4015 uses either pin 1 or pin 9 for the clock and the input is on 7 and 15. The 4017 has just one shift register and has its clock input on pin 14 and the enable on pint 13.

In most receivers you are after the clock; though some may be pulsed; in which case you need the enable. Note that the 4017 enable has inverted logic (low to be enabled) whereas the input on the 4015 can be either (typically high). If the enable pin is held low (4017) or if the input pin (4015) is held high always;e.g. connected to the ground or the Vcc - then it is fair to assume that the PPM signal is most propably on the clock input.

== Recommended 35/40Mhz RC Receivers ==

Note that there is information on modifying other receiver models at [http://mikrokopter.de/ucwiki/RC-Empf%C3%A4nger mikrokopter.de]. It's in German however the pictures contain most of the information or use google translate.
Shielded wire is recommended for receiver and autopilot connection, as unshielded one may cause noise in receiver.

=== Futaba FP-R116FB 6 Channel FM 35MHz receiver ===

[[Image:Rc_fut_web.jpg|thumb|left|Wiring of a Futaba R136]]
*Orange wire is connected to PPM signal
*Red wire is connected to VCC
*Brown wire is connected to GND
<br style="clear:both">

=== Futaba R136F 6 Channel FM receiver ===

[[Image:rx_futaba136.jpg|thumb|left|Wiring of a Futaba R136]]
*41 MHz
*White wire is connected to PPM signal

=== Futaba R168DF 8 Channel dual FM receiver ===

[[Image:rx_futaba168df.jpg|thumb|left|Wiring of a Futaba R168DF]]
*35 MHz
*PPM wire is connected to 862 receiver pin on the board. VCC and GND is on the 8/B original position.

=== ACT Micro-6 FM receiver ===

[[Image:rx_act_micro-6.jpg|thumb|left|Wiring of a ACT Micro-6]]
*Available in 35 or 40 MHz versions
*White wire is connected to PPM signal
*[http://www.acteurope.com/Micro_6anl.pdf Datasheet (German)]
<br style="clear:both">

=== ACT DSL-4top [http://www.mikrokopter.de/ucwiki/DSL4top mikrokopter.de] version ===
[[Image:DSL4top.jpg|thumb|left|DSL-4top mikrokopter.de version]]
* Special version for mikrokopter.de - Only available in their [https://www.mikrocontroller.com/index.php?main_page=product_info&products_id=215&zenid=8ce8bab70f3e9d684e01f724316d9690 shop]!
* '''Outputs PPM directly''' on the channel 1 connector!
* No soldering necessary
* ACT Lifetime warranty
* Sells for ~45 euro

===Futaba R115F 5 Channel FM receiver===
[[Image:pprz_rx115.jpg|thumb|left|Wiring of a Futaba R115]]
*Available in 35 and 40 MHz versions
*White wire is connected to PPM signal

===JETI REX 5 plus (no MPD) receiver===
[[Image:520_Jeti_5_plus.jpg|thumb|left|Wiring of a REX 5]]

*Popular Czech made micro r/c receiver, available in 35 or 40 MHz versions
*´folded´ PCB design with parts inside, mostly inaccessable
*Small grey wire is connected to via with PPM signal
*Unusual connector used for testing, soldering recommended
*shielded wire recommended, this one taken from PC parts recycling (former soundcard to m/b connector cable)
*[http://www.jetimodel.cz/eng/navody_en/rex5_eng.pdf Datasheet (English)]
<br style="clear:both">
[[Image:DSC02414.JPG|thumb|left|other Layout of REX 5]]

=== Receiver RX-7-SYNTH IPD receiver [http://www.multiplex-rc.de/hp/produkte/artikel_detail.jsp?lfdnr=55880&action=add2notice&qty=1&cachenepper=1227896925116 Multiplex-rc.de] ===
[[Image:RX-7-SYNTH_IPD.jpg|thumb|left|Wiring of RX-7-SYNTH IPD]]

*Available in 35, 36 and 40 MHz versions
*A compact, high-quality 7-channel single-conversion FM / PPM IPD receiver
*Easy modification through connectors, see pictures

=== Protech 5FM 35 mHz Receiver ====

The low cost Protech '5FM' receiver makes use of an SMD version of the standard 74AHC164[http://www.ic-on-line.cn/IOL/datasheet/74ahct164_18057.pdf] 8 bit shift register; you are after PIN 1 of this chip. The circuit board has a testpad for just this pin at the top side of the circuit board.

<gallery>
Image:protech-5fm.jpg|Figure 1. <br>Protech 5FM 35 mHZ Receiver, mark 2
Image:protech-5fm-pad.jpg|Figure 2. <br> PPM tap location for the Protech 5FM receiver, near the 74AHC164 shift register
Image:protech-5fm-scope.jpg|Figure 3.<br> Protech 5FM PPM signal - not very clean/digital
</gallery>

Two physical versions exist; the older one [http://www.protech.be/Manuals/PRO205manual%20web.pdf] and a newer one pictured (fig 1). It has been distributed by protech with various ready-to-fly planes; such as the Skyraider[http://www.modelbouwforum.nl/forums/beginners/50677-protech-skyraider.html].

The solder/testpad you are after the one right next the 74x164 chip its pin 1. In this image it has a jellow wire soldered to it (the yellow wire at the top left is the normal antenna connector (fig 2). Note however that the signal is not very clean (1v/div) - which may cause issues - as shown in the above image (fig 3).

This is further compunded by the relatively noisy electrical engines; which are not brushless. A ferrite coil does not seem to help enough - Papparazi and GPS loose sync often through Xbee. Replacing the engine by a brushless outrunnen resolve the issue completely.

===Profi Penta 35 MHz===

[[Image:DSC00547.JPG]]
[[Image:DSC00545.JPG]]

==72Mhz Receivers ==

===Castle Creations [http://www.castlecreations.com/products/berg_ms4l.html Berg 4L]===

[[Image:berg4L.jpg|thumb|Wiring of a Berg 4L]]
* Expect fantastic performance from these $40 USD parts but be warned that they are known to have unreliable crystal sockets and brittle antenna wire. The ''Berg 7'' channel receiver should work equally well and is known to have a better crystal socket - note that either receiver will provide '''8 channels''' in manual R/C mode when used with Paparazzi. Note: the rugged ''Berg 4'' cannot be modified, only the ''Berg 4L'' and ''Berg 7''.
To Modify a Berg4L, follow these instructions:
# Remove the shrink wrap. Use a good knife and be careful to not damage any of the components on the receiver. I would recommend that you cut on the sides (edge of the PCB) to be sure to avoid damaging the shielding
# Desolder the headers. We will not use them with tiny AP as the servos are connected directly to the AP. This is pretty easy to do when you have a hot air rework station. If you don't have one, your best bet is to cut the header off and remove the left over pins one by one with a regular iron. There is a piece of shielding material that is connected to one of the ground pins of the header. You need to remove it carefully from the header without damaging it and re-solder it to the gnd pad.
# You need to solder 3 wires to the receiver. Gnd, +5V and PPM. To locate the PPM signal, first locate the PIC micro controller close to the location of the headers. The PPM signal is on the corner pin closest to the corner of the receiver. Soldering a 28guage wire directly to the PIN isn't very difficult. For the power connection, use the pads that were used for the header. The outside pin is Gnd, the second pin is +5V. What I did is solder the wires on the pad going straight down, then I looped the 3 wires 360 degrees and glued them to the PCB with hot glue. This provides good strain relief.
# While you have the PCB in your hands, take the opportunity to remove the crystal connector and solder your crystal directly to the PCB for added reliability.
# I also used some hot glue to add more strain relief to the antenna
# Use some large shrink wrap to cover the entire receiver again

===Hitec Electron 6 72MHz Reciever===

This was written for MNAV from crossbow but is still usable with PPRZ.

[[Image:Electron6mod.jpg]]

===Corona Synthesized Dual-Conv Receiver 8Ch===
[http://www.corona-rc.com/coproductshowE.asp?ArticleID=63 manual]

This receiver is available in 27,35,36,40,72 mhz and a Synthesized receiver, meaning you do not need to change frequency crystals.

How to modify for combined signal

# Cut the 8th channel PWM output pin near the PCB.
# Connected a pin from the Atmel (see picture) to the 8th channel PWM signal. (optionally, weaving the wire through some holes on the board.) Make sure you have a fine tip on your soldering iron and a magnifying glass strapped to your head!
# Glue the wire down (CA works)
# Be sure to glue the pin that you cut in place (previously, being soldered to the board was holding the pin in place)

It is maybe possible to reprogram the atmel with your own firmware. If you succeed in this plz add relevant info here.

That pin provides a 1V to 2V signal, it works with the PPRZ, although its a bit gittery (the slew rate is not real good).
[[Image:Corona_Synthesized_Receiver_72Mhz_bottom.jpg|thumb]]
[[Image:Corona_Synthesized_Receiver_72Mhz_top.jpg|thumb]]
[[Image:Corona_Synthesized_Receiver_72Mhz_top_atmel.jpg]]

<br style="clear:both">

=UHF Receivers=

Note that in most countries an amateur radio license is required to use 433MHz UHF.

==Scherrer UHF==

[[Image:ScherrerUHF.jpg|thumb|left|Scherrer UHF Rx]]

The [http://www.webx.dk/rc/uhf-link3/uhf-link3.htm Scherrer UHF] is a high quality diversity radio control system. It has a PPM output and can be connected directely to Paparazzi. A ppm encoder board is not required. It has an RSSI output.

<br style="clear:both">

==ImmersionRC EzUHF==

[[Image:EzUHFTx.jpg|thumb|left|ImmersionRC Tx]]

The [http://www.immersionrc.com/products.htm ImmersionRC EzUHF] is a high quality diversity radio control system. The recent firmwares have a PPM output on Ch. 1, but this needs to be activated through the PC configuration software with the proper firmware loaded. It connects directly to EzOSD and the TrackR2 which enables RSSI monitoring and head tracking for FPV.

Some people had issues with the exact timing, where the ROLL channel disappeared. If the radio has more than 6 channels, there may be methods to slave another channel to the roll channel (usually for the operation of dual ailerons). The ezuhf configuration file is using this method, where channel 1 is copied to channel 6. The EzUHF modules receive the PPM output stream from the radio and need to interpret it. For this reason, the ezuhf configuration file should be verified for proper functioning and you may find that channels are remapped to others with different purposes.

Search "sander style" antennas for a way to build your own cheap, high-quality antennas for these rx modules and which provide a range well beyond the horizon.

See [http://www.immersionrc.com/EzUHF.htm EzUHF manual+firmware] for more information.

[[Category:Hardware]] [[Category:User_Documentation]]

Get Hardware

2013-03-25T20:09:47Z

Jkg: updated TRI URLs and images to Lisa/M v2

As an open-source project, all source code and hardware plans are [https://github.com/paparazzi/paparazzi-hardware freely available on GitHub] for anyone to produce, use, modify, and redistribute in accordance with the [http://www.gnu.org/licenses/gpl.txt GPL License Agreement] which requires only that the open-source nature of the project be maintained by all who redistribute it.

We encourage the distribution of hardware for profit or otherwise and invite any users with paparazzi-related hardware to post links and purchasing information on this page. Please use the [[Talk:Get_Hardware&action=edit|Discussion Tab]] to describe your experiences with any of these vendors.

<hr>

<br style="clear:both">
<br style="clear:both">

= [http://aerofu.com [[image:aerofu_logo.png]] Aerofu.com ] =

Low cost Paparazzi hardware from Australia.
Licenced to export to [http://aerofu.com/index.php?main_page=page&id=2 33 countries], including Europe and North America. Recentry restocked with:
<ul>
<li>
[http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=30 Tiny]
and
[http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=31 TWOG]
autopilots.
</li>
<li>
Complete Kits ([http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=48 Tiny] or [http://www.aerofu.com/index.php?main_page=product_info&cPath=11&products_id=49 TWOG] based).
</li>
<li>
[http://www.aerofu.com/index.php?main_page=product_info&cPath=10&products_id=20 PPM Encoders] and [http://www.aerofu.com/index.php?main_page=product_info&cPath=8&products_id=44 IR Sensors] from the Paparazzi project.
</li>
<li>
Inexpensive [http://www.aerofu.com/index.php?main_page=product_info&cPath=7&products_id=12 uBlox LEA-5H GPS units].
</li>
<li>various PCBs</li>
</ul>

<br style="clear:both">

= [http://www.ppzuav.com/ [[Image:Ppzuav.jpg]]] PPZUAV.com [[Image:All ppz autopilots med.jpg|thumb|400px|Paparazzi controllers]] =
<h2>Providing professionally assembled and tested hardware for your Paparazzi Projects since 2007</h2>
<p>
We want to help you get your Paparazzi project off the ground. We have helped hundreds of projects become successful. Confused what to buy? Just give us an email and we will help you decide ('''sales@ppzuav.com''').
</p>
<p>Whatever the part we make all the Paparazzi hardware available either via bare PCBs or fully assembled ready to program. TWOG, Tiny2.11, Umarim, YAPA2 we can make them all in any quantity you require.</p>
<p>
If you do not see what you need just ask. Please eMail with any questions or special requests before you place your orders. We return emails as quickly as possible.
</p>
<p>
Visit the PPZUAZ [https://store.ppzuav.com WebStore] to see the latest offerings.
</p>
<p><b>NEW BUNDLE->:</b>[https://store.ppzuav.com/osc/product_info.php?cPath=2&products_id=144 UmarimLite v2 Bundle]</p>
<br style="clear:both">
<br style="clear:both">

= [http://transition-robotics.com [[Image:Transition_Robotics_Logo.png|100px]] Transition Robotics Inc.] [[Image:LisaM_V2_0_TopView.JPG|thumb|Lisa/M V2.0 top view]][[Image:LisaM_V2_0_BottomView.JPG|thumb|Lisa/M V2.0 bottom view]] =

Transition Robotics Inc. is a young company developing new solutions for and with the Paparazzi UAV platform. Their core product is the [[Image:Quadshot_Logo.jpg|100px|link=http://thequadshot.com|Quadshot]], a VTOL transitioning aircraft.

Beside the Quadshot itself they develop and provide hardware and software that is especially optimized for Paparazzi, such as the Lisa Autopilots, Aspirin IMUs and associated accessories.

They have a shop on their [http://transition-robotics.com Quadshot product page].

As of February 2012, Transition Robotics, Inc. has acquired all IP and Paparazzi related inventory from Joby Robotics. We are thankful to Joby Robotics for their important and faithful support of Paparazzi related hardware projects, and hope to carry on this tradition. Hardware formerly supplied by Joby Robotics may now be purchased at the [http://transition-robotics.com/collections/all Transition Robotics/Quadshot webstore.]

The [http://transition-robotics.com/collections/all TRI/Quadshot Webstore] also stocks pre-crimped Molex Picoblade wires and connector housings.

<br style="clear:both">

= Other =

==[http://www.olimex.com/pcb/ Olimex]==
[[image:pcb-green.jpg|thumb|250px|Olimex PCBs]]
*Fast PCB Prototypes [http://www.olimex.com/pcb/ www.olimex.com/pcb]
*Development Boards [http://www.olimex.com/dev/index.html www.olimex.com/dev/]

<br style="clear:both">
<br style="clear:both">

==[http://www.sparkfun.com Sparkfun]==
[[image:P1030095.jpg|thumb|250px|Sparkfun]]
Sparkfun is a great source of miscellaneous electronics like:
* Development boards
* GPS
* Gyros
* Accelerometers
* Pressure sensors
* Ultrasonic distance sensors
* Temperature/humidity sensors
* USB to Serial converters
* LEDs
* Etc.
They also have an inexpensive PCB service, [http://batchpcb.com/index.php/Products BatchPCB].

<br style="clear:both">
<br style="clear:both">

'''Sparkfun distributors in Europe'''

Incomplete list.
*http://www.lipoly.de/index.php?main_page=index&cPath=880_883&language=en
*http://www.watterott.com/en/SparkFun

== [https://store.diydrones.com/ DIYDrones] ==
Mainly focused on ArduPilot hardware. But carries Paparazzi compatible Telemetry and sensor boards.

'''DIYDrones distributors in Europe'''
*http://www.lipoly.de/index.php?main_page=index&cPath=880_1912 [DE]
*http://www.unmannedtechshop.co.uk/ [UK]
*http://www.buildyourowndrone.co.uk/ [UK]

==u-Blox GPS receivers==

There seems to be a few alternative source of u-Blox GPS out there. They are considerably cheaper then the samples u-Blox offers

If you do order from any of them, please update this page with your feedback.

Here's a few link worth exploring:

*[http://www.navilock.de/produkte/gruppen/13/Boards_und_Module Navilock] (also available on [http://www.amazon.de Amazon.de] by searching for Navilock)
*http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/Antaris-4-Modules.asp (Also [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/u-blox-5-Modules.asp u-blox 5] and [http://www.rfdesign.co.za/pages/5645456/Products/GPS-Products/u-blox-6-Modules.asp u-blox 6] modules avialable)
*http://www.comet.srl.ro/shop/info.html?ID=6195 ( Link error, you can find them in this list: http://www.comet.srl.ro/shop/statements.html?Type=MOD&Subtype=GPS )
*http://www.expedienttech.com/ ( Singapore )
*http://www.csgshop.com/category.php?id_category=16 (US UBLOX MAX-6Q)

==Airspeed Sensors==

Eagle Tree Systems makes a small standalone airspeed sensor that can be connected via i2c. They also sell pitot tubes standalone for other differential pressure sensors. For integration, please see [[Sensors/Airspeed]].
*[http://www.eagletreesystems.com/Standalone/standalone.htm Eagle Tree Systems] (Also available from a number of distributors)

[[Category:Hardware]] [[Category:User_Documentation]]

== DIGI XBee telemetry modules ==
For detailed shopping guide see [Modems]
*http://www.watterott.com/en/Digi (DE EU)
*https://store.diydrones.com/ (US See above for local distributors)
*http://unmannedtechshop.co.uk/UAV-Components/UAV-telemetry (UK)
*http://mouser.com/ (AU and other regions)

= Old vendors =

Here is a list of former paparazzi hardware vendors for reference. They were providing a great service to the Paparazzi community.

* [http://chebuzz.com/paparazzi Chebuzz Pprz] had to move back to US and close his store, [http://aerofu.com/ AeroFu] is carrying on his business.
* [http://jobyrobotics.com Joby Robotics] stock and IP was bought by [http://transition-robotics.com Transition Robotics] that is carrying on their business.

Lisa/M v2.0

2013-03-25T20:07:21Z

Jkg: typo

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div>
<div style="float: right; width: 40%">__TOC__</div>

Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on a STM32 processor for extensive peripheral connection and faster processing.

A number of tutorials are being prepared for getting started with Lisa/M:
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]

Please join us in our quest to make the getting started information even more, eh... informative, by adjusting those pages with your own improvements.

== Features ==

Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].

* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)
* 7 x Analog input channels
* 3 x Generic digital in-/out-puts
* 2 x 3.3V TTL UART (5V tolerant)
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)
* 1 x CAN bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)
* 1 x Micro USB
* 4 x status LEDs with attached test point
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)
* ~34mm x ~60mm x ~10mm
* 4 layers PCB design

With mounted Aspirin IMU has the following additional sensors on board:

* 3 Axis Gyroscope
* 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer MS5611 (as of Aspirin v2.1)

NOTE:
'''Lisa/M has pads for the BMP085 pressure sensor. Lias/M 2 boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1 which has the new MS5611-01BA03 barometric pressure sensor.'''

The drivers for the MS5611-01BA03 are work in progress and are available in the master branch of the Paparazzi codebase. All help with testing and improving the driver are very welcome!

So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.

<gallery widths=200px heights=200px>
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view
</gallery>

== Pinout ==
Pins Name and Type are specified with respect to the Autopilot Board.

<div style="float: right; width: 100%">
[[Image:LisaM_V2_0_top_labeled.png|900px]]
[[Image:LisaM_warning_label.png|200px]]
</div>

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SERVO1/2/3/4/5/6/7/8'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow
|-
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red
|-
|3||GND||PWR||common ground||style="background:black; color:white"|Black
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''JTAG'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|-
|4||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''GPIO'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan
|-
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta
|-
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink
|-
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1 CAN'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red
|-
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red
|-
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange
|-
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow
|-
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green
|-
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange
|-
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow
|-
|5||SCK||Out||SCK||style="background:green; color:white"|Green
|-
|6||SS||Out||SS||style="background:blue; color:white"|Blue
|-
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green
|-
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue
|-
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green
|-
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue
|}

'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. There one has to choose, either use SERVO7 and SERVO8 '''OR''' the use ''second'' I2C bus (I2C1) if that one needs to be used for whatever reason. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. For this to work one must make sure to have the latest Paparazzi sourcecode.

=== LEDs ===
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).
By default the LEDs are use for:
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok
; LED_5, green : not set to anything by default

=== Jumper Configuration ===
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.

The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.

<gallery widths=380px heights=205px>
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers
</gallery>
<br style="clear:both">

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Power Jumper Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP1||SERVO_BUS to V_IN||OPEN||Connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail
|-
|JP2||V_BATT to V_IN||OPEN||Connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail
|-
|JP3||V_IN to +5V||OPEN||Connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail
|-
|JP7||UART3_VCC to +3V3||OPEN||Connects UART3 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''

'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP4||UART2_VCC to V_IN||OPEN||Connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''
|-
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART2 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).

'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||OPEN||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.

=== Powering the Board ===

[[Image:LisaM_warning_label.png|right|200px]]

The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice.

The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.

When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is

<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math>

If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).

== Schematic ==
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3
</gallery>
<br style="clear:both">

== Examples of Airborne Equipment Electrical Connections ==

=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===

[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]

This configuration assumes the ESCs have a battery eliminator circuit (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].

=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===

[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]

This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.

=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Fixedwing, Spektrum Satellite Receivers ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===

[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]

The ESCs have BECs and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example

== R/C Receivers ==

One can use Spektrum DSM2 or compatible receivers as well as traditional PPM receivers. It is even possible to connect two Spectrum or compatible satellite receivers for better redundancy or to improve RC signal reception. Connecting a RC receiver for flying your aircraft in manual mode during setup and test phase is 99% of the cases a must. Therefore the Paparazzi team made it easy to connect one.

=== Using a Spectrum DSM receiver ===

==== Connecting ====

Connect the out signal to the RX pin of UART1 , the GND to GND or receiver and + to the + of Spectrum receiver. Make sure the voltage on the AP board UARD1 pins can be handled by your Spectrum DSM or compatible receiver.

==== Binding ====

It is important to bind your Spectrum DSM receiver with your transmitter '''via your Lisa board''', not in any other way. The way to do this is via fiddly small molex pins. It is advised to make a small bind plug out of a molex connector for this purpose. Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable.

The procedure:

# On the connector ANALOG1 have a wire between the GND pin ADC1, located in the middle of the board
# Power up your autopilot board
# Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter
#:Wait.. all light of receiver blink then go steady
# Let go of your transmitter bind button
# Power off your Lisa Board
# remove the wire between GND and ADC1 pins
# Repower your board, if you have servos connected and wiggle the RC transmitter sticks some servos should move

That all, you are done. Only needs to be done '''once''' for your receiver.

=== Using a PPM receiver ===

Using a PPM receiver, a so called '''PPM sum stream''' input is possible. [[RC_Receivers_and_Radios#PPM_Based_Systems | To make it work, you need a PPM sum stream out capable receiver. Find out more following this link]]

==== Connecting ====

Connect the PPM out signal to the RX pin of UART1.

Make sure put this in your airframe file in your AP target section.

...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>
</subsystem>
...

===== Alternative =====

However if in the case you want to use the RX or UART1 for something else, there is an option to connect the receiver to a servo pin. Yes, that's right, a servo connector is used for receiver PPM stream '''input'''. The default pin number to capture the PPM sum stream is via servo connector six(6)

If you connect the PPM ou capable receiver that way make sure to put this in your airframe file in your AP target section:

...
<subsystem name="radio_control" type="ppm">
<configure name="RADIO_CONTROL_PPM_PIN" value="SERVO6"/>
</subsystem>
...

If you do not have or cannot modify a receiver to a ''PPM out'' able receiver, a [[PPM_Encoder | PPM encoder board]] can be used to avoid opening your receiver for PPM out modification.

== Extras ==

=== UART I/O ===

UART pins can also be used as general purpose I/O, this might come in handy in case all other inputs or your AP board are in use.

=== USB as UART1TX + hardware flow control===

[[File:Lisam-usb-uart1.jpg]]

The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respactively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line.

If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level treshold of the microcontroller, causing strange behaviour.

For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)
CTS, most blue, on pin 9 of the Xtend

<gallery widths=380px heights=205px>
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.
</gallery>

== PCB ==

=== Gerber & Drill Files ===

'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

== Assembly ==

To create and assemble a board oneself is possible. It ake some skills ofcouse. In case you wan to follow that path you need the desing. You came to the right place here is the info to get the needed files;

===Components Layout===

''[[Lisa/M_v2.0#Get the design|Get the design]]''

Need some top and bottom of board images and line drawings here.

=== Bill Of Material ===

'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''[[Lisa/M_v2.0#Get the design|Get the design]]''

== PCB and assembled boards suppliers ==

To difficult to creat your own AP board, understandable, thus pre made board available via [[Get_Hardware|Get Hardware]] page... hopefully :)

== Mechanical Dimensions ==

[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]

The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).

== Get the design ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material

== Uploading new software ==
New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain the [[Luftboot]] bootloader. All Lisa/M 2.0 from Transition Robotics Inc. come with luftboot already in the board.

An alternative to get your firmware in the board is by using a JTAG connector connected via the 10-pin Samtec connector that is available on the board.

See the [[FirmwareFlashing]] page for an overview of different methods to upload new software to your autopilot.

=== Using luftboot ===
'''This is the default FLASH_MODE for Lisa/M v2.0''', it could be explicitly selected by adding
:<source lang="xml"><configure name="FLASH_MODE" value="DFU"/></source>
to the firmware section of your airframe file. Make sure to set Lisa/M 2.0 as it's target board.

Once USB is plugged in, the board automatically goes to bootloader mode and the status LEDs cycle up and down:

[[File:Luftboot.gif|320px]]

If you have trouble entering the bootloader mode or want to upload/update the bootloader itself, see the [[Luftboot]] page.

=== Using JTAG ===
You still can use a [[JTAG|JTAG adapter]] for [[FirmwareFlashing#JTAG|flashing]] and [[DevGuide/JTAG-Debug|debugging]] your paparazzi firmware. To use [[FirmwareFlashing#JTAG|JTAG flashing]] configure the ''FLASH_MODE'' in your firmware section:
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source>
Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source>

Then press upload as normal...

=== Serial Firmware Upload ===
Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten [[Luftboot]] accidentally and don´t have access to [[JTAG]].<br/>
Either set the flash mode in the target section of the airframe configuration:
:<source lang="xml"><configure name="FLASH_MODE" value="SERIAL"/></source>
or add it to the commandline invocation:
make AIRCRAFT=<aircraftname> ap.upload FLASH_MODE=SERIAL

Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads

Now a boot sequence works as follows:
#BOOT1 has to be set to 3.3V by use of a jumper cable
#Connect a 3,3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS
#Power the board and activate the bootloader program

== Detailed Hardware Revision History ==

=== Changes Between LISA v1.1 and v2.0 ===

* Lots of silkscreen improvements
* Added attributes to all parts to make the usage of bom-ex ulp possible.
* Improved routing to allow teardropping
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.
* Added pullups on all UART RX lines to prevent undesired floatation.
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.
* ...

== Hardware Change Requests ==

If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.

* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain.
** A: Using a MS5611 is possible through using a Aspirin v2.1 board

* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.

* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.

* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.
[[Category:Lisa]] [[Category:User_Documentation]]

Lia

2013-03-25T20:02:27Z

Jkg: corrected CAN tranciever info

'''Lia''' is a lower cost version of [[Lisa/M]] first developed for inclusion with the [http://wiki.thequadshot.com/wiki/The_Mocha Quadshot Mocha].

== Differences from Lisa/M ==

* 0.1" pitch connectors instead of molex picoblade
* No CAN transceiver (footprint still present just not populated) on [http://www.transition-robotics.com Transition Robotics]serial numbers LI1-001 through LI1-200 (populated on serial numbers ≥LI1-201)
* No I2C2 level shifter (footprint still present just not populated)
* No 5V voltage regulator (footprint still present just not populated)
* No JTAG connector (footprint still present just not populated)
* Added servo power inline resistors (by default 0 ohm but can be changed to higher value for balancing the linear voltage regulators of the motor controllers)

== Pictures ==

<gallery>
Image:Lia_1.1_top.jpg|Lia V1.1 top side
Image:Lia_1.1_bottom.jpg|Lia V1.1 bottom side
Image:Lia_1.1_aspirin_bottom.jpg|Lia V1.1 bottom side with Aspirin 2.1 nomag nobaro placed.
</gallery>

== Jumper Configuration ==
There are a number of jumpers on Lia used to configure voltage levels and power input. Their locations and functions are identical to those on the Lisa/M v2.0.<br/>
See the [[Lisa/M_v2.0#Jumper_Configuration|Jumper Configuration section on the Lisa/M v2.0 page]].

Note that the default states of JP8 and JP9 are reversed with respect to the defaults of Lisa/M v2.0; that is:

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Lia UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||OPEN||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

Lia

2013-03-23T00:19:01Z

Jkg: re-added differing default jumper config

'''Lia''' is a lower cost version of [[Lisa/M]] first developed for inclusion with the [http://wiki.thequadshot.com/wiki/The_Mocha Quadshot Mocha].

== Differences from Lisa/M ==

* 0.1" pitch connectors instead of molex picoblade
* No CAN transceiver (footprint still present just not populated)
* No I2C2 level shifter (footprint still present just not populated)
* No 5V voltage regulator (footprint still present just not populated)
* No JTAG connector (footprint still present just not populated)
* Added servo power inline resistors (by default 0 ohm but can be changed to higher value for balancing the linear voltage regulators of the motor controllers)

== Pictures ==

<gallery>
Image:Lia_1.1_top.jpg|Lia V1.1 top side
Image:Lia_1.1_bottom.jpg|Lia V1.1 bottom side
Image:Lia_1.1_aspirin_bottom.jpg|Lia V1.1 bottom side with Aspirin 2.1 nomag nobaro placed.
</gallery>

== Jumper Configuration ==
There are a number of jumpers on Lia used to configure voltage levels and power input. Their locations and functions are identical to those on the Lisa/M v2.0.<br/>
See the [[Lisa/M_v2.0#Jumper_Configuration|Jumper Configuration section on the Lisa/M v2.0 page]].

Note that the default states of JP8 and JP9 are reversed with respect to the defaults of Lisa/M v2.0; that is:

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Lia UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||OPEN||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

JTAG

2013-03-12T19:08:33Z

Jkg: grammar/spelling

=Introduction=
A JTAG interface is designed for on-chip debugging. It is used to program that do not have a means to upload software via USB already. For short; if you want to upload your own software or want to do serious paparazzi development work, the you need a cable like this.

=JTAG Cable overview=
There are multiple Paparazzi-compatible devices available that support JTAG. Below you find a list of JTAG devices that you can use in combination with e.g. a Paparazzi Lisa/M board.

== FLOSS JTAG ==

The FLOSS JTAG is based on an FTDI chip that allows two simultaneous USB connections, which means that FLOSS JTAG allows JTAG and UART/COM connections.

Let's take a look at upper side of the board. It contains JTAG connector (which is connected on photo) and two sets of RX/TX LEDs for JTAG and UART/COM interface separately. The JTAG connector is 2x5 pins, 0.05-inch pitch, and is compatible with the Samtec FFSD-05-D-06.00-01-N-RW-R ribbon cable.

[[Image:Jtag-up.jpg]]

On the other side of the board there is 4 pin UART/COM connector, which contains (from top to bottom in the image below): Ground (black), RX (orange), TX (yellow), and +5V (red)

[[Image:Jtag-down.jpg]]

Usage of board is pretty simple: JTAG can be used to upload firmware into the board and/or repair board with broken bootloader, and UART/COM interfaced can be used to make "COM port style" connection to the board. COM connection can be used for example for telemetry debug.

More info available on the [http://randomprojects.org/wiki/Floss-JTAG randomprojects.org wiki].

== Black Magic Probe ==

[[Image:BMPM_1_top.jpg|500x500px]]

[[Image:BMPM_1_bottom.jpg|500x500px]]

Full info about the Black Magic Probe is available at the [http://www.blacksphere.co.nz/main/blackmagic Black Sphere Technology website].

To use Black Magic Probe instead of FLOSS-JTAG or Luftboot, append the following string to the upload command:

On Linux:
FLASH_MODE=JTAG BMP_PORT=/dev/ttyACM0
On Mac OS:
FLASH_MODE=JTAG BMP_PORT=/dev/cu.usbmodem<serial>

if this all makes no sense and you need another way to upload take a look at this section http://paparazzi.enac.fr/wiki/Lisa/M_v2.0#Using_JTAG

=== Benefits ===

There are good reasons to use the Black Magic Probe Mini instead of FLOSS-JTAG:

*Lower cost
*No need for OpenOCD as BMPM has a built in GDB server
*Orders of magnitude faster as all the high speed protocol logic happens on the built-in STM32
*Supports Serial Wire Debug (SWD)
*Supports tracing using the SWD trace pin
*No need for loading and unloading of FTDI drivers on Mac OS X

===How to use Debugging features===

A page describing on how to start debugging using the BlackMagic probe cable can be found here JTAG: [[DevGuide/JTAG-Debug]]

===Upgrade BMP firmware===

To upgrade the brain of your Black Magic Probe, a.k.a. its firmware, use these commands on your command line:

$ git clone git://blackmagicdebug.git.sourceforge.net/gitroot/blackmagicdebug/blackmagicdebug
$ cd blackmagicdebug/src
$ make CROSS_COMPILE=~/sat/bin/arm-none-eabi-
../scripts/stm32_mem.py blackmagic.bin

== FT2232 Dev Board ==

Use ftdi prog to change the Description String into: FLOSS-JTAG

[[File:AlternativeFlossJtag.png]]

= Related articles =
* [[DevGuide/JTAG-Debug]] - Developer's guide JTAG debugging
* [[Dev/Debugging]] - General debugging information

[[Category:Hardware]] [[Category:Software]] [[Category:Developer_Documentation]]

----
(*(oo)*), ,~

JTAG

2013-02-13T22:21:17Z

Jkg: added verbiage to make it clearer which wire is which

=Introduction=
A JTAG interface is designed for on-chip debugging. It is used to program that do not have a means to upload software via USB already. For short; if you want to upload your own software or want to do serious paparazzi development work, the you need a cable like this.

=JTAG Cable overview=
There are multiple Paparazzi-compatible devices available that support JTAG. Below you find a list of JTAG devices that you can use in combination with e.g. a Paparazzi Lisa/M board.

== FLOSS JTAG ==

The FLOSS JTAG is based on an FTDI chip that allows two simultaneous USB connections, which means that FLOSS JTAG allows JTAG and UART/COM connections.

Let's take a look at upper side of the board. It contains JTAG connector (which is connected on photo) and two sets of RX/TX LEDs for JTAG and UART/COM interface separately. The JTAG connector is 2x5 pins, 0.05-inch pitch, and is compatible with the Samtec FFSD-05-D-06.00-01-N-RW-R ribbon cable.

[[Image:Jtag-up.jpg]]

On the other side of the board there is 4 pin UART/COM connector, which contains (from top to bottom in the image below): Ground (black), RX (orange), TX (yellow), and +5V (red)

[[Image:Jtag-down.jpg]]

Usage of board is pretty simple: JTAG can be used to upload firmware into the board and/or repair board with broken bootloader, and UART/COM interfaced can be used to make "COM port style" connection to the board. COM connection can be used for example for telemetry debug.

More info available on the [http://randomprojects.org/wiki/Floss-JTAG randomprojects.org wiki].

== Black Magic Probe ==

[[Image:BMPM_1_top.jpg|500x500px]]

[[Image:BMPM_1_bottom.jpg|500x500px]]

Full info about the Black Magic Probe is available at the [http://www.blacksphere.co.nz/main/blackmagic Black Sphere Technology website].

To use Black Magic Probe instead of FLOSS-JTAG or Luftboot, append the following string to the upload command:

On Linux:
FLASH_MODE=JTAG BMP_PORT=/dev/ttyACM0
On Mac OS:
FLASH_MODE=JTAG BMP_PORT=/dev/cu.usbmodem<serial>

if this all makes no sense and you need another way to upload take a look at this section http://paparazzi.enac.fr/wiki/Lisa/M_v2.0#Using_JTAG

=== Benefits ===

There are good Reasons to use Black Magic Probe Mini instead of FLOSS-JTAG: It just has much more options and cost less.

*No need for OpenOCD as BMPM has a built in GDB server
*Orders of magnitude faster as all the high speed protocol logic happens on the built-in STM32
*Supports Serial Wire Debug (SWD)
*Supports tracing using the SWD trace pin
*No need for loading and unloading of FTDI drivers on Mac OS X

===How to use Debugging features===

A page describing on how to start debugging using the BlackMagic probe cable can be found here JTAG: [[DevGuide/JTAG-Debug]]

===Upgrade BMP firmware===

To upgrade your the brain of your Black Magic Probe, a.k.a. firmware use thes commands on you command line

$ git clone git://blackmagicdebug.git.sourceforge.net/gitroot/blackmagicdebug/blackmagicdebug
$ cd blackmagicdebug/src
$ make CROSS_COMPILE=~/sat/bin/arm-none-eabi-
../scripts/stm32_mem.py blackmagic.bin

== FT2232 Dev Board ==

Use ftdi prog to change the Description String into: FLOSS-JTAG

[[File:AlternativeFlossJtag.png]]

= Related articles =
* [[DevGuide/JTAG-Debug]] - Developer's guide JTAG debugging
* [[Dev/Debugging]] - General debugging information

[[Category:Hardware]] [[Category:Software]] [[Category:Developer_Documentation]]

----
(*(oo)*), ,~

Lisa/M v2.0

2012-11-29T18:59:33Z

Jkg: added more info about power

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div>
<div style="float: right; width: 40%">__TOC__</div>

Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on the STM32 for improved peripherals and faster processing.

A number of tutorials are being prepared for getting started with Lisa/M:
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]

== Hardware Revision History ==

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
!''Version #''!!''Release Date''!!''Release Notes''
|-
|v2.0(current)||03/2012||Updated Production Release
|-
|v1.1||MM/YYYY||Updated Prototype
|-
|v1.0||MM/YYYY||Initial Production Release
|-
|v0.1||MM/YYYY||Initial prototype of Lisa/M
|}
For detailed hardware revision history, please [[Lisa/M#Detailed_Hardware_Revision_History | see below]].

== Features ==

Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].

* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)
* 7 x Analog input channels
* 3 x Generic digital in-/out-puts
* 2 x 3.3V TTL UART (5V tolerant)
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)
* 1 x CAN bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)
* 1 x Micro USB
* 4 x status LEDs with attached test point
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)
* ~34mm x ~60mm x ~10mm
* 4 layers PCB design

With mounted Aspirin IMU has the following additional sensors on board:

* 3 Axis Gyroscope
* 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (as of Aspirin v2.1r1)

'''Lisa/M has pads for the BMP085 pressure sensor. Boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1r1 which has the new MS5611-01BA03 barometric pressure sensor.'''

The drivers for the MS5611-01BA03 are work in progress and will be available in the master branch of the Paparazzi codebase soon. All help with testing and improving the driver are very welcome!

So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.

<gallery widths=200px heigths=200px>
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view
</gallery>

== Pinout ==
Pins Name and Type are specified with respect to the Autopilot Board.

<div style="float: right; width: 100%">
[[Image:LisaM_V2_0_top_labeled.png|900px]]
[[Image:LisaM_warning_label.png|200px]]
</div>

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SERVO1/2/3/4/5/6/7/8'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow
|-
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red
|-
|3||GND||PWR||common ground||style="background:black; color:white"|Black
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''JTAG'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|-
|4||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''GPIO'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan
|-
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta
|-
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink
|-
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1 CAN'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red
|-
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red
|-
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange
|-
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow
|-
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green
|-
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange
|-
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow
|-
|5||SCK||Out||SCK||style="background:green; color:white"|Green
|-
|6||SS||Out||SS||style="background:blue; color:white"|Blue
|-
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green
|-
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue
|-
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green
|-
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue
|}

'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. There one has to choose, either use SERVO7 and SERVO8 '''OR''' the use ''second'' I2C bus (I2C1) if that one needs to be used for whatever reason. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. This is recently fixed, so for this to work one must make sure to have the latest Paparazzi sourcecode.

=== LEDs ===
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).
By default the LEDs are use for:
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok
; LED_5, green : not set to anything by default

=== Jumper Configuration ===
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.

The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.

<gallery widths=380px heights=205px>
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers
</gallery>
<br style="clear:both">

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Power Jumper Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP1||SERVO_BUS to V_IN||OPEN||Connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail
|-
|JP2||V_BATT to V_IN||OPEN||Connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail
|-
|JP3||V_IN to +5V||OPEN||Connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail
|-
|JP7||UART3_VCC to +3V3||OPEN||Connects UART3 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''

'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP4||UART2_VCC to V_IN||OPEN||Connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''
|-
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART2 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).

'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||OPEN||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.

=== Powering the Board ===

[[Image:LisaM_warning_label.png|right|200px]]

The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice.

The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.

When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is

<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math>

If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).

== Schematic ==
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3
</gallery>
<br style="clear:both">

== Examples of Airborne Equipment Electrical Connections ==

=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===

[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]

This configuration assumes the ESCs have a battery eliminator circuit (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].

=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===

[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]

This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.

=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Fixedwing, Spektrum Satellite Receivers ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]

This configuration assumes the ESC has a BEC and provides 5 volts on its 5V pin. Closing JP1 powers Lisa/M and the attached accessories.

=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===

[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]

The ESCs have BECs and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example

=== R/C Receivers ===
One can use traditional PPM receivers as wel as Spektrum DSM2 or compatible receivers for flying your aircraft in manual mode during setup and test phase. The Lisa M can direcly connect to a Spectrum DSM2 satellite receiver. It is even possible to connect two satellite receivers for better redundancy or RC reception. It is

==== Bind your Spectrum DSM receiver ====

It is important to bind your receiver with your transmitter '''via your Lisa board''', not in any other way. The way to do this is via fiddly small molex pins

Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable

* On the connector ANALOG1 have a wire between the GND pin ADC1, located in the middle of the board
* Power up your autopilot board
* Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter
* Wait.. all light of receiver blink then go steady
* Let go of your transmitter bind button
* Power off your Lisa Board
* remove the wire between GND and ADC1 pins
* Repower your board, if you have servos connected and wiggle the RC transmitter sticks some sould move

That all, you are done. Only needs to be done '''once''' for your receiver.

=== PPM sum stream input ===

The default pin to capture the PPM sum stream is servo channel 6, but this can be reconfigured to the RX of UART1. To use ppm for your radio, put this in your airframe file in your ap target.

<subsystem name="radio_control" type="ppm">

<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>

</subsystem>

=== Extra Input ===

Also UART pins can be used as general purpose I/O to be used for PPM input. By default connect your PPM out able receiver to servo pin 6. If you do not have or cannot create a PPM out able receiver, additionally a [[PPM_Encoder | PPM encoder board]] can be used to avoid receiver hardware modification.

=== Use USB as UART1TX + hardware flow control ===
[[File:Lisam-usb-uart1.jpg]]

The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respactively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line.

If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level treshold of the microcontroller, causing strange behaviour.

For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)
CTS, most blue, on pin 9 of the Xtend

<gallery widths=380px heights=205px>
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.
</gallery>

== PCB ==

=== Gerber & Drill Files ===

'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''NOT YET AVAILABLE BUT SEE [[Lisa/M#Downloads|Downloads]]''
Need some generated gerbers and drill files here.

== Assembly ==

===Components Layout===

''NOT YET AVAILABLE BUT SEE [[Lisa/M#Downloads|Downloads]]''
Need some top and bottom of board images and line drawings here.

=== Bill Of Material ===

'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''NOT YET AVAILABLE BUT SEE [[Lisa/M#Downloads|Downloads]]''
<br>
<br>

== PCB and assembled boards suppliers ==

Available on [[Get_Hardware|Get Hardware]] page, hopefully :)

== Mechanical Dimensions ==

[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]

The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).

== Downloads ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material

== Uploading new software ==

New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain a "luftboot" bootloader. All Lisa/M 2.0 from Transition Robotics Inc. come with luftboot already in the board.

An alternative to get your software/flightplane in the board is by using a JTAG connector connected via the 10-pin Samtec connector that is available on the board.

=== Using luftboot ===

First make sure you '''update to the latest stable Paparazzi version''', then you will have support for this bootloader method. By default use the associated DFU loader to program the firmware. Make sure that your airframe file is set to use Lisa/M 2.0 as it's target board.

Currently Paparazzi firmware does not contain the needed software to switch into bootloader mode using software only by USB. To circumvent this shortcoming, you need a small cable to force the bootloader to run. This cable should bridge pin GND and ADC2. Make sure you do not shortcircuit your board.

Once your "Boot mode connector" is inserted, connect the Lisa/M to the PC via a micro-usb cable and it should start in bootloader mode. If the status LEDs cycle up and down, it is in booatloader mode, ready to receive your new flightplan and autopilot control software upgdate.

Note that all of this won't be necessary in the future once a working USB stack stub is added to the latest Paparazzi.

[[File:Luftboot.gif|320px]]

You should disconnect the "Boot mode connector" after enforcing the bootloader. Pressing upload in the Paparazzi Center should now upload new code onto the board.

In the rare case you somehow have removed the luftboot bootloader, you can re-insert this Boatloader by following the instructions of ''Uploading the Paparazzi USB Bootloader''

=== Uploading the Paparazzi USB Bootloader ===

Reading or performing these steps is not needed if you got your Lisa/M 2.0 from Transition Robotics Inc., these boards come with luftboot already preloaded. But in the case you made a board yourself or somehow do not have a preloaded bootloader, or it is gone because of unknown cause, then read this section. It describes the process on how to upload/recover the luftboot bootloader on your Lisa/M 2.0.

[https://github.com/paparazzi/luftboot Luftboot] is a Paparazzi-compatible bootloader for STM32-based autopilots.
Depending on your vendor, your Lisa/M may already come with a bootloader, in which case you should skip to [[Lisa/M#Uploading new software]]

==== Required components ====

*Floss-JTAG debugger or Blacksphere mini JTAG
*Lisa/M board
*PC

==== Procedure ====
<ol>
<li>
Get the [https://github.com/paparazzi/luftboot Luftboot sourcecode from Github] via
<source lang=bash>git clone https://github.com/paparazzi/luftboot.git</source>
</li>
<li>
Change directory into the luftboot/src folder
<source lang=bash>cd ./luftboot/src</source>
</li>
<li>
Build luftboot
<source lang=bash>make clean && make</source>
</li>
<li>
Flash the Lisa/M
Attach the floss-jtag unit to the PC and connect it to the Lisa/M via the black connector.
Power the Lisa/M (easiest way is to connect to the PC via a micro-USB cable).
<source lang=bash>make flash DEV_SERIAL="LM2-ser"</source>
where "ser" stands for the serial number of your Lisa/M. So for example if you have lisa/m with the serial number 020 this would be:
<source lang=bash>make clean && make flash DEV_SERIAL="LM2-020"</source>
</li>
</ol>

==== Connection Diagram ====

==== Boot Sequence ====

* Luftboot
** Check if ADC2 is configured as output pull down indicating software bootloader request
*** '''If ADC2 output pull down:''' initialize usb and stay in bootloader mode
** Setting the ADC2 pin to input pull up
** Checking if the ADC2 pin is low
*** '''If ADC2 low:''' initialize USB and stay in bootloader mode
*** '''If ADC2 high:''' check if there is a payload at 0x8002000
**** '''If payload detected:''' set vector table pointer to be at 0x8002000 and jump to the reset handler of the payload
**** '''If payload not detected:''' initialize USB and stay in bootloader mode

==== Luftboot USB permissions ====

[[Installation/Linux#Udev_rules|Copy the udev-rules file]] is needed for the upload software to get permission to use this hardware in your PC for uploading.
For short: the Python program "stm32_mem.py" needs permission to write to the the Luftboot USB device. If you do not have set this rules already you get an error message, which explanation what is wrong is quite obscure due to the way python-libusb accesses the device.

=== Using JTAG ===
If you are using the Lisa/M 2.0 target board you still can use JTAG for programming and debugging your paparazzi firmware. To use JTAG flashing configure the ''FLASH_MODE'' in your firmware section:
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source>
Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source>

* [[JTAG]] description;
* General [[Dev/Debugging|debugging information]];
* [[DevGuide/JTAG-Debug|JTAG usage]], includes Eclipse uplink tutorial.

==== Quick JTAG Upload Guide ====
# Connect floss-jtag to Lisa via the cortex cable (little black socket)
# Attach the UART port on the bottom of the floss-jtag to UART2 on the Lisa.
# Plug in USB port of the floss jtag
# Plug in USB port of the Lisa
# Make sure your airframe uses the <target name="ap" board="lisa_m_2.0"> definition
# Click Build, wait until complete, then click Upload. You should see the following towards the end:
{{{
...
Info : device id = 0x10016418
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 1 with 7972 bytes
wrote 152576 bytes from file src/paparazzi/var/Hexa_LisaL/ap/ap.elf in 7.498179s (19.871 KiB/s)
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
shutdown command invoked
}}}
# Run Flight USB-serial at the baud rate you need (default 57600 for rotorcraft)
# You may need to change the device to /dev/ttyUSB1, and 'Redo' the Data Link

=== Serial Firmware Upload ===

Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten Luftboot accidentally and don´t have access to JTAG.

Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads

Now a boot sequence works as follows:
#BOOT1 has to be set to 3.3V by use of a jumper cable
#Connect a 3,3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS
#Power the board and activate the bootloader program

The according bootloader script can be found at :
[https://github.com/jsnyder/stm32loader stm32loader from Github]
<source lang=bash>git clone https://github.com/jsnyder/stm32loader.git</source>

To reload Luftboot, upload luftboot.bin

Serial upload can also be used directly from paparazzi Center by adapting the right path in [https://github.com/paparazzi/paparazzi/blob/dev/conf/Makefile.stm32 Makefile.stm32] for the LOADER argument and setting

<define name="FLASH_MODE" value="SERIAL"/>

in the target section of the airframe configuration.

== Detailed Hardware Revision History ==

=== Changes Between LISA v1.1 and v2.0 ===

* Lots of silkscreen improvements
* Added attributes to all parts to make the usage of bom-ex ulp possible.
* Improved routing to allow teardropping
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.
* Added pullups on all UART RX lines to prevent undesired floatation.
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.
* ...

== Hardware Change Requests ==

If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.

* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain.
** A: Using a MS5611 is possible through using a Aspirin v2.1 board

* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.

* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.

* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.
[[Category:Lisa]] [[Category:User_Documentation]]

Lisa/M v2.0

2012-11-29T18:51:13Z

Jkg: added more info about power

<div style="float: right; width: 15%"><categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Autopilots</categorytree></div>
<div style="float: right; width: 45%; overflow: hidden">[[Image:LisaM_V2_0_TopView.JPG|right|500px|Lisa/M V2.0 top view]]</div>
<div style="float: right; width: 40%">__TOC__</div>

Lisa/M is a small, general purpose autopilot designed with flexibility across multiple applications in mind. Small weight and size, with (optional) integrated [[AspirinIMU | Aspirin IMU]] and full size 0.1" servo headers make the Lisa/M suitable for both fixed-wing and rotorcraft vehicles. This autopilot is based on the STM32 for improved peripherals and faster processing.

A number of tutorials are being prepared for getting started with Lisa/M:
* [[Lisa/M/Tutorial/FixedWing|Fixedwing tutorial]]
* [[Lisa/M/Tutorial/RotorCraft|Rotorcraft tutorial]]

== Hardware Revision History ==

{|border="1" cellspacing="0" style="text-align:center" cellpadding="6"
!''Version #''!!''Release Date''!!''Release Notes''
|-
|v2.0(current)||03/2012||Updated Production Release
|-
|v1.1||MM/YYYY||Updated Prototype
|-
|v1.0||MM/YYYY||Initial Production Release
|-
|v0.1||MM/YYYY||Initial prototype of Lisa/M
|}
For detailed hardware revision history, please [[Lisa/M#Detailed_Hardware_Revision_History | see below]].

== Features ==

Lisa/M is based on the 64 pins STM32F105RCT6 [http://www.st.com/internet/mcu/product/221023.jsp connectivity line family] processor featuring 64k of RAM and 256k of FLASH. All the pins are exposed, providing access to the complete set of the STM32 peripherals.
NOTE: This MCU is different from LISA/L. Lisa/L is based on the 64 pins STM32F103RE processor featuring 64k of RAM and 512k of FLASH, which is part of the [http://www.st.com/internet/mcu/product/164485.jsp high-density performance line family].

* STM32 microcontroller [http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00220364.pdf STM32F105RCT6 datasheet] with 256kB flash and 64kB RAM
* Pressure sensor [http://www.bosch-sensortec.com/content/language1/html/3477.htm BMP085] (optional as of 08/2012)
* 7 x Analog input channels
* 3 x Generic digital in-/out-puts
* 2 x 3.3V TTL UART (5V tolerant)
* 8 x Servo PPM outputs (only 6 if second I2C (I2C1) bus in use)
* 1 x CAN bus
* 1 x [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface SPI] bus
* 1 x [http://en.wikipedia.org/wiki/I2c I<sup>2</sup>C] bus (2 x when using only the first 6 Servo PPM outputs)
* 1 x Micro USB
* 4 x status LEDs with attached test point
* 10.8 grams (0.4 oz) (with Aspirin IMU mounted)
* 9.9 grams (0.35 oz) (without Aspirin IMU mounted)
* ~34mm x ~60mm x ~10mm
* 4 layers PCB design

With mounted Aspirin IMU has the following additional sensors on board:

* 3 Axis Gyroscope
* 3 Axis Accelerometer
* 3 Axis Magnetometer
* Barometer (as of Aspirin v2.1r1)

'''Lisa/M has pads for the BMP085 pressure sensor. Boards made before August 2012 had the BMP085 sensor mounted. Boards made after August 2012 do not have the sensor mounted as they are designed to be used with Aspirin 2.1r1 which has the new MS5611-01BA03 barometric pressure sensor.'''

The drivers for the MS5611-01BA03 are work in progress and will be available in the master branch of the Paparazzi codebase soon. All help with testing and improving the driver are very welcome!

So, except for a GPS unit you have all necessary sensors for full attitude and altitude stabilization in an extremely small package.

<gallery widths=200px heigths=200px>
Image:LisaM_V2_0_TopView.JPG|Lisa/M V2.0 top view
Image:LisaM_V2_0_BottomView.JPG|Lisa/M V2.0 bottom view
</gallery>

== Pinout ==
Pins Name and Type are specified with respect to the Autopilot Board.

<div style="float: right; width: 100%">
[[Image:LisaM_V2_0_top_labeled.png|900px]]
[[Image:LisaM_warning_label.png|200px]]
</div>

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SERVO1/2/3/4/5/6/7/8'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||SERVOx||OUT||Servo signal (PWM)(See Note 1 below)||style="background:Yellow; color:black"|Yellow
|-
|2||SV||PWR||Servo Bus Voltage Rail (conf w/ JP1)||style="background:red; color:white"|Red
|-
|3||GND||PWR||common ground||style="background:black; color:white"|Black
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''JTAG'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||JTAG Debug Header (Pin 1 is +3V3)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2||V_IN||PWR||UART Voltage (conf w/ JP6 and JP7)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART3 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART3 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1/5'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|3||RX1||IN||USART1 Serial Input (3.3V level)(Pullup to Pin 2 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|-
|4||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|5|| +3V3||PWR||3.3V Rail from autopilot (conf w/ JP8 and JP9)||style="background:Red; color:white"|Red
|-
|6||RX5||IN||UART5 Serial Input (3.3V level)(Pullup to Pin 5 voltage)(5V tolerant)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''GPIO'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||PC12||I/O||GPIO, connected to PC12 (5V tolerant)||style="background:#FDC579; color:black"|Dark Tan
|-
|5||TRST||I/O||JTAG_TRST (also connected to LED1 cathode)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC4||I/O||by default connected to LED_4 cathode (Remove LED/resistor to use as ADC4)||style="background:magenta; color:white"|Magenta
|-
|5||ADC6||I/O||by default connected to LED_3 cathode (Remove LED/resistor to use as ADC6)||style="background:#FFA1B2; color:black"|Pink
|-
|6||BOOT0||I/O||BOOT0||style="background:grey; color:black"|Grey
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''USB'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||N/A||N/A||USB (The USB connections are also available as 0.05" (1.27mm) through hole pads underneath the GPIO header)||style="background:white; color:black"|None
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C1 CAN'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| V_BATT||PWR||V_BATT Bus on autopilot, voltage divider for V_BAT_MEAS, (conf w/ JP2 to connect to V_IN)||style="background:Red; color:white"|Red
|-
|3|| V_IN||PWR||Connected to autopilot voltage regulator inputs (conf w/ JP1, JP2 and JP3)||style="background:Red; color:white"|Red
|-
|4||CANL||I/O||CANL (5V level)||style="background:orange; color:white"|Orange
|-
|5||CANH||I/O||CANH (5V level)||style="background:yellow; color:black"|Yellow
|-
|6||SCL||I/O||SCL (5V level)(See Note 1 below)||style="background:green; color:white"|Green
|-
|7||SDA||I/O||SDA (5V level)(See Note 1 below)||style="background:blue; color:white"|Blue
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''SPI1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||MOSI||Out||MOSI||style="background:orange; color:white"|Orange
|-
|4||MISO||In||MISO||style="background:yellow; color:black"|Yellow
|-
|5||SCK||Out||SCK||style="background:green; color:white"|Green
|-
|6||SS||Out||SS||style="background:blue; color:white"|Blue
|-
|7||DRDY||I/O||DRDY||style="background:#FDC579; color:black"|Dark Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''ANALOG1'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3|| +5V||PWR||5V Rail from autopilot||style="background:Red; color:white"|Red
|-
|4||ADC1||In||ADC1 (or LED_6 if populated)||style="background:green; color:white"|Green
|-
|5||ADC2||In||ADC2 (or LED_7 if populated)||style="background:blue; color:white"|Blue
|-
|6||ADC3||In||ADC3 (or LED_8 if populated)||style="background:#FED6B1; color:black"|Light Tan
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||UART Voltage (conf w/ JP4 and JP5)||style="background:Red; color:white"|Red
|-
|3||TX||OUT||USART2 Serial Output (3.3V level)||style="background:Yellow; color:black"|Yellow
|-
|4||RX||IN||USART2 Serial Input (3.3V level)('''NOT 5V TOLERANT''')(Pullup to Pin 2 voltage)||style="background:Orange; color:white"|Orange
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''I2C2'''
!width="7%"|''Pin #''!!width="10%"|''Name''!!width="10%"|''Type''!!''Description''!!width="5%"|''Color''
|-
|1||GND||PWR||common ground||style="background:black; color:white"|Black
|-
|2|| +3V3||PWR||3.3V Rail from autopilot||style="background:Red; color:white"|Red
|-
|3||SCL||I/O||SCL (3.3V level)||style="background:green; color:white"|Green
|-
|4||SDA||I/O||SDA (3.3V level)||style="background:blue; color:white"|Blue
|}

'''NOTE 1''': SERVO7 and SERVO8 are directly connected to I2C1_SCL and I2C1_SDA lines. There one has to choose, either use SERVO7 and SERVO8 '''OR''' the use ''second'' I2C bus (I2C1) if that one needs to be used for whatever reason. To use the servos 7 and 8 just set the <define name="USE_SERVOS_7AND8"/> in your airframe file and you are good to go. This is recently fixed, so for this to work one must make sure to have the latest Paparazzi sourcecode.

=== LEDs ===
Lisa/M 2.0 has 5 LEDS (+1 power LED). There are 3 additional LEDs (LED_6, LED_7, LED_8) that are not populated by default (in favor of using ADC1-3 on the ANALOG1 connector).
By default the LEDs are use for:
; LED_1, red: ''SYS_TIME_LED'': blinks with 1Hz
; LED_2, green : ''AHRS_ALIGNER_LED'': blinks until the AHRS is aligned (gyro bias initilalized) and then stays on
; LED_3, green : ''GPS_LED'': blinking if trying to get a fix, on if 3D fix
; LED_4, red : ''RADIO_CONTROL_LED'': on if RC signal is ok
; LED_5, green : not set to anything by default

=== Jumper Configuration ===
There are a number of jumpers on Lisa/M used to configure voltage levels and power input.

The default configuration is UART3 VCC at V_IN, UART1/2/5 VCC at +3V3, with the V_SERVO servo voltage rail NOT connected to the autopilot V_IN rail, allowing one to power the autopilot and servos separately. The +5V regulator is NOT bypassed, allowing a regulated +5V on listed headers and for the CAN transceiver and I2C level shifter. The V_BATT connector is NOT connected to V_IN, so one can attach a battery voltage to the V_BATT pin to measure the battery voltage, if so desired.

<gallery widths=380px heights=205px>
Image:LisaM_V2_0_top_jumpers_and_leds.png | Lisa/M v2.0 Top Jumpers and LEDs
Image:LisaM_V2_0_bottom_jumpers.png | Lisa/M v2.0 Bottom Jumpers
</gallery>
<br style="clear:both">

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''Power Jumper Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP1||SERVO_BUS to V_IN||OPEN||Connects servo header voltage rail SERVO_BUS to autopilot input voltage V_IN rail
|-
|JP2||V_BATT to V_IN||OPEN||Connects I2C1/CAN rail V_BATT to autopilot input voltage V_IN rail
|-
|JP3||V_IN to +5V||OPEN||Connects autopilot input voltage V_IN rail to autopilot +5V rail, bypassing onboard 5V supply
|}

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART3 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP6||UART3_VCC to V_IN||style="background:black; color:white"|CLOSED||Connects UART3 connector VCC to autopilot input voltage V_IN rail
|-
|JP7||UART3_VCC to +3V3||OPEN||Connects UART3 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting!!!'''

'''WARNING: DO NOT CLOSE BOTH JP6 AND JP7 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART2 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP4||UART2_VCC to V_IN||OPEN||Connects UART2 connector VCC to autopilot input voltage V_IN rail '''SEE WARNING BELOW'''
|-
|JP5||UART2_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART2 connector VCC to autopilot +3V3 rail
|}
'''WARNING: UART2 RX is NOT 5V TOLERANT. Thus, while possible to connect UART2_VCC to V_IN, DO NOT ATTEMPT THIS. Only use JP5 (the default).

'''WARNING: DO NOT CLOSE BOTH JP4 AND JP5 SIMULTANEOUSLY!!!'''

{|border="1" cellspacing="0" style="text-align:center" cellpadding="2%" width="70%"
|+'''UART1 and UART5 VCC Configuration'''
!width="7%"|''Jumper''!!width="20%"|''Bus Connection''!!width="7%"|''Default''!!''Description''
|-
|JP8||UART1&5_VCC to V_IN||OPEN||Connects UART1 and UART5 connector VCC to autopilot input voltage V_IN rail
|-
|JP9||UART1&5_VCC to +3V3||style="background:black; color:white"|CLOSED||Connects UART1 and UART5 connector VCC to autopilot +3V3 rail
|}
'''WARNING: DO NOT CLOSE BOTH JP8 AND JP9 SIMULTANEOUSLY!!!'''

There are additional jumpers on the board for expert or developer configurations, please see [[Lisa/M_v20#Schematic|schematic]] and [[Lisa/M_v20#Downloads|layout]] for more information.

=== Powering the Board ===

[[Image:LisaM_warning_label.png|right|200px]]

The 3.3V regulator on Lisa/M is a [http://www.micrel.com/page.do?page=/product-info/products/mic5209.shtml MIC5209-3.3YM] capable of delivering up to 500mA. While it is possible to power this regulator with up to 16V, '''DO NOT''' do this. By default, the UART3 RX pin is pulled up to the input voltage V_IN. For this reason, 5V is the maximum input voltage. Note that the UART3 GPS Connector is connected to V_IN, check your GPS input voltage before connecting. If one desires to have V_IN at a higher voltage, the jumpers should be adjusted accordingly. As noted, this regulator can handle up to 16V, though experience has shown that this regulator can become very hot in operation with high input voltages, resulting in potential thermal shutdown while in flight. Depending on the expected current draw, it is best to power this regulator with a lower voltage. 5V is the perfect choice.

The onboard 5V regulator on Lisa/M is a [http://www.national.com/pf/LP/LP2992.html LP2992], a low-noise, low-dropout linear regulator capable of delivering up to 250mA. This regulator can be bypassed with JP3, connecting the autopilot V_IN bus directly to the autopilot 5V bus if, for example, one is using an external 5V regulated supply, and a higher current is needed. Unless external use of 5V is required on the ANALOG1 and ANALOG2 headers, the only 5V usage onboard is for the CAN transceiver and the I2C1 level shifter.

When measuring the supply voltage of a battery with the V_BATT pin (could be connected to V_IN through JP2), it is important to note the maximum voltage limit. The voltage divider on the board for measuring with a 3.3V ADC is --'''V_BAT'''--/\/\'''10k'''/\/\--'''V_BAT_MEAS'''--/\/\'''2k2'''/\/\--'''GND'''--. This means that the maximum allowable voltage on V_BATT is

<math>V\_BAT_{max} = 3.3V*\frac{10k}{2.2k} = 15V</math>

If a higher voltage measurement is desired, another voltage divider is required off-board. Alternatively, one could modify the existing voltage divider (e.g. change 10k resistor to 22k to get 33V maximum). When checking if voltage exceeds the maximum, make sure to consider maximum battery voltage, not nominal voltage (e.g. 4.22V or so for a single lithium cell, not 3.7V nominal, so the maximum number of cells in series is 3, like a 3S LiPo pack).

== Schematic ==
<gallery widths=250px heights=168px>
Image:Lisa_m_v2_0_sheet_1.png | LisaM V2.0 Schematic Sheet 1/3
Image:Lisa_m_v2_0_sheet_2.png | LisaM V2.0 Schematic Sheet 2/3
Image:Lisa_m_v2_0_sheet_3.png | LisaM V2.0 Schematic Sheet 3/3
</gallery>
<br style="clear:both">

== Examples of Airborne Equipment Electrical Connections ==

=== Quadrocopter, Spektrum Satellite Receivers and PWM Motor Controllers (ESC) ===

[[File:LisaM_v2_0_wiring_quadrocopter_spektrum_pwmesc.png|700px]]

This configuration assumes the ESCs have a battery eliminator (BEC) function and provide 5 volts on their 5V pins. Closing JP1 powers Lisa/M and the attached accessories.

When using cheap ATMega or SiLabs-based PWM motor controllers consider replacing their firmware with either [https://github.com/sim-/tgy Simon Kirby] or [https://github.com/bitdump/BLHeli BLHeli] firmware respectively to get useful performance of your multicopter! You can find a firmware compatibility list [https://docs.google.com/spreadsheet/ccc?key=0AhR02IDNb7_MdEhfVjk3MkRHVzhKdjU1YzdBQkZZRlE here].

=== Quadrocopter, Spektrum Satellite Receivers and I2C Motor Controllers (ESC) ===

[[File:LisaM_V2_0_quadrocopter_spektrum_i2c_esc_wiring.png|700px]]

This diagram "should" be the same for AscTec as well as Mikrokopter motor controller based airframes.

=== Fixedwing, Spektrum Satellite Receivers and Elevons Only ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum_elevons.png|700px]]

=== Fixedwing, Spektrum Satellite Receivers ===

[[File:LisaM_V2_0_wiring_fixedwing_spektrum.png|700px]]

=== Transitioning [http://wiki.thequadshot.com Quadshot] Using Spektrum Receivers ===

[[File:LisaM_V2_0_wiring_quadshot_spektrum.png|700px]]

Still need: Large Fixed-wing with advanced power system and/or IC engine, PPM example

=== R/C Receivers ===
One can use traditional PPM receivers as wel as Spektrum DSM2 or compatible receivers for flying your aircraft in manual mode during setup and test phase. The Lisa M can direcly connect to a Spectrum DSM2 satellite receiver. It is even possible to connect two satellite receivers for better redundancy or RC reception. It is

==== Bind your Spectrum DSM receiver ====

It is important to bind your receiver with your transmitter '''via your Lisa board''', not in any other way. The way to do this is via fiddly small molex pins

Before you start make sure you have your airframe configuration already uploaded either via USB or a JTAG cable

* On the connector ANALOG1 have a wire between the GND pin ADC1, located in the middle of the board
* Power up your autopilot board
* Hold the bind button on your '''transmitter''', while '''keeping it pressed''' switch on your transmitter
* Wait.. all light of receiver blink then go steady
* Let go of your transmitter bind button
* Power off your Lisa Board
* remove the wire between GND and ADC1 pins
* Repower your board, if you have servos connected and wiggle the RC transmitter sticks some sould move

That all, you are done. Only needs to be done '''once''' for your receiver.

=== PPM sum stream input ===

The default pin to capture the PPM sum stream is servo channel 6, but this can be reconfigured to the RX of UART1. To use ppm for your radio, put this in your airframe file in your ap target.

<subsystem name="radio_control" type="ppm">

<configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>

</subsystem>

=== Extra Input ===

Also UART pins can be used as general purpose I/O to be used for PPM input. By default connect your PPM out able receiver to servo pin 6. If you do not have or cannot create a PPM out able receiver, additionally a [[PPM_Encoder | PPM encoder board]] can be used to avoid receiver hardware modification.

=== Use USB as UART1TX + hardware flow control ===
[[File:Lisam-usb-uart1.jpg]]

The USB_VBUS on the Lisa/M 2.0 can be used as UART1 TX. To do this, a diode has to be removed. Make sure to include a series resistor of 100-3000 Ohm to protect the microcontroller from overcurrents. The 2nd and 3th pin of the USB pads are CTS and RTS respactively. It is recommended to include a series resistor in the RTS line, as this is an outgoing line.

If you want to enable flow control in the software, but don't want to use flow control when no cable is connected to the CTS/RTS, a pulldown resistor of 10 kOhm has to be added between the CTS and the GND. If you do this, take care when connecting UART devices that have a large series resistor in their RTS line. The combination of the pulldown resistor and the series resistor might cause the high-level voltage to drop under the high-level treshold of the microcontroller, causing strange behaviour.

For Example the RTS , mostly a purple wire, is the '''pin 10''' on the Xtend module when set in the module with Hardware flow control (use X-CTU)
CTS, most blue, on pin 9 of the Xtend

<gallery widths=380px heights=205px>
Image:Lisam-diode.JPG | Remove this diode. After removing this diode you can not power the board via USB anymore.
Image:Lisam-gpio-usb.JPG | Take care of the small distance between the GPIO pins and the USB pads.
</gallery>

== PCB ==

=== Gerber & Drill Files ===

'''''Download Lisa/M v2.0 gerber & drill files (zip)''''' ''NOT YET AVAILABLE BUT SEE [[Lisa/M#Downloads|Downloads]]''
Need some generated gerbers and drill files here.

== Assembly ==

===Components Layout===

''NOT YET AVAILABLE BUT SEE [[Lisa/M#Downloads|Downloads]]''
Need some top and bottom of board images and line drawings here.

=== Bill Of Material ===

'''''Download Lisa/M v2.0 Bill Of Material (zipped .xls file)''''' ''NOT YET AVAILABLE BUT SEE [[Lisa/M#Downloads|Downloads]]''
<br>
<br>

== PCB and assembled boards suppliers ==

Available on [[Get_Hardware|Get Hardware]] page, hopefully :)

== Mechanical Dimensions ==

[[Image:LisaM_V2_0_top_mechanical.png|500px|Lisa/M v2.0 Mechanical Dimensions]]

The overall height of the board including the servo connectors is 10mm. Note that the overall length includes the USB connector. The mounting holes are nominal 2mm diameter (with a bit of clearance).

== Downloads ==

'''Source files'''
:*download available on GitHub: ''[https://github.com/paparazzi/paparazzi-hardware/tree/master/controller/lisa_m/v2.0 Lisa/M v2.0 Cadsoft Eagle 6 Design]''
'''Gerber & Drill files'''
:*download ''NOT YET AVAILABLE'' Need generated gerbers and drill files
'''Assembly files'''
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Components layouts (pdf)
:*download ''NOT YET AVAILABLE'' Need Lisa/M v2.0 Bill Of Material

== Uploading new software ==

New onboard software for the Lisa/M v2.0 can uploaded by connecting your PC via a micro-USB port to the autopilot board. For this the board need to contain a "luftboot" bootloader. All Lisa/M 2.0 from Transition Robotics Inc. come with luftboot already in the board.

An alternative to get your software/flightplane in the board is by using a JTAG connector connected via the 10-pin Samtec connector that is available on the board.

=== Using luftboot ===

First make sure you '''update to the latest stable Paparazzi version''', then you will have support for this bootloader method. By default use the associated DFU loader to program the firmware. Make sure that your airframe file is set to use Lisa/M 2.0 as it's target board.

Currently Paparazzi firmware does not contain the needed software to switch into bootloader mode using software only by USB. To circumvent this shortcoming, you need a small cable to force the bootloader to run. This cable should bridge pin GND and ADC2. Make sure you do not shortcircuit your board.

Once your "Boot mode connector" is inserted, connect the Lisa/M to the PC via a micro-usb cable and it should start in bootloader mode. If the status LEDs cycle up and down, it is in booatloader mode, ready to receive your new flightplan and autopilot control software upgdate.

Note that all of this won't be necessary in the future once a working USB stack stub is added to the latest Paparazzi.

[[File:Luftboot.gif|320px]]

You should disconnect the "Boot mode connector" after enforcing the bootloader. Pressing upload in the Paparazzi Center should now upload new code onto the board.

In the rare case you somehow have removed the luftboot bootloader, you can re-insert this Boatloader by following the instructions of ''Uploading the Paparazzi USB Bootloader''

=== Uploading the Paparazzi USB Bootloader ===

Reading or performing these steps is not needed if you got your Lisa/M 2.0 from Transition Robotics Inc., these boards come with luftboot already preloaded. But in the case you made a board yourself or somehow do not have a preloaded bootloader, or it is gone because of unknown cause, then read this section. It describes the process on how to upload/recover the luftboot bootloader on your Lisa/M 2.0.

[https://github.com/paparazzi/luftboot Luftboot] is a Paparazzi-compatible bootloader for STM32-based autopilots.
Depending on your vendor, your Lisa/M may already come with a bootloader, in which case you should skip to [[Lisa/M#Uploading new software]]

==== Required components ====

*Floss-JTAG debugger or Blacksphere mini JTAG
*Lisa/M board
*PC

==== Procedure ====
<ol>
<li>
Get the [https://github.com/paparazzi/luftboot Luftboot sourcecode from Github] via
<source lang=bash>git clone https://github.com/paparazzi/luftboot.git</source>
</li>
<li>
Change directory into the luftboot/src folder
<source lang=bash>cd ./luftboot/src</source>
</li>
<li>
Build luftboot
<source lang=bash>make clean && make</source>
</li>
<li>
Flash the Lisa/M
Attach the floss-jtag unit to the PC and connect it to the Lisa/M via the black connector.
Power the Lisa/M (easiest way is to connect to the PC via a micro-USB cable).
<source lang=bash>make flash DEV_SERIAL="LM2-ser"</source>
where "ser" stands for the serial number of your Lisa/M. So for example if you have lisa/m with the serial number 020 this would be:
<source lang=bash>make clean && make flash DEV_SERIAL="LM2-020"</source>
</li>
</ol>

==== Connection Diagram ====

==== Boot Sequence ====

* Luftboot
** Check if ADC2 is configured as output pull down indicating software bootloader request
*** '''If ADC2 output pull down:''' initialize usb and stay in bootloader mode
** Setting the ADC2 pin to input pull up
** Checking if the ADC2 pin is low
*** '''If ADC2 low:''' initialize USB and stay in bootloader mode
*** '''If ADC2 high:''' check if there is a payload at 0x8002000
**** '''If payload detected:''' set vector table pointer to be at 0x8002000 and jump to the reset handler of the payload
**** '''If payload not detected:''' initialize USB and stay in bootloader mode

==== Luftboot USB permissions ====

[[Installation/Linux#Udev_rules|Copy the udev-rules file]] is needed for the upload software to get permission to use this hardware in your PC for uploading.
For short: the Python program "stm32_mem.py" needs permission to write to the the Luftboot USB device. If you do not have set this rules already you get an error message, which explanation what is wrong is quite obscure due to the way python-libusb accesses the device.

=== Using JTAG ===
If you are using the Lisa/M 2.0 target board you still can use JTAG for programming and debugging your paparazzi firmware. To use JTAG flashing configure the ''FLASH_MODE'' in your firmware section:
:<source lang="xml"><configure name="FLASH_MODE" value="JTAG"/></source>
Using JTAG will not overwrite the bootloader by default. To overwrite the luftboot bootloader configure
:<source lang="xml"><configure name="NO_LUFTBOOT" value="1"/></source>

* [[JTAG]] description;
* General [[Dev/Debugging|debugging information]];
* [[DevGuide/JTAG-Debug|JTAG usage]], includes Eclipse uplink tutorial.

==== Quick JTAG Upload Guide ====
# Connect floss-jtag to Lisa via the cortex cable (little black socket)
# Attach the UART port on the bottom of the floss-jtag to UART2 on the Lisa.
# Plug in USB port of the floss jtag
# Plug in USB port of the Lisa
# Make sure your airframe uses the <target name="ap" board="lisa_m_2.0"> definition
# Click Build, wait until complete, then click Upload. You should see the following towards the end:
{{{
...
Info : device id = 0x10016418
Info : flash size = 256kbytes
stm32x mass erase complete
Info : Padding image section 1 with 7972 bytes
wrote 152576 bytes from file src/paparazzi/var/Hexa_LisaL/ap/ap.elf in 7.498179s (19.871 KiB/s)
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
shutdown command invoked
}}}
# Run Flight USB-serial at the baud rate you need (default 57600 for rotorcraft)
# You may need to change the device to /dev/ttyUSB1, and 'Redo' the Data Link

=== Serial Firmware Upload ===

Firmware upload using the factory integrated bootloader can be useful e.g. if you have overwritten Luftboot accidentally and don´t have access to JTAG.

Due to hardware constraints, the board has to be modified to make use of the bootloader, which is only accessible on UART1:
# Diode D3 has to be removed (the bigger black brick next to the USB connector). Attention, no more powering via USB after that.
# BOOT1 has to be set to GND by connecting ACC_DRDY(unused) to GND at the Aspirin pads

Now a boot sequence works as follows:
#BOOT1 has to be set to 3.3V by use of a jumper cable
#Connect a 3,3V serial cable (FTDI, MAX232...) to UART1, the TX pin is USB_VBUS
#Power the board and activate the bootloader program

The according bootloader script can be found at :
[https://github.com/jsnyder/stm32loader stm32loader from Github]
<source lang=bash>git clone https://github.com/jsnyder/stm32loader.git</source>

To reload Luftboot, upload luftboot.bin

Serial upload can also be used directly from paparazzi Center by adapting the right path in [https://github.com/paparazzi/paparazzi/blob/dev/conf/Makefile.stm32 Makefile.stm32] for the LOADER argument and setting

<define name="FLASH_MODE" value="SERIAL"/>

in the target section of the airframe configuration.

== Detailed Hardware Revision History ==

=== Changes Between LISA v1.1 and v2.0 ===

* Lots of silkscreen improvements
* Added attributes to all parts to make the usage of bom-ex ulp possible.
* Improved routing to allow teardropping
* Fixed stm32f1, f2 and f4 compatibility circuit. (has to jump to ground not to 3v3)
* Connected existing UART RX pullups to the respective connector power pins instead of 3v3. To prevent connecting 5V over IO pin to the 3v3 power rail.
* Added pullups on all UART RX lines to prevent undesired floatation.
* LED's are connected to 3v3 now. To make sure we don't have an issue with voltage tolerance on the gpio pins.
* ...

== Hardware Change Requests ==

If you have a Lisa/M 2.0 and in the process of using it you come up with something you find annoying, dangerous, or restricting, add your hardware update requests here. Better still, modify the Lisa schematics yourself and show your new improvements if you are skilled enough to do this.

* REQ: Replace BMP085 with MS5611 (the MS5611 seems to be better in performance then the BMP but it is more expensive and seems to be more difficult to obtain.
** A: Using a MS5611 is possible through using a Aspirin v2.1 board

* REQ: Replace 7 Pin CAN with molex with something less risky to be inserted in 7 Pin SPI in relation to powering the board via CAN molex.

* REQ: Separate spot for external power if powered via separate battery. Realizing we can via Servo ports by Bridge J1 but still like to measure board voltage then and have a way to add power without mistakenly insert I2CCAN Molex conector into SPI Molex on board connector. Thus a separate CAN and Power plug. Power on regular four pin molex with GND, V+5, , V_BATT, V_I (Current sense). Option to have thicker wire to be soldered to the board, for power hungry setups and other issues connectors for power are not a good idea.

* REQ: Replace Aspirin IMU board with InvenSense MPU-9150 and bring the MS5611 back onto the Lisa/M board to reduce footprint, mass, and manufacturing cost once the 9150 becomes readily available(if at al with SPI) and is tested to perform well.
[[Category:Lisa]] [[Category:User_Documentation]]

RC Receivers and Radios

2012-10-25T21:42:37Z

Jkg: typo

== 2.4GHz Systems==
If using a Lisa/M or Lisa/L autopilot board the whole range of Specktrum/JR transmitters can be used with 1 or 2 Spektrum/JR/Hobbyking satellite receivers. For other autopilot boards to use a 2.4 GHz system a few requirements are necessary
# Must use [[PPM_Encoder | PPM Encoder]] board. (See [[Get_Hardware|Get Hardware]] page for suppliers) (Except for the Futaba FASST 7 channel receiver R617FS that has a 5 (not 7) channels combined pulse)
# Needs a three position switch
# Ability to set failsafe to any or at least 1 channel (pprz-mode) as desired
# At least one extra channel beyond those needed to control the servos and motor. (throttle-roll-pitch-mode)
=== Radios ===

====Futaba FASST 7-channel receiver====

[[Image:rs617fasst.jpg|thumb|right]]

* Pin 8 (upper right corner in picture) of the small IC on the right contains 5 PPM pulses and can go directly to paparazzi. Pulse 6 and 7 go directly to the servos.
* Best is to remove the resistors of one of the channels and connect a small wire to pin 8 to get the combined 5 pulses on the robust 1/10th inch header.
* Do not forget to use channel 3 (only failsafe channel) as mode switch with fail safe "throttle off" as mode 2.

====Robbe RASST 7 & 8 channel receivers ====
Robbe has produced line of Futaba FASST compatible receivers that can output only PPM which results ablility to plug into autopilot without encoder.
* [http://www.robbe.de/empfaenger-r-6007-sp-2-4-g-rasst.html R6007SP 2,4 GHz RASST] - 7 channel, for small aircraft
* [http://www.robbe.de/empf-r6107sp-2-4-ghz-rasst.html R6107SP 2,4 GHz RASST] - 7 channel, >1000m range
* [http://www.robbe.de/empf-r6008sp-2-4-ghz-rasst.html R6008SP 2,4 GHz RASST] - 8 channel, upto 3000m range

====Spektrum DX-7====
[[Image:DX7.jpg|thumb|left]]
*7 Channels
* 20-Model memory
* Airplane and Heli software
* Switch assignment
* P-mixes
* Includes 4 powerful DS821 digital servos with high-tech resin gears
* 3-axis dual rate & expo
* 3-position flap (Airplane)
* 5-point throttle curve (Heli)
* 3 flight modes plus hold (Heli)
* Gyro programming (Heli)
* CCPM, 2-servo 90°, 3-servo 90°, & 3-servo 120°
* Price $320-$350
<br><br>
===== Switch Assignment =====
To assign the three position switch to any other channel but channel 7 follow these steps:
# Set up aux2(refers to aux2 on rx not the switch on the tx. aka ch7) with its input selected as 3 pos switch.
# Set up this mix - Gear to Gear (Up=-100, Down=-100, Offset =0). This inhibits the gear switch.
# Set up another mix - Aux2 to Gear (Up=100, Down=100, Offset = 0).
Notes:
#Gear on a DX-7 Air is Channel 5 and AUX2 is CH7. Once again i am referring to the inputs which are labeled on the RX not what the switches are named on the TX. If your using a DX-7 heli please substitute the names for what the rx channels are named into this guide
# DX7 Heli the 3-pos switch is named "flight mode"
# DX7 Air the 3-pos switch is named "flaps"

===== Failsafe Setup =====
To set up the mode channel (3 pos switch) to default to auto2 if connection is lost between rx and tx follow these steps:
# Put 3 position Switch into AUTO2 Position
# Put in bind plug
# Power up
# REMOVE the bind plug
# Power up Tx while pushing bind button
# Wait until light becomes steady and not blinking (it may become steady right off but will then start blinking again so let it go at least 5 seconds)

===Receivers===
====Jeti Duplex 2.4 GHz Receiver Rsat 2====
[[Image:Jeti_Duplex_Rsat2.jpg|thumb|left|Jeti RSat 2]]
* Outputs PPM, no soldering or PPM board required
* Only 12 gramms
* Full duplex technology provides safe radio link and redundant telemetry to standard paparazzi telemetry.
* [http://www.jetimodel.cz/index.php?page=products&old=0&category=4 Transmitter module] can be installed in any receiver.
See the official [http://www.jetimodel.cz/index.php?page=product&id=165 Homepage of Jeti] or the [http://www.mikrokopter.de/ucwiki/JetiDuplex MikroKopter Wiki].
<br style="clear:both">
====Spektrum 2.4Ghz Satellite Receiver - Lisa/L implementation====
[[Image:Lisa l hex 1.jpg|thumb|right|Connection View]]
[[Image:SPM9545-250.jpg|thumb|left|Remote Receiver [SPM9545]]]
* [http://www.spektrumrc.com/Products/Default.aspx?ProdID=SPM9545 Specifications]
* Lisa/L Radio_Control_Spektrum_Primary_Port = Uart 3
* Lisa/L Radio_Control_Spektrum_Secondary_Port = Uart 5
* arch files:~/paparazzi/sw/airborne/arch/stm32/subsystems/radio_control/spektrum-arch.h and .c
* Additional hardware -
[http://parts.digikey.com/1/parts/355490-conn-housing-5pos-1-25mm-51021-0500.html Molex CONN HOUSING 5POS 1.25MM - 51021-0500],

[http://parts.digikey.com/1/parts/355493-conn-housing-8pos-1-25mm-51021-0800.html Molex CONN HOUSING 8POS 1.25MM - 51021-0800],

[http://uk.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=2799544 Molex Socket to free end crimped lead,300mm L],

[http://parts.digikey.com/1/parts/270897-conn-term-female-26-28awg-tin-50079-8000.html Molex CONN TERM FEMALE 26-28AWG TIN],

[http://parts.digikey.com/1/parts/1806245-hand-tool-26-32awg-crimp-638190300.html Molex HAND TOOL 26-32AWG CRIMP]
* Transmitter options - Spektrum DX6, DX7(see above), DX8, bind compatible JR units up to 12 channels and those bearing the Specktrum DM9 module - note these transmitters must be channel order compatible with Spektrum's protocol (in fact all transmitters that use Spektrum protocol have the same channel ordering regardless which stays consistent across different modes (ie throttle on left / right etc))) - [http://code.google.com/p/er9x/ here is an example]

=====Installation=====
# Cut off original receiver connector and crimp molex connector terminals to the three wires.
# Insert terminals into appropriate positions-[http://paparazzi.enac.fr/wiki_images/LisaL_v1_0_schematic_3.png CON_USART3]-of the 5 way connector - black to pos1 = GND, orange to pos3 = +3v3, grey to pos5 = STM_USART3_RX.

=====Bind plug=====
# Take the 8 way molex connecter and create a loop between pos1 = GND and pos4 = XXX_STM_SPARE_2. This plug is placed in the-[http://paparazzi.enac.fr/wiki_images/LisaL_v1_0_schematic_3.png CON_SPARE]-receptacle housing before power-up to enable the receiver binding state.

=====Configuration=====
* Set the spektrum radio parameters for Lisa/M or Lisa/L ap in ~/paparazzi/conf/airframes.xml file. Check 'esden' directory as a possible rotorcraft example. Refer to ~/paparazzi/sw/airborne/arch/stm32/subsystems/radio_control/spektrum-arch.h and .c for other options. Be sure to set actuators, rotor configuration/mixes and channel reversal parameters that are appropriate for the rotorcraft/aircraft (note "lisa_l_1.0" can also be "lisa_m_1.5" or "lisa_m_2.0"):

<firmware name="rotorcraft">
<target name="ap" board="lisa_l_1.0">

<subsystem name="radio_control" type="spektrum"/>
<subsystem name="actuators" type="mkk"/>
<subsystem name="telemetry" type="transparent"/>
<define name="RADIO_MODE" value="RADIO_AUX1"/>
<define name="RADIO_KILL_SWITCH" value="RADIO_GEAR"/>
</target>

<target name="stm_passthrough" board="lisa_l_1.0">
<subsystem name="radio_control" type="spektrum"/>
<subsystem name="imu" type="b2_v1.2"/>
</target>
*Create a new transmitter 'airplane' model. Do not introduce any mixes or change the endpoints, subtrims etc. Note that a radio.xml file is not required for this implementation, unlike analogue RC directed autopilots.
*Upload ap software in the usual way.
*Unplug the aircraft battery. Turn transmitter off. Insert the bind plug (see above) in the 8 way CON_SPARE receptacle. Power up the aircraft - specktrum receiver LED should be flashing in readiness to bind. Press and hold bind button on transmitter while turning on. Receiver LED should stop flashing after a few moments to confirm it is bound. Turn everything off in preparation to start in the normal way. Note that the transmitter should now be turned on first to enable the spektrum receiver to acknowledge it.
*Should be ready to fly.
*Adding a second spektrum satellite receiver requires different wiring dependent on the Lisa board version. As the pinouts to uart5 differ between Lisa-L v1.0 and v1.1. Seek advice from the [http://lists.gnu.org/archive/html/paparazzi-devel/2011-01/index.html paparazzi mailing list] prior to making this addition.

To enable the use of the secondary satellite receiver you have to add two lines to your firmware section in the airframe file:

<define name="RADIO_CONTROL_SPEKTRUM_SECONDARY_PORT" value="UART5"/>
<define name="OVERRIDE_UART5_IRQ_HANDLER"/>

== PCM Systems ==

Most of the known PCM transmitter also can be set to PPM mode. If this is set, then the regular description for PPM applies since the PCM receiver like a JR/Gaupner SMC16 Scan can output PPM perfectly.

If PPM out is not setable on your transmitter then the following applies:

# Must use ppm encoder board. (See [[Get_Hardware|Get Hardware]] page for suppliers)
# Needs a three position switch
# Ability to set failsafe to any channel as desired
# At least one extra channel beyond those needed to control the servos and motor.

== PPM Based Systems ==
=== Configuration ===
The [[Radio_Control]] page describes how to set up the radio.xml config file.

=== Requirements ===
To use a 26/27/35/40/41/72/ MHz **(uses PPM) system a few requirements are necessary
# Need a Transmitter with a three position switch
# At least one extra channel beyond those needed to control the servos and motor.
# A modified receiver which outputs a full ppm signal.

===Adding a 3 position switch===
===== Futaba T6EXAP =====
For this particular transmitter, the Potentiometer on channel 6 can be replaced with a 3 position switch. Channel 5 appears not to be connected to an ADC converter; therefore it will not support a 3 position switch.
#Disconnect the potentiometer being careful not to shorten the wires
#Solder the switch and resistors onto the wires using the wiring diagram as a reference. (Any two equal value resistors should work). I used 10k resistors.
[[Image:SwitchWiringDiagram.JPG|thumb|left|Switch wiring diagram]]
[[Image:3positionswitch.JPG|thumb|left|Switch installed in transmitter]]
<br style="clear:both">
Suitable 3 position switches:<br style="clear:both">
RS Components: [http://australia.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=344-710 344-710]<br style="clear:both">
Mouser: [http://au.mouser.com/Search/Refine.aspx?Keyword=633-M202402-RO 633-M202402-RO]

=== R/C Receiver Interface===
All versions of the Paparazzi autopilot include a connector to interface with a standard R/C receiver for manual or semi-autonomous control during the testing and tuning phases. Two interface options exist:
# Tap into the PPM signal running between the RF section and the servo driver of your receiver and route it to the Paparazzi. Let the Paparazzi generate individual servo signals and connect all servos directly to the autopilot. This method requires only 3 wires to the receiver (power and PPM), is compatible with all Paparazzi autopilots, and provides 8 manual R/C channels and the potential for more autonomous channels regardless of the capability of the R/C receiver.
# Cut the PPM trace and route it thru the autopilot and back to the receiver, using the servo driver IC on your R/C receiver to drive the servos. This option requires 4 wires (Ground, PPM-in, PPM-out, Reset) and your receiver must have a supported servo driver IC. This allows you to use the large servo connectors on your R/C receiver and does not require any modification to your servos or ESC but does require you to cut a trace on your R/C receiver and limits the number of servos to the capacity of your receiver. Compatible with Classix and Tiny 1.1.
# Note that on the Classix the PPM_in pin is FOO2...
[[Image:RC_Receiver_Timing_Diagram.jpg|thumb|left|PPM Timing Diagram<small>Note 1: Exact value not critical. Depending on RC Transmitter type & Manufacturer.<br>Note 2: Depending on Transmitter number of Channels and t,,n,, durations.<br>Note 3: Not critical. Depending on Synchro detection method.</small>]]
[[Image:RC_Receiver_Tiny.jpg|thumb|left|3-Wire setup, driving servos from the autopilot]]
[[Image:RC_Receiver_classix.jpg|thumb|left|4-Wire setup, driving servos from the R/C receiver]]
<br style="clear:both">

=== Common demux chips ===

Typical used chips are the cmos [http://www.doctronics.co.uk/4015.htm 4015] and [http://www.doctronics.co.uk/4017.htm 4017].

The 4015 uses either pin 1 or pin 9 for the clock and the input is on 7 and 15. The 4017 has just one shift register and has its clock input on pin 14 and the enable on pint 13.

In most receivers you are after the clock; though some may be pulsed; in which case you need the enable. Note that the 4017 enable has inverted logic (low to be enabled) whereas the input on the 4015 can be either (typically high). If the enable pin is held low (4017) or if the input pin (4015) is held high always;e.g. connected to the ground or the Vcc - then it is fair to assume that the PPM signal is most propably on the clock input.

=== Recommended 35/40Mhz R/C Receivers ===

Note that there is information on modifying other receiver models at [http://mikrokopter.de/ucwiki/RC-Empf%C3%A4nger mikrokopter.de]. It's in German however the pictures contain most of the information or use google translate.
Shielded wire is recommended for receiver and autopilot connection, as unshielded one may cause noise in receiver.

=====Futaba FP-R116FB 6 Channel FM 35MHz receiver=====
[[Image:Rc_fut_web.jpg|thumb|left|Wiring of a Futaba R136]]
*Orange wire is connected to PPM signal
*Red wire is connected to VCC
*Brown wire is connected to GND
<br style="clear:both">

=====Futaba R136F 6 Channel FM receiver=====
[[Image:rx_futaba136.jpg|thumb|left|Wiring of a Futaba R136]]
*41 MHz
*White wire is connected to PPM signal
<br style="clear:both">
=====Futaba R168DF 8 Channel dual FM receiver=====
[[Image:rx_futaba168df.jpg|thumb|left|Wiring of a Futaba R168DF]]
*35 MHz
*PPM wire is connected to 862 receiver pin on the board. VCC and GND is on the 8/B original position.
<br style="clear:both">

=====ACT Micro-6 FM receiver=====
[[Image:rx_act_micro-6.jpg|thumb|left|Wiring of a ACT Micro-6]]
*Available in 35 or 40 MHz versions
*White wire is connected to PPM signal
*[http://www.acteurope.com/Micro_6anl.pdf Datasheet (German)]
<br style="clear:both">

=====ACT DSL-4top [http://www.mikrokopter.de/ucwiki/DSL4top mikrokopter.de] version=====
[[Image:DSL4top.jpg|thumb|left|DSL-4top mikrokopter.de version]]
* Special version for mikrokopter.de - Only available in their [https://www.mikrocontroller.com/index.php?main_page=product_info&products_id=215&zenid=8ce8bab70f3e9d684e01f724316d9690 shop]!
* '''Outputs PPM directly''' on the channel 1 connector!
* No soldering necessary
* ACT Lifetime warranty
* Sells for ~45 euro
<br style="clear:both">

=====Futaba R115F 5 Channel FM receiver=====
[[Image:pprz_rx115.jpg|thumb|left|Wiring of a Futaba R115]]
*Available in 35 and 40 MHz versions
*White wire is connected to PPM signal
<br style="clear:both">
=====JETI REX 5 plus (no MPD) receiver=====
[[Image:520_Jeti_5_plus.jpg|thumb|left|Wiring of a REX 5]]

*Popular Czech made micro r/c receiver, available in 35 or 40 MHz versions
*´folded´ PCB design with parts inside, mostly inaccessable
*Small grey wire is connected to via with PPM signal
*Unusual connector used for testing, soldering recommended
*shielded wire recommended, this one taken from PC parts recycling (former soundcard to m/b connector cable)
*[http://www.jetimodel.cz/eng/navody_en/rex5_eng.pdf Datasheet (English)]
<br style="clear:both">
[[Image:DSC02414.JPG|thumb|left|other Layout of REX 5]]
<br style="clear:both">

=====Receiver RX-7-SYNTH IPD receiver [http://www.multiplex-rc.de/hp/produkte/artikel_detail.jsp?lfdnr=55880&action=add2notice&qty=1&cachenepper=1227896925116 Multiplex-rc.de]=====
[[Image:RX-7-SYNTH_IPD.jpg|thumb|left|Wiring of RX-7-SYNTH IPD]]

*Available in 35, 36 and 40 MHz versions
*A compact, high-quality 7-channel single-conversion FM / PPM IPD receiver
*Easy modification through connectors, see pictures
<br style="clear:both">

==== Protech 5FM 35 mHz Receiver ====

The low cost Protech '5FM' receiver makes use of an SMD version of the standard 74AHC164[http://www.ic-on-line.cn/IOL/datasheet/74ahct164_18057.pdf] 8 bit shift register; you are after PIN 1 of this chip. The circuit board has a testpad for just this pin at the top side of the circuit board.

<gallery>
Image:protech-5fm.jpg|Figure 1. <br>Protech 5FM 35 mHZ Receiver, mark 2
Image:protech-5fm-pad.jpg|Figure 2. <br> PPM tap location for the Protech 5FM receiver, near the 74AHC164 shift register
Image:protech-5fm-scope.jpg|Figure 3.<br> Protech 5FM PPM signal - not very clean/digital
</gallery>

Two physical versions exist; the older one [http://www.protech.be/Manuals/PRO205manual%20web.pdf] and a newer one pictured (fig 1). It has been distributed by protech with various ready-to-fly planes; such as the Skyraider[http://www.modelbouwforum.nl/forums/beginners/50677-protech-skyraider.html].

The solder/testpad you are after the one right next the 74x164 chip its pin 1. In this image it has a jellow wire soldered to it (the yellow wire at the top left is the normal antenna connector (fig 2). Note however that the signal is not very clean (1v/div) - which may cause issues - as shown in the above image (fig 3).

This is further compunded by the relatively noisy electrical engines; which are not brushless. A ferrite coil does not seem to help enough - Papparazi and GPS loose sync often through Xbee. Replacing the engine by a brushless outrunnen resolve the issue completely.

==== Profi Penta 35 MHz ====
[[Image:DSC00547.JPG]]
[[Image:DSC00545.JPG]]

=== Recommended 72Mhz R/C Receivers ===
====Castle Creations [http://www.castlecreations.com/products/berg_ms4l.html Berg 4L]====
[[Image:berg4L.jpg|thumb|Wiring of a Berg 4L]]
* Expect fantastic performance from these $40 USD parts but be warned that they are known to have unreliable crystal sockets and brittle antenna wire. The ''Berg 7'' channel receiver should work equally well and is known to have a better crystal socket - note that either receiver will provide '''8 channels''' in manual R/C mode when used with Paparazzi. Note: the rugged ''Berg 4'' cannot be modified, only the ''Berg 4L'' and ''Berg 7''.
To Modify a Berg4L, follow these instructions:
# Remove the shrink wrap. Use a good knife and be careful to not damage any of the components on the receiver. I would recommend that you cut on the sides (edge of the PCB) to be sure to avoid damaging the shielding
# Desolder the headers. We will not use them with tiny AP as the servos are connected directly to the AP. This is pretty easy to do when you have a hot air rework station. If you don't have one, your best bet is to cut the header off and remove the left over pins one by one with a regular iron. There is a piece of shielding material that is connected to one of the ground pins of the header. You need to remove it carefully from the header without damaging it and re-solder it to the gnd pad.
# You need to solder 3 wires to the receiver. Gnd, +5V and PPM. To locate the PPM signal, first locate the PIC micro controller close to the location of the headers. The PPM signal is on the corner pin closest to the corner of the receiver. Soldering a 28guage wire directly to the PIN isn't very difficult. For the power connection, use the pads that were used for the header. The outside pin is Gnd, the second pin is +5V. What I did is solder the wires on the pad going straight down, then I looped the 3 wires 360 degrees and glued them to the PCB with hot glue. This provides good strain relief.
# While you have the PCB in your hands, take the opportunity to remove the crystal connector and solder your crystal directly to the PCB for added reliability.
# I also used some hot glue to add more strain relief to the antenna
# Use some large shrink wrap to cover the entire receiver again
=====Hitec Electron 6 72MHz Reciever=====
This was written for MNAV from crossbow but is still usable with PPRZ.
<br>
[[Image:Electron6mod.jpg]]

=====Corona Synthesized Dual-Conv Receiver 8Ch=====
[http://www.corona-rc.com/coproductshowE.asp?ArticleID=63 manual] <br>

This receiver is available in 27,35,36,40,72 mhz and a Synthesized receiver, meaning you do not need to change frequency crystals.

How to modify for combined signal

# Cut the 8th channel PWM output pin near the PCB.
# Connected a pin from the Atmel (see picture) to the 8th channel PWM signal. (optionally, weaving the wire through some holes on the board.) Make sure you have a fine tip on your soldering iron and a magnifying glass strapped to your head!
# Glue the wire down (CA works)
# Be sure to glue the pin that you cut in place (previously, being soldered to the board was holding the pin in place)

It is maybe possible to reprogram the atmel with your own firmware. If you succeed in this plz add relevant info here.

That pin provides a 1V to 2V signal, it works with the PPRZ, although its a bit gittery (the slew rate is not real good).
[[Image:Corona_Synthesized_Receiver_72Mhz_bottom.jpg|thumb]]
[[Image:Corona_Synthesized_Receiver_72Mhz_top.jpg|thumb]]
[[Image:Corona_Synthesized_Receiver_72Mhz_top_atmel.jpg]]

<br style="clear:both">

==433MHz UHF Systems==

Note that in most countries an amateur radio license is required to use 433MHz UHF.

===Scherrer UHF===

[[Image:ScherrerUHF.jpg|thumb|left|Scherrer UHF Rx]]

The [http://www.webx.dk/rc/uhf-link3/uhf-link3.htm Scherrer UHF] is a high quality diversity radio control system. It has a PPM output and can be connected directely to Paparazzi. A ppm encoder board is not required. It has an RSSI output.

<br style="clear:both">

===ImmersionRC EzUHF===

[[Image:EzUHFTx.jpg|thumb|left|ImmersionRC Tx]]

The [http://www.immersionrc.com/products.htm ImmersionRC EzUHF] is a high quality diversity radio control system. The recent firmwares have a PPM output on Ch. 1, but this needs to be activated through the PC configuration software with the proper firmware loaded. It connects directly to EzOSD and the TrackR2 which enables RSSI monitoring and head tracking for FPV.

Some people had issues with the exact timing, where the ROLL channel disappeared. If the radio has more than 6 channels, there may be methods to slave another channel to the roll channel (usually for the operation of dual ailerons). The ezuhf configuration file is using this method, where channel 1 is copied to channel 6. The EzUHF modules receive the PPM output stream from the radio and need to interpret it. For this reason, the ezuhf configuration file should be verified for proper functioning and you may find that channels are remapped to others with different purposes.

Search "sander style" antennas for a way to build your own cheap, high-quality antennas for these rx modules and which provide a range well beyond the horizon.

See [http://www.immersionrc.com/EzUHF.htm EzUHF manual+firmware] for more information.

<br style="clear:both">

== Flight mode switch ==

A important requirement is a three way flight mode switch to choose between the flight modes MANUAL, AUTO1 and AUTO2.

Cheap entry level radios often don't have this. As a workaround two two-position switches can be used.

The switch designated to RADIO_MODE will switch between MANUAL and AUTO
And a second switch designated to RADIO_AUTO_MODE one will select between the different AUTO MODES if the first switch is set to AUTO.
{{Box Code|conf/airframes/myplane.xml|
<source lang="xml">
<firmware name="fixedwing or rotorcraft">
<define name="RADIO_MODE" value="RADIO_AUX2"/>
<define name="RADIO_AUTO_MODE" value="RADIO_AUX1"/>
</firmware>
</source>
}}

This feature is available since v3.9.2.

[[Category:Hardware]] [[Category:User_Documentation]]