⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

The OpenHD Core Team consists of

Thomas B. Project Lead

Raphael S. Lead Developer

Max P. Lead Hardware Developer

Peter A. Lead Embedded Systems Developer

Additional Mentions

Since OpenHD is an open source project, it's hard to name every person who contributed to OpenHD over the years, but here we want to add a few honorable mentions (for privacy reasons we'll only mention their nicknames)

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

I can't find the images.

The easiest way to flash OpenHD images is to use our ImageWriter, just select the Image in the drop down and click flash.

In the advanced tabs there are the images for X86 and Jetson devices.

Where are the config-files ?

With 2.3-evo we removed the complex config files. Everything is set up in QOpenhd or the ImageWriter.

I just get a command line, what do I need to do now?

OpenHD is setup to automatically setup and connect. On the Air you just get a Command Prompt and no interaction is needed. On the Ground QOpenHD will start automatically and give you a GUI. If not you may have made an error while flashing, please remember selecting GROUND while writing your SDCard.

I don't want to use the ImageWriter, what do I need to do.

In general the image writer writes the image, mounts it and writes a file (air.txt) or (ground.txt) into the folder openhd. You just need to do this manually without the ImageWriter. In the future there may be a lot more functionality coming, which then just needs to be done manually.

I can't see the wifi-hotspot

You need to enable the hotspot in the QOpenHD settings first, it is disabled by default.

My camera is not detected, what can I do?

With 2.3-evo we extended the camera support a lot, but to do this we needed to add a way to handle all the new cameras. Autodetection isn't that easy anymore. As default all MMAL cameras are selected, but you can select the right Overlay for your camera in AIR_tmp. The overlays are listed in our camera-tabs in this wiki.

I just bought a camera which is not supported, how can I use it?

Not all cameras are usable, that's why we do not support each and every camera, you can try if it is compatible with one of our overlays, if not it isn't compatible. In general we do not recommend (or actively) support Autofocus cameras, since they are highly susceptible to vibration which can even damage your camera.

⚠️ This documentation is outdated! A current version is available at

The following improvements have been made to the provided wiki page:

Supported Devices:

List of Features in the Latest Evo Release

The latest of OpenHD incorporates a range of advanced features and capabilities:

Enhanced Channel Support

• OpenHD now supports all 2.4GHz and 5.8GHz channels, providing users with versatile frequency options.

Stable Video Reception

• OpenHD ensures remarkably stable video reception even in challenging multipath environments. This stability eliminates the constant glitching commonly experienced with analog FPV systems.

Dual Camera Support

• The platform offers dual camera support for a variety of , including libcamera, veye, raspivid, USB, thermal, and unmanaged cameras.

Custom Camera Integration

• OpenHD is developing together with arducam, specifically designed for the platform, expanding hardware choices for our users.

Two-Way Settings

• Experience real two-way communication settings, enhancing control and customization options.

Integrated High-Resolution OSD

• The OSD (On-Screen Display) features high-resolution visuals and is fully customizable. It also seamlessly integrates with MAVLink telemetry data.

Real-Time Telemetry Display

• Users can monitor real-time data such as Received Signal Strength Indicator (RSSI), packet loss, video bitrate, and other critical information directly on the OSD.

Dynamic Adjustability

• OpenHD enables real-time adjustments of various parameters, including TX power, modulation, video settings, camera configurations, and more.

Picture-in-Picture Functionality

• Enjoy the benefits of an adjustable Picture-in-Picture feature for secondary video signals, enhancing situational awareness.

Reliable Video Link

• OpenHD employs a unique wifibroadcast link with highly optimized FEC, that overcomes issues commonly associated with standard Wi-Fi connections, such as high latency, disconnections and video freezing. The system ensures rapid video recovery.

Secure Link

• OpenHD provides mechanism's to ensure the security of your UAV, including verification and customizable encryption. Always providing a secure link which can not simply be overtaken by external signals.

MAVLink Telemetry Support

• Bidirectional MAVLink telemetry support is integrated, offering compatibility with a wide range of flight controllers, with remarkable stability.

Multi-Device Data Forwarding

• Users can forward video streams and telemetry data to secondary devices using multiple methods, enhancing data accessibility and allowing for custom setups like FPV over the Internet.

Seamless QGroundControl Compatibility

• FC (Flight Controller) settings, video parameters, and telemetry configurations seamlessly integrate with QGroundControl without requiring any modifications. For better integration with existing Groundstations.

Multi Platform Compatibility

• OpenHD is programmed to work on various platforms, like the raspberry pi or X86 devices. On X86 we provide Images with preinstalled and tuned versions of QOpenHD,OpenHD,Inav,MissionPlanner,QGroundcontrol,...

OSD Clarity in Challenging Situations

• The OSD overlay displayed on the receiver remains clear and functional even when video quality is compromised, ensuring essential flight information is still accessible.

Streamlined Configuration

• Configuration tasks are simplified through the use of QOpenHD and the , eliminating the need for complex configuration files.

Efficient Flashing Process

• OpenHD flashing is recommended to be performed using the tool, streamlining the flashing procedure.

Low-Latency RC Control

• Experience low-latency and high-update-rate remote control over the Wi-Fi broadcast link via USB joystick compatibility.

Optimized FEC

• OpenHD employs an optimized Forward Error Correction (FEC) mechanism to ensure the most stable and reliable video transmission connections.

Dedicated Development Team, Beta Testers, and Vibrant Community

• OpenHD benefits from a dedicated and specialized development team that continually strives to enhance the platform. Regular and frequent updates, along with feature improvements, are diligently implemented and tested by this skilled group.

• Our will to always innovate, our supporters via and , allow us to test, integrate, manufacture new and exiting hardware. In addition part of our team is working on , which allows us furter optimize and minimize hardware for OpenHD.

