Avionics and Homemade RC Electronics
NightOwl Gyros | Drag Rudders | Servo Driver | HK 2.1 | Draganfly FETs | Mag8 ESC with SimonK | Lemon Receiver w/ RSSI + E-OSD RSSI Firmware | UHF Long Range | Immersion Vortex F1 Flight Controller | 5' Travel Wing Avionics | XP8103 iNav Flight Mode Switches
Several of these projects include a PIC 12C508 as the brains. The source code for each project is included, and the pinouts for the PIC are listed in the comments in the source code for each project. See my PIC development page for links to the necessary PIC compiler and PIC programmer software packages, both of which are is free. All you will need to buy is an inexpensive PIC programmer interface which connects to a serial port on your computer, and of course the PIC, wiring, resistors, and capacitors that make up each project.
NightOwl - Stabilizing 3-Axis Gyros with PIC 12C508 mixer
|
NightOwl versions 4 and 5 each have a 3-axis rate gyro stabilizer. There are four control surfaces on each NightOwl. Two horizontal surfaces move together and control pitch. Two vertical surfaces move together and control yaw. All four surfaces together and control roll. The gyro stabilizers installed to versions 4 and 5 of the NightOwl are made from disassembled HK 401B rate gyros. These photos shows the gyro and mixer setup for NightOwl version 4. |
|
Three HK 401B gyros were taken apart, removed from their original boxes, and hot-melt glued together into a smaller package with each gyro rotated to the correct angle for its sensing axis. Gyro #1 senses roll, gyro #2 senses pitch, and gyro #3 senses yaw. The outputs of each gyro is routed to mixers. The first mixer is used for the horizontal control surfaces, for roll and pitch. The second mixer is used for the vertical control surfaces, for roll and yaw. Rx aileron output --> roll gyro --> roll stabilized PWM roll stabilized PWM + pitch stablized PWM --> mixer #1 --> left
horizontal surface + right horizontal surface |
|
NightOwl version 5 was actually the first NightOwl to receive stabilization with gyros. Because of the inherent slight variability of the timing circuits in all gyros, the use of three HK 401 gyros meant that the input to the mixers would slowly walk apart from each other, as each gyro's timer was not EXACTLY the same as the other gyros. The timing oscillator output on one gyro was connected to the other two gyros, and their timing oscillators were disconnected and overridden. This kept all three gyros on the exact same timing, and allowed the output of the gyros to be connected into two standard commercial mixers, which are the yellow objects in the photo. |
|
NightOwl version 4 received special home-made mixers were made from PICS with custom code that ignored the inherent timing problems that occur with separate timing circuits in independent gyros. This required that one mixing input come from a gyro set to high-speed digital output at 3 ms frame rate, and one mixing input come from a gyro set to normal speed output at 20 ms frame rate. The 20 ms frame rate was the master for input, and was also used for the output frame rate. The PIC source code for the timing independent mixers is here. Both versions worked great; these separate setups were done to test
if both methods would work. |
|
A final, smaller version of stability was completed on both NightOwl #4 and #5 via the use a 3-axis gyro stabilized receiver from Hobby King. The outputs of the receiver, already having gone through the receiver's internal gyro on each axis, are fed into the same commercial mixers originally used for NightOwl #5. Because all three internal gyros are already on the same timing circuit, no additional modifications are needed. This reduced the components from (receiver + 3 gyros + 2 mixers + special wiring : on the right in photo #2) to (receiver + 2 mixers + less wiring : on the left in photo #2). If you want to build a similar aircraft with three control surfaces (two elevons and a single rudder), as NightOwl's #1 through #3 were configured, you could even eliminate the 2 mixers, as the 3-axis stabilized receiver has the built-in ability to control elevon aircraft. |
PIC 12C508 Drag Rudder Controller
The PIC reads the rudder PWM output from the receiver, and extracts out the left and right commands to send to the separate servos on each wing tip. 1 - 1.5 ms = left rudder, 1.5 - 2 ms = right rudder. Since the left drag rudder only needs to move for left rudder command, and vice versa for the right rudder command, the PIC code translates all of this to individual commands for each servo. The PIC source code for the drag rudder controller is here.
1.0 to 1.5 ms --> left yaw command from receiver
2.0 to 1.5 ms from Rx = no left command --> PWM output = 1 ms to
left drag rudder servo
1.5 ms from Rx = no left command --> PWM output = 1 ms to
left drag rudder servo
1.5 to 1.0 ms from Rx = increasing left command
--> PWM output = 1 ms - 2 ms to left drag rudder servo
1.0 ms from Rx = full left command --> PWM output = 2 ms to
left drag rudder servo
1.5 to 2.0 ms --> right yaw command from receiver
1.0 to 1.5 ms from Rx = no right command --> PWM output = 1 ms
to right drag rudder servo
1.5 ms from Rx =
no right command --> PWM output = 1 ms
to right drag rudder servo
1.5 to 2.0 ms from Rx = increasing right command
--> PWM output = 1 ms - 2 ms to right drag rudder servo
2.0 ms from Rx = full right command --> PWM output = 2 ms to
right drag rudder servo
The PIC reads three momentary pushbuttons as inputs, and drives three
outputs: a PWM for the servo, and two LEDS for status. The PIC starts at
1.50 ms output, and has 100 positions available for output from 1.0 ms to 2.0
ms. One pushbutton increases the output by .01 ms, and one
pushbutton decreases the output by .01 ms, with safety bounds at 1.0 ms and 2.0
ms to avoid overdriving the servo connected to the PWM output. The third
pushbutton puts the PIC into status display, with one LED showing the current
PWM / 10, and the second LED showing the single digit remainder, starting
at 1.00 ms. The PIC
source code for the servo driver is here. Example of status display: At 1.01 ms, push the status button and the LEDs will flash : #1 for 0 flashes, #2 for 1 flash. At 1.59 ms, push the status button and the LEDs will flash : #1 for 5 flashes, #2 for 9 flashes. At 2.00 ms, push the status button and the LEDs will flash : #1 for 10 flashes, #2 for 0 flashes. |
HK Multi-Copter 2.1 Flight Controller
The HK 2.1 rate gyro board was one of the first purpose-built boards designed for multicopters. Before these simple rate boards, multicopters were stabilized by independent rate gyros set up on separate axis and controlling separate ESC or servos, directly or via mixers. These boards have since been made obsolete by the newer HK KK 2.0 and later flight controllers, but they still work fine for other uses. OpenAero software 1.14.1 is available to install to these boards, and this software allows them to act as 3 axis rate gyro stabilizers. The source code is available here.
If you wish to modify this base software, you will need AVR Studio 4 or later (version 4.19 works well), available here. You will also need WinAVR, available here. Finally, you will need to modify a couple settings in AVR Studio to point to the correct locations for the toolchain and compiler. Instructions for those settings are available here. I have also posted all of these setup instructions to RC Groups.
One modification I made to the stock OpenAero firmware was to increase the required timeout period before entering programming mode via the optional LCD. This default period was about 2 seconds, which would enable the programming option. During acrobatics, it is possible to command the correct combination of stick inputs to get into this mode, which disables outputs. I discovered this accidentally while flying an acrobatic plane through a series of snaps. I just happened to hit the correct stick combination and held it for more than 2 seconds. Once the controller had entered programming mode (unknown to me), the plane kept the same control outputs and snapped up, over, and down, right into the ground. I increased the timeout to 20 seconds so this would never happen again. The source software can also be compiled for various wing types: normal, flying wing, and flaperons. I have a flying wing version with the programmable period bumped to 20 seconds in one of my flying wings for stability. Take a look at the source code and experiment with possibilities; many other modifications can be done.
Draganfly FET Interface with PIC 12C508
The original Draganfly quadcopter and its control board has been around for 20+ years. It uses three rate gyros, a custom circuit board with a PIC running custom code, and four FETS to drive four brushed motors. It was expensive, but it was all that was available to fly commercially for a long time. You can get orders of magnitude more performance now out of inexpensive brushless motors, BESCs, and off the shelf flight controllers, but it is still fun to play with these older electronics.
|
Experimenting with this hardware, I traced the wiring on the board
and O-scoped the inputs to the FET gates to see the range of signals
they receive. The PPM pulses going to the FETs last from 0 ms to
5.8 ms. It was a simple matter to solder onto that connection, and
use a PIC to scale the 0.0 ms - 5.8 ms pulse to a standard 1 ms - 2 ms
PWM pulse that is used to control servos and ESCs. I built four of
these converters and tested them to drive four servos from the Draganfly
board. The PIC source code for the Draganfly FET to PWM converter is here. |
|
I then used the Draganfly board and the converters to drive brushless ESCs and motors on a home-made quadcopter of similar size to the Draganfly. This worked fine electronically, but the gains were vastly different between the original brushed Draganfly setup and the brushless setup of the new quadcopter. A modification to the code in the PIC converters would allow variable gains (scaling of 0.0 ms - 5.8 ms --> 1 ms - 2 ms) via a separate PWM input, but I have not gone back to make that addition to the code yet. It is still something to be done when I have the time. The original Draganfly board and converter board with four PICS, mounted to a simple frame, is shown the first photo. The original Draganfly frame with its brushed motors, and the new brushless motor frame with the adapted electronics is shown in the second photo. |
Hextronic/TowerPro Mag8 15-18A ESC with SimonK firmware
There are several version of this ESC, with two different combinations of FETs: pFETs + nFETS, or just nFETs, and different clock sources: 16 MHz external, 8 MHz external, 4 MHz internal. I traced the ATmega8 pinouts to each set of FETs on the Mag8 version that I own, but none of the definition files for the SimonK Mag8 alternatives ( tgy.inc, tgy6a.inc, tgy_8mhz.inc, tp.inc / tp_8khz.inc / tp_nfet.inc) matched these versions of Mag8s that I own for pinout to FETs or the external 16 MHz oscillator present. I figured I would have to make my own definition file and compile a special version of SimonK firmware for my Mag8 ESCs. However, after more searching, I found that the rct50a.inc and tp70a.inc FET definitions matched my Mag8 for pinouts, with the low side FETs inverted for TP70A. Both also specify a 16 MHz clock. The analog input channels (PC2/ACD2, PC3/ADC3, PC4/ADC4) to read the back EMF from each motor phase, the main voltage input (PC7/ADC7), and the PWM input on PD2 also match the connections on this version of the Mag8. The Mag8 ESCs that I have use a separate daughterboard for the 5V BEC, which is three 7805 voltage regulators wired in parallel. I have removed the BEC from these ESCs to save weight, since the 5V supply is not needed for the multi-rotors to which I have installed these ESCs. These photos show the top and bottom of the ESC with the 5V BEC daughterboard removed.
TP70A.inc definitions for ATmega8 pinouts:
; PORT D definitions *
;*********************
.equ ApFET = 7 ;o
.equ c_comp = 6 ;i common comparator input (AIN0)
.equ AnFET = 5 ;o
.equ BnFET = 4 ;o
.equ BpFET = 3 ;o
.equ rcp_in = 2 ;i r/c pulse input, opto-coupled, needs pull-up [This 18A Mag8
is not opto-coupled like the 70A version, but this does not impact the code
execution.]
.equ CpFET = 1 ;o
.equ CnFET = 0 ;o
; PORT C definitions *
;*********************
.equ mux_voltage = 7 ; ADC7 voltage input (44k from Vbat, 2.0k to gnd, 10.45V in
-> .448V at ADC7)
;.equ = 6 ; ADC6
;.equ = 5 ; ADC5
.equ mux_c = 4 ; ADC4 phase input
.equ mux_b = 3 ; ADC3 phase input
.equ mux_a = 2 ; ADC2 phase input
;.equ = 1 ; ADC1
;.equ = 0 ; ADC0
The TP70A version works in these ESCs; Hextronic must have wanted to use the same firmware in different ESCs, so they made the ATmega8 pinouts the same between the original version of the Mag8 15-18A and the TowerPro 70A ESCs. The faster update via OneShot125 and better ESC control inherent in SimonK allows for much higher gains on the multi-rotors with Mag8 ECS with SimonK firmware. Updating these ESCs from stock firmware to SimonK firmware made the difference between an unstable multi-rotor and stable multi-rotor with the exact same PID gains.
Lemon Telemetry Receiver with RSSI + HobbyKing E-OSD with updated firmware to display RSSI
Lemon Telemetry Receiver with RSSI (LM0051 / LM0052)
- LM0052 receiver includes altitude sensor with altitude & variometer
(climb/descent rate), receiver voltage, RSSI - all sent via telemetry to ground
- LM0051 does not include the altitude sensor & variometer
- additional telemetry supported :
- main battery pack voltage + main battery pack current - needs connection
to Lemon V/I sensor; need to calibrate this connection
- main battery pack voltage only - needs connection to main battery
pack positive lead; need to calibrate this connection
- temperature - needs temperature sensor
Set switch on DX9 for altitude voice readout.
Set switch on DX9 for main battery pack voltage voice readout.
Set switch on DX9 for Rx voltage voice readout.
Set alarm on DX9 for low main pack voltage.
Set alarm on DX9 for low receiver voltage. This receiver needs 4.5 volts
to function, so set the alarm level a little higher, at 4.7 volts. ESC BEC
output should
always be at 5.0 volts.
Set audio tone on DX9 for variometer report; you can set the up and down rates
in ft/sec where tones will start.
- RSSI (received signal strength indicator) is down-linked via telemetry, and
is also output at the receiver via an analog pin
with 0-3V range = 0 - 100% RSSI
HOWEVER (!), the RSSI value down-linked in the telemetry stream is NOT displayed as RSSI; it is displayed as FlightLog - A, which is signal strength for the main receiver. This is annoying, as there is no way to set up an audible alarm on the DX9 for FlightLog - A, while an audible alarm can be set for RSSI. I confirmed this with the latest Spektrum firmware Airware version installed to my DX9 as of July 2020.
I contacted Lemon about this in July 2020. The response was that Lemon had implemented RSSI before Spektrum had added RSSI to the Spektrum telemetry stream, so Lemon used the best available data field at the time, which was FlightLog - A. When Spektrum added RSSI to Spektrum receivers, they included RSSI in a different data field labeled 'RSSI', and enabled the alarms on Spektrum transmitters on that new field. Lemon plans to release newer versions of their RSSI receivers, and will be putting RSSI into the same data field that is used by Spektrum. With these new Lemon receivers, the same low RSSI alarm will be able to be programmed on Spektrum telemetry-enabled transmitters, as can be done with Spektrum receivers.
Set audio alarm on DX9 for low RSSI. - cannot be done yet,
Lemon-reported RSSI not a valid telemetry audio option (!)
Set switch on DX9 for FlightLog-A voice readout. - cannot be done yet, Lemon-report
RSSI not a valid telemetry voice option (!)
The analog 0-3V RSSI output can be read by a flight controller or an on-screen
display (OSD) video overlay.
Using the
E-OSD from HobbyKing : https://hobbyking.com/en_us/hobbyking-e-osd.html
There is a free firmware upgrade available for the E-OSD, called
CL-OSD firmware.
- https://code.google.com/archive/p/cl-osd/wikis/Programming.wiki
-
https://www.rcgroups.com/forums/showpost.php?p=26238951&postcount=3213
-
https://oscarliang.com/e-osd-flash-firmware-rssi-display-using-arduin/
This new firmware needs to be flashed to the E-OSD ATmega88 processor. You
will need to solder connectors to the 6 pin ISP headers on the E-OSD. They are
defined here:
http://static.rcgroups.net/forums/attachments/3/1/3/1/1/2/a4051434-140-E-OSD.jpg
These photos show the E-OSD with the 6 pin ISP connections on the E-OSD. I had a spare board and just wired them with the same pinout that is used by a USBASP. The videos show flights on 26 July 2020 and 7 August 2020 at the RCMB flying field with this setup in a 5' flying wing.
The new firmware is flashed with the application AVRDude, which is available for Windows, Linux, Mac. AVRDude can be used to flash many ATMega chips on Arduinos, ESCs, flight controllers.
The AVRDude command line options are explained here:
- https://www.nongnu.org/avrdude/user-manual/avrdude_4.html
If programming with a USBASP (same USBASP which is used for a HobbyKing KK 2.1 flight controller), the command line is:
>avrdude
-P usb -c usbasp -p ATmega88P -v -e -U flash:w:cl-osd.hex -U eeprom:w:cl-osd.eep
This assumes you have the two files to flash located in the same directory as AVRDude. The individual command line options are:
-P usb -c usbasp (port = usb, programmer = usbasp)
-p ATmega88P (CPU =
ATmega88P)
-v
(verbose output to display everything - this is useful for debugging problems,
but not mandatory)
-e (erase; need to toggle everything to 0 before writing)
-U flash:w:cl-osd.hex (write to flash
memory,
"cl-osd.hex" is the executable)
-U eeprom:w:cl-osd.eep (write to eeprom
memory,
"cl-osd.eep" is the eeprom memory - this is the character set / font used for the video
overlay)
You MUST write both files to the ATmega88P, because the executable relies on the character set as the display font.
Once the new firmware has been flashed to the E-OSD, you connect video, main battery pack voltage, and the 0-3V RSSI voltage from the Lemon receiver to the E-OSD. Main voltage goes to battery input #1 and RSSI voltage goes to battery input #2.
To display RSSI as an overlay in video downlink, you need to calibrate low and high RSSI voltage
values.
If you wish for the main battery pack voltage to flash at a low level, you need to calibrate low voltage value
for that flashing alarm.
Calibration of each of these values is explained here:
https://www.rcgroups.com/forums/showpost.php?p=26238951&postcount=3213
HobbyKing Orange UHF 915 MHz and 433 MHz Long Range Datalinks using OpenLRSng software
I have an Orange UHF 1 watt 915 MHz transmitter module which can drop right into the RF module section of my JR XP8103 radio. The transmitter module is running Open LRSng (long range system - next generation) software, available here at Github. I previously also had an Orange UHF 1 watt 433 MHz transmitter module, but decided to use only the 915 MHz equipment, so I sold the 433 MHz equipment. The photos to the right show all the modules I originally purchased to experiment with, when HobbyKing had a good sale. For actual flying I have replaced the stock whip antennas with home-made dipole antennas on everything except for the 915 MHz transmitter, which has a FrSky Super 8 antenna. These various modules have RF output power levels that range from 100 mw to 1 watt, depending on the transceiver module and supply voltage. Details on how to build the homemade receivers are below. |
|
XP8103: 915 MHz Tx, RFM23B @ 6V [1 watt],
Orange Tx with 6V
DC-DC converter & capacitor added, Super 8
antenna - uplink range of 10.75 miles at 1 watt - downlink range of 6.8 miles at 400 mw - downlink range of 3.4 miles at 100 mw Details on #5 and #6 @ 915 MHz: I have two Orange 9ch receivers that were both originally 433MHz receivers. Those two receivers are shown in the top photos on the right, and they use the RFM22B transceiver, which is rated at 100 mw RF maximum output. I swapped the RFM22B 433MHz RF modules for RFM22B 915MHz RF modules, and re-flashed the ATmega328P processors with 915 MHz receiver firmware. As of February 2020, HobbyKing was selling the Orange 9ch 433 MHz receiver for $13. The RFM22B 915 MHz RF modules can be found on eBay for about $7 shipped. After a little soldering, that gives you a small, long range 915 MHz receiver with RSSI and telemetry for $20. 915 MHz Range Tests: During a flight test in April 2021 using the Orange 915 MHz transmitter with a Super 8 antenna, and an Orange 915 MHz transmitter modified to be a receiver, with a homemade 915 MHz dipole antenna, the wing reached 1950 feet altitude and 1551 feet ground range, for a total line of site distance of 2491 feet. The received signal strength indicator (RSSI) was 73% at this point. During a second flight test in April 2021 using the Orange 915 MHz transmitter and a homemade 915 MHz receiver with the RFM22B transceiver module, with the same antennas as above, the wing reached 1463 feet altitude and 1213 feet ground range, for a total line of site distance of 1900 feet. The received signal strength indicator (RSSI) was 68% at this point. During a third flight test in April 2021 using the Orange 915 MHz transmitter and one of the Orange 9ch receivers, which I had converted from 433 MHz to 915 MHz, with the same antennas as above, the wing reached 1530 feet altitude and 757 feet ground range, for a total line of sight distance of 1707 feet. The received signal strength indicator (RSSI) was 71% at this point. |
|
Details on #2 @ 433 MHz:
The older version Orange 100 mw 433 Mhz transmitter module
was configured as a receiver. Using dipole antennas tuned to 433 MHz wavelength, the
433 MHz equipment has a calculated: 433 MHz Range Test: |
|
The Orange Open LRSng transmitter module's hardware for each frequency is identical, except for the HopeRF RFM23BP transceiver which is tuned to 433 MHz or 915 MHz. Open LRSng software also supports the RFM23BP 868 MHz transceiver, if you want to operate in that band. They are listed as having a 1 watt RF output, but these “1 watt” transmitter modules do not really provide 1 watt RF output in their stock configuration. The voltage regulator on the board only supplies 3.3 volts to the RF transceiver, which then provides an RF output of around 400 mw. That RFM 23BP transceiver is rated at 1 watt RF output at 5.5 to 6 volts input, so the only way to get 1 watt RF actual output is to bump up the voltage input to between 5.5 to 6 volts. You have to be careful how you do this, because other components on the board will get fried at 5.5 volts. I have added an adjustable DC-DC converter set at 5.5 volts, with a large capacitor to keep a smooth supply. This 5.5 volts goes just to the RF section of the transceiver module, isolated from the rest of the board. This DC-DC converter and capacitor are protected in shrink wrap, and sits inside the transmitter module, shown to the right. You can see the power input to the RF section on the red wire in the bottom center of the photo. That trace which now has 5.5 volts running to it has been cut on the board to isolate the RF transceiver power from the rest of the board. The built-in 3.3 volt regulator powers everything on the board, except for the RF section of the RFM23B transceiver, which is powered at 5.5 volts from the added DC-DC converter. |
|
I have several additional Orange 1 watt 915 Mhz transmitter modules configured as receivers, having re-flashing them with Open LRSng 915 MHz “use transmitter as receiver” software. Leaving the 3.3 volt power supply unaltered on the "receiver" modules for simplicity sake, they are good for about 400 mw downlink, but still provide very long range telemetry and include RSSI. The "receiver" modules are wired to accept 6 – 12 volts input on a JST connector, and provides PPM output on a standard 3-pin servo connector. There is normally a transistor controlling the built-in buzzer on these "receiver" modules. The pin from the ATmega328P processor that controls the buzzer is also the one pin that can supply PPM output, so you have to desolder that transistor if you don't want the buzzer running all the time when PPM is output on that pin. I run this PPM signal to a flight controller running iNav software. |
Homemade OpenLRSng Receiver
You will need an Arduino Pro Mini running at 16 Mhz, and an RFM22B or RFM23B UHF module at 433 Mhz, 868 MHz, or 915 MHz; whichever frequency you are using. The pinouts on the RFM22B and RFM23B are the same. The RFM22B is powered at 3.3 volts and provides 100mw (20 dBm) of RF output power. The RFM23B is powered by 3.3 to 6 volts and provides up to 1 watt (30 dBm) of RF output power. While the RF portion of the RFM23B can be powered by more than 3.3 volts, the digital control pins MUST be powered at 3.3 volts, so the Arduino Pro Mini that controls the RFM23B must be powered at 3.3 volts, so that its digital outputs will be at 3.3 volts. If you power the Arduino at 5 volts, it will send digital control signals at 5 volts, which will degrade and damage the control circuitry of the RFM23B. If you want the full RF power of 1 watt from the RFM23B, it must be powered at 5.5 to 6 volts, but again, only the RF module can be powered by more than 3.3 volts - the controlling CPU must be powered by 3.3 volts so the digital IO it sends the RF module is at 3.3 volts.
The final receiver, a combined Arduino and RF module, is shown in the left photo connected to an ARM F1 flight controller. The receiver sends a PPM signal to the FC via two wires: ground and signal. The PPM output from the Arduino is run to an ARM F1 flight controller running iNav in this example, but any FC that accepts PPM will work. The OpenLRSng software is also capable of outputting several different serial signals, including Spektrum satellite and SBUS. You would use the serial Tx pin from the Arduino for that connection. I built the first two homemade receivers with RFM22B transceiver modules using a soldered, permanent antenna connection. After building those first two receivers, I reworked the PCB layout to add a SMA connector for removable antennas for later receivers. The front and back of this final layout is shown to the right. That turned out so nicely that I went back and changed part of the traces on the first two receivers to allow the same SMA connectors to be used to allow removable antennas. |
|
|
Using the connections above, you must use the type 2 receiver board software available on the OpenLRSng website. You flash this software to the Arduino Pro Mini using either the OpenLRSng Configurator or AVRDude. The syntax for the AVRDude command line when using an USBASP programmer is: >avrdude -p m328p -P usb -c usbasp -e -U flash:w:RX-2-bl.hex -U lfuse:w:0xFF:m -U hfuse:w:0xDE:m -U efuse:w:0x05:m -p 328p (CPU = ATMega328P processor on an Arduino Pro Mini board) -P USB -c usbasp (port = USB, programmer = USBASP) -e (erase; need to toggle everything to 0 before writing) -U flash:w:RX-2-bl.hex (upload and write the OpenLRSng executable (.hex) file to flash memory) -U lfuse:w:0xFF:m (sets the low fuse byte to 0xFF) -U hfuse:w:0xDE:m (sets the high fuse byte to 0xDE) -U efuse:w:0x05:m (sets the extended fuse byte to 0x05) The three fuse bytes must be set correctly to allow the program to run at the correct clock speed and use the proper resources on the processor. This web page details the fuse bits: https://github.com/openLRSng/openLRSng/blob/master/README.md |
Immersion Vortex F1 Flight Controller with OSD and barometric pressure sensor
I have this same information available at RCGroups here.
HobbyKing had a sale on the Vortex F1 flight controller for $5. https://hobbyking.com/en_us/vortex-f...c-osd-pcb.html I know you can buy just about any F1 FC for around $10, and F3 and F4 FCs for just a little more. I still wanted to see if this FC could be made to work on another multicopter, so I bought a few to experiment with. The Fusion Vortex F1 FC (gen 1) board has two ARM F1 processors and a baro pressure sensor for altitude. ARM F1 #1 runs the flight controller. The earliest version of FC firmware was stock NAZE, but the last version is a special compile of BetaFlight 3.1.7. ARM F1 #2 runs the OSD and also acts as an intermediary between the USB connection and the FC ARM. |
If you want the latest FC and OSD firmware, you can download it from Immersion
RC here. Select Firmware / Downloads at the bottom of the page:
https://www.immersionrc.com/fpv-prod...x-racing-quad/
Latest firmware release Vortex_285_OSDv1.0.0.43_BFv3.1.7.zip, includes:
- OSD firmware 1.0.0.43
- IRCFUSIONF1.hex (BetaFlight 3.1.7)
You will also need the Immersion utility software available at this same page:
- Vortex Configurator v0.0.1.7
- IRCDrivers (x86 or x64) for 32 or 64 bit OS
- IRCRool v1.42.5
Once you have the OSD firmware installed, you will need a copy of BetaFlight
Configurator 10.4.0 to flash FC Betaflight firmware (IRCFUSIONF1.hex). You can
get that here:
https://github.com/betaflight/betafl...ses/tag/10.4.0
CN4:
1 - GND
2 - M6 ESC PWM signal
3 - M1 ESC PWM signal
4 - M2 ESC PWM signal
5 - M4 ESC PWM signal
6 - M5 ESC PWM signal
7 - N/C
8 - 5V
9 - Battery pack resistor divider output. I tried a 10k/1k divider and the
voltage as displayed by the OSD was not correct, and the voltage as shown in
BetaFlight configurator was also incorrect with a different wrong value. It may
be something like 10k/3k, but I have not tried other resistor values to find the
correct ratio.
10 - M3 ESC PWM signal
11 - LED Board RX
12 - LED Board TX
CN5:
1 - GND
2 - RX PPM
3 - GPS RX
4 - GPS TX: GPS TX goes to this pin - for a serial receiver, the serial receiver
Tx goes to this pin. Make sure to use a correct voltage adaptor, as serial sat
receivers run on 3.3V, and the FC board requires 5V.
5 - VTX AL6.0 (Fusion board output)
6 - USB D-
7 - USB D+
8 - Video Input
9 - Video Output (includes OSD)
10 - VTX CS1
11 - VTX CS2
Steps:
Make USB connection for flashing new firmware (OSD + BF)
Flash both ARM F1's.
Unplug USB connection.
Provide power from 5V source with USB not active.
Have a PPM receiver connected to proper connections (+5, PPM, GND) or serial
receiver connected to GPS serial connector (with correct voltage adaptor, as
DSM2 and DSMX satellite receivers run on 3.3 v).
Once done with the TxWizard process, all mods to BetaFlight can be done with BF
Configurator, and some BF mods can be done with OSD menu system:
- you can adjust the PIDs at field via OSD - this is nice capability
- ex: can change mixer (up to any 6 channel multicopter) via BetaFlight-Config
- ex: can change modes and channel controls for each mode (like arm/disarm on
switch instead of stick movement)
- alter anything via BetaFlight-Config and it will remain as set by
BetaFligh-Config until TxWizard is run again
- if you do have to re-run TxWizard, it will reset everything in BetaFlight to
defaults, so you will have to redo all BetaFlight-Config changes
Note that all mods to the OSD layout are done with the OSD menu.
BetaFlight-Config does not affect the OSD, which is completely separate from any
BetaFlight-OSD settings.
To verify that the OSD ARM F1 will not be modifying anything after TxWizard is
complete, I soldered onto the serial connection from the OSD ARM F1 to the FC
ARM F1. I used RealTerm and monitored the UART Tx from the OSD ARM to the FC ARM
to see the actual MultiWii Serial Protocol (MWSP) commands and requests sent to
FC at boot.
- before TxWizard has been run, the OSD resets several items within BetaFlight
every time it boots, so once you have everything wired together and a receiver
bound to your transmitter, TxWizard should be your first step in the setup
process
- after TxWizard is complete, the OSD does not reconfigure anything at boot
- attached is a photo of the wiring connection for COM monitoring with a FTDI
adaptor, serial setting is 8-n-1, 115200 baud
5' Travel Wing Avionics (first configuration)
Most of my FPV aircraft have some type of flight controller or stabilization. I have installed a slightly unique setup to my 5' wingspan flying wing, which I built to be disassembled so I can take it apart and fit it in my luggage for traveling. This setup uses an AcroFlight Naze32 rev 6 flight controller running a special compile of iNav 1.7.2, a micro MinimOSD running MWOSD 1.6 firmware, a Lemon LM00052 DSMX receiver with telemetry, and GPS receiver.
The Lemon DSMX receiver, in addition to supporting telemetry downlink back to my Specktrum DX-9 transmitter, also supplies an analog signal for received signal strength indicator (RSSI). RSSI is used to determine the strength of the uplink control signal. I used this same receiver and its RSSI output for the setup above on this page where the RSSI signal is read by special software running on a HobbyKing E-OSD video overlay device. I wanted to add a full flight controller to this flying wing, and continue to take advantage of the Lemon RSSI output.
The AcroFlight Naze32 rev 6 flight
controller runs the same special compile version
of iNav 1.7.2 that I run on all my Flip32 flight
controllers,
as
detailed here. This FC has a full IMU,
barometric pressure sensor, and magnetometer,
but I have turned off the magnetometer for this
fixed wing non-hovering application.
Position data comes from a GPS receiver
installed at the far right wingtip. This
keeps the GPS receiver away from the main
avionics in the center of the wing, and the
5.8GHz video transmitter in the far left
wingtip. The FC also monitors the main
battery voltage (VBAT), which is included in the
data sent to the OSD. Main 3S lipo battery power at 12V is cleaned by a 3 amp LC filter, and then dropped down to 5V for the avionics by a DC/DC converter with smoothing 24V, 330 uF capacitors (C1 & C2) on each side. I originally had a 7805 regulator with a heat-sink, but even with the minimal current requirements of just the GPS, FC, RC Rx, and OSD, it got too hot for taste. The ESC BEC provides isolated 5V power for the two elevon servos. I like to keep avionics and servo power separate. The diagram shows two 3S battery inputs, but that is just to display the divide between avionics and motor/servo power. All power comes from a single 3S lipo battery. The Lemon RC receiver supplies RSSI as an analog 0 - 3V output signal. This version of the Lemon receiver does not include a PPM output, so I either had to install a PWM to PPM converter to get that signal into the FC, or use 6 separate PWM inputs to the FC (throttle, aileron, elevator, rudder, aux1, aux2). Since this FC supports PWM input, I used that method. This Lemon receiver also separately monitors main battery voltage, receiver-avionics voltage, altitude, and an external temperature thermocouple. All these values are sent in the telemetry downlink, and I have my DX-9 configured to use voice output to read these values out by toggling a switch on the radio. Video overlay information is supplied to the micro MinimOSD via a serial connection. The analog RSSI 0-3V signal and 5V avionics power are monitored by the OSD hardware and included in the video overlay. |
5' Travel Wing Avionics (second configuration)
JR XP8103 Transmitter with Flight Mode Switches
I have various flight controller hardware
installed to my multi-rotor and fixed wing FPV
aircraft. I use BetaFlight software on all
my multi-rotor aircraft, and iNav software on
all my fixed wing aircraft. The various
flight modes for autopilot control in each
software package are set using RC auxiliary
channels (usually channels 5 and higher), with
each flight mode set within a specific region of
that channel's command. For example,
channel 6 may normally be used for flap control
with the three available switch locations used
to command three discrete flap throws: flaps up
/ flaps at takeoff / flaps down, or something
similar. Using those same three positions
with iNav, position #1 is used to command manual
mode (no flight controller stabilization),
position #2 is used to command rate mode, and
position #3 is used to command horizon mode.
These are the three basic flight modes for iNav. There are many more flight modes available, most of which make use of an altitude sensor and GPS to allow automatic navigated flight to specific locations and altitudes. These navigated flight modes are normally commanded via multiple 3-position switches, but the XP8103H only has one 3-position switch, with the rest being 2-position (gear, throttle hold, dual rates) or continuously variable dials (hover pitch, hover throttle, pitch trim). The continuously variable dials could be used to set multiple flight modes, but you would have to ensure you have the dial set to a specific location as you turn it, which can be tricky as you are flying. I have modified my XP8103 on channel 8 to include an input select switch and discrete push-button box. With the select switch (the small red switch next to the channel 8 hover pitch control dial) set to position #1, the channel 8 input comes from the normal RC dial on the top of the transmitter. With the select switch set to position #2, the channel 8 input comes from the push-button carbon fiber box attached to the top of the transmitter. This box contains five momentary-on push buttons, a programmable integrated circuit (PIC) 12C508 running custom software I wrote, and some electronics that mimic the potentiometer of the channel 8 control dial. The PIC 12C508 has six input/output pins; I have five pins connected to the pushbuttons and one pin connected to drive an output signal with a variable duty cycle. Whenever a button is pressed, the PIC output pin is set to high (5V) or low (0V), at various duty cycles at an update rate of 250 hz (40 ms frame rate). Whatever was the last button pressed remains the command until a new button is pressed. You can see the output for each switch command on AUX3 in the photos below; ATV has been set to 125% for AUX3. Button #1 = 0% duty cycle (always 0V) = no navigation flight modes are turned on. Button #2 = 25% duty cycle (5V for 10 ms, 0V for 30 ms) = launch mode. Button #3 = 50% duty cycle (5V for 20 ms, 0V for 20 ms) = altitude and position hold = loiter in a circle. Button #4 = 75% duty cycle (5V for 30 ms, 0V for 10 ms) = waypoint navigation. Button #5 = 100% duty cycle (always 5V) = return home. A resistor-capacitor (RC) filter, with R = 15K to 21K ohm, C = 10 uF, is used to smooth off this duty cycle 'flickering' output to a smooth value that is fed back to the transmitter where it normally receives the channel 8 potentiometer input. Tau (the RC filter time constant) = .15 to .21 seconds with these values, which works nicely with the 250 hz update rate of the PIC output. There is still a small amount of 'flickering' using this setup as the RC filter charges and discharges at the 25% / 50% / 75% duty cycles, but it only amounts to a few microseconds at the final PWM output from the receiver. Each iNav mode setting is defined within a small range, and this tiny variation does not matter. There are different ways to improve this setup; a more powerful PIC or even an Arduino with more IO could be used, the PIC 12C508 five input pins could be multiplexed to allow 6 switch selections, and a real digital potentiometer could be used to drive the final output instead of a simple RC filter. However, I kept it simple, this works for me, and I already had all the electronics in my parts bins. The PIC source code and executable .hex file are available here for download, along with a schematic of the whole thing. More information on use of the PIC 12C508 in other projects is available here. |
|