After weekend tests of Betaflight 3.5 and some discussions with Betaflight developers, here are two things you have to (yes, have to) change in Betaflight 3.4 and 3.5 if you did not did that yet. Worth to do it!
Looks like I was able to solve all major known problems with my DIY long range radio system Crossbow. I'm writing known, since no idea what lies beneath… Anyhow… What changed? Quite a lot:
- I've extended Arduino-LoRa library with ability to transfer full packet in single SPI transaction. Right now, each read of write to SX1276 uses single transaction. Previously, there were 2 transactions per byte…
- The same library now has ability to send packets in async mode. Previously it was blocking code execution until LoRa packet was transmitted. Huge waste on processing time
- With OpenTX 2.2.1 on the loose, I was finally able to drop PPM input from Taranis to TX module and replace it with S.BUS. But not without problems. According to specification, S.Bus should be
SERIAL_8E2. But my Taranis clearly outputs it as
- For now, OLED display is disabled. It was taking too much time to update it using I2C and TX module was loosing S.Bus packets
- I've improved RC channels processing time, time required for encoding/decoding went down by 1ms
- It is still LoRa32u4 II 868MHz based but I'm considering different hardware. For example ESP32 with LoRa. Time will show
Next test hopefully this weekend. If weather allows, of course. We have very wet autumn this winter in central Europe this year…
One of the most important features of modern, computerized, radios is that you can make them talk to you. After all, with setup telemetry link from UAV, radio should “know” things. Things like battery voltage for example. Why not make FrSky Taranis (or Horus or Taranis X Q7) talk to you and report LiPo voltage in a smart way?
In OpenTX menu navigate to last page called Telemetry and check if VFAS is reporting proper value.
FrSky X9D Plus Taranis or cheaper FrSky Taranis Q X7 or even more expensive X10S Horus, are incredible radios. But also can be intimidation when migrating from simpler radios. A great example is mixing multiple switches into 1 channel to pass flight mode to the flight controller. Yes, you can do it, but it can be a pain in the ass on a Mixer level. I've lost a lot of time trying to understand the logic behind mixer weight and offset only to discover possibility to replace channel value, not add. And everything was simple again. So, here what I wanted, and what I did.
What I wanted
When I fly bigger FPV quadcopter, I want to use 7 different flight modes:
- Angle without Altitude Hold (no BARO),
- Horizon without Altitude Hold (no BARO),
- Acro/Rate without Altitude Hold,
- Angle with Altitude Hold (BARO),
- Horizon with Altitude Hold (BARO),
- Position Hold with Altitude Hold (BARO),
- Return To Home with Altitude Hold (BARO)
And I've figured out, that 3 switches should be used to enable all the flight modes: SC, SD, and SG. SC toggles Angle/Horizon/Acro. SD switches PosHold and RTH (as well as BARO and overrides SC and SG). SG enables Altitude Hold but only when SC is in up or middle position. 3 switches, 7 modes. I could do it with 3 radio channels, but that would have few flaws: would use 3 channels instead of one, and would allow for mistakes like no BARO with POSHOLD. So, advanced mixes and logical switches that is. Continue reading “Multiple flight modes for Cleanflight with Taranis” »