• The OpenHD Community is a thriving and dynamic hub of support and knowledge. In the event of any challenges or issues, the community is always ready and willing to offer assistance and guidance.

These features are just a collection of most notable features, which enhance the capabilities of OpenHD, making it a powerful and versatile choice for remote video transmission and telemetry in various applications.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

Donations

Donations are handled through OpenCollective, 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 OpenHD

The OpenHD project uses Github to manage its source code. The code is split into multiple repositories which itself have multiple branches. Github is also used to build all packages and images. Packages are hosted on Cloudsmith, which hosts and distributes packages for OpenHD.

Contacting Developers

If you're interested in contributing to OpenHD, the easiest way is to join our Telegram development channel. The core-development group is also doing weekly meetings on Discord. Those are not open for everyone, but occasionally we invite guests. If you are interested in cooperating with OpenHD, just write us a message at: development@openhdfpv.org and we'll schedule a meeting.

Repositories

There are several repositories for different parts of the OpenHD system. The most important ones are:

• OpenHD/OpenHD, the main software which handles all the features that are needed to run the OpenHD project.

• OpenHD/QOpenHD, the GUI/Configuator app which displays the video and OSD, but is also the UI for OpenHD.

• OpenHD/OpenHD_ImageBuilder, the repository containing the script which builds all our images.

• OpenHD/OpenHD_KernelBuilder, the repository containing the script which builds all our kernels.

Branches

The most stable code is hosted in #master. New branches are made for major and minor releases. These are either a development snapshot for older versions like #2.0 or contain actively developed non-stable code like #2.2.3-evo, which isn't ready to be pushed into #master yet. The lead developers usually use branches like "consti-test", "rapha-test",... to develop new features and fix bugs. Those branches are highly unstable, aren't ready for non-dev usage and can change rapidly.

Contributing a fix or feature

This is not intended to be a full guide to using Github.

To start start developing/fixing bugs, you should fork the OpenHD/OpenHD repository on Github first before making any changes or cloning anything to your local machine, and then clone your fork rather than the main OpenHD/Open.HD repository.

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.

Now make your changes to the files in the repository.

Comment and Document your changes

When programming changes, please comment as much as possible. Our current goal is to have a highly docomented/commented code in order to make mods and changes easier in the future.

Opening a pull request

To finally merge your code into OpenHD you need to open a pull request.

In your pull request, make sure you describe what you changed, why it was needed and the result of any testing you've done with those changes. If you need help building a new image that can be tested, ask in the Telegram development channel.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

Supported Raspberry's for the AirSBC in descending order from good to worse

Earlier Raspberrys might work, but can't be officially supported anymore.

1. 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

2. Different carrier boards need different dt-blob.bin files, needs to be placed on the root of the SD-Card, if it differs from the ochin board-file

3. The most widely used and cost/effective

Supported Raspberry's for the GroundSBC in descending order from good to worse

Earlier Raspberrys might work, but can't be officially supported anymore.

1. Keep in mind, that your carrier board needs to support HDMI and needs (multiple) USB Ports to be used as Ground.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

On this page we're documenting, the most appearing "bugs/issues" and how to fix them, also we're adding a little troubleshooting information, which will help to understand and document the issue you're having.

WIFI-LED is off or not continiously on

In the newer Realtek drivers the LED isn't controllable anymore, meaning we can not turn it on to show that the device is working.

Since we can not control it, blinking or not even turning on the LED is no indicator of the device or software is malfunctioning.

(Air) Terminal is shown and no stats ?

In evo we do not have any display-stats or indicator that the software is running. It'll show up a regular Terminal for debugging. OpenHD is setup to automatically setup and connect. On the Air you just get a Command Prompt and no interaction is needed.

If you want to see if openhd is running, you can type in "systemctl status openhd", this will show some stats.

(Ground) Terminal is shown and no OSD ?

OpenHD is setup to automatically setup and connect. On the Ground you should get QOpenHD (our OSD). If it didn't you may have made an error while flashing, please remember selecting GROUND while writing your SDCard.

My RPI-0,1,2 doesn't work

With OpenHD evo we stopped support on some platforms, all ARMv6 devices are not supported anymore.

Where are the extended settings for my veye camera

We don't have extended i2c settings for veye cameras, since veye didn't integrate them in standard v4l2 controls.

I can't get my custom display to work

If you need special drivers and need to use KMS as the display driver, we can not support that, since low latency modes are only available on FKMS.

Troubleshooting steps

1. Make sure all your devices are powered via seperate BEC's and you have a keyboard available

2. You can check the status of openhd with "systemctl status openhd"

3. For better debugging please download the journal from our webinterface and provide it when contacting us in our Telegram Chat.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

Starting with the evo releases OpenHD managed the step to be less platform independend, which means that we not only support the RaspberryPi, but can be used on multiple platforms.

Currently OpenHD supports : X86,RPI,Rock5 and our Custom Hardware.

Our custom Hardware will allow the low latency features so many users requested, while also giving superb image quality and size.

Latency considerations

Lowest latency can be achieved with OpenHD-Custom Hardware. Because of carefully selected SBC and Camera and a little "magic", which can't be reproduced on "normal" SBC's. This has the ability to cut the latency in half.

Second lowest latency can be archieved with Rock5, which can hardware encode in realtime h265.

For receiving lowest latency, currently the Rock5 or a X86 System with great performance is needed.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

What is the minimum hardware I need to try this?

Two Raspberry Pis, two supported WiFi adapters, one Pi cam (Or CSI-HDMI adapter), and 2 good quality (preferably industrial micro SD cards).

What is the lowest latency I can achieve?

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

The easiest way to reduce latency is to use OpenHD on a "potent" X86 Laptop, it'll reduce the latency a lot. (This was tested on a "hp omen en1179ng" )

On a Jetson Nano as Air-SBC you can expect to lower the latency, but no official numbers are published yet.

The lowest latency can be achieved on our custom hardware combined with a X86-Ground. There are no official numbers yet, but you can expect to cut your latency in half, which makes OpenHD repsonsive enough to fly on race/freestyle-setups. It's not released yet, but you can follow our progress on the OpenHD Hardware Patreon page.

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. The current record is 75km on 5.8GHz frequency with a 30dbi gain panel antenna.

• YouTube video of 60km flight

• YouTube video of 75km flight

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

OpenHD is optimized to regain the connection fast and without interaction, the time it needs to reconnect is very low (can be counted in ms).

Will I see a blue screen when I lose connection?

OpenHD does not generate a solid blue screen when interference is encountered. When experiencing a loss of signal, you will see progressive artifacts and pixilation, finally the image 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?

OpenHD generally operates in 5.8GHZ, but can also use the 2.4GHZ band (depending on your setup), which should allow you to choose a band your RC transmitter isn't using. You can also send RC control commands through OpenHD itself and thus avoid using 2 different transmitters. There are tradeoffs however. Control latency might be slightly higher than a dedicated RC system and there are currently some limitations on the channel count (16channels maximum).

If you're planning a long range flight and want to have the "best" setup for range, we advise you to use the OpenHD control link, since even with carefully seperated frequencies the range can be affected by any radio signal due to the increased noise floor.

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 adapter for video, another for telemetry and another for RC control?

No, just one adapter for ground and one for air. You can optionally use 2 WiFi adapters on the ground side for diversity, which improves signal reception.

Can I run OpenHD on different platforms ? (Orange Pi, Banana Pi, BeagleBone)?

In OpenHD > 2.2 most of the code has been rewritten. This means that we're much less hardware bound and support for new SBCs could be added in the future. Officially we currently differentiate between air and ground.

Ground:

The most optimized Platform on the ground is the Raspberry Pi, but if you have quite capable hardware, x86 will give you even better latency than the Pi.

Air:

The lowest latency platform is our custom hardware. The second best latency will be achieved with on Jetson Nano (which as limited camera support). The most flexible platform will be the Pi, but it can only encode h.264 video, which will result in increased latency.

What about Orange Pi, Banana Pi, BeagleBone ?

Officially we can not support every platform, but we optimized OpenHD to be enable being ported to different SBCs.

You can also run the groundstation (including QOpenHD) on different platforms, but since every SBC handles decoding/compositing/rendering differently, we can't really optimize everything and the workload for our devteam is limited. Therefore we only officially support Pi and x86 on the ground.

Which WiFi adapters do I need?

See Supported WiFi Adapters.

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

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. We use a custom kernel, which requires drivers for each new card. Basic requierements are monitor mode and packet injection. If the card is stable in both modes and the injection rate is high enough, we can potentionally integrate it.

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, which allows you to connect Android and other devices to the ground station over normal WiFi in order to receive the video signal.

Why can't I use the WiFi-hotspot on Jetson Nano?

Jetson Nano does not have an included WiFi-card, so it can't be used to create a hotspot. You can use usb-tethering or ethernet though.

Why am I seeing noise or interference in the video?

There are many possible causes of interference.

You might be experiencing interference from normal WiFi devices nearby. If that is the case, try another frequency or change your physical 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 copper 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 to each other, 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 and Raspberry Pi. The Raspberry Pi's USB ports are not capable of supplying enough power to power hungry WiFi cards. In some cases the USB connectors can briefly disconnect during flight, which might lead to total video loss. If you are still seeing interference or even video freezes, this should be the next thing for you to address.

Why do I get a low power warning?

In OpenHD 2.3 you can get low power warnings when your BEC is not able to supply enough power. Please change it to a more powerful one. In addition to that, carefully check and wire the WiFi cards correctly in order to avoid power issues.

How many WiFi adapters can I use?

Two WiFi adapters on the Ground are supported.

Where can I buy the hardware I need for OpenHD?

• eBay

• Amazon

• banggood.com

• AliExpress

• TaoBao (chinese marketplace)

Due to the global chip shortage it is currently not that easy to buy all the required hardware. Try to use rpilocator or buy used hardware.

Keep in mind that OpenHD 2.3 dropped support for Pi-Zero, Pi1 and Pi2 (lower than 1.2).

Is OpenHD legal to use?

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

OpenHD can be disruptive to nearby WiFi networks due to the continuous broadcast though. OpenHD starts at 25mW transmit power, which is allowed in every part of the world. It can be configured to use power levels and frequencies which might not be legal in your location, so please check your local regulations before use.

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.

In future releases we'll add a "BindMode" which will only allow people with a passphrase to view your video.

What is diversity?

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

Diversity is currently not enabled in 2.2, but will be added in later versions.

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 towards the UAV when it is nearby.

What is FEC/Forward Error Correction?

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

Since 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 the data 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 FEC, the video would be very easily distorted.

Is latency going to improve in future updates?

In OpenHD 2.2 we started to highly focus on latency. The first releases will have a pretty average latency, but currently we're saving every ms we can. With 2.3 we returned to the same latency, which ez-wifibroadcast had, which was significantly lower than previous OpenHD releases. Thanks to the use of h.265 video encoding (not available on Raspberry Pi) and custom hardware we are able to reduce the latency even more.

What do these numbers mean on the OSD display?

See Telemetry and OSD

Which RC protocols are supported?

We reduced the RC protocols down to only MAVlink, since nearly every FC firmware supports MAVLink.

Which telemetry protocols are supported?

We reduced the telemetry protocols down to only MAVlink, since nearly every FC firmware supports MAVLink telemetry.

What is an AirSBC / GroundSBC?

This is a shorter way to refer to which SBC is transmitting video from the UAV and which SBC is transmitting RC and/or uplink telemetry. Both are using the same OS images.

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 as 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, 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 us when something is wrong or if something should be improved.

If you have any development experiences and time, we're always open to new developers which want to help improve and extend our codebase.

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

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

If you want to support the project financially, you can do so via OpenCollective.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

When a project reaches a certain stage, the amount of options to choose from can get pretty overwhelming. This section of the documentation is intended to help guide newcomers to the project towards their first functional OpenHD implementation.

Sourcing hardware

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

Ground

• A regular Laptop with disabled SecureBoot

• A 8812AU, 8812BU, 8811AU or 8814AU WiFi Card (See WiFi Adapters)

• A fast USB stick, to write the OpenHD USB Image on

Air cheap

• A Raspberry Pi Zero 2:

• High Quality BEC's, one for the Wifi-Adapter and one for the Raspberry. (See Wiring -> Power)

• A (supported Camera) and the required cable (keep in mind, the Pi Zero uses a 22 Pin type B csi cable)

• A soldering iron and required disposables.

• Various lengths of connection wires.

Air more sophisticated (better for advanced features/dual Camera)

• A Raspberry CM4 with EMMC with:

  • An Ochin CM4 carrier board

  • We recommend fitting a cooler to the CM4, because it really can get hot.

  • A 8812AU, 8812BU, 8811AU or 8814AU WiFi Card (See WiFi Adapters)

• A (supported Camera) and the required cable (keep in mind, the Ochin uses a 22 Pin type B csi cable)

• A soldering iron and required disposables for creating the connections to the Wifi-Card

Step-by-step

Now that you have your prerequisite Hardware, we can get down to business.

Step 1: Considerations about X86

When using X86 the genaral rule of thumb is "the more potent"/newer the device is, the lower the latency should be. Keep in mind, that you have enough battery or an external charging device. Its also recommended to use a device with a good screen (high brightness) to have a pleasent experience

Step 2: Connecting the WiFi Adapter to the AIR

Since we use very powerfull WiFi-Cards and most SBC's have limited USB-Output-Power, we need a dedicated BEC for that Card's. In Addition to that it's mandatory to solder the wifi card to the SBC because on the Air-SBC vibrations and movement in general will result in connection problems, that's why we recommend to remove the USB-Connector or at least solder to the USB-Connector. If you need help with that look in our forums, there are some extensive guides how to do it nicely. Also writing in the Telegram or Discord Chat can help you. Is recommended to visit the wiring section to see how to connect everything (Wiring)

Step 4: Flashing the Ground SBC for the first time

Please refer to the (Installation Guide) since its quite similar

Step 5: Booting your Ground

Please make sure SecureBoot is disabled and set up your BIOS(UEFI) to boot from USB. Everything else is beeing taken care of. If QOpenHD doesn't start automatically, please execute OpenHD and QOpenHD which are linked to your Desktop.

(The boot can take several minutes, depending on your usb-sticks speed)

Step 6: Flashing the Ochin SBC for the first time

If you're not using the Ochin board,you can jump to the next step. If you're using the Ochin, you first need to install your CM4 into the Ochin board and flash it. The Ochin board requires external power even when the usb-c is connected. To enter the "flash-mode" push the Button while connecting power. Now you can continue with the normal setup shown in this Video. And when it comes to flashing jump to the next Step

Keep in mind, flashing is very slow, because some limitations of the RPi-Foundation. Do not disconnect while flashing, it can brick your device.

Step 6.5: Flashing the Air SBC

Please refer to the (Installation Guide)

Step 7: Starting the Air SBC

The first boot will take several minutes, because initial configs and setups are executed. The SBC will reboot multiple times. OpenHD will automatically start to transmit Video, if everything is correct.

Problem 1: Not having image but you have connection

To know if you at least have connection you can go to the tab "status" and if you can see both air and ground "live" both are connected and we can move on

If you haven't configured your camera correctly you'll see a black image that says "rebooting camera", in this case look into the "AIR CAM 1" Menu in QOpenHD (the OpenHD Logo opens the Menu) and select the correct camera overlay in the CAMERA_TYPE setting. After this your SBC will reboot and start transmitting video.

Problem 2: Having image but no telemetry

If you dont have telemetry coming from your FC to the ground usually its an issue of wiring (refer to (Wiring) to know how to connect the FC to the air, if not fixed it can be and issue with the baud rate of the uart (remember that needs to be the same) you can change it on OpenHD or on your FC, to change it on OpenHD you need to go to the "AIR" tab and then into the "FC_UART_BAUD"

(Installation Guide)

Step 8: Setting up the link

OpenHD has a enormous amount of settings but the most important ones are going to be explained here below

The first thing that almost everyone needs to set up its the power of the cards, the frecuency and STBC and LDPC, you can do all of it in a single tab located in "OPENHD" and "LINK/QUICK" Also you have the options "SCAN" and "ANALYZE" the first one its very handy to find the frequency where your UAV is transmittings and the second one analyze all the wifi spectrum to find how pulluted are the wifi frequencies (it takes a while)

To change the power please refer to the (TX POWER) STBC and LDPC are two important parameters that needs to be turn on on both air and ground to improve wifi coverage and range by using the two antennas to receive and send at the same time, by default both are off because you CANT turn them on in rtl8811au because it only has one antenna

Now we need to introduce is the "SIDEBAR" that opens in the side of your main screen to allow you to change important settings without lossing eye contact with the video To open it just click on the red circle

In this sidebar you can finish your configuration and also change settings while flying, you can move around it with the touch or with a mouse In this firts tab called "LINK" you can select your wifi frequency (you cant change it while armed), channel width and bandwith

In this tab called "VIDEO" you can select your resolution for the link and also rotate the camera if you wish (the resolution that you set here is also the resolution that is going to be recorded)

In the thrid tab called "CAMERA" you can change settings of the camera itself like saturation, contrast, sharpness and brightness

In the fourth tab called "AIR RECORDING" you can change settings regarding the air recording, in EVO we use air recording instead of ground recording like in 2.0 to improve the experience of the recording by removing the possible interference that can be present in the link By deafult is set to OFF but you can set it up ON or AUTO, in AUTO the system is going to start recording at the moment you arm the UAV

Other very important screen is the one where you can see statistics of the link, to open it click on the red circle

⚠️ This documentation is outdated! A current version is available at

The ochin_CM4v2 board is a carrier board for the Raspberry Pi CM4 module, designed to expose the connections to the peripherals made available by the CM4 module.

Overview

This summary is intended to facilitate the installation and use of the ochin_CM4v2 with OpenHD software.

For more detailed documents, please follow the official GitHub links:

Specifications

• 4x USB 2.0 480Mbps (4x SM04B-GHS-TB(LF)(SN) connectors)

• 1x USB Type-C (for flashing eMMC)

• 2x CSI camera (2x FH12-22S-0.5SH (55) connectors)

• I2C1 (SM04B-GHS-TB(LF)(SN) connector)

• SPI1 / 6 (SM06B-GHS-TB(LF)(SN) connector)

• UART0 / 1 + Video Out (SM06B-GHS-TB(LF)(SN) connector)

• UART4 / UART5 (SM06B-GHS-TB(LF)(SN) connector)

• 1x Ethernet transformerless 100Base-T

• 1x microHDMI

• 2x general purpose LEDs

• RGB LED on external tiny board

• 1x general purpose button on external tiny board

Wiring

Preliminary Considerations

1. The ochin_CM4v2 now supports the uHDMI video output. It is designed to be used both on the “air” and on the “ground” side.

2. The ochin_CM4 does not have a slot for the microSD; it is mandatory to use Raspberry Pi CM4 modules with eMMC (not lite).

3. The Raspberry Pi CM4 module gets pretty hot very quickly, please use an adequate heatsink.

4. The ochin_CM4 cannot be powered via the USB-C connector. The Type-C connector is only used for writing the eMMC.

5. The CSI flat cable is very close to the USBs and is prone to RF noise. It’s suggested to shield the flat cable with copper tape (or at least alu tape).

6. The USB WiFi dongle will draw some Amps, please use supply cables of adequate size between the ochin_CM4 board and the USB dongle.

Installation and Connections

Power Supply

The ochin_CM4v2 board is equipped with a 5VDC switching regulator necessary to power the CM4 module and all the peripherals connected to it. The regulator can accept input voltages from 7.5VDC to 28VDC (LiPo from 2S to 7S) and provide output currents up to 7A. It is possible to use the VBUS of the USB ports also to power the WiFi module. The board is equipped with a current switch that cuts the VBUS for currents higher than 3A to protect the CM4 module. It is possible to bypass the current switch if more current is needed on the VBUS, waiving the VBUS safety (see the ochin_CM4 board manual).

CM4 Module Installation and Flash

The CM4 connectors are delicate and dense. Ensure no dust or debris is on the connectors before positioning the CM4 module. Gently place the module on the connectors until they snap into place. Press the two long edges of the CM4 module until the connectors are fully inserted. Limit disassembly to avoid damaging the connector contacts.

To remove the CM4 module from the ochin board, use the proper extractor. The .STL files for printing the extractor can be found in the “3D” section of the GitHub repository.

Flashing the CM4 eMMC

1. Power up the board with boot configuration as a “mass storage device”.

   • Power off the board (no Vin connected)

   • Press the “nRPiboot” button on the tiny external board and, keeping it pressed, power up the board using the “Vin” Connector.

   • Connect the board to your PC using the USB Type-C port.

1. Run the “RPiboot” software, downloaded from the Raspberry Pi . The PC will see the eMMC partition as if it were an SD card in the SD card reader.

2. Flash the eMMC using the OpenHD imageWriter.

Connecting the CSI Camera

The CSI camera can be connected to one of the two FFC connectors. The copper contacts of the flat cable must be oriented PCB-side.

Connecting the WiFi Dongle

The WiFi dongle can be connected to one of the 4 USB connectors on the board. It is advisable to cut a USB extender and solder it to a GHS connector, keeping the wires on the connector side as short as possible.

Connecting the Telemetry

To connect the telemetry to the FC, use one of the available UART ports. The default UART is UART0 / 1. Ensure that the logic levels of the FC UART are 0V-3V3, as the GPIOs of the CM4 module are not 5V tolerant.

Where to Buy the Ochin?

.

⚠️ DOCUMENTATION MOVED - READ THIS FIRST!

⚠️ This documentation is outdated! A current version is available at

🔄 This documentation is END OF LIFE and no longer maintained

The official OpenHD documentation has moved to: 👉 👈

Please use the new documentation for:

• ✅ Up-to-date information

• ✅ Latest installation guides

• ✅ Modern troubleshooting

• ✅ Current hardware support

Introduction (LEGACY - NOT MAINTAINED)

OpenHD is a suite of software designed for long-range video transmission, telemetry, and RC control. While we originally designed it with hobbyist drones in mind, it can be adapted to a wide range of other applications as well.

What OpenHD Can Do

Our suite can transmit:

• High definition video (with multiple cameras)

• Two-way UAV telemetry

• Two-way OpenHD telemetry (General settings, range-adjustments, channel-changes, wifi-modulation,...)

• RC control signals

All of these signals can be sent over a single transmission channel and telemetry is using MAVlink to ensure high compatibility and stability.

OpenHD digital fpv world record 55km

How does the OpenHD link (wifibroadcast) work

OpenHD employs readily available Wi-Fi adapters, although not in the standard manner commonly associated with everyday Wi-Fi usage. To ensure low-latency and long-distance transmissions, we configure these adapters to function akin to analog video transmission hardware. This innovative protocol, inspired by , has been reimplemented by OpenHD for optimized performance.

The configuration empowers OpenHD to transmit high-quality video and other signals across significant distances while maintaining minimal latency.

QOpenHD App

We offer a multi-platform with a customizable on-screen display (OSD) for live video. The app is designed to work seamlessly with our suite, and allows you to easily view and control your OpenHD transmission.

Support and Further Reading

If you need help or want to learn more, we offer several resources:

• Public and groups for lots of immediate interaction

• Please document problems on

• First intro to Open.HD from CurryKitten on

⚠️ Important Note: Support for OpenHD 2.0.x is no longer provided.

⚠️ Important Note: If you have a problem with a specific version of OpenHD, 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.

⚠️ This documentation is outdated! A current version is available at

The Radxa Single Board Computers (SBCs) are highly capable devices that offer significantly higher performance compared to the Raspberry Pi. Due to their impressive capabilities, we have incorporated support for Radxa SBCs in our 2.4-Evo releases and newer.

However, it's important to note that the software development for Radxa SBCs is currently in its early stages. We recommend using them primarily on the ground where hardware decoding support is only partially functional. Despite this limitation, the performance is still superior to that of the Raspberry Pi.

At present, there is only one camera available for Radxa SBCs, namely the IMX415, which may not meet the requirements of OpenHD. To address this limitation, we are actively collaborating with Arducam to develop and offer better camera options for Radxa SBCs.

For it there is a initial pipeline included, but it may not function well. We're also working on a HDMI pipeline and the integration for this. But keep in mind that only the Rock5B does have this functionality.

In the near future, we have plans to introduce support for the newest camera module from Arducam, the IMX462.

Currently Supported Radxa SBCs

The following Radxa SBC models are currently supported:

The following Radxa SBC models are currently being worked on:

*not technically radxa but we run radxa software on that board, it's also not the best working board, so it may take a lot of time until it is perfectly supported

Radxa Zero3W pins

Even 7 keys mapped to GPIO pins, only Right/Left/Up/Down needed for joystick navigation.

Flashing Your Air and Ground Units with OpenHD Firmware (Windows)

⚠️ This documentation is outdated! A current version is available at

Requirements:

1. A Windows or Linux PC (Alternatively, see "Manual Install" below).

2. a) An SD card reader and a high-quality SD card with a minimum capacity of 16GB (Raspberry Pi only needs 8GB).

   b) A high-quality USB cable (required for hardware with internal memory, e.g., Ochin & CM4 with eMMC).

Installation Guide

Step 1: Download and install the latest OpenHD ImageWriter, which is based on the Raspberry Pi Imager, from and .

Step 1.1 (Only for CM4 with eMMC): If you're using the Ochin,or any other CM4 carrier you first need to install your CM4 into the carrier board and flash it. Some boards requires external power even when the usb-c is connected. To enter the "flash-mode" push the Button while connecting power. Now you can continue with the normal setup shown in this Video. And when it comes to flashing jump to the next Step

Keep in mind, flashing is very slow, because some limitations of the RPi-Foundation. Do not disconnect while flashing, it can brick your device.

Step 2: Open the image writer and select the latest OpenHD release from the drop-down menu. The image writer will automatically download the selected image. Alternatively, you can manually download the image and flash it using the "Custom image" selector. Ensure you unzip the image externally first and then select the .img file (not the .zip file).

Step 3: Insert your SD card into the card reader, and select it from the "Choose storage" option. If you are using a CM4, it will appear as an SD card.

Step 4: Click on "Settings" in the lower-right corner and choose either "Air" or "Ground," depending on whether you want to flash an air or ground image. This step is essential for a functional OpenHD setup; you need to flash one Air unit (select air) and one Ground unit (select ground).

Step 4.1: In this step you can also select a binding phrase to improve the protection of the link (its not mandatory) both binding phrases on air and ground need to be the same (you CANT change it after without a reflash of both air and ground sds), if you want to use it just click on "set binding phrase" and write the phrase (max 10 characters)

Step 4.2: For ground the settings are quite simple, just click on ground and then "SAVE"

Step 4.3: For air you need to select "air" and then the camera you want to use (you can change it after that on the settings) also you need to click "SAVE" when you have finished

Step 5: Flash your image by clicking on "Write." This process may take some time.

Manual Install:

You can always flash OpenHD images using the flashing tool of your choice. In this case, you must manually specify whether you want to boot as an air or ground unit after flashing. For an air unit, create a file called "air.txt" under /boot/OpenHD/. For a ground unit, create a file called "ground.txt" under /boot/OpenHD/.

Note: Filenames are case-sensitive. If you wish to switch from air to ground, it is recommended to reflash your image and then create the appropriate "air.txt" or "ground.txt" file.

⚠️ This documentation is outdated! A current version is available at

OpenHD custom hardware is an ongoing project that is currently being developed and funded through . The project aims to create a small and modular wireless high-definition video transmission system that is capable of transmitting and recording video in various resolutions and framerates with low latency capabilities.

The system is specifically designed to fit into the standard 30.5x30.5mm FPV drone stack system, making it easy to integrate into existing drone setups.

The project team is currently working on refining the design and improving its performance. The custom hardware system will be optimized to work with OpenHD and run specially created software.

It's worth noting that the OpenHD custom hardware project has already progressed beyond the conceptual stage and the team has developed several prototypes. These prototypes are currently being tested and refined.

If you would like to learn more about this project and stay up-to-date on its progress, be sure to visit . The team is always looking for new supporters and contributors to help bring this exciting project to life.

⚠️ This documentation is outdated! A current version is available at

X86 is a quite common Architecture. Most of modern Computers do run X86 processors, which often are much more powerfull then any SBC.

With 2.3-evo we start to support X86 in two ways.

1. We provide Images which are already setup and can be used via plugging an external USB-Drive/USB-Stick into your computer and run it live.

2. We provide X86 packages for Ubuntu 22.04. If you want you can build your own OpenHD Image/Setup right on your computer.

X86 will have different performance gains or losses depending on the Hardware used. The OpenHD Developers use quite potent Gaming-Hardware to test, so your experience will vary.

OpenHD will also interfere with your normal wifi-setup, it requires special drivers and may cause problems on your own installs.Thats why support always will be limited.

Flashing X86

You can simply use our ImageWriter to flash OpenHD images to a USB-Stick. The Images can be found under the Advanced tab. (you do not need to setup ground or air, because it'll be selectable on the Desktop of the Image)

Please keep in mind, that your USB-Stick should be quite fast to reduce boot time.

When booted you'll be greeted by a Desktop which includes the Programs you need to run OpenHD. (You need to run OpenHD-Ground and QOpenHD for Ground usage)

Installing OpenHD on X86

Installing:

Starting OpenHD on X86

We added OpenHD as Standard Linux Application, so you can find it under Applications. Please select OpenHD-Air or OpenHD-Ground depending on your usecase. When running OpenHD as Ground, you also need to start QOpenHD to view the user interface.

Troubleshooting

** Wifi Adapter not found **

• One cause could be that the drivers could not be installed because you are using secure boot

** Wifi Adapter (e.g. Asus AC56) does not show the indicator LED**

• The new drivers don't support intercation with the LED anymore, so this is not a problem

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

⚠️ Important Note: OpenHD does not support ANY autofocus cameras due to their impracticality on equipment with vibrations, such as drones. This restriction includes the official Raspberry Pi V3 lineup.

On the Raspberry Pi, you have the option to choose between two CSI camera modes.

1. Broadcom MMAL (Legacy Camera Stack)

The Broadcom MMAL mode is the legacy camera stack. It only works with original Raspberry Pi Foundation cameras or clones that have the security chip. While it offers better latency compared to libcamera, it has been deprecated by the Raspberry Pi Foundation in favor of libcamera. OpenHD uses Broadcom MMAL as the default option, as done in previous OpenHD releases.

2. Libcamera

The libcamera mode works with both original Raspberry Pi Foundation cameras and a wide range of other cameras. Generally, you can achieve the same or even better image quality using libcamera by selecting the appropriate CSI camera. However, it might not provide the same latency as broadcom mmal.

You can switch between Cameras using QOpenHD (V_OS_CAM_CONFIG), but it requires a reboot.

Note: Autodetection is not available for identifying whether you've connected a camera supported only by libcamera/libcamera-ardu. You must manually select the appropriate CSI camera mode in QOpenHD for OpenHD to detect your CSI camera.

Note: We use a proprietary version of the libcamera library, which ensures compatibility with arducam and normal libcamera while also providing image adjustments which are normally excluded in gstreamer-libcamera. This version is licenced to OpenHD and not Open Source.

Tip: When choosing between the camera modes, consider your latency and image quality requirements along with the compatibility of the camera you are using.

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

As OpenHD continues to evolve and introduce new features that require enhanced performance, we have made the decision to discontinue support for certain hardware that was previously compatible with earlier versions.

The following Single Board Computer (SBC) models are no longer supported:

⚠️ This documentation is outdated! A current version is available at openhdfpv.org

📖 View Updated Version of This Page →

Öchin CM4 Carrier

The ochin_CM4 board is a carrier board for the Raspberry Pi CM4 module and is meant to expose the connections to the peripherals made available by the CM4 module.

Specifications

• 4x USB 2.0 480Mbps (4x SM04B-GHS-TB(LF)(SN) connectors)

• 1x USB Type-C (for flashing eMMC)

• 2x CSI camera (2x FH12-22S-0.5SH (55) connectors)

• I2C1 (SM04B-GHS-TB(LF)(SN) connector)

• SPI1 / 6 (SM06B-GHS-TB(LF)(SN) connector)

• UART0 / 1 + Video Out (SM06B-GHS-TB(LF)(SN) connector)

• UART3 / UART5 (SM06B-GHS-TB(LF)(SN) connector)

• USART4 (SM06B-GHS-TB(LF)(SN) connector)

Wiring

Important notices on the Ochin_CM4

1. The ochin_CM4 has no video output, it is designed to be used on the “air” side only.

2. The ochin_CM4 does not have a slot for the microSD, it is therefore mandatory to use Raspberry Pi CM4 modules with eMMC (not lite).

3. The Raspberry Pi CM4 module get pretty hot very quickly, please use an adequate heatsink.

4. The ochin_CM4 cannot be powered via the USB-C connector. The Type-C connector is only used for writing the eMMC.

5. The CSI flat cable is very close to the USBs and it prone to RF noise. It’s suggested to shield the flat cable with copper tape (or at least alu tape);

6. The USB WiFi dongle will drawn some Amps, please use supply cables of adequate size between the ochin_CM4 board and the USB dongle.

Installation and connections:

The ochin_CM4 board is equipped with a 5VDC switching regulator, necessary to power the CM4 module and all the peripherals connected to it.

The regulator is able to accept input voltages from 7.5VDC to 28VDC (LiPo from 2S to 7S) and provide output currents up to 7A.

Thanks to the great power supplied by the regulator, it is possible to use the VBUS of the USB ports also to power the WiFi module, which is not normally recommended due to the large currents required by these modules.

However it should be noted that, to protect the CM4 module from any problems on the VBUS, the board is equipped with a current switch, which cuts the VBUS for currents higher than 3A.

This allows you to keep the CM4 module running even in the event of a short on the VBUS.

For this reason it is good to be sure to never exceed 3A on the VBUS (it is rare for a module to reach this limit, in fact 3A at 5V are 15W of power drawn).

However, it is possible to bypass the current switch in case you need more current on the VBUS, waiving the VBUS safety (see the ochin_CM4 board manual).

CM4 module installation

The CM4 connectors are quite delicate and very dense, so you need to be careful.

Before positioning the CM4 module, it is advisable to check that there are no specks of dust or other things that could prevent contact of the pins, if necessary clean with a brush and air.

Place the module gently on the connectors until you feel they are seated in each other (there is a first zero force step where they snap into). When you are sure that the two boards are perfectly aligned and the connectors engaged, press the two long edges of the CM4 module until the connectors are fully inserted.

It is advisable to limit the disassembly of the CM4 module as much as possible to avoid damaging the connector contacts.

To remove the CM4 module from the ochin board is always suggested to use the proper extractor.

You can find the .STL files to print here.

Flashing the Ochin

The procedure to flash the CM4 eMMC it’s straightforward, what you need to do in synthesis is the following:

1. Power up the board with boot configuration as “mass storage device”. • To do so you need to power off the board (no Vin connected) • Press the “nRPiboot” button and, keeping it pressed power up the board using the “Vin” Connector. • Connect the board to your PC using the USB Type-C port

1. Run the “RPiboot” software, downloaded from the Raspberry Pi website. After the software starts, the PC will see the partition of the eMMC like if it would an SD into the SDcard reader.

2. Flash the eMMC using the OpenHD imageWriter.

OpenHd already includes the dt-blob.bin file, and 'dtoverlay=dwc2,dr_mode=host' has been enabled in 'boot/config.txt'.

Connecting the CSI Camera:

The CSI camera can be connected to one of the two FFC connectors.

If you want to use the "Camera0" connector, make sure that the two jumpers of the I2C (used for the camera config) are shorted.

Connecting the WiFi dongle:

The WiFi dongle can be connected to one of the 4 USB connectors on the board.

In order to minimize the problems associated with connecting a "fast bus" such as USB, it is advisable to cut a USB extender and solder it to a GHS connector, leaving the wires on the connector side as short as possible.

Connecting the Telemetry

To connect the telemetry to the FC it is possible to use one of the available UART ports, the UART used by default is UART0 / 1.

It is important to keep in mind that the GPIOs of the CM4 module are not 5V tolerant, it is therefore important to be sure that the logic levels of the FC UART are 0V-3V3.

Where to buy the Ochin?

Here

⚠️ This documentation is outdated! A current version is available at

The RPI HDMI to CSI adapter provides a means of interfacing HDMI output from cameras to the Raspberry Pi platform. However, it's important to note that this adapter is not officially supported by the Raspberry Pi Foundation, and as a result, it presents certain challenges and limitations. Here's a concise rundown of these quirks:

1. Encoder Bitrate Control: One notable issue is the unreliable performance of the encoder bitrate control. This often results in fluctuations like overshoot and undershoot in the bit rate. To mitigate this problem, it is recommended to disable variable bitrate and instead manually set a conservative bitrate, such as 8 MBit/s for MCS3 encoding.

2. Resolution and Framerate Configuration: Configuring the resolution and framerate through the adapter can be problematic and may even fail in certain instances. To enhance the likelihood of successful configuration, it is advised to set the camera resolution to match exactly the resolution and framerate output by your HDMI source.

3. Maximum Resolution and Framerate: The Raspberry Pi hardware encoder is constrained to a maximum output of 1080p@30fps or 720p@60fps. Consequently, it's important not to select an HDMI output video signal from your camera that exceeds these limits.

4. Reliable Adapter Detection: For consistent and reliable detection of the HDMI to CSI adapter during boot, it is crucial to sequence the power supply. In practice, ensure that the OpenHD system is powered on after your HDMI camera. This ensures that the adapter receives a valid HDMI input signal prior to the initialization of the Air Pi system.

While the RPI HDMI to CSI adapter serves as a bridge between HDMI cameras and Raspberry Pi devices, its unofficial nature can lead to these operational quirks. Users seeking to employ this adapter should be aware of these limitations and implement the recommended workarounds for optimal results.

⚠️ This documentation is outdated! A current version is available at

OpenHD supports and recommends the following cameras on the Raspberry Pi:

Raspberry Pi CSI cameras

*This cameras use mainly raspivid which is legacy and discontinued. These cameras aren't really recommended for FPV, since V1,V2 of Raspberry cameras do not provide a good image outdoors, and the HQ camera is much bigger and more expensive then smaller versions of it. V1 sensor is also not produced anymore and V2 sensor is about to follow.

Thermal/USB Cameras

HDMI CSI Adapter

More information about CSI-HDMI can be found .

USB Cameras

IP Cameras

Get your camera supported !

Cameras not listed here may potentionally work, but aren't tested and configured.

We only integrate Cameras which are tested and fitting to the purpose of openhd. If you want to get new cameras supported ask your camera vender to support OpenHD development with their hardware, but contact us first at developer@openhdfpv.org

We also want to thank our cooperation partners for providing the Team with Prototypes and want to specifically thank for helping us in developing cameras specifically to our need.

⚠️ This documentation is outdated! A current version is available at

Overview

As the Rock5 is a distinct platform and MIPI is not a plug-and-play system, we are awaiting official camera releases for compatibility. We are actively dedicating resources to introduce more camera options in the future.

Currently, the camera support is limited to:

Note 1: There currently appears to be no compatible adapter or camera with this sensor available for the Rock5.

We are working towards expanding the selection of supported cameras and adapters, and we appreciate your patience as we continue to develop and improve camera compatibility

⚠️ This documentation is outdated! A current version is available at

The Jetson Nano is a capable H265 encoding device, that's why we supported it in our 2.2-evo till 2.3-evo releases. Since it is fundamently different and doesn't give any advantage on the Ground, we do not officially support it as GroundSBC.

Previously Supported Jetson-SBC's