Today the first “Test Flight” at the field of honor
It was not so good as estimated - but overall a sucsess.
I have installed the latest update at the Crossfire and at the Pixhawk 1 the version 0.8 was running.
After the first takeoff the telemetrie get frozen. The RC functions were still working. Very nice as I could land the plane safety.
Second and a few other flights this problem didn’t occour.
Short after take off the RFMD switch to 1. The R- and TQly was fine between 100 and 80 Percent. But after about 100m distance the RS value drop down below 60. For a plane this will still work.
Missing the values for Airspeed and Throttle in % at the widget. Also on the log this values are “0”.
For the first trial it was a sucsess and I will waiting for the updates.
Markus, did you ever use crossfire telemetry before?
My code does not touch basic CRSF telemetry so if you get a switch to mode1 you would have got it even without my patches. As soon as crossfire switches to mode 1 you will experience a freeze of the horizon but you will get all other data every 3 seconds, so battery, flightmode, altitude, speed, GPS coordinates are all updated every 3 seconds so pretty safe to fly.
I have no control on rf modes, I did my best to maintain the basic telemetry info while in mode 1
You can try on the bench by forcing rf mode 1 with TBS agent X or by using the oled of the full TX, you’ll see that horizon is almost frozen but all other data works!
One last note, the switch to rf mode 1 is only for telemetry, RC control is never affected!!
So far I didn’t use the crossfire telemetry before.
Yes, the horizon is for real frozen. But this doesn’t matter. The update every 3 seconds is absolutly fine for me.
Good to know that the RC control is seperated from the telemetry.
Is it possible to get the airspeed and the trottle infos to the basic telemetrie?
Your program and code is really a big step for the Horus and TBS crossfire. I will use it for the airplanes with “Basic Telemetrie”. For the Turbine Jets I keep the old configuration with the FrSky and the TBS as I need the info from the jet controler.
Short update.
Today I set at the Crossfire TX The frequency setting to “868Race” (double bandwidth) and at the MicroRX the RF Profile to 150Hz. The maxium output for the TX was limited to 1W at dynamic power on.
With this setting the RFMD keep on 2 and the elemetrie was perfect even on distances over 1000m.
Hi Alex,
I’ve got all this working on my Kakute F7 and it is really nice. Working with a development version of Arducopter makes me a little nervous though. What is the usual time frame for getting this into a stable version?
I assume the prebuilt binaries are all Arduplane - would it be possible to provide one for Arducopter on MatekF405?
Btw, I wouldn’t worry about using a dev version - I’ve been using them almost exclusively since I started 2 years ago and never had a problem. The only case I maybe wouldn’t use them would be on a really huge and potentially dangerous craft.
Good evening everyone I have a Jumper T16 with Yaapu installed, all right, but last Saturday due to loss of telemetry and signal I lost my glider with Arduplane, now I would like to switch you to Crossfire and if I understand correctly now it could work in the T16, I think I understand that I have to switch to a night version of Opentx is that right?
Someone knows with what power the RX Crossfire transmit telemetry.
Greetings Giampiero
Hi Giampiero,
No, as written above we tested PT via CRSF on regular OpenTX builds. OpenTX 2.2.4 is the oldest version of transmitter FW I have tested CRSF passthrough telemetry.
@vierfuffzig@andyp1per my latest code supports fw version detection (thanks andy for the hint on how to do it) which opens up some interesting options.
Firmware 4.06 adds support for an ardupilot custom frame, so if I detect >= 4.06 I use that frame for custom telemetry, for older fw I use frame 0x7F as suggested by TBS. (Lua scripts/widgets support both frames)
Since rf_mode reporting is not reliable for old firmwares I only trust it on fw reported to work, personally I tested >= 3.72, so anything <3.72 will use avg telemetry rate to detect rf_mode changes.
But we hit a problem here because of the slow uart issue we’ve seen on Matek boards.
On those boards rfmode 2 is @60/70Hz on slow uarts and @150Hz on fast ones while rfmode 1 is @30Hz on slow uarts and around 65Hz on fast ones.
Detecting rf mode changes get’s tricky, any ideas?
@yaapu thanks for your constant effort on this. honestly i’m still having a hard time really separating inherent CRSF bandwidth issues from ardupilot implementation issues. having a dedicated ardupilot passthrough frame sure is a great thing, but i wonder how that will affect basic bandwidth allocation, like will there be some kind of per-frame-priorization?
@andyp1per that was what came to my mind in the first place too. from my limited understanding i would expect functional differences from APB1 und APB2 UARTS to some extent, mostly regarding marginal baudrate support (both very high and very low due to divisors exceeding BRR register capabilities). if that was the issue we see here, i would ecpect both USARTs 1 and 6 (on F4xx) to act the same though, which obviously is not the case.
All TBS did was grant a dedicated frame to ardupilot, individual frame types, except for RC, don’t seem to prioritized.
Bandwidth is an issue because we want to have full legacy CRSF telemetry + full passthrough telemetry in both rf mode 1 and 2.
These are pretty strict requirements.
Implementation dependant issues I see right now:
slow uart issue on F4 boards
reliable detect of crsf firmware issues (rf mode in primis)
