Welcome to the Open.HD Introduction Page!

Open.HD uses commercial off-the-shelf (COTS) WiFi adapters, however it does not operate them in standard WiFi mode, which is unsuitable for low-latency or very long distance video transmission. Instead, Open.HD configures the WiFi adapter in a way that is similar to a simple broadcast, much like analog video transmission hardware you may be using already.

High definition video, bidirectional UAV telemetry, audio, and RC control signals can all be sent over a single radio link.

A multi-platform Open.HD app is available for live video with a customizable OSD.

For support and further reading:

• Open.HD Forum

• Public Telegram and Discord groups for lots of immediate interaction

• Issue tracker on Github

• First Intro to Open.HD from CurryKitten on Youtube (2 of x parts available)

If you have a problem with a specific version of Open.HD, please check the name of the image you used to burn your SD cards and provide it to us in Telegram so we can help narrow down the cause and find a solution.

If you don't have or remember the version of Open.HD you used for your SD cards, you can find out what it was by looking in the root partition of the image (either connect the SD card it to a Linux machine or connect to the pi via SSH). There will be a file called /openhd_version.txt containing the exact version of the image.

Pay attention to the version number of the WiFi adapter, manufacturers often use a completely different chipset with a different version number! We highly recommend at least 2 WiFi cards on the GroundPi. This will enable diversity and give you significant gains! The Pi3 can support 2-3 USB connections, and the Pi4 can support 4 or more.

When choosing between 2.4 and 5.8ghz, know that 2.4 will get better range, but is susceptible to more common sources of interference. 2.4ghz RC transmitters and many common WiFi signals will interfere with 2.4ghz OpenHD. 5.8 WiFi is less common, for now, and it also conflicts less with most popular RC transmitters. For those reasons, more people currently choose 5.8 for OpenHD.

Please use this form to submit any WiFi Dongles you may have tested. We will add them to the matrix below!

ASUS AC56

This adapter is currently the most popular for OpenHD. Its small size makes it easy to fit into many builds, it uses 5.8ghz, and it is widely available. The retail price can be high, but it can often be found used or on sale for $30 or less. One antenna is internal, the 2nd is optional, and connects with RP-SMA.

• FCC info

• WikiDevi

AWUS036NHA

This adapter is highly recommended as it is easy to find and works well. Ideal for long range as it will provide around 280mW output power. Ranges of several kilometers have been reported (with directional antennas though).

• FCC info

• WikiDevi

Chinese generic RTL8812AU single antenna

Cheap and functional RTL8812AU card. This adapter can be found under different names on Ali Express, Amazon, Ebay etc. Theoretical power around 2-300mw, it has 1x RPSMA connector and a secondary internal antenna that can be hacked to be excluded and use a secondary custom antenna. Relatively easy to make lightweight by removing plastic shell and desoldering USB port. Tested on a 250g drone reached 3km with no problem with stock antenna. It has been tested with maximum power = 58. Further test will follow. Included antenna works ok but is quite big and heavy. It is suggested to replace it with proper 5-5.9ghz antenna in long range setups

• product example

• alternative example

Chinese generic RTL8812AU double antenna

Cheap and functional RTL8812AU card. This adapter can be found under different names on Ali Express, Amazon, Ebay etc. Theoretical power around 2-300mw, it has 2x RPSMA connectors Relatively easy to make lightweight by removing plastic shell, removing RP-SMA connectors and desoldering USB port. It require additional cooling if used in high power configuration. It has been tested with maximum power = 58. Further test will follow. Included antennae works ok but they are quite big and heavy. It is suggested to replace them with proper 5-5.9ghz antenna in long range setups

• product example

• alternative example

Ubiquit Wifistations

This adapter is quite large, but seems to have a good quality amp on it. Useable TXPower is not yet determined, but should be slightly higher than the AWUSH036NHA.

• FCC info

• WikiDevi

TL-WN722N V1

This adapter will provide around 60mW output power. Range should be roughly around 800-1000m with 2.1dbi stock antennas.

• FCC info

• WikiDevi

NOTE: There have been reports that the TL-WN722N V1 seems to be replaced by V2 and V3 versions. These new versions use a completely different chipset and are not compatible. Consider asking the seller for the version, if it says "V2" or "V3" on the back of the dongle it's the wrong chipset!

NOTE: The PCB antenna causes packetloss and bad reception under certain circumstances. It is recommended to disconnect the antenna by moving the SMD component as shown below:

AW-NU138

This adapter is very small, output power about 50mW. The internal antenna can be de-soldered and replaced with an external antenna. Since it's very small it runs quite warm, good cooling is needed.

• FCC info

• WikiDevi

AW-NU137

Very similar to the NU138. Reported power is 70mW. I-PEX antenna connector allows for light weight build.

• FCC info

• WikiDevi

Taobao Card

Store link

This is a generic RTL8812au card sold on Taobao, which is where the name comes from.

It is a widely used card and known to work well, but it does tend to get hot. Reported power output is 500mW. This card requires soldered wiring or the USB connection may disconnect before or even during flight.

It supports 2x u.fl antenna connectors.

re3332r0115

These are spare parts for an RCA smart television, and contain a Mediatek mt7601u chipset along with a single u.fl connector. They are extremely small, barely larger than a few microSD cards lined up, and only weigh 2.7 grams.

These are not high powered cards and should not require a heatsink, but do not produce anywhere near the power output of some of the other cards.

Finding alternatives

The following USB WiFi dongles with the following chipsets work and are actively supported:

• Atheros AR9271 (2.3-2.6G ONLY!)

• Realtek RTL8812AU (5.8G ONLY!)

For cheap alternatives check out the usual computer stores and maybe consider AliExpress. Be a little careful, some cards are of questionable quality. Generally, High-Quality/Brand Name modules from ALFA WIRELESS with the AR9271 or RTL8812 chipsets perform best.

A good way to find out more about WiFi sticks and modules offered online is to look for product numbers, chipsets, or even better an FCC ID. With those, try to find high-res internal photos of the cards, to find out the chipset and the amps used.

Search the web for those numbers and also these two very helpful sites:

• https://fccid.io/ (FCC documents which contain internal photos)

• https://wikidevi.com/wiki/ (general info and sometimes photos)

When you have found photos, google for the numbers on the amps to find a datasheet giving a rough estimate about the expectable output power.

It would be nice if you report back your findings in case you tried a WiFi card that is not listed here.

External amp

Another way to increase output power is to use a low-power WiFi stick combined with an external amp like this "2W" amp:

Banggood amp

Real output power is around 600mW with a low-power AR9271 stick.

AliExpress bi-directional amp

Allows for bi-directional communication and amplification, great in combination with a low power "Green Stick".

Wiring the system for stability

While it may seem like you could just connect the WiFi adapter to one of the USB ports, supply power to the raspberry pi and go fly, it's not quite that simple.

Some lower power WiFi adapter such as the TPLink 722n V1 may work out that way, but others may not. If your WiFi adapter needs more power than it is able to draw from the Raspberry Pi USB port, you will see "interference" that isn't really interference, dropped video frames, and potentially sudden video blackout. That could happen during flight if you don't take some simple steps to avoid it.

In addition, if the USB connection is briefly moved or subjected to vibration, it may cause the WiFi adapter to reset or disconnect from the system. This disruption might be just long enough to completely stop the connection between ground and air.

The solution for those kinds of problems is to solder power from a BEC or other 5v power supply, to the WiFi adapter(s).

