Loris, may I suggest that you rather flash the TXMOD with the 8266 version of mav2pt. I’m flatout busy for the next few days and hope to look at this later this weekend. In the meantime there are lots of guys here who will help.
I’v been working on adding an ESP32 Variant and came up with a new feature you guys might appreciate.
Dual Screens!
So any time a message comes from the software I flip to Link Status for 5 seconds.
Then I switch back to a system status screen with a bunch of info.
I am having a problem getting RPM to come through which I had working on the Teensy way back on 1.10…
Anyone have any idea what may have changed on the Mavlink side?
-Shane
2 Likes
Nice work Shane! I’d love to have a look at your innovation. Perhaps you could send a pull request? Thinking about this, there is nothing stopping us using a a bigger colour screen.
I’m building in web support right now (to change settings) and should post a new version in the next few days. With that, it would also be possible to add support for a regularly updated web page with telemetry data on it, and perhaps a Google map.
You should post this neat innovation on rcgroups. Here
I can’t think of anything changing on the mavlink side, but its relatively easy to build in some debugging.
1 Like
Not to familiar with pull requests just yet. Maybe I can share the files some other way?
All of my changes are noted under Volocom or SuperVolo depending if they are associated with our ground station implementation or specific to our aircraft.
I was hoping we could add Volocom to master so I tried to be tidy with the code.
A little more on my MavLink message question.
We have an internal combustion engine so we care quite a bit about rpm. On 1.10 I added…
and
this to pull in the RPM information but it doesn’t work any more.
What is more concerning is the RPM Mavlink data is also no longer displayed on my GCS software via the TCP connection so it seams some Mavlink data is being lost?
-Shane
Shane I’m on my mobile so cant check the details right now, but rpm could also be coming in from frsky sensors, and share the S.Portin the receiver with the mav2pt in Air Mode. But I guess you know that. In that scenario you need to do a scan for sensors on the Horus.
Alternatively rpm could be fed into the Pixhawk, and come through Mavlink. I can add a bit of debugging code to shed some light.
I’ll be back at the office tomorrow.
Hello Eric,
we had this setup Working with another unit.
Now with a new unit, we do have the same problem, the Setup is:
Ardupilot passthrough (same with Teensy and Mavlink to Frsky Passthru)
Set to protocol 10
Inverter
R9
Update on the latest flex Firmware and 100mw
Latest Open TX Firmware 2.35 on a Horus X12
It works in the office fine for on hour or longer, but in flight after 5-6min the message “telemetry lost” on the Horus x12 comes. But the RSSI Signal was still around 70-80.
Because I didn´t saved the last paramter file, are there any under settings I need to change?
best regards
christian
Hi Christian, I’m sorry but I’m rather confused by your post. Are you using a Teensy, yes on no? From your post I conclude that you do not need the Teensy translator. So I assume you run the Passthrough protocol (10) through a hardware inverter/converter straight into the R9M receiver. I don’t think my receiver is flashed with the flex firmware yet, so maybe there is a problem there?
When you are running a platform under normal flying conditions in the sky you have massive current surges to deal with, so make sure your BEC/voltage regulator is smoothing everything out adequately. Also you have much more vibration, so make sure your connections are secure.
Hope that helps.
with regards
Eric
Hello Eric,
thank you for your feedback. I think I didn´t explain it very well, sorry for that.
We used the combination of teensy and the Frsky X6R for the last 1,5 years on different drones, without any problems. The setup also included a cuble black and the kore board.
We than used on a new setup, but same drone design, the R9slim and R9M on a Horus X12. And experienced the problem I have mentioned above. Same occurs also when we used an inverter/converter.
It works on the ground usually fine, but with both setups (Teensy or converter/inverter) the telemetry gets lost after a couple of minutes in the air.
We tried also different firmwares on the R9, non flex and flex. Ma
Hmm. This is a tough one. “Telemetry lost” usually means that either the rf signal is lost, possibly momentarily, or the telemetry message carrying the rssi value is delayed beyond about 900 mS. The OpenTx/Horus firmware/lua complains. I know you said the rssi reading remained 70%-80%, but are you sure you have set the rf power up correctly. I use the adaptive setting.
What antenna are you using on the craft? I found that the horizontal dipole worked best for me. Not the plastic one from FrSky, but a dipole out of co-axial cable. It is possible that at certain attitudes the aircraft shades the antenna, so I find it’s best to let it dangle below where it can’t be shaded. Are you using 868MHz or 915MHz in your country? The 868 antenna is slightly bigger to remain resonant.
Hello Eric,
thank you again for the feedback. I checked the settings for RF Power, it was correct. I checked the logfile, it did not show any RC Failsafe
We used the 868 antenna and mounted it like this. As mentioned, we used a similar setup with the X6R Receiver, where this problem did not occur.
In a new test today, we exchanged everything, Receiver, Transmitter and Teensy with a new one. Works fine again on the bench for 2h, did not have time to test in flight. One strange thing, one this new setup it does not show the flight mode. But shows in the mavlink data, that it changed from simple on to off.
Hi Christian
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.
Hello Eric,
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.
Hi Eric,
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?
Thanks again for all your work on this.
Hi Travis,
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 admittedly haven’t tried FD in a long while.
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.
What works (for me):
- TBS Crossfire (only the full size TX with Bluetooth) on Taranis with 12 Channels
- All telemetry values for the yapuu
- Routing of mavlink with udp
- The ESP32 fits into a (in my case) old TBS JR slot case, or you can use an 3D printed one (thingiverse is your friend)
What does no longer work:
- All special CSFR functions, like the CrossfireLUA scripts. But for me this doesn’t matter.
Used hardware:
- Just a ESP32 Dev module, like https://www.az-delivery.de/products/esp32-developmentboard?_pos=2
- Optional a common OLED module
- A decent case
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.
bg, Stefan
2 Likes
Hey Stefan
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.
Hello Eric,
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.
Hello Christian, if you send me a TLog I’ll see if I can find the problem.