Thank you for your detailed explanation. Nice work with the drone. As I said above, I still don’t understand why you are using the Teensy. I apologise, it must be that I am missing something. If you set protocol to 10, it is already in DIY Frsky passthrough protocol, it just needs a hardware inverter to work with the R9. No Teensy. If you set it to Mavlink 1 or Mavlink 2, then you need the Teensy, right? If you are indeed using Mavlink 2 and the Teensy, be sure to use the latest firmware.
Flight mode is predicated on frame_type. Naturally, if you are a quad drone, (flight) modes are not the same as a plane or submarine. Frame type is transmitted a few times after boot up of the flight controller, and then should happen periodically after that. If the Horus misses them for any reason, it can’t display flight mode.
thank you
I think I didn´t explain it well enough. We used also the hardware inverter in the past without any problems, but only in the combination with the X6R and Horus X12.
When we used than the R9 and R9M, the same problem appears, telemetry gets lost and does not come back.
So we are little bit at a loss, where exactly the problem could be, we already tried the latest firmwares for the R9 and R9M.
You are in Europe I think. The FrSky firmware includes LBT (listen before transmit) to comply with EU law. Maybe this is the variable. Did you make sure there is no noise on the band? You could use an SDR receiver, like the HackOneRF or similar.
Just wanted to report that I had a little trouble getting your libraries going. For some reason I had to manually copy c_library_v2 over to my local libraries. The rest seem to work fine on clean teensyduino install.
I also cannot get Craft and Theory Flight Deck to work, even though yaapu works great. I was sure to comment out the plus option, am I missing anything else?
Do you mean the mavlink-c_library_v2 ? Yes, I don’t include the mavlink library because it is so big, but simply provide the link.
If I’m not mistaken, for FlightDeck you need to “discover new sensors” on the Taranis/Horus, but Alex’s newer implementations pick up the sensors automatically.
Also you must have a good RSSI reading, but that is also true with yappu’s interface.
I’d like to tell that it is possible to use your wonderful mav2pt solution, together with TBS Crossfire, for displaying the telemetry with the yaapu lua script (and of course relaying the mavlink to wifi as well). I’m using a ESP32 dev module for that task.
Some simple modifications for the connection Taranis <-> Corssfire <-> ESP32 are necessary.
Pin 1 of the Taranis expansion slot connector receives the PPM from the Crossfire TX. So you have to reconfigure the settings for the external HF module to PPM (12 Channels).
Pin 3 is Vcc to Crossfire and to ESP32. The ESP32 Dev module I’m using has it’s own voltage regulator, so it is no problem to feed the 8v from Taranis directly to the v5 pin of the module.
Pin 4 ist GND.
Pin 5 must be disconnected from the Crossfire TX. This is the the SPort input from the ESP32. As the ESP32 with mav2pt can invert and single wire on its own, there is no need for an external onewire or inversion logic.
Software configuration in config.h (I’m using the recent version 2.56.4): Telemetry in/out to the FC via Crossfire Bluetooth: #define Ground_Mode #define FC_Mavlink_IO 1 #define GCS_Mavlink_IO 2 #define BT_Mode 1 #define BT_ConnectToName "Crossfire "
//#define RSSI_Override (comment out) Telemetry relay to WIFI (either as own acces point, of connecting to a existing network): #define HostName #define APssid #define APpw #define APchannel #define STAssid #define STApw #define Start_WiFi #define WiFi_Mode 3 #define WiFi_Protocol 2 ESP module specific settings: #define ESP8266_Invert_SPort_To_Onewire #define ESP32_Variant 1 #define MavStatusLed 01 (in my case)
Caveats (at the moment):
From time to time the Taranis or the yapuu script announces a “telemetry lost”, immediately followed with a “telemetry recovered”. It seems that from time to time the RSSI packets are coming a litte tick to late. But tha must be investgated deeper
Maybe this litte text is helpfull for some of you.
Thank you, Eric, yaapu and all others for your wonderful work.
Great work on that CrossFire, and thanks for sharing. I’m sure there will be others who are interested in your project.
For the “telemetry lost” problem, take a look at this code, around line 1100 in the main module:
if ((set.trmode == ground) || (set.trmode == relay)) { // In Air_Mode the FrSky receiver provides rssi
if (((rssiGood) || ((rssiOverride) && mavGood)) && (millis() - rssi_millis > 700)) {
PackSensorTable(0xF101, 0); // 0xF101 RSSI
rssi_millis = millis();
}
}
Try changing the 700 mS, to a smaller timing cycle for the rssi packet. Try 500mS, or even 200mS. Perhaps something is delaying the packet somewhere. OpenTX starts to complain when it gets no rssi packet for around 800mS if I remember correctly.
I just wanted to give an update, we solved the problem for the lost telemetry. It was so simple The teensy received the 5V from the receiver, in the air it received some spikes above the 5V and it stopped working.
Only thing left is, that it does not show the flight mode on the horus.
Hi Graham, no you can compile successfully without the board. You need to move all the libraries in my GitHub library folder into your Arduino library folder. Also click the link to the Mavlic C library, download it and add it to your library file.
@Eric_Stockenstrom Does your code with the ESP-F support hardware flow control? I believe the cts, rts lines are wired in the TXMOD module. RFDesign recommends using HW flow control.
Good question David. I know the RFD900x has optional flow control for the telemetry path between the two transceivers, on the ground and in the air. That is where it is most needed. Now, when telemetry arrives at the ground trx, we divert it to the GCS using WiFi. So there is a second telemetry path from ground trx to GCS, where different flow control might apply. The first hop is from the trx UART to the ESP-F board, on a few cms of copper, and the second hop from the WiFi radio modem to the GCS using UDP (or TCP) with their own protocol. UDP will not have flow control.
I have not tried to support rts/cts on the first hop (of the second path), as I doubt it matters there. But I’m open to ideas and guidance.
On earlier versions I only sent frame type a few times early on after booting, as the information is static and I wanted to save bandwidth. But if you only connect later, the LUA script never gets frame type, so does not show flight mode. Flight mode is dependent on frame type.
Fixed in later versions. See Change Log. Hope that helps.
I was thinking about flow control on a very basic level, like only allow to trasmit/receive, when the serial buffers are not full. I have no idea how often the serial buffers are full in practice, but that´s my understanding how it should work on a basic level.
Also something different: I noticed, that I can only connect to the ESP-F wifi after I have powered on my drone. Does this also happen with your setup?
As I said above, I still don’t understand why you are using the Teensy. I apologise, it must be that I am missing something. If you set protocol to 10, it is already in DIY Frsky passthrough protocol, it just needs a hardware inverter to work with the R9. No Teensy. If you set it to Mavlink 1 or Mavlink 2, then you need the Teensy, right? If you are indeed using Mavlink 2 and the Teensy, be sure to use the latest firmware.
The teensy received the 5V from the receiver, in the air it received some spikes above the 5V and it stopped working.