It is also strongly recommended that you solder the USB data lines. On some WiFi adapters this is easy because they have ready to use solder pads, or have a mini-USB connector on the adapter (in which case you don't have to solder anything to the adapter itself, just the other end of the cable).

General tips and guidelines

• use short wires

• use wires with at least 20AWG gauge (0.5mm²) for any power wires. Signal wires can be a lot thinner.

• use a shielded USB cable with the shield soldered to ground. If you use unshielded cables, twist the signal wires.

• solder everything, avoid any USB cables or plugs without a latching mechanism

• use a quality BEC with at least 3A

• consider adding low-ESR electrolytic capacitors near the WiFi adapters and the raspberry pi

• do not use USB power banks

• do not use the micro USB connection on the raspberry pi for power

• do power the raspberry pi through the GPIO pins or by soldering power to the underside of the board

• do make sure the camera cable is properly seated on both ends

  • On the raspberry pi zero, the camera connection is not very secure, especially if you have connected and disconnected it many times

  • You can secure the camera cable with some tape or a drop of hot glue

• do make sure the raspberry pi and WiFi adapters don't get hot

  • Consider adding small heat sinks, but be sure they will remain firmly attached with strong thermal tape

• Keep the antenna away from the camera and camera cable

• If you see straight vertical lines in the video, you may need to use a shorter camera cable or shield it with foil

• The system can potentially interfere with 433Mhz, 868Mhz LRS, or GPS

  • If you encounter problems like this, consider separating, shielding or changing some of the components (ask us for help)

In General plan to specifically allocate power to the PI and specifically to the Wifi Card

POWER PI options:

• A micro usb (not recommended)

• B solder wires from bec to micro usb points

• C solder wires from bec to gpio (recommend)

AND

POWER WIFI options:

• 1 micro usb plugged into pi. No other wiring... (DOESNT WORK)

• 2 solder wires from the micro usb power point to the pi wifi usb power points (not recommended)

• 3 solder wires from bec to the pi USB Power points

• 4 solder wires from bec to wifi card (recommend)

Power wiring

Ground

Much like the Air SBC, the Ground SBC will likely be powered by a LiPo battery. The Raspberry Pi and the WiFi cards all use 5V, which is what most BEC's produce. So hook up one of your SBC's to a LiPo battery and use a multi meter to double-check the output is +5V.

When you have verified the output of the BEC, you can connect it to the Raspberry Pi, to do this, you have two options. Soldering or using the GPIO Pin Header, for the Ground SBC it's OK to use the GPIO Pin Header, for the Air unit we recommend soldering. Connect the output from the BEC to the PI on pins 2 and 6 (or 4 and 6) according to this diagram:

This can be done easily by just plugging in the Servo header that comes with most BEC's into the Raspberry Pi Pin Header. Make sure the RED wire is connecting to Pin 2 or 4 and the BLACK wire is connecting to PIN 6. Now when you connect power to the BEC, the Raspberry Pi will power up!

The 3A BEC can also power a 7" HDMI screen with a micro USB connector.

Now that we have power going to the Raspberry Pi it's time to power the WiFi adapter(s). Due to the way the Raspberry Pi is designed the USB ports do not receive enough power to drive the WiFi cards, especially when connecting more than one WiFi card as is often the case on a ground station.

To mitigate this problem it is necessary to power the WiFi card(s) directly from the BEC as well. Please refer to the diagram below to see how. Please note that 5V and GND are NOT connected to the Raspberry Pi USB Port.

Soldering as much of these connections as possible will prevent accidental disconnects. On the Ground side, soldering might be optional, on the Air side it is mandatory as it is subjected to greater vibrations.

Air

Much of the explanation for the Ground wiring also applies to the Air, except that where it is likely no problem to use USB adapters on the Ground, using them in the Air will absolutely cause problems. It is therefore absolutely recommended to solder as much as possible in the Air setup and if you want to use connectors, please use connectors that can withstand the vibrations and stresses of being in a vehicle.

When using the Raspberry Pi Zero as an Air SBC you can solder the power and USB data lines to the points shown in this diagram:

Other connections

Flight Controller

Most Flight Controllers will allow for Serial (UART) connections, while some may only output Telemetry, most modern Flight Controllers will allow true bi-directional communication, allowing the system to send commands to the Flight Controller as well.

In order to connect via Serial to a Flight Controller the following pins must be connected:

Refer to the schematics of your specific Flight Controller to find the right connections for the UART you want to use. Most Flight Controllers have more than one UART, so pay attention!

The Raspberry Pi uses 3.3V level for it's UART, like most Flight Controllers available today (including but not limited to: pixhawk v1, Cube black, Cube orange, Matek FC, holybro FC) while Micro controllers such as the Arduino use 5V. Directly connecting these to the Raspberry Pi will ensure membership of the aforementioned club. As with most issues there are two ways around this, a nice way and a cheap and easy way.

Cheap

Good

A better solution with more guarantees, but slightly more expensive and slightly more complex to wire up is an actual Logic Level Converter. These come in many forms, but in principle they all do the same. Make sure only 3.3V shows up at the Pi and making sure 5V is sent to the connected Flight- or Micro controller.

There are many different types of logic level converters out there, they are mostly very cheap and come with easy enough manuals. You don't need bi-directional logic level converters for serial communication since the flow only goes one way through the wires.

Camera extension cables

CSI camera

It is also important to advise that longer the cable is, the easier it is to absorb and transmit interferences. It is suggested to keep cables as short as possible and in case of interference on video or to other components (such as WiFi card, FC, servos etc) shield the cable using aluminium foil. Flat cables can be easy bed a fold to avoid loosing wires.

Antenna tracker

On the ground SBC you might want to attach an Antenna Tracker, most of these units require us to output the Mavlink data via Serial communication. When only connecting the TX from the Raspberry Pi to the RX of the Ground station no special consideration needs to be given to the voltage levels. Most Micro controllers will allow the 3.3V of the Raspberry Pi as a logic signal.

While support for SBC's other than the Raspberry Pi is underway, currently the only officially supported devices are:

1. it is not a good idea to use a Pi Zero, Pi Zero 2 W or a Pi 3A(+) on the ground side, you may get it to work but the resource requirements (particularly GPU memory) on the ground are higher than they are on the air side.

2. Will work but does not have internal dual band hotspot which will reduce functionality

3. Requires a dt-blob.bin file for your carrier board when used as AIR to support dual cameras at the moment, ask for help in Telegram

4. Zero 2w is currently supported by replacing files 0n the SD with the files available on the telegram user group or from this forum post Zero 2 W Post. Once the SD has been flashed, before booting use a pc to replace the files in the boot partition. In future OpenHD will support this board on the defualt image.

Future support

The team is hard at work to support more SBC's. Active development is done on these SBC's:

• NVIDIA Jetson (series)

• NanoPi (series)

If you want to participate in the development, please reach out to us to see how you can help.

Supported Display Options

Virtually any screen/monitor connected to the HDMI port on your Pi will work. Besides that the following displays have been successfully tested:

• Samsung 32 inch TV connected via HDMI to Pi.

• Pi Official Touch Screen connected to DSI port on your Pi. Resolution 800x480.

• An LCD module from old 17 inch laptop with eBay driver using 1920x1080 to HDMI on Pi. Default FPS.

• Goggles One (1920x1080) (set to fixed 1920x1080 resolution in config.txt!)

• Headplay HD (1280x800)

• Fatshark Base HD (1280x720)

• Fatshark HDO (960x720)

• Fatshark HD1/2/3 (800x600) (set to fixed 800x600 resolution in config.txt!)

• Yuneec Skyview

• Zeiss Cinemizer OLED

Please note that the monitor has to be connected and powered before the Pi is powered because the auto-detection only works at start-up. You can define your (custom) monitor resolution in config.txt statically though to be able to connect the monitor after the Pi is already running.

Using a phone or tablet

Regardless of the monitor attached directly to the Ground SBC you can use a phone or tablet running one of the following apps:

Using a Ground Station

In this scenario the Ground SBC acts as a proxy for the Video and Telemetry for a separate Groundstation. This can be anything you can think of as longs as it is able to interpret the Video and Telemetry and is able to connect to the Ground SBC.

Common examples of ground stations are:

Dual Display Setup

If you would like to use the Raspberry DSI "ribbon" style connection with the popular Raspberry Pi 7" LCD display, you can simply connect it and power it up.

The same goes for any HDMI display, however, by default they cannot be used simultaneously. A patch was created with the intention of implementing it with the stock image however, it created problems with the new Pi3 A+ because the patch did not work and the Pi3 A+ only has 512MB ram

If you want to use MIPI-DSI & HDMI Simultaneously:

You might need to set resolution manually so HDMI matches the default Raspberry Pi DSI LCD Display.

The official 7" Raspberry Pi LCD which is 800 x 480 might need to be set as the default resolution to match so that both displays come up.

In the Openhd-settings.txt file

In the config.txt file

Change GPU memory to:

Towards the bottom of config.txt file change the default field from

To This:

What is the minimum hardware I need to try this?

Two Raspberry Pi, two supported WiFi adapters, one Pi cam (Or CSI-HDMI Adapter), and 2 good quality (preferably Industrial micro SD Cards). See for a minimal example.

What is the lowest latency I can achieve?

On a Raspberry Pi, 110ms “glass to glass”. Although most setups are in the 125ms range.

On other boards it can be significantly lower, as low as 40-60ms has been demonstrated with the Jetson Nano and a carefully selected camera. A public release supporting SBC's other than the Raspberry is forthcoming.

What kind of range can I expect?

It depends, 1-3KM is easy to achieve even with low power WiFi cards and the antennas that come with them.

Carefully chosen WiFi cards, antennas, and optionally an antenna tracker should put 20KM+ within reach, and the current record is 75KM on 5.8Ghz frequency with a 30dbi gain panel antenna.

How long does OpenHD take to regain a lost “connection”?

It depends on the kind of camera you are using, if it is a Raspberry Pi camera and the settings are still left on the defaults, the system should recover from serious interference within 300ms at most, more likely the interference will only partially disrupt the video and you will see momentary noise that will clear up rapidly.

When I lose connection will I see a “blue screen”?

OpenHD does not generate a solid blue screen when interference is encountered. If experiencing a loss of signal you will see progressive artifacts and pixilation, finally the image typically freezes. The telemetry and/or RC link is more robust and will often continue to operate well beyond the loss of the video stream.

Does OpenHD interfere with my RC transmitter?

You can use 2 different bands, 5.8Ghz for OpenHD, and 2.4Ghz for RC. You can also send RC control through OpenHD itself, and avoid using 2 different transmitters. There are tradeoffs however, control latency may be slightly higher than a dedicated RC system, and there are currently some limitations on the channel count.

What is a Raspberry Pi?

A computer on a single circuit board. In this case running a derivative of Linux. Don't worry you do not need to know anything about the software side, we have that covered!

Do I need a WiFi adapters for video, another for telemetry, and another for RC control?

No, just one for ground and one for air.

You can optionally use 2x WiFi adapters on the ground side for "diversity", which improves signal reception.

Can I run OpenHD on this other board (Orange Pi, Banana Pi, BeagleBoard)?

In OpenHD 2.0, no. The system is designed around the Raspberry Pi as it is cheap, widely available, and the video encoder/decoder hardware works properly.

In OpenHD 2.1, several other boards will be supported, however there will be some hardware limitations. Most other boards do not have anywhere near the level of stable software support that the Raspberry Pi benefits from. Most other boards also do not have a CSI camera connector, and even those that do may not have properly working video encoder hardware. On those boards, the only option will be IP/USB cameras that have an internal h264 video encoder.

Note that webcams and other USB video devices that do not have an internal h264 video encoder are not usable with OpenHD, the USB interface is not capable of transferring 720p60 or 1080p30/60 video.

Which WiFi adapters do I need?

Can I use this other WiFi adapter that’s not on the list?

Perhaps, but most likely not.

Only a few WiFi adapters are able to work the way OpenHD needs them to, which limits the selection of WiFi adapters you can use.

Why can’t I just use the Raspberry Pi onboard WiFi?

The built-in WiFi chip on the Raspberry Pi does not work the way OpenHD needs it to for video broadcast, however it can still be used for "hotspot" purposes, the you can connect Android and other devices to the ground station over normal WiFi to receive the video signal.

Why am I seeing noise or interference in the video?

There are many possibilities.

You might be experiencing interference from normal WiFi devices. If that is the case, try another frequency or change location. In most cases if you are outside in a suitable location for flying, there are not many normal WiFi devices around.

If you have a long CSI camera cable attached, it may be generating or receiving interference. You can test this by wrapping it in foil or getting a shorter cable. The kind of interference you will see in this case is very specific, it will look like perfectly straight vertical lines.

The AirPi and GroundPi may also be too close together if you are testing on the ground, this can cause the receiving WiFi card to be overloaded.

It is generally necessary to solder power wires and even the USB data wires directly to the WiFi adapters. The Raspberry Pi USB ports are not capable of supplying enough power to cards that require a lot of it, and in some cases the USB connectors can briefly disconnect during flight which may lead to total video loss. if you are still seeing interference or even video freezes, this should be the next thing you address.

Why do I get a low power warning?

In OpenHD 2.0 you should not be seeing a power warning, however you must still carefully check and wire the WiFi cards correctly to avoid power issues.

How many WiFi adapters can I use?

2x on the air side, 3x on the ground with a Pi3b+. If you are going to connect this many WiFi adapters you are strongly encouraged to use a Pi4b instead of a Pi3b+ for stability.

You can use 4x with a Pi4b, but this is overkill.

Where can I buy the hardware I need for OpenHD?

• eBay

• Amazon

• banggood.com

• AliExpress

• TaoBao (chinese marketplace)

Raspberry Pi are the easiest to find, and you can use any model, but there is no reason to use the old original Raspberry Pi and it is unlikely to work very well.

Is OpenHD legal to use?

Open.HD uses normal WiFi hardware, which is perfectly legal to buy and use.

However, some frequencies such as the 2.3Ghz range, and high power settings, might not be legal in your location.

Open.HD can be disruptive to nearby WiFi networks due to the continuous broadcast, and some of the things that can be changed in the Open.HD settings file can make this worse.

You are responsible for your use of the system, but please ask us for advice if you are concerned about a particular setting or use case.

Can someone else watch my video stream?

Yes, you can receive the video with any GroundPi that is configured to the same frequency as your AirPi.

The system is not encrypted in Open.HD 2.0, but encryption is being added.

Where did my recorded video go?

Why is the OSD not on the video recording?

In older versions of OpenHD, this was not easily possible due to the way the GPU works in the Raspberry Pi, however it is being added in the new QOpenHD OSD, which can run on the ground station.

What is diversity?

A way to improve the reliability and quality of video reception.

If you connect 2 or more WiFi adapters to the GroundPi, whichever adapter is currently receiving the best signal will be used. This is entirely automatic and occurs in realtime, you do not have to change any settings or monitor anything.

Some OpenHD users connect different kinds of antennas to the 2+ WiFi adapters, such as a directional antenna and a normal omnidirectional antenna. This allows for automatic switching from long range to short range, so that you don't have to keep your directional antenna pointed toward the UAV when it is nearby.

What is FEC/Forward Error Correction?

FEC is a way to add redundancy to the video stream.

Because the latency must be kept to a minimum, there is no opportunity to retransmit parts of the video that were distorted by interference. Instead the system will process the video in a way that allows for some of it to be lost in transmission, without affecting the received video on the GroundPi.

There is a cost to using FEC, the radio bandwidth is a little bit higher (or viewed another way, the maximum video bitrate/quality is a little bit lower). However it is mandatory for safe flight, without it the video would be very easily distorted.

Is latency going to improve in future updates?

Latency is almost entirely a result of the kind of video encoder and decoder hardware being used on the AirPi and GroundPi.

With the Raspberry Pi, there is a lower limit to the minimum latency that can be achieved. This is generally somewhere between 80-90ms, and that requires a particular configuration.

On other boards, latency as low as 40-60ms is possible with a carefully selected camera and video decode/receive hardware.

What do these numbers mean on the OSD display?

Which RC protocols are supported?

The AirPi can send SUMD/Graupner, IBUS/FlySky, SRXL/Multiplex, and Mavlink to the flight controller board.

If you are using Mavlink for both RC and telemetry you will only need to wire 1 pair of UART wires between the AirPi and the flight controller.

Which telemetry protocols are supported?

Mavlink, FrSky, LTM, Vector, and a few others will work with the OSD.

Mavlink supports 2-way communication in OpenHD, which means you can connect a GCS to the ground station and the GCS can change the flight controller settings (for Ardupilot in this case).

What is an AirPi / GroundPi?

This is a shorter way to refer to which Raspberry Pi is transmitting video and which one is transmitting RC and/or uplink telemetry.

They are configured a bit differently depending on their role, and it is critical for each one to know what it is supposed to be doing. At the moment this is determined by looking for a Raspberry Pi camera or a file called /boot/air.txt, if either are found the system knows it is supposed to act as an AirPi and will configure itself accordingly.

How about Circular vs. Linear polarized antennas?

Circular antennas are known to be very effective in suppressing signal reflections (multi-pathing), which degrades the quality of analogue transmission.

Digital systems are not affected by multi-pathing though (and often can take advantage of it). Circular antennas are not as important like they would be with an analog video system.

However, circular antennas still have some advantages compared to linear antennas:

• They work independent of angle to each other, almost no polarization losses

• Typically circular antennas have a lower gain, and thus higher opening angle than linear antennas

• Less susceptible to signal blocking from nearby solid objects

How can I support this project?

Use the system! There are a lot of different features and settings and possible hardware combinations, it can be very difficult to test everything each time we release an update. As a result, we depend on users to tell use when something is wrong, or whether something should be improved.

We also frequently need translators who can read/write both english and another language, as the system supports translation in the OSD.

And of course if you have an idea for something you would like to see use add or change, let us know in Github Issues, on the forum, or on Telegram.

Donations

Donations are handled through , a non-profit 501(c)(6) funding host.

You can make a single or monthly donation of any amount.

100% of donations are used for hardware purchases to ensure team members have access to the SBCs, cameras, and radios they need to help work on the project.

Contributing to Open.HD

The Open.HD project uses git to manage the source code used to build Raspberry Pi images, as well as companion apps for desktops and smartphones.

Repositories

There are several repositories for different parts of the Open.HD system.

• , the main repository containing the custom code for sending/receiving video, telemetry, and RC control data

• , the repository containing the scripts used to build air/ground images for the Raspberry Pi

• , the new desktop/smartphone/ground station OSD and settings app

Git

You don't need to be a git expert to work on Open.HD, but you should be familiar with the basics.

It is highly recommended to read through a Git tutorial and to use a Git GUI client, for example (highly recommended, but Mac, Windows only), (Mac, Windows, and community build for ), or (Mac, Windows only).

A GUI is not strictly required, but makes a lot of things much easier, particularly if you need to see which commits are in a specific branch, or whether 2 branches have been merged yet. It also makes it much easier to create tags in a particular place in the repository history and "cherry-pick" specific commits into a separate branch, in order to create a pull request on Github.

A Git GUI can also automate the process of "logging in" to your Github fork whenever you push changes to it, without it you either need to setup SSH keys (requires several steps, but not particularly complicated), or enter your Github password every time you push changes back to Github.

This document will give instructions for the command line, because they can be used anywhere and the exact steps can be easily provided.

Contributing a fix or feature

Once you have your own fork on Github, you can clone it to your local machine, replacing "username" with your Github username:

Note that when we clone a new repo from the Internet, Git will assign a new "remote" to the place it came from so that we can easily interact with it again.

By convention, the first remote is called "origin", so if you see references to "origin" later in this document, keep this in mind: it's just shorthand for referring to that particular remote repository on the Internet.

You can see the remotes registered in your local repository like this:

Make a new branch

Before you start making any changes to the files, you should now create a new branch specifically for your changes.

If you are working on a fix for a bug affecting the airspeed display, you might create a branch called fix_airspeed. You should always keep unrelated changes in different branches so they can be tested separately and submitted to the main repository as individual "pull requests" on Github.

(Once you're more familiar with Git, you can even switch back and forth between multiple branches on your machine in order to keep unrelated features or fixes separate from each other. This is particularly useful when one set of changes isn't quite done yet, you can "set it aside" in another branch and come back to it later.)

Start by making sure you're in the master branch, which should be your starting point for any changes:

If not, checkout the master branch:

Then create a new branch and check it out in one step (the -b argument creates a new branch):

Now you can verify that you are in your new branch:

Now make your changes to the files in the repository.

Stage your changes

Let's say we changed several lines in a file, and we want to see what changed before we continue.

We changed the render.c file, but we haven't yet staged those changes.

Staging allows us to select which particular changes we want to commit right now, which makes it possible to commit things separately, even individual lines in a file. This is significantly easier in a Git GUI, but for now all of our changes are in one file and they all go together, so we can stage all of our changes in that file:

Now git status should tell us that the file has been staged:

Commit your changes

Now we can commit those staged changes:

The -m argument provides a commit message, and you should always use quotes around your message.

Push to Github and open a pull request

Now we can push this change to our Github account:

Notice that our new branch has been created on Github as well, but in our own account.

Now we need to open a pull request, and Git has helpfully provided a link we can copy/paste (or depending on the terminal you're using, click).

Releases (for those managing official releases)

To make a new release, you just need to create a tag in your local Open.HD repo and push it to the HD-Fpv/Open.HD repository on Github.

In a Git GUI client, this very easy but how you do it will differ in each client. You can still follow the general steps below but use the GUI to do the same thing the commands do.

From the command line, you would need to do the following steps:

1. Make sure the local repo is in the state you want it. Check to make sure you're in the right branch (run git branch):
2. Make sure that you're tagging the commit you want to tag (run git log, check the top commit):
3. Run git tag -a -m '' 2.0.0rc1.2, or whatever you would like the tag to be.

4. Check the tag to make sure it shows up where you expected, run git log and you should see your new tag on the most recent commit in parenthesis:
5. Push the new tag to the main repo on Github (run git push origin master --tags)

Keep in mind that this command will also push any commits in your local master branch that are not already in the main repo on Github.

You can then click the "Attach binaries" area and select any files you would like to be part of the release, such as SD card images or Android APK files.

Overview

If you have tested a camera, please let us know how it performs by filling out this . We will add the results to the camera matrix.

• Resolutions are maximum, which might not be ideal for performance

• Higher FPS is possible in certain cases with some cams

• HDMI connection implies the use of an HDMI adapter card and incurs additional latency

• Many users report success with HDMI adapter cards and cameras with low latency HDMI out. GoPro and similar are popular and offer perhaps some of the best image quality at the expense of greater size, weight, cost and depending on the camera, latency

CSI Camera cables for Raspberry Pi Zero

The Raspberry Pi Zero requires special CSI cables since it has a smaller CSI connector on the board. You can find these on sites like AliExpress, we have included two example links:

Feel free to use any other cable you might find, these two are known to work.

OTS sensor plus lens for Pi camera V2

Not official from Raspberry but this 3rd party sensor has support for 8mm lens allowing the user to select any OTS 8mm mount lens for custom FOV. Compared to original optic, this one provides more light to the sensor allowing it to operate better. It is plug and play and doesn't require almost any tool for replacement (double side tape provided)

Latency considerations

When very low latency is required, every part of the system from glass-to-glass must be carefully chosen and tuned. In some cases a particular combination of SBC + camera sensor may be required.

Generally, there must be an H.264/H.265 encoder inside the camera board itself, or there must be a CSI connection between the sensor and the SBC to ensure that frames are transferred and encoded as fast as possible.

Some USB 3.0 cameras might be capable of ultra-low latency when paired with a suitable SBC with a zero-copy video processing pipeline, but in most cases USB cameras are only suitable when they have an internal H.264 encoder.

IP cameras are not specifically designed for low latency, and many of them have latency upwards of 500 ms+, but there are specific cameras available for purchase that have reasonable latency closer to 100-200 ms.

USB Cameras

Logitech C920

Note that in recent years Logitech has been removing the H.264 encoder from all of their webcams, if you buy one new it may not actually have an H.264 encoder inside and that would prevent it from being used properly in Open.HD.

C1 series from Kurokesu

These are exceptionally well made USB H.264 cameras built with high quality sensors and a Sonix chip to handle image processing and H.264 encoding. Latency is reported to be 90-125 ms minimum.

A USB H,264 camera with an IMX290 sensor and an onboard ISP tuned for low light, also supports HDR/WDR. Should work with every board supported by Open.HD, including the Nanopi series. It is expensive, but may be useful to someone.

Comes with an M12 lens with 132° FOV.

There are 2 boards, one with the camera sensor 40 mm x 25 mm, and the other 25 mm x 65 mm board contains the encoder and USB connector, the total weight for everything is 37.5 g.

HDMI Input

These adapters will allow you to connect a camera with an HDMI connection, which allows you to use more than just the usual pi camera sensor boards. Depending on the camera, this may give you a much better picture, including support for things like WDR.

All of the small/cheap Toshiba chip boards are very similar, and will support up to 1080p25 or 1080p30 HDMI camera resolution on most of the pi models.

This is a limitation of the CSI connection between the adapter and the pi. The Raspberry Pi Compute Module boards are technically capable of 1080p60, however the driver needs a minor change to support 1080p60 and that has not be done yet.

Note: If your camera only supports 1080p60 or 4k60 output on the HDMI connection, it will not work with any of the Toshiba boards.

Latency test

This was done by the user Bortek, using the Auvidea B102 with a Gopro4 camera.

Camera compatibility

• GoPro4

• SJcam M10

These cameras do not work!:

• Samsung NX500 (1080p60, framerate too high)

• Canon EOS M (1080i, interlaced output is not supported by these adapters)

Settings

They will be auto detected and do not require special settings, but you should still set the resolution and frame rate to match your camera in openhd-settings-1.txt like this:

You may need to change the resolution/frame rate on the camera itself so that it does not exceed the capabilities of the adapter board.

DCDZ HDMI CSI-2 adapter

Very widely used for Open.HD, but only available through AliExpress and Taobao, so those of you in the U.S. or Europe may have trouble getting them quickly. See the similar Geekworm board below, those are available on Amazon.

Has a connector for both the Raspberry Pi Zero and full size Raspberry Pi models, none of the other cards do.

Geekworm HDMI CSI2 adapter

Available on Amazon in the U.S., and is similar to the DCDZ adapter above.

Has a connector compatible with the full size pi models.

Auvidea B102

Same basic capabilities as the others, but has a connector compatible with the Pi Zero only.

Auvidea B101

Same basic capabilities as the others, has a connector compatible with the full size pi models.

Lintest Systems PiCapture HD1

This is a more complicated (and expensive) card, it supports HDMI just like the others (with the same limitations), but also supports analog component input, though it is unlikely that any camera worth putting on a drone will have component connections (they were common on HDTV's and DVD players at one point).

The adapter has LED's that will tell you whether the camera connection is OK.

HDMI Cameras

An HDMI camera specifically designed for drones, has onboard recording to Micro-SD on the camera itself, WDR support and weighs 60 g.

Thermal Cameras

Open.HD supports several thermal cameras, including the FLIR One, the Seek Compact, Hti-301, and others.

Thermal cameras generally connect via USB, and you do not need to do anything except configure the Open.HD settings file to get them working.

Note: This page needs example flight images from each thermal camera, if you have any please get in touch with us so we can add them.

A Warning

Thermal cameras are nothing like normal cameras! Review the available info about each camera before you make any purchase decisions.

It may seem counter intuitive, but a thermal camera with a resolution of 204x156 can be significantly worse than one with an 80x60 resolution. The entire thermal imaging system in the camera matters, from the lens material and size, to the kind of sensor inside, the resolution of the sensor, and the image post-processing done by the camera.

Any poorly performing part of the system can severely degrade the image produced by the camera, potentially making it unusable for a particular use case. Sometimes that is an acceptable trade off in order to reach a low price point.

And keep in mind that a particular thermal camera might be OK for close up electronics work or basic household uses, but could be terrible for drone flight.

Legal restrictions

Thermal cameras are highly regulated items, so depending on where you live you may have to pay a higher price for a specific camera, obtain a license of some kind in order to import or possess it, or may not be able to buy one at all.

The frame rate is generally the issue when it comes to regulations, not the resolution. The reason for that restriction comes from the possibility that a thermal camera could be used for as part of a weapon.

If you live in a country that is part of the Wassenaar agreement, you should be able to buy 30/60 Hz thermal cameras but the price may be higher if they were imported from the United States.

There are Chinese companies such as Hti Instrument that sell directly on AliExpress, TaoBao and through their own websites. If you have trouble getting a FLIR or Seek camera from the United States, you may have better luck with something like Hti.

Camera Overview

Flying with a thermal camera

You will want to give some consideration to what you will actually be able to see with a specific thermal camera in a particular situation.

Very low resolution thermal cameras may allow you to see that a hot object is in a particular area, but you may not be able to tell what it is. In some cases like search and rescue, this may be perfectly fine, but in other cases you may need higher thermal resolution.

Remember we're talking about sensors with very low resolution to begin with, for example a 1280x720 FPV camera has 48x the resolution of a 160x120 thermal camera. At longer range you may not even be able to see an object at all, even if you can still see it with the main FPV camera.

Another consideration is the thermal "span" of the area in view of the thermal camera, if the ground is the same temperature as the trees, objects and animals (for example they're all around 97F), you will have trouble seeing anything but noise or a flat image with many cameras. In that case you would need to look for a camera with a low NETD rating, and a good sized lens.

FLIR Tau 2 and range test

FLIR Boson 320 flight over a neighborhood

Lenses

The lens on a thermal camera is not ordinary glass (which does not allow IR wavelengths to pass through).

Germanium lenses allow for high quality thermal images, but they are expensive. Most cheap/light thermal cameras will use Silicon or Chalcogenide lenses instead.

You generally cannot replace the lens on a thermal camera unless it was specifically designed for it, and even those that are designed to have removable lenses sometimes require very careful handling to avoid causing damage.

Camera information

Below are some brief descriptions of individual cameras from the table above, please read this info carefully before buying any of them.

In some cases a thermal camera may require a different SBC, a video adapter of some kind, or special software in order for it to work properly.

FLIR One G2

These are designed to connect to a smartphone, there were iOS and Android versions with different connectors. The Android version has a standard Micro USB connector and can be connected to an Open.HD system with a USB OTG cable.

Many people use these cameras, they are well known and they do work, despite the low resolution and thermal performance.

The resolution is 160x120, which is the absolute minimum you would want for drone flight. You will be able to see heat signatures but without much detail.

The sensor inside the FLIR One G2 is a FLIR Lepton 3 (confusing, yes), which is a very good thermal image sensor. However FLIR's lens and image processing choices reduce the image quality.

DO NOT BUY THESE, they are significantly worse than a G2. Even when the G2 was new, it was only about $50 more than the G3 is now, it's a very bad deal.

These are largely identical to the G2, they have a Lepton 3 sensor with 160x120 resolution.

FLIR created 2 different price points with the G3 and G3 Pro. The Pro is significantly more expensive now than the G2 was when it was being manufactured and sold, but you can still find used G2 cameras for $120-200 on eBay and other websites.

These are cheap, but have always had significant issues due to the lens and the sensor. You are much better off with a FLIR One G2 if cost is your primary reason for looking at these cameras.

Model numbers for these cameras do not end with an X, e.g. UQ-AAA.

These are significantly better than the non-pro model, the sensor is 320x240 and has a Chalcogenide lens.

There is still a fair amount of noise in the system, these are better for scenes where there is a big difference/span between the hottest and coldest object in view. When the thermal span is small, the noise in the system can become very obvious.

Note that Seek has quietly updated these cameras over time, so you may have one that works more like a FastFrame even though it wasn't marketed that way when purchased. They have also made some improvements to the sensor and firmware over time.

Model numbers for these cameras end with an X, like UQ-AAAX. The UQ-EAAX is an export version but is otherwise identical.

Same as the regular Pro, but the frame rate is never locked to 9 Hz, and can instead reach at least 15 Hz.

These are export controlled items because of the frame rate, you can buy them easily in many countries but you may have trouble ordering one if you have to ship across a border.

These are basically clones of the Seek Compact Pro.

The camera housing has a very awkward shape compared to most other thermal cameras, the side with the sensor and lens has a significant bump.

A very good thermal camera with 384x288 resolution and a fairly large germanium lens and a frame rate of 25 Hz. They are expensive compared to some others, but the thermal performance is very good.

These cameras are designed to work like a normal webcam, in that there is no special driver required.

Note that you may have trouble getting 25 Hz video streams out of these when used with a raspberry pi due to USB limitations.

A 320x256 thermal imager "core", full 60 Hz frame rate but FLIR makes a 9 Hz version as well. They are fairly expensive but have Germanium lenses.

Unlike most of the other cameras these are not designed for a smartphone, they are designed for integration in something like a larger camera system or a drone. You must buy an appropriate connection board to snap on to the back of the camera, some have USB while others have analog video output. For Open.HD you would want the USB kind, analog video requires a special adapter to digitize it again and most of them will not work well with a raspberry pi.

These are export controlled items due to the very high frame rate.

Note: as of the time this wiki page is being written, I am not aware of anyone having used a Boson with Open.HD, there may be some changes required in software to make them work.

Real world flight video:

Same as the 320 model, but with higher resolution.

The features as per the latest include:

• Supports the following single board computers (SBC): - Pi Zero, Pi Zero W (constraint in several aspects such as bitrate but working) - Pi2B, Pi3B, Pi3B+, Pi3A+, Pi4, Odroid-W, Pi (NOTE: Ground Pi shall be Pi2B or higher)

• Support of numerous camera modules: - Raspberry Foundation V1, V2 and HQ cameras - InnoMaker line of CSI cameras (e.g. MIPI CAM 290-ISP, MIPI CAM 327-ISP) - IP cameras capable of h.264/265 (e.g. Hi3516C based models) - USB cameras (e.g. Logitech C920)

• Multi camera support (e.g. secondary thermal camera)

• HiRes video transmission (typical resolutions/fps): - 1280x720p 60fps, 1296x972p 42fps, 1640x922p 40fps, 1920x1080p 30fps

• High bitrate of up to 12Mbit

• Low Latency (~125ms typical, ~110ms minimum)

• Support for various RF bands: - 2.3/2.4/2.5Ghz; 5.2-5.8Ghz

• Typical range (3dbi omni antennas anticipated): - 2,4Ghz: 1-1.5km (~70mW), 2-3km (~300mW) - 5Ghz: 250m (~25mW), 1km (~300mW)

• Extreme range (record flights with directional antennas/antenna tracking) - 2,4Ghz: approx 30km - 5Ghz: approx 70km

• Easy Configuration - File based configuration (can be done from Windows, no Linux knowledge required) - Change Settings via QOpen.HD App

• Supports different configuration profiles selectable on the field via jumpers or DIP switches

• Forwarding of video stream and telemetry data to 2nd display via: USB TetheringWifi Hotspot, Ethernet, Wifibroadcast relay mode

• Bi-directional Mavlink telemetry support

• Complete Mavlink v1 and v2 support

• Integrated high resolution fully customizeable OSD with support for: Mavlink, Frsky, LTM, Smartport telemetry

• Support for video and telemetry inside: QOpen.HD, FPV-VR, QGroundcontrol, Mission Planner, Tower App

• Automatic detection of portable device (Phone or Tablet) as a second display, just plug it in or connect via Hotspot

• Receive Diversity: - 3 times receive diversity support for 2,4Ghz Atheros (4+ receive diversity on Raspberry Pi 4) - 5 times receive diversity support for 5Ghz Realtek

• .AVI Ground recording, PNG screenshots and telemetry data automatically saved to USB stick

• Automatic graphing of RSSI, packetloss, video bitrate and other data

• No issues as with standard WiFi, no disconnection, video freeze etc, video will quickly recover

• Live and responsive RSSI display with defective blocks and packetloss display

• Stable video reception even in multipathing environments (no constant glitching as with analog)

• Groundside OSD rendering (stays clear and functional even if video breaks up)

• Low-latency/high update-rate RC via USB-Joystick

• Encrypted RC

• Ability to designate strongest WiFi adapter for RC

• Audio

• Frequency Band switching ability

When a project reaches a certain stage, the number of options can be very overwhelming. This section of the documentation is intended to help guide newcomers towards their first functional Open.HD implementation.

Sourcing hardware

Assuming you are starting with nothing, we recommend you get the following hardware:

• A Raspberry Pi4B for the Ground SBC

• A Raspberry Pi3A+ or Raspberry Pi Zero for the Air SBC

• A Raspberry Pi Zero 2 . We no longer recommend a Pi Zero 1, it most likely will be depreciated. (Raspberry Pi Zero needs a different CSI cable)

• Two WiFi cards that support the band you want to use. (See )

• An HDMI cable for connecting the Ground SBC to a screen

• An HDMI capable screen (you can use your TV for testing!)

• Two High class SD Cards of 8Gb or more

• An SD card Adapter for your computer to flash the cards.

• A mobile device capable of running QOpen.HD and connecting to the Ground SBC (optional)

• Two BEC's for powering the Air and Ground SBC's. (See )

• Various lengths of connection wires.

• A soldering iron and required disposables.

Step-by-step

Now that you have your prerequisite hard- and software, we can get down to business.

Step 1: Powering the Ground SBC

This is where the BEC's come in. Much like the Air SBC, the Ground SBC will likely be powered by a LiPo battery. The Raspberry Pi and the WiFi cards all use 5V, which is what most BEC's produce. So hook up one of your SBC's to a LiPo battery and use a multimeter to double-check the output is +5V.

When you have verified the output of the BEC, we can connect it to the Raspberry Pi, to do this, we have two options. Soldering or using the GPIO Pin Header, for the Ground SBC it's OK to use the GPIO Pin Header, for the Air unit we recommend soldering. Connect the output from the BEC to the PI on pins 2 and 6 (or 4 and 6) according to this diagram:

This can be done easily by just plugging in the Servo header that comes with most BECs into the Raspberry Pi Pin Header. Make sure the RED wire is connecting to Pin 2 or 4 and the BLACK wire is connecting to PIN 6. Now when you connect power to the BEC, the Raspberry Pi will power up!

Step 2: Connecting the WiFi Adapter

Now that we have power going to the Raspberry Pi it's time to complicate things. Attaching WiFi cards should be as easy as plugging them into the Pi's USB ports, unfortunately it isn't. Due to the way the Raspberry Pi is designed the USB ports do not receive enough power to drive the WiFi cards, especially when connecting more than one WiFi card as is often the case on a ground station.

Using the diagram above create a USB cable with the D+ and D- soldered to the Raspberry Pi and the +5V and GND soldered to the BEC.

Step 3: Connecting a display

Step 5: Preparing the SD card

Now that we have all the hardware connected to the Ground SBC it's time to put Open.HD on an SD card and boot it up! In order to put Open.HD on an SD card please follow these steps:

2. Extract the archive to a place on your computer where you can find it again.

3. You should now have a .img file.

5. Put the SD card in the SD card reader (if you don't have one in your PC or laptop, get a USB to SD card adapter, they can be found for cheap, but investing in a slightly more expensive high speed adapter will greatly reduce the time spent staring at the progress bar of Balena Etcher)

6. If your OS prompts you to format the card, ignore that.

7. Start Balena Etcher.

8. Select the .img file we downloaded and extracted earlier for the image file.

9. Select the SD card as the target (Balena Etcher should only show the SD cards, but be careful, double-check that the indicated size matches the SD card).

10. Hit write and wat for the process to complete, depending on your SD card adapter this can take minutes to an hour.

11. When Balena Etcher finishes it will automatically dismount the SD card making it safe to unplug it from your computer.

12. Put the SD card in your Ground SBC.

13. Pro tip: Start the second SD card for the Air unit before continuing to the next step, Air and Ground use the same image. That way it will be done when we arrive at the Air unit steps.

Step 4: Starting the Ground SBC for the first time

Now that we have everything connected to the Ground SBC, it's time to plug in the power.

Step 5: Connecting QOpen.HD to the Ground SBC

If everything went well, you should see the SBC boot up and eventually show the QOpen.HD screen on the connected HDMI monitor. If for some reason it does not, please go back and make sure you have followed all the steps exactly as described.

If you happen to be lucky and you are running on a touchscreen you can go ahead and press the Open.HD logo in the top left corner. You will see the menu system that allows you to configure all the settings. If you don't have a touchscreen, don't worry, you can attach a mouse and/or keyboard to the Ground SBC and use those as well!

Optionally you can connect a mobile device (Phone or Tablet) with the QOpen.HD App installed to the ground station. By default the Open.HD image will create a 'hotspot' WiFi network to which you can connect with the device. The default network name will be Open.HD and the password will be wifiopenhd.

When connected to the hotspot start the QOpen.HD app on your device. If all went well you should see the same interface as on the HDMI monitor. Since we don't have an Air device yet it will show a black screen with the HUD, but you should see the Temperature and CPU load of the Ground SBC change as on the HDMI monitor.

TODO: Picture

Step 6: Powering the Air SBC

Power for the Air SBC is much like powering the Ground SBC. So use the steps described there to make sure you hook up an BEC with enough Amps to the Air SBC. Please try to solder as much of the connections that you can, soldering will prevent many troubleshooting steps later on.

Since it is quite common to use a Raspberry Pi Zero for the Air SBC here are some schematics for hooking up power AND connecting the WiFi card to that SBC.

As you can see both the USB Cable and the Pi are fed power from the BEC.

Step 7: Connecting the WiFi Adapter to the Air SBC

This step is mostly covered in the diagram shown above. Let's reiterate that, however tempting it might be, do NOT use the USB connectors on the Pi to connect the WiFi Adapter with a standard cable, you might get lucky, but soldering is the only way to prevent costly lessons.

Step 8: Connecting a camera

We will now attach the CSI camera to the Air SBC, this is a very simple procedure, but you need to make sure to connect the cable 'the right way around' on both ends. First let's take a look at the ports on the Raspberry Pi's.

The pictures above should make it clear how to inspect the camera, but for good measure, here is the connector on the camera side:

So now that we know where the pins are on the boards, let's inspect the CSI cable itself.

So now it's a matter of inserting the cable into the ports with the pins of the cable facing the pins of the connector, pull up the locking tab and insert the cable:

Now using equal pressure on both sides gently push the locking tab all the way down while making sure the cable does not slide out:

Make sure the cable is properly seated before continuing.

Now do the same on the Camera connector. The procedure on the Raspberry Pi Zero is the same, the CSI connector is a bit smaller and in a different place, but it works the same. Be aware that you need a different CSI cable for the Raspberry Pi Zero due to the smaller connector.

Step 9: Preparing the SD card

Now if you've been following the steps to the letter you will already have an SD card from step 5. If not, please use the instructions from step 5 to create a second SD card for the Air SBC.

Good, now it's a simple matter of inserting the SD card into the Air Pi and your air unit is good to go!

Step 10: Bask in the glory of your work

So now comes the moment of truth, apply power to the Ground SBC and subsequently apply power to the Air SBC. Allow both to boot completely, most CSI cameras have a small LED that lights up when the camera is activated, this is a good indication the boot went well and the system has started.

When all went well, and for the sake of this step-by-step we will assume so, you will be greeted by a nice crisp HD video streaming from your Air SBC to your Ground SBC, go ahead and wave at yourself to get a feel for the latency. Please notice that when using the HDMI out to a TV, the TV itself might introduce quite some latency.

Next steps

Open.HD is capable of direct control of your model by transmitting your control data alongside the HD video stream. This potentially means that only a single HF-Link between ground and aircraft is required for all your needs. Essentially there are two ways in which Open.HD facilitates RC control, RC via mavlink (Ardupilot) or RC via a serial protocol (iNAV, Betaflight, Cleanflight).

• If you have a flight controller which can be controlled by MAVLink RC_CHANNELS_OVERRIDE messages then that is the recommended solution. Since the RC_CHANNELS_OVERRIDE is an implementation of the bi-directional MAVLink telemetry protocol both Telemetry and RC can happily co-exist on the very same transmission medium. (See RC over MAVLink)

• If your flight controller cannot be controlled by MAVLink RC_CHANNELS_OVERRIDE messages you can still use Open.HD for RC control. You must have a flight controller that accepts one of the following uninverted serial receiver protocols: MSP, SUMD (Graupner/JR), IBUS (FlySky), SRXL / XBUS Mode B (Multiplex). (See RC over Serial)

If you meet any of these requirements you can eliminate your old radio receiver. As described in this documentation you will configure software and hardware and then plug-in a supported USB joystick (or transmitter) into the Ground unit. The inputs will be sent to the Air unit and forwarded on to your flight controller.

One HF-Link for all aspects of operations: Video + Telemetry + Control

• Only single HF-Link (WiFi) required

• weight savings

• cost savings

• simplicity

• Open.HD RC control has longer range than video

Input Devices / Joysticks

In order to allow control of your model the user needs some sort of USB joystick which will provide input to the Ground unit. For this HID-compatible USB-Joysticks and traditional RC transmitters (with USB/hid ability) can be used as input device. For the sake of simplicity this input device will be referred to as joystick from now on. The joystick simply connects via USB to the Ground unit and gets recognized automatically by the system. All standard HID-compatible joysticks can be used, however we recommend using a decent quality joystick with good quality gimbals and a narrow stick dead-band. Best results have been reported using RC transmitters with a USB-port (normally used for flight simulators).

The following joysticks are known to work well with Open.HD:

• FrSky Taranis X9D

• FrSky Taranis X9D+

• FrSky Taranis X9E

• iRangeX IR8M

• Radiomaster T16S

• GeeekPi Raspberry Pi USB-Joystick controller

Basic setup

Configure RC general parameters

Please make the following modifications to the openhd-settings-1.txt file in the boot partition of both SD cards or use the QOpen.HD app to modify the settings.

EncryptionOrRange=Range
CTS_PROTECTION=Y
RC=mavlink or other option

EncryptionOrRange=Encryption
CTS_PROTECTION=N
RC=mavlink or other option

Optionally you can lock the transmission from the Ground unit to the Air unit to one specific WiFi card on the Ground by setting the MAC address of this card in the config file:

PrimaryCardMac=(MAC ADDRESS)

Configure joystick related settings

Next edit the joyconfig.txt file in the boot partition of both SD cards (same content):

Axis mapping to ROLL, PITCH, THROTTLE, etc. USSUALLY NOT needed to be changed.

#define AXIS0_INITIAL=<value>

sets the initial values for the controls. This is necessary, as it is currently not possible to detect the stick positions until they have been moved. For yaw, roll, pitch you probably want 1500, for throttle 1000.

Wiring

In order for any of this to work, the Air unit needs to be able to talk to the Flight Controller in a proper manner. Please refer to Wiring -> Flight Controller for an explanation on this.

If you use the builtin Serial of the Raspberry Pi leave default RC_FC_SERIALPORT=/dev/serial0, if using an external USB2Serial adapter, set RC_SERIALPORT=/dev/ttyUSB0

Testing

Depending on your Flight Controller make sure you followed either RC over MAVLink or RC over Serial.

Connect Joystick or Transmitter in Joystick mode (Taranis needs to be powered before connecting).

Do a ground test for correct packet reception and signal:

Bi-directional telemetry allows you to send messages from your Ground Station Software to the Flight Controller connected to the Air SBC.

Enabling bidirectional telemetry

By default bidirectional telemetry is disabled, to enable it simple set the following options in the config file or enable them in the QOpen.HD settings.

TELEMETRY_UPLINK=mavlink
TELEMETRY_TRANSMISSION=wbc
RC=mavlink

In order for this to work please make sure you have connected your Flight Controller properly.

General

By default the Open.HD system will use it's own transmission system to send the Telemetry for the Air unit to the Ground unit. This is controlled by the TELEMETRY_TRANSMISSION parameter in the openhd-settings-1.txt file in the boot partition of the SD card.

• If you want to connect your flight controller to the Air unit and use Open.HD for telemetry transmission, leave TELEMETRY_TRANSMISSION=wbc

• If you have some other means of transmitting the telemetry to the ground (e.g. a Long Range System with serial downlink or 3DR dongles) choose TELEMETRY_TRANSMISSION=external to receive the telemetry stream on the Ground unit serial port. If using external telemetry transmission, also configure EXTERNAL_TELEMETRY_SERIALPORT_GROUND= and EXTERNAL_TELEMETRY_SERIALPORT_GROUND_BAUDRATE=

The most common ports used are:

• /dev/serial0 for the internal UART of the Raspberry PI

• /dev/ttyUSB0 for a USB 2 Serial adapter

Wiring

Please refer to the Flight Controller section of the Wiring chapter.

Baud rate and port setting

When connecting a Flight Controller with Ardupilot installed, it is important to also set the correct baud rate both in the FC and in Open.HD. You can use QOpen.HD to modify this setting or directly edit the openhd-settings-1.txt file in the boot partition of the SD card for the Air unit.

Make sure to keep both references to the Flight Controller in sync:

FC_RC_SERIALPORT=/dev/serial0
FC_RC_BAUDRATE=115200

FC_TELEMETRY_SERIALPORT=/dev/serial0
FC_TELEMETRY_BAUDRATE=115200

In the above (default) config we use the Raspberry Pi internal UART to connect to the Flight Controller with a baud rate of 115200. These are pretty default settings. Don't go below 9600 for the baud rate.

The most common ports used are:

• /dev/serial0 for the internal UART of the Raspberry PI

• /dev/ttyUSB0 for a USB 2 Serial adapter

Now connect a PC to the Flight Controller using USB and start Mission Planner.

Using the Config/Tuning -> Full Parameter Tree menu items change the following settings:

Make sure the baud setting matches what you set in Open.HD and for the best performance use MAVLink protocol 2.

Save the settings and disconnect the Flight Controller.

Stream rates settings

When connecting a Flight Controller with Ardupilot installed, it is important to also set the correct Stream rates. Else nothing will be shown on the OSD.

You can choose from different subsets of telemetry information and how often you want the Flight Controller (FC) to stream that particular set of data per second (defined in Hz). These parameters are the so called SRx_Parameters where x represents the serial ports using Mavlink in an ascending order. (If SERIAL0, SERIAL2, SERIAL6 are using Mavlink, the corresponding Paramaters are SR0_, SR1_ and SR6_).

In order to avoid transmitting telemetry data too often over our radio link, we have to select just the necessary data (the right subsets of information) and at the same time find a good compromise on how often this data should be send and thus be updated. The following parameters have to be found working very reliably:

SR1_ADSB=5
SR1_EXT_STAT=2
SR1_EXTRA1=4
SR1_EXTRA2=4
SR1_EXTRA3=2
SR1_PARAMS=10
SR1_POSITION=2
SR1_RAW_CTRL=0
SR1_RAW_SENS=2
SR1_RC_CHAN=2

Connect a PC to the Flight Controller using USB and start Mission Planner.

Using the Config/Tuning -> Full Parameter Tree menu items change the mentioned settings:

Save the settings and disconnect the Flight Controller.

Using the 'old' OSD

By default Open.HD starts the QOpen.HD app on the Ground unit as it contains both an OSD and the full menu system to change the configuration. Some people prefer the older OSD and it is still included in the Open.HD distributions!

To change to the original OSD system, please make the following modification in thopenhd-settings-1.txt file in the boot partition of the SD card for the Ground unit.

ENABLE_QOPENHD=N

Configure telemetry protocol and OSD options in osdconfig.txt (only on the Ground SBC)

• Choose the telemetry protocol used, Mavlink is default, other options supported are Frky and Lightweight telemetry (LTM). E.g.: #define LTM

• Choose graphical OSD options you would like to have enabled in osdconfig.txt. Should be self-explanatory.

Note: INav users must enable the Compass by settings COMPASS_INAV=true

What is SmartSync and why do I need it?

To understand the need for SmartSync we need to refresh the basics.

When Open.HD first started development we wanted to easily change settings as many people working with this project and other branches are interested in experimenting with various frequencies, settings and configurations. Others were primarily interested in using it to just fly and enjoy the beautiful HD video. So, we wanted to make sure we kept things as simple as possible to maintain the plug & play ease-of-use that we want the project to have.

We accomplished a lot by using a dedicated settings and OSD application which makes it easy to change settings on the fly. This left us with two issues:

1. This all-in-one fpv, telemetry and control system is primarily optimized to send video data from the air to ground with some up-link capability for RC and Telemetry as well. So, the QOpen.HD app is able to save settings to both air and ground pretty well however, it can take quite a long time to upload a large number of changes. Under some circumstances, settings can be lost in the process, then during reboot if your video or radio function was changed and not saved you no longer have your communication link in place to assign the correct settings. As such, this requires removing the SD cards and manually editing the configuration.

2. In the case where an FPV Pilot who goes to the field with 3 different vehicles i.e. a mini quad optimized for 720x480p low latency video on 5.8ghz ; A medium range drone set to high data rate for HQ video ; And a long range FPV Plane set to low data rate... Without identical settings on both Ground and Air, the process of matching settings would include removing the SD card from at least one of the sides and manually changing the parameters when switching between drones.

What is SmartSync?

SmartSync is a program that guarantees synchronization between any vehicle and the ground station that you have Open.HD installed on by making the air and ground always briefly start with fixed settings on a specific wifi channel (settable in QOpen.HD) then automatically matches whatever settings happened to be applied on the ground.

Basic Configuration

If you change any setting in QOpen.HD and save them with the AIR vehicle connected, they will be persisted automatically. SmartSync comes into play at boot, by default you don't have to worry about it.

Advanced scenario's

If you want or need more control over SmartSync there are several options to prevent the default behavior. You can use GPIO 26 with a switch to disable SmartSync, or you can use a connected Joystick's Elevator channel during startup.

Aside from the methods mentioned to prevent SmartSync, we also have complete control over the system in the settings. Again, all settings are best modified through the QOpen.HD app.

Not everybody uses this feature, but in some use cases it might be necessary to transmit Audio from the Air unit to the Ground unit as well. This is disabled by default as there are many options that can not be auto detected.

Microphones

Currently 3 tested options

• A Linux compatible 3.5mm audio in/out USB stick with separate CCTV style 5v or 12v powered mic. (best option)

• The small all in one mic (smallest but poor/very low volume)

• Logitech C920 webcam (great audio input/output and if the webcam part of the video feed can be eventually matured it should be plug and play for video/audio)

Audio out on Ground

For hardware you can use the 3.5 jack, or HDMI output on the ground station. Please make the following modifications in the openhd-settings-1.txt file in the bootpartition of the SD card for both Air and Ground unit.

DefaultAudioOut=2 #0 Auto, 1 Analog, 2 HDMI
IsAudioTransferEnabled=1
MicBoost=75
SpeakersLevel=75

To make it easy to connect a Phone or Tablet to your Ground SBC in order to view the video or change settings or even run your Ground Control software the system allows for a WiFi Hotspot by default.

You can change the way the Hotspot behaves by changing the WIFI_HOTSPOT parameter. It takes the following values:

Default SSID an Password

The default SSID is Open.HD and the default password is wifiopenhd. Both values can be changed by editing the apconfig.txt file in the BOOT partition of the SD card. No settings for this have been exposed yet in the app.

Custom Band and channel settings

When selecting the y option you can set the Band and Channel on which the system starts the WiFi Hotspot.

Custom Hotspot WiFi power

By reducing the power of the WiFi hotspot, you reduce the range, e.g. how far away from the Ground SBC you can be while still being connected to the WiFi, but you also reduce the interference impact on the main WiFi reception from the Air SBC.

Automatic WiFi Hotspot shutdown

If you only use the hotspot for the initial setup it might be helpful if it shuts down after an initial period of time. Allowing yourself time to do any setup and then forgetting about it.

Open.HD automatically stores video and telemetry in a temporary storage while it is being received from the Air SBC.

To save video, telemetry and screenshots to a USB memory stick, simply plug the USB drive into the Ground SBC AFTER you are done flying. After a few seconds, a message should appear and the recorded video will start playing on the HDMI screen while being saved to USB. A message will appear when it is done saving.

These are the relevant settings:

In some cases you want to use the Ethernet port of the Ground SBC to connect to a laptop for instance. In this case you can enable the Ethernet Hotspot.

Open.HD currently detects whether it is an Air or Ground unit by looking for an CSI camera. If one is found, the system assumes the role of the Air unit. When you use an IP camera as the main camera, the system will not find a CSI connected camera and will assume the role of Ground unit.

To prevent this, place a file called air.txt on the boot partition of the SD Card you use in the Air SBC. This forces the Open.HD system into Air unit mode.

Inside openhd-settings-1.txt change these settings:

To

Now enable the band switcher:

And remove the comment before these lines:

The settings in those two lines will need to be modified to suit your specific IP Camera and are only provided as a starting point.

Open.HD currently detects whether it is an Air or Ground unit by looking for an CSI camera. If one is found, the system assumes the role of the Air unit. When you use a USB camera as the main camera, the system will not find a CSI connected camera and will assume the role of Ground unit.

To prevent this, place a file called air.txt on the boot partition of the SD Card you use in the Air SBC. This forces the Open.HD system into Air unit mode.

Inside openhd-settings-1.txt change these settings:

To

Now enable the band switcher:

And remove the comment before this line

Now turn on the Air and Ground unit. If all is working as intended you will see a test video stream. Now that you know the basics are working we can send the actual video by changing the USBCamera setting to an appropriate pipeline for your USB camera.

Since this depends heavily on the camera used there is no single solution. We are working on adding predefined pipelines for known cameras. Several examples are included in the config file for now, use these as a starting point.

Fundamentals of RC Control via Serial

Start by selecting the correct type of serial in the openhd-settings-1.txt file in the boot partition of SD card for the Air unit. Please change the following settings:

iNav Configurator Settings

1. Connect your flight controller to the configurator and open the Ports tab

2. Turn on “Serial RX” on the UART you have connected the wire from the Air Pi TX pin. Now save settings

3. Open the Configuration tab. Under Receiver Mode select “RX_SERIAL” and the protocol you choose above. Now save settings

Wiring

Please make sure to follow the guidelines and precautions outlined in -> , but since most INav boards function a bit differently in regards to the serial communication observe the following:

1. Connect the Air Pi tx pin to your flight controller UART RX pin. This is the same UART you have selected in the configurator. This UART might also be shared and/or labeled as the designated serial RX pin (serial RX, SBUS, ppm) it depends on your board. Keep in mind some boards have soft serial capability thereby allowing an uninverted serial connection to be made. NOTE: softserial connections are limited to 19200 baud. This limits you to the msp protocol in Open.HD, which is msp v1. Users have had success with msp RC but beware.

2. Test. Power everything while the FC is connected to the iNav configurator and view the receiver tab

This is an experimental functionality that allows you to switch the WiFi channel width being used for the transmission from the Air unit to the Ground. The available bandwidths are:

5 MHz, 10 MHz and 20 MHz

Using a narrower bandwidth will allow for greater range, using a wider bandwidth will allow for higher quality video but at the cost of reduced range.

To enable this functionality make the following changes to the settings file openhd-settings-1.txt in the boot partition.

This will enable the bandwidth switching feature. Be aware that the MAC address of the most powerful WiFi card on the Ground unit needs to be specified. For example if you have one TP-Link and one Wifistation, use the mac address of the Wifistation card as this is significantly more powerful.

And optionally change the RC channel used to switch between the bandwidths:

You can also adjust the PWM values if they are out of range for your TX:

Also, it is recommended to change this in joyconfig.txt:

To

That will prevent bandwidth from changing at boot time.

This describes the case where you have a CSI camera connected AND want to connect a USB or IP camera as well. The Open.HD system allows you to view both streams simultaneously (using Picture in Picture) and to switch between both streams for the main display. This is often used with Thermal cameras or an extra rear facing camera on a plane.

Inside openhd-settings-1.txt set these settings:

For a secondary IP camera or

For a secondary USB camera. Then set:

Now enable the band switcher:

And enable RC over Mavlink by setting:

And optionally change the RC channel used to swap between the main video feeds:

Please be aware you can switch between the feeds from the main QOpen.HD interface as well without the need of a joystick connected to the Ground SBC.

Displaying the video stream via FPV_VR

Connect your device either via USB Tethering, Wifi-Hotspot or Ethernet-Hotspot to the GroundPi. USB tethering is more reliable and preferred.

Android

FPV_VR app in Playstore Usage information and source code Leave FORWARD_STREAM=rtp in openhd-settings-1.txt to send a rtp h264 stream to the FPV_VR app. RAW is also possible. Most important is that all settings in the app match those on your GroundPi.

Active thread on rcgroups https://www.rcgroups.com/forums/showthread.php?2873827-FPV_VR-Ultra-low-latency-for-FPV-Virtual-Reality-Android-App

Fundamentals of LTE

An LTE stick connected to the Air unit is part of a ZeroTier ( ZT ) network. Any other devices connected to the ZeroTier network can receive data from the Air unit. Any device with a data connection can view video (no telemetry or RC yet) via QOpen.HD app. As of now only one ZeroTier connected device can receive LTE video.

Latency is variable depending on the quality of your 3g/4g/5g connection. Latency has been measured at about 350ms with a 3g connection and 1280x720 30fps raspberry pi camera v2 via gstreamer.

LTE Hardware

• Air unit

• Open.HD compatible WiFi adapter for the Air unit

• 3g/4g/5g data stick. Must be Linux compatible https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/ Hilink compatibility is good. Internal WiFi is probably bad. A good example LTE stick is a Huawei e3372h

• Possibly a sim adapter. Most phone sims are Nano size and many LTE sticks require a larger sim card/adapter

• Telecom provider that does not throttle or limit your data rate or connection speed

• Ground unit and associated hardware is recommended but not required. You could just view your Air unit video sent by LTE on any internet connected device which is also part of your ZeroTier network (your smart phone running ZeroTier and QOpen.HD app)

Setup LTE

• signup for a ZeroTier account and establish a network (its free)

• note your ZeroTier network ID

• setup your viewing device on the ZeroTier network. For phones you will need an app. Computers install a ZeroTier program for your platform.

• wherever you manage your ZeroTier network, confirm that your viewing device is connected ( you probably have to authorize the viewing device). Note the IP address of the viewing device as shown on ZeroTier network manager

• in openhd-settings-1.txt under the LTE section:

LTE=Y
ZT_NETWORK=<your ZeroTier network ID>
ZT_IP=<The ip of the device you want to VIEW the video on>

• install QOpen.HD app on your viewing device. On the QOpen.HD app "video" enable the LTE Video slider control

• plug your LTE stick, Open.HD compatible WiFi dongle, and camera, into your Air unit and power up install happens at runtime, so first time takes extra long (like 1 extra minute, its hacky right now). I highly recommend attaching a monitor to your Air unit and follow the install

• go to your ZeroTier network manager and you should see a new device trying to connect. You probably have to authorize the device with ZeroTier.

• at this point video data should be getting sent by the Air unit -> LTE stick -> ZeroTier -> IP address of ZeroTier viewing device -> QOpen.HD app. ZeroTier network manager will look like this. Note the Authorization check marks on left. Also note I have 3 devices however you can only send video to one IP at this time.

• Troubleshooting: If you do not see your LTE stick connecting to ZeroTier its probably a problem with the install on the Air unit. You can delete ZeroTier tracker.txt file created in boot partition of the Air unit SD card (this will force a reinstall attempt) and hook up a monitor to Air unit to see what's going on. The ZeroTier tracker file gets created upon every install attempt. If that fails you can look at an Open.HD image or in the GitHub repo within wifibroadcast scripts and the file lte_functions.sh. Within lte_functions.sh are the install steps- try those manually on a pi with your LTE stick and attempt a manual installation

• Some of these 3g/4g cards pull a lot of amps. YOU MUST SUPPLY SUFFICIENT POWER TO AIR UNIT AND WiFi ADAPTERS!

Introduction

Mission Planner (MP) is a Ground Control Station (GCS) software for all types of vehicles based upon the ArduPilot open source autopilot system, e.g. ArduPlane, ArduCopter, ArduRover or newest to the family ArduSub. It is compatible with Windows only. It can be used as a configuration utility or as a dynamic control supplement for your autonomous vehicle. Here are just a few things you can do with MP:

• Flash firmware (the software) into the autopilot board (i.e. Pixhawk series) that controls your vehicle.

• Setup, configure, and tune your vehicle for optimum performance.

• Plan, save and load autonomous missions into the autopilot with simple point-and-click way-point entry on Google or other maps.

• Download and analyze mission logs created by the autopilot.

• Interface with a PC flight simulator to create a full hardware-in-the-loop UAV simulator.

• Monitor your vehicle’s status while in operation.

• Record telemetry logs which contain much more information than the on-board autopilot logs.

• View and analyze the telemetry logs.

• Operate your vehicle in FPV (first person view)

Setting up bi-directional telemetry with OpenHD.

In order to use MP in conjunction with OpenHD it is necessary to forward all telemetry to the PC. In the course of this walk-through we will choose to do it the most convenient way, namely using the Wifi-Hotspot feature running off the OpenHD GroundPi (of course you can alternatively connect your PC also via USB Tethering, or Ethernet-Hotspot).

!!! Before we start make sure you have read and followed the section on how to setup RC with Ardupilot. Those things are prerequisites for the following to work properly !!!

Now, Let's gets get started:

1. Enable the WiFi-Hotspot on your GroundPi by editing the openhd-settings-1.txt. Set the following parameters: TELEMETRY_UPLINK=mavlink ENABLE_RC=mavlink WIFI_HOTSPOT=Y

2. Next power on your Air- and GroundPi

3. Connect to the OpenHD WiFi with your computer Default SSID is "Open.HD", default password is "wifiopenhd", channel is 1.
4. Next open up a Command Prompt (press Win+R -> type: cmd.exe -> Press Enter)

Injecting HD-Video into Mission Planner Heads Up Display (HUD)

Forwarding the HD-Video stream to MP is a little bit tricky and does not work right out of the box (other than e.g. for QGroundControl). However once you succeed you will have some neat benefits such as stacking the MP HUD on top of your live video.

Now, Let's do it:

1. In order to display the HD-video we need a third party software named Gstreamer. (Download the 32bit version, since the 64bit version is known to cause issues). You can download it here

2. Now install Gstreamer by choosing the "Complete Install" option. Most preferably install it to C:\gstreamer since it is the default path and some programs depend on the binaries to be found exactly there.

3. Now edit your GroundPi's openhd-settings-1.txt and alter the following parameter: VIDEO_UDP_PORT=5600 --> VIDEO_UDP_PORT=5500 FORWARD_STREAM=raw

4. Put the MicroSD card back into GroundPi and power it on.

5. Connect to the "OpenHD" Hotspot.

6. Once connected, open up a Command Prompt (press Win+R -> type: cmd.exe -> Press Enter)

8. Now start MP. Upon first start it should notify you that a video-stream was detected and advice you to install a missing Addon. Please follow the dialog and install the component. After the install MP will automatically restart.

10. Go ahead and connect the telemetry link by choosing the TCP connect option and proceed as described above.

Displaying the video stream via QGroundControl

Connect your device either via USB Tethering, Wifi-Hotspot or Ethernet-Hotspot to the GroundPi.

For WiFi connect to the OpenHD WiFi with your computer Default SSID is "Open.HD", default password is "wifiopenhd", channel is 1.

Android Manual Setup

QGroundControl App Set FORWARD_STREAM=rtp in openhd-settings-1.txt to send use a RTP encapsulated h264 video stream to the app. Set udp port to 5600

(Modified QGC APP with Open.HD Up/Down RSSI and system data overlay)

The default Ground Station software is already included in the downloaded image! In fact, you've probably been looking at it when using Open.HD for some time now.

The default OSD is so much more than that, if you have a touchscreen you might have found out by accident, if you don't have a touch screen, try attaching a mouse and/or keyboard. Clicking that Open.HD logo in the left top corner will reveal the true power of this fully operational Ground Station!

What is QOpen.HD?

All nerd jokes aside (yes that was a Star Wars reference before), QOpen.HD is absolutely vital to the Open.HD system. When the project started all settings had to be done in a text file and updating anything on the OSD meant recompiling from source. QOpen.HD allows for easy config changes through a touch-enabled interface while also providing a touch enabled interface for the OSD elements.

You can drag and drop, resize, change transparency, all with a mouse or your finger on a touch screen. But what if you don't have a mouse or touch screen? Well, if you connect an Android or iOS phone or tablet running the QOpen.HD APP (yes, it comes as an app as well) it will mimic any change to the OSD on your phone or tablet on the main display as well. How far we have come!

In short QOpen.HD allows you to setup anything Open.HD related, like frequencies, transmit power and what the OSD looks like.

What QOpen.HD isn't

Where QOpen.HD differs from the other Ground Station Software in the list is that it doesn't do any actual vehicle related stuff. You can't setup your Mavlink parameters or load a mission for instance. Now if you don't use any of that you can just use QOpen.HD and nothing else. Most users however require more advanced features like changing parameters and uploading mission plans. That's what the other Ground Control Software in the list is for, but remember to always use QOpen.HD for changing settings that are Open.HD related!

The antennas are a key component for any radio link solution and the same for radio waves are applicable here. The right combination depends on the objectives, like short-range (all-around flight) or long-range flight for more advanced pilots. A good starting point is the default antennas for the wifi cards at the workbench (omnidirectional), once you get confident with the system during a line of sight and short flights, you can move with directional antennas.

As nothing is free, changing your antennas is a trade-off, while omnidirectional antennas give you autonomy to fly around your position, these antennas offer limited range, on the other side directional antennas concentrate the radiated pattern and allow a long-range at the cost of the need of pointing the antennas precisely, in other words, more antenna gains more directional. For the high directive antenna, add components like trackers are recommended to keep always pointing the main antenna pattern lobule to the aircraft.

5 TIPs for Antennas

1. Make sure you have proper wiring and you have followed all previous sections, wrong connections can lower your range or destroy your radio link.

2. Start simple using Omni antennas, and move with directional ones as you get more experience.

3. Make sure you use the same polarization on both sides, Vertical/Vertical, Horizontal/Horizontal. The cross-polarization can work but you will lose 3dB (half of the power).

4. Lower bands like 2.4GHz can benefit the range, however, in some areas, this band is highly polluted and you may consider 5.8GHz. Try changing also the channels in the selected band.

5. When using directional antennas (meant for ground side), always aligned with the airside, consider using ATT (automatic antenna tracker). Omnidirectional antennas are always recommended in the Airside.

The below link explains how the video quality is impacted under different scenarios.

Antenna Hardware

*Links are only for reference purposes. It will be added more as users report, check the connector type in order to make sure it will fit to your wifi card.

Range Calculation

A typical question is related to the maximum range, link budget or system range have relation to three main elements: Transmitter power, Antenna gains, and Receiver sensitivity. The next formula can be used to calculate this:

R = 10^( (Lfs-LM-32.44-20*Log(f)) / 20)

Lfs = Ptx + Gtx + Grx – Srx

where,

• R = range in Km

• f = frequency used MHz

• LM = Link Margin dB

• Lfs = free space path loss dB

• Gtx = Tx antenna gain dBi

• Grx = Rx antenna gain dBi

• Ptx = Tx power dBm

• Srx = Sensitivity Rx

*Network card receiving sensitivity approx. -93dBm. Link margin assumed 10 dB

To understand the impact in range against the transmitter power, the below logarithmic graph shows some calculations using different antenna sets:

This probably will only be done on a Ground-Pi as its usually much harder to give a data connection to an Air-Pi and then login.

ssh into the pi and give it internet connectiviy. Then issue the following commands in this example to update qopenhd app: