Sticky:
Overview of my blog posts
Comments (2)
Add Comment
I was asked to help to diagnose an issue with RadioKing TX18S, that originally made EdgeTX firmware hang, when the internal 4-in-1 Multi-Protocol-Module was turned on. More about the original problem can be read at EdgeTX GitHub Issue #802. This blog post discusses my findings and the solution.
@pafleraf, the lead developer of EdgeTX, had already found that by adding a 1 millisecond delay between turning on the internal MPM and further processing of firmware code, eliminated the system hang when MPM was powered-up (for more, see EdgeTX Pull-Request #851). Taking this info as a clue, I had a hunch that there is likely a problem in the power distribution on the TX18S mainboard and thus concentrated my further efforts in this direction.
After I received a TX18S for diagnosis, as a first step, I had a good look at both sides of the mainboard of TX18S to localize the main components and to get a rough overview of the schematics (exact schematics of TX18S were not available to me, and to my knowledge were also never made available to OpenTX nor EdgeTX developers):
I identified pads for probing the main microcontroller (STM32F429BIT6) supply rail, the supply rail of the internal 4-in-1 Multi-Protocol-Module and GND as a reference, all 3 circled red in the image:
...Continue Reading
@pafleraf, the lead developer of EdgeTX, had already found that by adding a 1 millisecond delay between turning on the internal MPM and further processing of firmware code, eliminated the system hang when MPM was powered-up (for more, see EdgeTX Pull-Request #851). Taking this info as a clue, I had a hunch that there is likely a problem in the power distribution on the TX18S mainboard and thus concentrated my further efforts in this direction.
After I received a TX18S for diagnosis, as a first step, I had a good look at both sides of the mainboard of TX18S to localize the main components and to get a rough overview of the schematics (exact schematics of TX18S were not available to me, and to my knowledge were also never made available to OpenTX nor EdgeTX developers):
I identified pads for probing the main microcontroller (STM32F429BIT6) supply rail, the supply rail of the internal 4-in-1 Multi-Protocol-Module and GND as a reference, all 3 circled red in the image:
...Continue Reading
If you followed my previous blog posts (especially #17 about the TX16S schematic diagram and #18 about electronic circuit improvement ideas), then you are informed about my plans to make the RadioMaster TX16S an even better radio by customizing some of the internals. In #21, I started this process by fixing the bugs in the roller board.
This post concentrates on adding some new cool features to the TX16S mainboard and at the same time fixing some minor bugs of it as well. In present state it is still work in progress, but for the interested I already created this page as a preview.
The changes and additions include:
This post concentrates on adding some new cool features to the TX16S mainboard and at the same time fixing some minor bugs of it as well. In present state it is still work in progress, but for the interested I already created this page as a preview.
The changes and additions include:
- WiFi & Bluetooth support, e.g. with ESP32-WROOM-32/32UE module instead of proprietary FrSky PARA Bluetooth module via internal 6-pin header.
- changed to STM32F439BIT6 (the hw-crypto addition in comparison to STM32F429BIT6 is currently not yet used by OpenTX/EdgeTX), so this change has no immediate benefit yet.
- full 19-pin Cortex ARM debug+trace port (Samtec FTSH-110-01-L-DV-007-K) on the STM32F439BIT6, especially interesting for low-level EdgeTX/OpenTX development. Not only does it include the Serial-Wire-Debug (SWD), but also SWO and full streaming trace (Segger has a nice page explaining streaming trace here), making it possible to extract a full backtrace of the instructions, while the code is running at full pace.
- added a DFU button in order to be able to keep the top USB-C connected to a tablet on power-up (more about it here).
- added internal 4-pin
If you followed my blog post about RadioMaster TX16S schematic, you might have read that I found two schematic errors in the original TX16S roller board circuit (Section 2.19 in the blog post).
I fixed both errors with a slightly adjusted circuit:
The changed circuit correctly connects the Alps EC10E encoder and fixes the position of the roller button filter capacitor C1005. Whereas, the original board uses 0402 sized SMD components, for easier manual soldering I changed the pads to significantly bigger 0805. I also added testpoints at the back of the PCB for easier debugging of the encoder and buttons. As a further small change, I connected the shielding pin of the buttons to GND (on original they are floating).
Attached to this post you can find the Eagle CAD files of the schematic diagram & board layout:
...Continue Reading
I fixed both errors with a slightly adjusted circuit:
The changed circuit correctly connects the Alps EC10E encoder and fixes the position of the roller button filter capacitor C1005. Whereas, the original board uses 0402 sized SMD components, for easier manual soldering I changed the pads to significantly bigger 0805. I also added testpoints at the back of the PCB for easier debugging of the encoder and buttons. As a further small change, I connected the shielding pin of the buttons to GND (on original they are floating).
Attached to this post you can find the Eagle CAD files of the schematic diagram & board layout:
...Continue Reading
Here you can find a step-by-step guide to building EdgeTX firmware for your radio under Microsoft Windows 10. If you prefer Linux as your operating system of choice, then please see my blog post #19 for the same instructions, but targeting Ubuntu Linux.
In the first half of this blog entry, I show how to setup the build environment and the second half lists the necessary steps to build EdgeTX firmware.
After following the steps here, if you are interested to learn how to setup a graphical development environment for coding and debugging, please see my blog post #4, showing how to setup Qt Creator and how to perform real-time in-circuit debugging with it on code running on radio microcontroller.
The steps in this guide are tested using Microsoft Windows 10 in Version 21H1 64-bit edition.
Disclaimer: I have assembled this guide to the best of my knowledge, but keep in mind that this is NOT the official guide of how to build EdgeTX (Docker is, see here). In short - if you run into problems, please consider first that it might stem from the steps here, especially before opening an issue in EdgeTX GitHub.
1. Setting up the build environment for EdgeTX v2.4
The following assumes, you have a fresh installation of 64-bit Windows 10 with all updates installed (tested with English version 21H1 at the time of writing).
1.1. Download and install Visual Studio 2019 Community Edition
https://visualstudio.microsoft.com/downloads/
If you already have a commercial version of...Continue Reading
In the first half of this blog entry, I show how to setup the build environment and the second half lists the necessary steps to build EdgeTX firmware.
After following the steps here, if you are interested to learn how to setup a graphical development environment for coding and debugging, please see my blog post #4, showing how to setup Qt Creator and how to perform real-time in-circuit debugging with it on code running on radio microcontroller.
The steps in this guide are tested using Microsoft Windows 10 in Version 21H1 64-bit edition.
Disclaimer: I have assembled this guide to the best of my knowledge, but keep in mind that this is NOT the official guide of how to build EdgeTX (Docker is, see here). In short - if you run into problems, please consider first that it might stem from the steps here, especially before opening an issue in EdgeTX GitHub.
1. Setting up the build environment for EdgeTX v2.4
The following assumes, you have a fresh installation of 64-bit Windows 10 with all updates installed (tested with English version 21H1 at the time of writing).
1.1. Download and install Visual Studio 2019 Community Edition
https://visualstudio.microsoft.com/downloads/
If you already have a commercial version of...Continue Reading
Here's a short step-by-step guide to building EdgeTX firmware for your radio using Ubuntu Linux. EdgeTX is a version of OpenTX, concentrating on new cutting edge developments.
In the first half of this blog entry, I show how to setup the build environment and the second lists the necessary steps to build EdgeTX firmware. I provide two examples - first for vanilla EdgeTX and second for OlliW MAVLink enhanced EdgeTX. In the examples, I use RadioMaster TX16S, but the steps are applicable to other radios as well, you just need to select another build target in the cmake line (more on that below).
After following the steps here, if you are interested to learn how to setup a graphical development environment for coding and debugging, please see my blog post #2, showing how to setup Qt Creator and how to perform real-time in-circuit debugging with it on code running on radio microcontroller.
Disclaimer: I have assembled this guide to the best of my knowledge, but keep in mind that this is NOT the official guide of how to build EdgeTX (Docker is, see here). In short - if you run into problems, please consider first that it might stem from the steps here, especially before opening an issue in EdgeTX GitHub.
You will need Ubuntu Linux in version 20.04. The steps will also work when Ubuntu is running virtualized, such as on a VMware Workstation, VirtualBox or Hyper-V.
1. Setting up the build environment for EdgeTX v2.4
In the first half of this blog entry, I show how to setup the build environment and the second lists the necessary steps to build EdgeTX firmware. I provide two examples - first for vanilla EdgeTX and second for OlliW MAVLink enhanced EdgeTX. In the examples, I use RadioMaster TX16S, but the steps are applicable to other radios as well, you just need to select another build target in the cmake line (more on that below).
After following the steps here, if you are interested to learn how to setup a graphical development environment for coding and debugging, please see my blog post #2, showing how to setup Qt Creator and how to perform real-time in-circuit debugging with it on code running on radio microcontroller.
Disclaimer: I have assembled this guide to the best of my knowledge, but keep in mind that this is NOT the official guide of how to build EdgeTX (Docker is, see here). In short - if you run into problems, please consider first that it might stem from the steps here, especially before opening an issue in EdgeTX GitHub.
You will need Ubuntu Linux in version 20.04. The steps will also work when Ubuntu is running virtualized, such as on a VMware Workstation, VirtualBox or Hyper-V.
1. Setting up the build environment for EdgeTX v2.4
- Download Ubuntu 20.04 LTS and install it (using Minimal
Out of curiosity and in order to create a schematic of the radio, I took RadioMaster TX16S breakout board apart.
First picture of the top side as it came from RadioMaster:
Bottom side:
I de-populated the board using a hot air station, removed solder rest with solder wick and removed flux residues with PCB cleaner. Here again, first top side:
...Continue Reading
First picture of the top side as it came from RadioMaster:
Bottom side:
I de-populated the board using a hot air station, removed solder rest with solder wick and removed flux residues with PCB cleaner. Here again, first top side:
...Continue Reading
If you have opened a RadioMaster TX16S radio, then maybe you have noticed the tiny SOP8 chip to the bottom right of the main STM32F429BI microcontroller (circled yellow in the image below):
The package marking reveals that it is a GD25Q127C 16 Mbyte serial flash chip by GigaDevice.
By tracing the mainboard PCB tracks, I was able to see that it is connected to STM32 chip's SPI2 port (pins 154 to 157):
Interestingly, if we look at the OpenTX source code, we can see that the SPI pins have been defined for the memory chip in hal.h, but the configuration functions (such as GPIO_Init() and GPIO_PinAFConfig()) are never called for these pins. This is not ideal, as floating inputs can cause on CMOS chips unnecessary high current draw. I opened an issue in GitHub with a possible fix for this.
Nevertheless of the fact that the chip is not used by OpenTX, I was curious to learn if RadioMaster has put any data onto the SPI flash in factory.
I hooked the flash chip up to Total Phase Aardwark I2C/SPI host adapter and started the Flash Center software:
...Continue Reading
The package marking reveals that it is a GD25Q127C 16 Mbyte serial flash chip by GigaDevice.
By tracing the mainboard PCB tracks, I was able to see that it is connected to STM32 chip's SPI2 port (pins 154 to 157):
Interestingly, if we look at the OpenTX source code, we can see that the SPI pins have been defined for the memory chip in hal.h, but the configuration functions (such as GPIO_Init() and GPIO_PinAFConfig()) are never called for these pins. This is not ideal, as floating inputs can cause on CMOS chips unnecessary high current draw. I opened an issue in GitHub with a possible fix for this.
Nevertheless of the fact that the chip is not used by OpenTX, I was curious to learn if RadioMaster has put any data onto the SPI flash in factory.
I hooked the flash chip up to Total Phase Aardwark I2C/SPI host adapter and started the Flash Center software:
...Continue Reading
Futaba TM-10 FASST module / Futaba T10CG internal module do not communicate with the radio via std. 5 pin-header, but use an additional 4-pin header for communication. Only the power and RF-output enable feedback are sent via the 5-pin header.
Using an oscilloscope and a logic analyzer, I had a look at the signals of the 4 additional pins on the Futaba T10CG internal module (which is the same as in Futaba TM-10). First observation is, that the 4-pin header actually only carries 2 signals, as the top two pins are shorted and so are the bottom two pins. I could see that the signal carried over the two signal lines is a 3.3V level non-inverted standard serial protocol using 125000 baud with 8 data bits, 2 stop bits and even parity. The used 125000 baud 8E2 serial stream is close, but not quite matching the S.BUS signal, which would be 100000 baud, 8E2.
I attach a zipped Saleae Logic Analyzer trace that I captured for a couple of seconds before and after powering on the system. To view it, you can download the software for free from Saleae. It will work fine without the logic analyzer hardware. Be sure to zoom deep in, first then you start seeing the single bits and bytes and their corresponding decoding.
Signal correlation with an S.BUS output of the receiver
To further investigate how the communication corresponds to the S.BUS signal output by the receiver, I added a bound Futaba R6208SB receiver S.BUS output to the trace (see second attachment below). The timing of the...Continue Reading
Using an oscilloscope and a logic analyzer, I had a look at the signals of the 4 additional pins on the Futaba T10CG internal module (which is the same as in Futaba TM-10). First observation is, that the 4-pin header actually only carries 2 signals, as the top two pins are shorted and so are the bottom two pins. I could see that the signal carried over the two signal lines is a 3.3V level non-inverted standard serial protocol using 125000 baud with 8 data bits, 2 stop bits and even parity. The used 125000 baud 8E2 serial stream is close, but not quite matching the S.BUS signal, which would be 100000 baud, 8E2.
I attach a zipped Saleae Logic Analyzer trace that I captured for a couple of seconds before and after powering on the system. To view it, you can download the software for free from Saleae. It will work fine without the logic analyzer hardware. Be sure to zoom deep in, first then you start seeing the single bits and bytes and their corresponding decoding.
Signal correlation with an S.BUS output of the receiver
To further investigate how the communication corresponds to the S.BUS signal output by the receiver, I added a bound Futaba R6208SB receiver S.BUS output to the trace (see second attachment below). The timing of the...Continue Reading
I created an interface to control a remote device (e.g. a drone) from the PC via a radio link and I call the project USB2PPM.
The USB2PPM circuit gets the signal from PC over USB connection and converts it to Pulse-Position-Modulation (PPM) to be input e.g. over a trainer jack into a remote control transmitter.
USB2PPM uses standard trainer port signal. Back in 2003, I did a similar project PC-to-R/C Interface V2.0, but it was much bigger than the current version and used RS-232 serial port that is deprecated today.
...Continue Reading
The USB2PPM circuit gets the signal from PC over USB connection and converts it to Pulse-Position-Modulation (PPM) to be input e.g. over a trainer jack into a remote control transmitter.
USB2PPM uses standard trainer port signal. Back in 2003, I did a similar project PC-to-R/C Interface V2.0, but it was much bigger than the current version and used RS-232 serial port that is deprecated today.
...Continue Reading
If you followed my blog post #5 about native MAVLink telemetry with RadioMaster TX16S, you are aware that we can use the TX16S top USB-C port in MAVLink routing mode to connect to a ground control station, such as Mission Planner or QGroundControl. To recap, I add the connection image from my blog post #5:
Without the modification to the radio hardware, as explained in this post, there is one caveat when using the top USB-C port connected to ground control station. This has to do with the specialty of the internal STM32 microcontroller, as used in most OpenTX radios, and the schematic wiring used. Namely, the main microcontroller of TX16S boots in Device Firmware Upgrade (DFU) mode when the USB cable is connected while the radio is powered-up and thus will NOT boot and run the normal OpenTX firmware. You will get a black screen when powering up in DFU mode and no functionality from the radio.
This behavior stems from otherwise a very nice feature of the STM32 microcontroller in the radio that allows it to be flashed without external programming device, even if no bootloader is yet programmed. (This is also the reason, why most OpenTX radios cannot be bricked by user doing something wrong while flashing.) Unfortunately, STM32 DFU paired with the electrical schematic in most OpenTX radios, where the BOOT0 pin hard-wired to VBUS, results in the before mentioned behavior of radio not booting in this situation. The solution is either to disconnect the USB cable from ground...Continue Reading
Without the modification to the radio hardware, as explained in this post, there is one caveat when using the top USB-C port connected to ground control station. This has to do with the specialty of the internal STM32 microcontroller, as used in most OpenTX radios, and the schematic wiring used. Namely, the main microcontroller of TX16S boots in Device Firmware Upgrade (DFU) mode when the USB cable is connected while the radio is powered-up and thus will NOT boot and run the normal OpenTX firmware. You will get a black screen when powering up in DFU mode and no functionality from the radio.
This behavior stems from otherwise a very nice feature of the STM32 microcontroller in the radio that allows it to be flashed without external programming device, even if no bootloader is yet programmed. (This is also the reason, why most OpenTX radios cannot be bricked by user doing something wrong while flashing.) Unfortunately, STM32 DFU paired with the electrical schematic in most OpenTX radios, where the BOOT0 pin hard-wired to VBUS, results in the before mentioned behavior of radio not booting in this situation. The solution is either to disconnect the USB cable from ground...Continue Reading
Update: RadioMaster offers now hollow shaft AG01s, making the mod explained in this page, unnecessary.
As a long time Futaba tray transmitter user, I was used to having additional controls on my sticks, e.g. to control a camera gimbal. After making a jump to OpenTX, got myself TX16S and made a tray modification (see my blog post #7). Nevertheless, I was still missing my old beloved stick controls.
I could not find readily available commercial solution for TX16S, so went the road of customization. Here's the final result:
The trickiest part is to get a hollow shaft into the existing sticks, as they are from solid material with a M4 thread:
I disassembled the TX16S hall sticks and very carefully in a lathe I was able to drill 2.0 mm through-holes into the stick pins:
...Continue Reading
As a long time Futaba tray transmitter user, I was used to having additional controls on my sticks, e.g. to control a camera gimbal. After making a jump to OpenTX, got myself TX16S and made a tray modification (see my blog post #7). Nevertheless, I was still missing my old beloved stick controls.
I could not find readily available commercial solution for TX16S, so went the road of customization. Here's the final result:
The trickiest part is to get a hollow shaft into the existing sticks, as they are from solid material with a M4 thread:
I disassembled the TX16S hall sticks and very carefully in a lathe I was able to drill 2.0 mm through-holes into the stick pins:
...Continue Reading
Being previously a long time Futaba tray radio user and being accustomed to controlling sticks by pinching, I put my TX16S into a tray.
AHLtec offers two tray options for TX16S: a fiberglass and a carbon. I picked the carbon version for optics. And as I was planning to use spatially slightly separated DragonLink, instead of the internal radio MULTI-module, the vicinity to large electrically conductive carbon surfaces was less of a concern for me.
The AHLtec tray comes as a kit and needs to be assembled. It fits TX16S perfectly, the build quality of the carbon parts is excellent. I had to file a bit the mounting holes in the metal braces in order for them to perfectly fit and not damage the thread of the screws during assembly.
...Continue Reading
AHLtec offers two tray options for TX16S: a fiberglass and a carbon. I picked the carbon version for optics. And as I was planning to use spatially slightly separated DragonLink, instead of the internal radio MULTI-module, the vicinity to large electrically conductive carbon surfaces was less of a concern for me.
The AHLtec tray comes as a kit and needs to be assembled. It fits TX16S perfectly, the build quality of the carbon parts is excellent. I had to file a bit the mounting holes in the metal braces in order for them to perfectly fit and not damage the thread of the screws during assembly.
...Continue Reading
I modified Yaapu LUA telemetry widget to work with OlliW MAVLink enhanced OpenTX (see my blog post #5 for more info about OlliW MAVLink enhanced OpenTX).
My modified Yaapu LUA telemetry widget is available under my GitHub page (for installation instructions just follow Yaapu's original instructions here, but for the SD-card source use my GitHub fork instead).
My mod adds some new menu items to the Yaapu configuration - when using OlliW OpenTX, the MavSDK option should be enabled (in the latest version in my GitHub it is called MavSDK, here, the older screenshot says still enable MAVLink support instead):
To add waypoint data to the left panel, enable MavSDK/Mav2PT mode for it:
I added an option to update the home position using the radio attached GPS instead of having to rely on a fixed home position, where the vehicle was armed. This option can be enabled here:
...Continue Reading
My modified Yaapu LUA telemetry widget is available under my GitHub page (for installation instructions just follow Yaapu's original instructions here, but for the SD-card source use my GitHub fork instead).
My mod adds some new menu items to the Yaapu configuration - when using OlliW OpenTX, the MavSDK option should be enabled (in the latest version in my GitHub it is called MavSDK, here, the older screenshot says still enable MAVLink support instead):
To add waypoint data to the left panel, enable MavSDK/Mav2PT mode for it:
I added an option to update the home position using the radio attached GPS instead of having to rely on a fixed home position, where the vehicle was armed. This option can be enabled here:
...Continue Reading
I would like to introduce an option to get MAVLink telemetry directly to Yaapu telemetry screens of RadioMaster TX16S, without having to resort to Mav2PT protocol conversion anymore. This eliminates numerous problems stemming from bandwidth and payload size limitations of FrSky Passthrough protocol and is especially interesting for anyone using a radio modem with native MAVLink capability, such as DragonLink.
The main role here plays OlliW MAVLink enhanced EdgeTX/OpenTX firmware that you can load to your RadioMaster TX16S. In addition, I modified Yaapu LUA telemetry widget to work in addition to FrSky PT also with OlliW customized EdgeTX/OpenTX fork for Horus-class radios that has not only MAVLink support baked in, but also MAVLink routing baked in. For more info about my modified Yaapu LUA telemetry widget, please see my blog post #6.
I created 4 connection diagram examples for OlliW MAVLink enhanced EdgeTX/OpenTX firmware using RadioMaster TX16S, DragonLink V3, GCS and GPS as examples.
RadioMaster TX16S is an ideal choice, as it provides two easily accessible UART ports on the bottom. Nevertheless, OlliW firmware and my Yaapu widget mods should also work on other Horus-class EdgeTX/OpenTX radios, like Jumper T16, but require opening the case and direct soldering the connection cables to pads on the mainboard.
Let's start with the simplest diagram with just RadioMaster TX16S and DragonLink V3:
--------------------------------------------------------------------------...Continue Reading
The main role here plays OlliW MAVLink enhanced EdgeTX/OpenTX firmware that you can load to your RadioMaster TX16S. In addition, I modified Yaapu LUA telemetry widget to work in addition to FrSky PT also with OlliW customized EdgeTX/OpenTX fork for Horus-class radios that has not only MAVLink support baked in, but also MAVLink routing baked in. For more info about my modified Yaapu LUA telemetry widget, please see my blog post #6.
I created 4 connection diagram examples for OlliW MAVLink enhanced EdgeTX/OpenTX firmware using RadioMaster TX16S, DragonLink V3, GCS and GPS as examples.
RadioMaster TX16S is an ideal choice, as it provides two easily accessible UART ports on the bottom. Nevertheless, OlliW firmware and my Yaapu widget mods should also work on other Horus-class EdgeTX/OpenTX radios, like Jumper T16, but require opening the case and direct soldering the connection cables to pads on the mainboard.
Let's start with the simplest diagram with just RadioMaster TX16S and DragonLink V3:
--------------------------------------------------------------------------...Continue Reading
