|
ℹ️
|
This page and the accompanying repositories are mostly for my rc (radio controlled models) electronics including EdgeTx/OpenTx addons, LUA-scripting, videos, and more. |
- 1. Foreword
- 2. ExpressLRS
- 3. Projects
- 3.1. Corona RP8D1 replacement firmware
- 3.2. Renewed mainboard for some (old) 27/35/40MHz RC transmitters
- 3.3. SDR RC receiver for 27/35/40MHz
- 3.4. Touch-Screen for the FrSky X12S
- 3.5. Modification of an old Graupner / JR 40MHz transmitter RF modul for use in e.g. a Radiomaster TX16s / FrSky X12S/X9e or similar
- 3.6. Brushed DC-motor controller with sensorless measurement of rotational speed
- 3.7. ESCape32: firmware for a familiy of small/medium BLDC motor controller (brushless ESC)
- 3.8. V/ESC: the ultimate firmware for medium/big BLDC motor controller (brushless ESC)
- 3.9. JR-module-bay adapter for ELRS receiver as transmitter
- 3.10. Adapter for ELRS receiver as internal XJT/ISRM module for FrSky X12S
- 3.11. ELRS for the FlySky-I6X
- 3.12. ELRS-MultiSwitch
- 3.13. Double Schottel-Control
- 3.14. CRSF-Switch
- 3.15. ELRS-MultiAdapter-EA
- 3.16. The
CruiseController - 3.17. Hardware-Extension-Protocol
- 3.18. LUA-script for the Hardware-Extension-Protocol
- 3.19. The TX16s internal switch controller
- 3.20. The RC-desk (for RadioMaster TX16S, FrSky X12S / X9E)
- 3.21. A new kind of stick: haptic-control
- 3.22. Simple RC main power latched switch
- 4. Openix6
- 5. OpenTx / EdgeTx weekly
- 6. Actual gear
- 7. Vintage RC
- 8. Licence
- 9. Kontakt
|
ℹ️
|
To the german readers
Die alte Seite ist noch (und bleibt auch) als Old.adoc verfügbar. |
ExpressLRS (ELRS) is a long range link for radio controlled models / machinery of all kind. Obviously it has some advantages over some other commercial rc-links like AFHDS2A, Hott or ACCST, …
ExpressLRS is:
-
open-source (software and hardware)
-
low-latency / high packet-rate
-
using open (well-documented) CRSF protocol (working group)
-
extremely long range
Together with EdgeTx (Open-Source radio transmitter operating system) one has a extremely powerful system at hand to control and monitor all kind of models or machinery from remote. And the whole system (but the handset) now is open-source: there are no limits in extending the system.
But ELRS is not limited to its long-range capability, that makes it useful for all kind of flying machinery (planes, helicopters, drones, …). ELRS is as well suited for short-range radio control of boats, cars, crawlers, stationary-models (e.g. cranes, …).
The most appealing features of ELRS with respect to short-range radio-control of models are:
-
extensibility due the flexibility of the CRSF protocol, mainly on the model side (after the receiver)
-
low-latency / high packet-rate for new kinds of features (e.g. haptic-control)
In the following sections are proposals for some extensions to the CRSF protocol. These extensions are already in use with my The CruiseController and some
multi-switch-modules or lighting-modules
Following is a proposal for an extension to the the CRSF protocol. This can be used with every handset, transmitter-module and receiver
due to the extensability of the protocol.
Refer to crsf.
This is used by a EdgetTx-Widget (encoder) alongside with the The CruiseController (decoder).
|
💡
|
CRSF-protocol extension
For all commands new realms are defined:
|
Total of 64 switches.
-
Paket type:
CRSF_FRAMETYPE_COMMAND,0x32 -
Command realm:
CruiseController,0xa0, (user defined realm) -
Command:
0x01 -
Data: 64 bits as 8 x 8 bytes (64 binary switches)
Overall packet: [0xc8] [len] [0x32] [ [dst] [src] [0xa0] [0x01] <byte0> … [byte7] ] [crc8]
Total of 64 switches.
-
Paket type:
CRSF_FRAMETYPE_COMMAND,0x32 -
Command realm:
CruiseController,0xa0, (user defined realm) -
Command:
0x02(2 bit per channel) -
Data: 128 bits as 16 x 8 bytes (64 quaternary switches)
Overall packet: [0xc8] [len] [0x32] [ [dst] [src] [0xa0] [0x02] <byte0> … [byte15] ] [crc8]
Total of 64 switches.
The total number of bytes is transferred in chunks:
-
Paket type:
CRSF_FRAMETYPE_COMMAND,0x32 -
Command realm:
CruiseController,0xa0, (user defined realm) -
Command:
0x03(4 bit per channel) -
Number of chunk:
0x00: (channels 0 - 31),0x01: (channels 32 - 63) -
Data: 128 bits as 16 x 8 bytes (32 16-ary switches)
Overall packet: [0xc8] [len] [0x32] [ [dst] [src] [0xa0] [0x03] <chunk nr> <byte0> … [byte31] ] [crc8]
Total of 64 channels switches.
The total number of bytes is transferred in chunks:
-
Paket type:
CRSF_FRAMETYPE_COMMAND,0x32 -
Command realm:
CruiseController,0xa0, (user defined realm) -
Command:
0x04(8 bit per channel) -
Number of chunk:
0x00: (channels 0 - 15),0x01: (channels 16 - 31),0x02: (channels 32 - 47),0x03: (channels 48 - 63) -
Data: 128 bits as 16 x 8 bytes (16 8-bit-channels)
Overall packet: [0xc8] [len] [0x32] [ [dst] [src] [0xa0] [0x04] <chunk nr> <byte0> … [byte31] ] [crc8]
-
Paket type:
CRSF_FRAMETYPE_COMMAND,0x32 -
Command realm:
Module,0xa1, (user defined realm) -
Command:
0x01(Set) -
Address:
0x00…0xff -
Data: variable length, 1 up to 8 bytes
Overall packet: [0xc8] [len] [0x32] [ [dst] [src] [0xa1] [0x01] <address> <byte0> … [byte7] ] [crc8]
With ELRS modules like Happymodel ES24TX transmitter module (approx. 100mW RF power) and ultra-small receivers like Happymodel EP1 and EP2 receiver with CRSF/SBUS output or RadioMaster ER6 receiver with dedicated PWM outputs you get an enormous range of n-times 10km. This is good for drone-pilots but is of no use for crawler or model-boat / ship control.
The Features for functional models can also be achieved using an ELRS-receiver as a transmitter-module. This is a big advantage because it make it possible to equip many handsets with an internal elrs-capability, e.g. the FrSky X12S, X9E or Jumper T12 or the FlySky FS-I6X. See JR-module-bay adapter for ELRS receiver as transmitter and Adapter for ELRS receiver as internal XJT/ISRM module for FrSky X12S and [elrs_i6x] for details.
Using the same pass-phrase it is possible to bin more than one receiver to a tx-module. If all receivers were sending telemetry data to the tx-module, there will be interference in the rf domain, and, if by pure accident the rf data comes through undistorted, the tx module would receive ambigous data. ELRS is not capable of handling multiple telemetry streams in one passphrase realm.
Therefore, one has to disable sending telemetry on all but one receiver. This can be done via the web interface of the receiver(s). In this scenario, one may have multiple receivers - maybe in different models -, but only one is allowed to send telemetry, while all others must not send telemetry data. Sometimes this may be acceptable, but more often this is not acceptable: if the recivers belong to different models, not all batteries, etc. can be monitored. This may lead to severe damage to the batteries.
Since version 3.4 of ELRS it incorporates a feature called TeamRace (see the receivers menu in the elrsV3.lua menu).
In TeamRace each receiver has a unique ID-number calles position. One can select an active receiver via a designated rc channel
(one of the 16 rc channels). The active receiver outputs servo data and sends back telemetry, an inactive receiver does not send telemetry and goes
into failsafe for the channel data. For more info see: TeamRace.
TeamRace allows to switch the receiver / model very quick by e.g. the six-position-switch on a TX16S or X12S.
Going into failsafe for the inactive receivers will not be desired in most above mentioned use cases: it would be way better, if the inactive receiver simply stops sending telemetry but still outputs the channel data.
This was implemented in this pull-request: Multi model telemetry.
Unfortunately this pull-request waas not accepted by the ELRS team. Therefore you have to select this pull-request manually in the
expresslrs-configurator.
ELRS transfers 16 RC-channels from the handset to the receiver. In EdgeTx one can select the first of the 16 consecutive channels to be transferred.
EdgeTx manages 32 RC-channels, so it would be of interest to tranfer the remaining 16 channels also.
On the handset a LUA-script (widget) collects the channels 17-32 and encodes them as a custom CRSF package (Proportional data (e.g. additional channels: >8bit)). The ELRS-receiver outputs this custom packages on his serial interface (select: CRSF-protokoll). Clearly, a special CRSF-decoder is needed: it has to decode the normal RC channel packages and the custom-packages.
The The CruiseController uses two SBus-interface, one for channel 1-16, and one for the channels 17-32.
The following chapters describe some of my active projects. The majority of my former projects (see Old (in german)) are in a frozen state now. This is due to the fact that I completely shifted the µCs from the AVR-family (DA, DB, tiny1/2) to the more powerful STM32-family, mainly the STM32G4xx. These have enough computing resources for the SDR RC receiver for 27/35/40MHz project, which would have been impossible sticking to the AVRs.
Well, there is one exception: the Corona RP8D1 replacement firmware.
The Corona RP8D1 receiver come into several flavors, for the 35MHz band, the 40MHz and the 72MHz band (afaik).
The reason for giving a substantial amount of time to develop a new firmware for this receiver is the fact that I am
hoarding vintage electronic RC stuff. Unfortunately some of this gear wasn’t working anymore. In the process of
reworking these things I needed a good receiver and I decided to get a scan-receiver without external crystals. But it turns out
that the mostly helpful signal filtering of the Corona receiver makes the situation worse if one tries to use these multi-channels
extensions in the transmitters. These encoders produce a time-multiplex over one RC channel, and the correspondant decoder
isn’t capable decoding the time multiplex if the receiver modifies / filters the impulse durations. So, the project started ;-)
There is an extra repositoty https://github.com/wimalopaan/CoronaRP8D1 for this project.
As you can see in Transmitter or Transmitter I own some old, vintage RC transmitters. As of this writing some of them are more than 40 years old. The majority of them does kind of work, but due to aging of the components the do not meet the RC criteria of the RF regulations in the EU.
But there are also some other shortcomings with these old transmitters:
-
to change the rf channel one has to change the quarz in the transmitter.
-
quarzes are very expensive nowadays
-
if not using receivers with quarzes, scan-receivers are ubiquous (see also Corona RP8D1 replacement firmware) and they don’t need a quarz
-
-
With the exception of the Robbe/Futaba F-14 most of them are not capable of having switches together with a switching encoder
-
They don’t have features like mixers, trainer …
All this lead to the idea to design a new mainboard not only for the Robbe/Futaba F14, but also for the yellow, red and black Graupner/Grundig Varioprop series of transmitters.
The first attempt was to make a new mainboard for the yellow Varioprop S8. This mainboard uses a small µC atmega324pb to sample the potentiometers
of the handset and produce a ppm-signal, which was fed into a FrSky DHT 2.4GHz module. This worked quite well but felt a bit like abusing the
old yellow Varioprop, which is very cool stuff nowadays (in germany). Actually the attempt is undocumented.
The next attempt was to design a kind of relais-station to transform the 2.4-GHz FrSky ACCST into FM-FSK-40MHz. I thought this to be a cool idea because this relais-station could (in theory) used by more than one pilot / captain. The main reason was to re-use a modern transmitter with all its features like mixers and other cool stuff for the 40MHz band. But then came Corona (the disease, not Corona RP8D1 replacement firmware) …
I learned a lot about rf electronics in the sub-GHZ range and this was great fun, so I decided to design something that would combine all the features I played with in the previous versions.
This lead to the actual design …
The mainboard comes as pcb that coul be easily adapted to the three form factors for the
-
Robbe/Futaba F-14 (see Robbe Futaba F-14 Navy 40MHz)
-
yellow Graupner/Grundig Varioprop 8S (see Varioprop Graupner Grundig 8S 27MHz)
-
red/black Graupner/Grundig Varioprop (see Varioprop Graupner Grundig C8 27MHz and Varioprop Graupner Grundig 8S 40MHz)
The mainboard
-
handles up to 8 analog inputs (usually the potentiometers of the handset)
-
has a 100mW rf module (27/35/40 MHz)
-
uses the analog gauge as an accu monitor
-
has a beeper
-
has a I2C-connector to use with up to two switches-boads with 8 3pos-switches each
-
has a bluetooth (BLE) module
-
has an ELRS module (to be used as receiver or transmitter)
-
can switch channels via BLE or ELRS
-
has a free uart for further extensions
There have been some iterations for the design of the new mainboard though. In the following you see the last iteration: this one really works, but has some design flaws that I’m actually in process of fixing ;-)
In Schematic of Version 2 (click to enlarge) you see the schematic. Aside from some minor flaws there is one major issue with this board: the generation
of the frequency-shift-signal! As you see in the schematic the Si5361 genarates two rectangular signals, one with the space
frequency f0 on CLK0 and one with the mark frequency f1 on CLK1. Thereafter a 74LVC1G157 is used to switch between
these two frequencies with the cppm signal.
Although this appears to work there are very serious problems! (Do not use this part of the schematic in your projects.)
A little bit of theory: the switching between these two signals can be seen as a convolution of each signal (each itself a si() signal in the frequency domain) with another according si() signal (the cppm rectagular signal in the time domain) and then added together. This produces two main problems:
-
The switching in the time-domain witch a rectangular signal or convolution in the frequency domain of two si() function results in a very broad spectrum (see Spectrum when hard-switching the frequencies (click to enlarge)).
-
Additionally the switching is not synchronized with the base signal, so there are additional short-term pulses and therefore broad fequency components.
It turns out that this renders the rf part unusable, because several conventional receivers were not able to decode the signal if the signal strength goes down. And clearly this was not acceptable.
Well, although I was aware of this problem from the beginning I didn’t think that the negative impact was as this huge!
I looked around and I found some 27MHz VCXO (voltage controlled crystal oszillator) with an appropriate pulling range up to 100ppm. This looks quite reasonable: the µC could generate the cppm signal
with some exponential (gaussian) roll-on / roll-off via its DAC. The VCXO clock signal is the used as the input for the SI5351. And the SI5351 simply generates the desired output
frequency from the modulated clock signal. I made several test with different roll-on / roll-off curves and found that an exponential gives the best results with respect
to the smallest frequency sprectrum of the resulting rf signal. Very good (see Spectrum when using gaussian roll-on / roll-off (click to enlarge)).
The roll-on / roll-off via DAC of the µC (STM32G431) is easily realized via timer-triggered DMA to the DAC for each pulse-edge of the cppm signal.
All modifications are now in Schematic of Version 3 (click to enlarge).
As said above the main reason for this version was the problematic rf signal generation part, but there are other modifications:
-
new rf signal generation part to produce way better spectral results
-
additional I2C interface (in total now two interfaces)
-
on/off switching of the ELRS
-
circuit to reduce rf power
-
simplified power switching for submodules
This version is actually under test.
The switches board is very simple: it is connected via I2C to the main board. And it can be cascaded.
My most ambitious project. The origin is also in Corona RP8D1 replacement firmware. The goal is to design a SDR as a I/Q-mixer (tayloe-mixer) with zero-IF and a STM32G431 doing all the DSP stuff.
Actually, this works for ppm/pcm-modulation in the near field of the transmitter.
Remaining problems are sensitivity and AGC.
There is no documentation yet.
In my opinion the FrSky X12S is a very well designed and high-quality RC transmitter. Together with EdgeTx this is unbeatable.
The only drawback is, that it has no touch-screen. I managed to modify EdgeTx and the hardware to get the same touch-LCD as with the
RadioMaster TX16S working inside the X12s.
The software modifications are in mainline EdgeTx (no need to patch or modify) and the hardware modification is described in an extra document: X12S touch
Video: Demo
3.5. Modification of an old Graupner / JR 40MHz transmitter RF modul for use in e.g. a Radiomaster TX16s / FrSky X12S/X9e or similar
Modern handsets with a JR-like module bay provide a cppm-signal and battery-voltage on the pins of the connector.
Therefore it must be possible to use an old vintage Graupner JR 40MHz quarz transmitter module together with an old 40MHz quarz receiver.
The good news are: yes, it is possible. But …
|
🔥
|
It is tempting to place an old 40MHz JR module into the module bay of a modern handset. Please: don’t do this!!! You can damage your handset! |
For the full story, please follow this Howto (german)
Features:
-
SBus(2)/IBus/SumDV3 serial input
-
SBus2/S.Port/IBus/Hott telemetry
-
PPM-Input
-
serial terminal configuration interface
-
telemetry
-
supply voltage
-
motor current
-
motor temperature (sensor needed)
-
motor rotational speed (no sensor)
-
The smaller one of the two versions comes as one pcb.
If you use Target 3001 as your EDA: Target 3001 design file.
The bigger one of the two versions consists of two pcbs, one pcb for the µC module and one pcb for the power module. Both are connected via two pin-header or the can be soldered directly back-to-back with one layer of capton-tape in between.
If you use Target 3001 as your EDA: Target 3001 design file.
If you use Target 3001 as your EDA: Target 3001 design file.
ESCape32 is a firmware for a family of brushless motor controller sharing a common design (originated in the BLHeli-project).
One of the most outstanding feature of ESCape32 is the possibility to use serial input (SBus(2), CRSF, …) and telemetry. A markable
feature ist the Sbus2 protocoll, than combines control and telemetry data via one half-duplex line.
Clearly, V/ESC is the king. The firmware provides sensorless FOC, that gives us full torque from zero RPM and silent motor operation. This comes together with an incredible configuration software.
Unfortunately the V/ESC project has only an analog PPM input, but no SBUS/IBUS/SumDv3 serial input.
This modification introduces a serial, half-duplex connection using the V/ESC serial commands for the FlipSky hardware:
Half-Duplex Modification VESC
Since the differences between ELRS receivers and transmitters (well: both are transceivers and the differences are mostly in transmit-power) are
marginal, one can use every ELRS receiver as a transmitter. Of course, you have to flash a different firmware to it.
See ELRS firmware selection for ESP8285 based receivers and ELRS firmware selection for ESP32 based receivers for the correct setting in expresslrs-configurator.
|
🔥
|
Don’t expect the range to be more than 1km. Please test before going to the field (or lake or sea)! |
The small receivers based upon the ESP8285 are very well suited to either placed inside the handset or to the used
mounted inside a typical JR-bay module.
But they have two (not so major) drawbacks:
-
they allow only univerted, full-duplex serial communication
-
they need regulated 5V as power source
If you want to use this kind of receiver as an external module it is neccessary to
-
uninvert and split the inverted, half-duplex serial signal out of the S.Port connector in the module bay
-
produce a regulated 5V out of the unregulated battery voltage out ouf the module bay connector.
A special case is the FlySky-I6X handset: here you get an uninverted, half-duplex serial, that can simply be converted to the full-duplex of the ESP8285-based rx-as-tx.
-
on OpenI6X uninverted mode ist compile-time option
Instead of the small / simple ESP8285-based receivers you can also use the (slightly larger) ESP32-based receiver (e.g. BetaFPV SuperD). Fortunately the are capable of inverting the serial polarity ond also to use half-suplex on one (tx) pin. Therefore, they can directly connected to the S.Port connector-pin.
Pleas be aware, that you now have to use a special firmware (gemini), see ELRS firmware selection for ESP32 based receivers.
In the hardware-config (wifi) you can now:
-
disable gemini mode
-
use inverted serial on one (tx) pin
For more detals see this PR.
The communication between the handset and the tranceiver-module inside the JR-module bay takes place over
CRSF / half-duplex serial protocol. The main difficulty here is that for historic reasons the polarity of the
physical layer is inverted, so the idle level is low (0V) instead of high (3.3V) as normal. The ESP8285 based boards
aren’t capable of processing inverted serial signals.
The next culprit is that there is no 5V regulated voltage on the pins of the module bay, but the ELRS receiver boad needs 5V regulated voltage.
Due to this fact it would be most convenient to have a adapter, that
-
produces the regulated 5V out of the main battery voltage of the handset,
-
uninvertes the inverted serial data, and
-
splits the half-duplex connection into a seperated full-duplex one.
If you are interested in the pinout of the module bay, see: pinout
If you use Target 3001 as your EDA: Target 3001 design file.
In Signals from the ELRS receiver (click to view in full-scale) you see a logic-analyser trace of the rx and tx serial signal as they appear
at the ELRS-receiver. So, they are in normal polarity.
Please not, the the sent bytes at the tx do not appear at the rx-pin: no local echo. This is
suppressed by the circuit.
The assembling is straight forward, all components are placed on one side. Please refer to the [jr_elrs_target].
Unfortunately, one cannot easily replace the internal XJT-module of a FrSky X9E.
It would be possible to use the antenne of the internal XJT oder the Bluetooth module as well as an antenna for the ELRS.
If you don’t want to use an external ELRS transceiver module e.g. for the JR-bay of your handset, then you may choose to replace the internal XJT / ISRM module of the X12S with an ELRS module.
As mentioned in JR-module-bay adapter for ELRS receiver as transmitter it is possible to use (most) ELRS receivers as trasmitters (well: transceiver). The advantage of this approach is that the ELRS is so tiny, that you can mount it onto the X12S internal daughter boad. Maybe you can also use the antennas of the X12S if the ELRS is also working at 2.4 GHz. The disadvantage is clearly, that the range is somewhat limited: don’t expect it to be more than 1km and please make range tests before going to the field or lake.
You can hand-wire all the stuff but much more convenient is a small adapter board as is The schematic (click to view in full-scale) and The PCB (click to view in full-scale).
If you use Target 3001 as your EDA: Target 3001 design file.
All you need is to identify the TX2 pad on the mainboard of the I6X,
refer to I6X elrs. This is used as the S.Port
signal, which would be inverted. But fortunately there is a compile-time option to the firmare (CRSF_UNINVERTED) that can be set.
So the cmake line should be read as follows:
crsf on the tx2 pin of the I6X mainbard.$ cmake -DCRSF_UNINVERTED=YES -DUSB_SERIAL=OFF -DCMAKE_BUILD_TYPE=Release -DSPLASH=OFF -DTIMERS=1 -DHELI=OFF -DTRANSLATIONS=DE -DPCB=I6X
-DLUA_COMPILER=NO -DLUA=NO -DGVARS=YES -DMULTIMODULE=OFF -DOVERRIDE_CHANNEL_FUNCTION=OFF -DPCBI6X_ELRS=YES -DPCBI6X_HELLO=YES ..The next dificulty is to get the regulated 5V for the rx-as-tx. You can install a LDO but it turns out to be sufficient to power the
rx-as-tx with the internal 3.3V of the mainboard.
If you want to power-off the external module, you can use PC13 of the µC to control a power-switch for the module. If you are stouthearted desolder the
volatge-regulator from the ELRS-receiver (tx-module) and try to solder a p-Channel mosfet with source and drain on the same foorprint. Then use PC13
to drive the gate (by an additional n-Channel (to invert the polarity)) or use the -DEXTPWR_INVERT=YES compile-time switch.
I have been working for a long time on generalized MultiSwitch-Modules (s.a. MultiSwitch-D ). For those not knowing what a MultiSwitch is lets first explain some things (for the german reader, the follwing maybe sufficient: Beier)
In ancient times handset / transmitters were only capable of transmitting proportional channel values like rudder or speed. These value got encoded as PPM-signals. There was no possibility to
transport binary information, e.g. like the state of a 2-position switch on the handset. Some clever people therefore invented the so called multi-switch-encoder / decoder. The encoder was placed
inside the handset and encoded the state of a set of switches (typically 8) as distinct pulse-length on one of the proportional-channels of the transmitter. Since only one channel should be use for
this purpose, the switch-states have to be encoded as a time-multiplex, making it neccessary to introduce a 9th (and maybe 10th) impulse as synchronizing event.
This situation has not really changed with the advent of modern, digital 2,4GHz rc-links: these are typically designed to transport 16 (or 24 or 32) 10/11/12-bit integers as proportional values. There is not direct way to transport arbitrary binary (state of switches) information (exception: Hott/SJ together with SUMDV3 can transport 64 binary state values).
My above mentioned old MultiSwitch modules somewhat got around this limitation with the obvious technique: use the 10/11/12-bit integers to transport the binary data. But if you want to do this you have recognize that there is some scaling on the way from the handset to the transmitter-module and inside the receiver. This renders this approach … well … say uncomfortable (but working). Other limitations are e.g. that the communacation uni-directional (exception as said above: Hott).
But the really serious limitation was, that all these rc-links (Hott, ACCST, AFHDS2A, …) where closed-source stuff!
But eventually then I dicovered ExpressLRS. And this was a game changer.
With ELRS and clearly EdgeTx we have two open-source projects, that work perfectly together and give us a complete rc solution. No need for closed-source components anymore.
And as an additional important fact, the communication protocoll between the handset and the ELRS transmitter-module and betwenn the ELRS-receiver and some other device (e.g. flight-controller)
is CRSF, which is well documented and nowadays the evolution is kind-of governed: CRSF-WG.
The first MutliSwitch-ELRS module is the MultiSwitch-E8: this module is capable of switching 8 loads (dc-motors, LEDs, sound, …) steady on/off, intervall on/off (blinking) or pwm on/off (the on-state is pwm-modulated). It is possible to have up to 256 such MultiSwitch-E8 connected to one ELRS-receiver.
To make use of the functions of the MultiSwitch-E8, a special MultiSwitch-Widget is needed on the radio. This widget has the module address (0 … 255) as an option. Each widget instance
can control one of the 256 MultiSwitch-E8 modules in the model. All functions can be reached via the touch-screen. If appropriate some of the functions can also be controlled via the
physical switches on the radio.
The configuration of each of all the MultiSwitch-E8 modules is done via the standard elrsv3.lua script. The modules are listed under Other devices in the menu of that elrsv3.lua script.
Different to the old versions using other rc-links (AFHDS2A, ACCST, …) this new concept does not need one the the 16 proportional channels: it is completely independent!
MultiSwitch widget
MultiSwitch widget (fullscreen)The hardware components:
-
Radio running
EdgeTx -
ELRS-Transmitter module
-
ELRS-Receiver (PWM or serial-only)
-
up to 256 MultiSwitch-ELRS modules (see below)
-
CRSF-half-duplex bus (not strictly needed) (see below)
The software components:
-
elrsv3.luascript on the radio (if you are already using ELRS, you know it for sure) -
MultiSwitchwidget script (see below)
Although it would be possible to control the MultiSwitch-E8 via the standard elrsv3.lua script, this approch would be very inconvenient. So, I wrote a special
widget to control the MultiSwitch modules. Each MultiSwitch module has its own address (0 … 255), so the widget must know the appropriate address. There is a widget
option where you can set the address of the correponding module.
For each address you can also set a descriptive name of the module unique for each model on the radio, as well as the names of the function to switch on or off and which physical switches should be used (if any). This is done via a model-specific configuration file on the sd-card of the radio.
The CRSF protocol is extensible, and this fact is used to propose an extension to control such modules: Module Commands (e.g. switch states: on/off).
Link to the PCB order (Aisler): PCB order
Link to Target 3001 design file.
Link to Gerber.
Link to source code (unfortunately you have to clone to whole repository)
Instructions to compile to firmware:
$ cd <repo-root>/boards/rcmultiswitchG030
$ make allThe code of the widget can be found here: https://github.com/wimalopaan/LUA
MultiSwitch widget
MultiSwitch widget (fullscreen)Allows to connect up to 4 half-duplex CRSF devices to a full-duplex receiver.
Attention: this requires an external means to activate the attached half-duplex devices (e.g. a button on the devices), because at most only one device can be active on the bus (s.a. CRSF-Switch).
Link to the PCB order (Aisler): PCB Order
Link to Target 3001 design file.
Prototyp: Video
This module controls two Schottel dives.
Features:
-
Servos
-
PWM-Servos with analog Feedback
-
PWM-Servos with PWM-Feedback
-
serial Servos
-
-
ESCs
-
PWM-ESCs
-
Subs,Sbus2,IBusEscs -
special : KISS(ESCape32), V/ESC
-
-
BEC joining
-
up to three BEC sources
-
-
CRSF
-
CRSF input
-
CRSF routing
-
-
GPS
-
Sbus-Out
-
channels 1-16
-
Channels 17-32
-
Allows to connect up to seven half-duplex CRSF devices to a full-duplex receiver.
In contrast to CRSF-Half-Duplex Bus this CRSF-Switch allows all attached devices to be active at the same time (no external activation required).
The ELRS-MultiAdapter-EA converts CRSF-serial input into
-
4 Servo-PWM outputs for arbitrary channels (out of the 16 CRSF channels) or for 4 individual out-of-band channels (4 additional 8-bit channels), or
-
acts like a ELRS-MultiSwitch but with 4 push-pull outputs up to 1A@18V (max.) (occupies 1 switch-module address in this mode), or
-
produces up to 4 PWM outputs for analog switch modules (like Graupner 4159) each occupying one of the 256 addresses, or
-
produces 4 motor PWM signals (duty 0 … 100%) (unidirectionl) up to 1A@18V (max.) for 4 individual out-of-band channels (4 additional 8-bit channels) or 4 normal channels (1 … 16), or
-
produces 2 motor PWM signals (duty 0 … 100%) (bidirectionl) up to 1A@18V (max.) for 2 individual out-of-band channels (4 additional 8-bit channels) or 2 normal channels (1 … 16), or
The CC (CruiseController) is like a Flight-Controller but mainly for ship/boat-models.
It consists of
-
ELRS receiver
-
Bluetooth module
-
Servo-PWM-outputs
-
SBus(2)/IBus/SumdV3 output
-
SBus(2)/S.Port/IBus/Hott telemetry
-
4 direct switching lines (up to 1A@16V) (shared with servo pwm outputs)
-
additional serial connections (e.g. GPS)
-
V/ESC support
-
16-channel switching mezzanine board
-
16-channel LED mezzanine board
More to come …
The hardware-extension-protocol is a simple serial protocol to send the state of external switches and potentiometers to the handset. The RadioMaster TX16S handset has two
serial interfaces one can use to extend the handset, e.g. to provide more switches or potentiometers (s.a. LUA-script for the Hardware-Extension-Protocol).
The protocol is designed as a multi-master / slave protocol, which gives the chance to have more than one external controller that sends data to the handset (s.a. The TX16s internal switch controller and The RC-desk (for RadioMaster TX16S, FrSky X12S / X9E)).
In the case of the RadioMaster TX16S, which has two serial interfaces, the other serial interface remains free to used for other purposes, e.g.
to connect a SBUS-receiver realizing a trainer connection or connecting other gear (s.a. The RC-desk (for RadioMaster TX16S, FrSky X12S / X9E)).
An external switch controller (master) sends packages to the handset. It is possible to connect more than one external switch controller to the
same half-duplex serial-line (the rx line of the handset). This requires unique IDs of the switch controllers (s.a. Multi-Master Timing)
Format: [0xaa] <cntrl-nr> <type> <payload-length> <payload> <check-sum>
-
<cntrl-nr>: the controller-number (source) (one instance of the LUA-scripts acts upon one specific controller-number (must be a unique number on the bus) -
<type>: type of message-
0x00: binary switches in payload (each byte encodes 8 switches) -
0x01: 8-bit-values in the payload (each byte encodes an distinct value)
-
-
<length>: number of bytes of the<payload> -
<payload>: bytes encoding switches or values -
<check-sum>: arithmetic sum of<payload>byte, only one byte, may overflow
The master with the controller-number 0 sends a package every 100ms (maybe down to 20ms) unconditionally. The user has to ensure, that excactly one controller
with number 0 exists on the serial bus.
If there are other masters on the bus with controller-number greater 0 (e.g. N), they listen on the bus and wait for a message to see with controller-number (N-1).
If this master receives such a message, it waits 2 byte-times after the last byte of the just received message and then switches to send-mode and sends its own messages.
The user has to ensure, that the inter-message gaps are long enough so that all masters can send their messages. All controllers must have numbers in ascending order
without gaps starting with 0.
There are several ways to read the information send via the Hardware-Extension-Protocol and some of the serial interfaces of a handset. The two most obvious are:
-
modify the
EdgeTx-firmware to read the data via theserial interface, parse the Hardware-Extension-Protocol and modify the state of switches and inputs, or -
use a
LUA-script to read the data
To modify the EdgeTx-firmware would be the most powerful, because the external hardware read via the Hardware-Extension-Protocol could act like the internal control elements like sticks and switches.
But, this would be a huge modification of edgeTx for only a small number of users I think. So, there will be little chance to get these modifications offcially approved and get them into
the main version of the source code of EdgeTx.
To use a LUA-script isn’t intrusive in any way, one can use the standard LUA-API of EdgeTx (some useful functions for this I got into EdgeTx soem time ago).
Clearly, this approach has limitations: you can’t introduce new inputs or new switches.
But
-
the
LUA-script can set/reset some of the 64 logical-switches as a reaction to flipping of an external switch, and -
it can set set one of the 16 shared-memory variables, which then can be used inside a mixer-script to produce an output-channel value.
Sure, there is a limitation of 64 logical-switches and 16 shared-memory variables: but I think there is a good chance to increase these limits a least on the color-LCD radios with a substantial amount of RAM.
The code of the widget can be found here: https://github.com/wimalopaan/LUA
This is a simple AVR attiny1614 that reads the stick switches of my TX16s and uses the Hardware-Extension-Protocol to send the data to the handset. The LUA-script for the Hardware-Extension-Protocol decodes the stick-switches into logical-switches in
EdgeTx. This controller has the controller-number 0, so one can connect more controllers using the Hardware-Extension-Protocol connected to the same serial interface of the TX16s.
Link to the code repo: https://github.com/wimalopaan/wmucpp/tree/master/boards/rcswitch
(unfortunately you have to clone to whole repo to include all neccessary files. Maybe this will change in the future)
In the old days there was this simple project: main switch. Please follow the preceeding link to get the documentation (unfortunately only in german, don’t have the time to translated all documents).
If you want to build this board, the Target3001 design file may be of interest.
The OpenI6X project provides OpenTx for small radios of the type FlySky FS-i6x.
If you want to use the modification where all switches are 3-position switches,
use the PR403 of the project
and set the compile-time option ALL3POS:
$ cmake -DALL3POS=YES -DUSB_SERIAL=OFF -DCMAKE_BUILD_TYPE=Release -DSPLASH=OFF -DTIMERS=1 -DHELI=OFF -DTRANSLATIONS=DE -DPCB=I6X
-DLUA_COMPILER=NO -DLUA=NO -DGVARS=YES -DMULTIMODULE=OFF -DOVERRIDE_CHANNEL_FUNCTION=OFF -DPCBI6X_ELRS=YES -DPCBI6X_HELLO=YES ..German how-to
List of devices:
$ dfu-util -l dfu-util 0.11 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2021 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Found DFU: [0483:df11] ver=2200, devnum=10, cfg=1, intf=0, path="1-2", alt=1, name="@Option Bytes /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF" Found DFU: [0483:df11] ver=2200, devnum=10, cfg=1, intf=0, path="1-2", alt=0, name="@Internal Flash /0x08000000/064*0002Kg", serial="FFFFFFFEFFFF"
Flashing:
dfu-util -s 0x08000000 -a 0 -D firmware.bin
OpenTx weekly is a YouTube-channel mostly for EdgeTx and OpenTx stuff but also for my above electronic projects. Unfortunately the spoken language is german :-(
On Holger Meyer you may find an up-to-date table of contents.
In the following chapters you will see my actual gear and the modifications.
EdgeTx
hall-sticks
internal 4-in-1
Extensions:
-
2x incremental encoder
-
withc µC attiny412
-
on top of the handset
-
wired in poti-mode to Ext1/Ext2
-
-
stick switches
-
encoded by a µC (Attiny1614) inside the handset into FrSky-D telemetry via AUX1
-
-
SWD-connector
-
magnetic connector on the bottom of the handset
-
Modifications:
-
External ELRS (rx-as-tx EP2) inside the handset (ELRS for the FlySky-I6X)
-
SWD-connector
-
magnetic connector on the bottom of the handset
-
-
Make all switches
SA,SB,SCandSD3-position
EdgeTx
External ELRS (JR-module bay): JR-module-bay adapter for ELRS receiver as transmitter
EdgeTx
External ELRS (JR-module bay)(inside the housing): JR-module-bay adapter for ELRS receiver as transmitter
Modifications:
-
AUX1 (P12)
-
magnetic connector at the bottom of the handset
-
EdgeTx
Modifications:
-
touch-screen: Touch-Screen for the FrSky X12S
-
internal ELRS: Adapter for ELRS receiver as internal XJT/ISRM module for FrSky X12S
-
LiIon accu
-
AUX1
-
magnetic connector at the bottom of the handset
-
Please see Lizenz, as far as not other licences apply (e.g. in the source code).