Feature request : add Crossfire CRSF protocol - MSP capability about frskytelemetryscript HOT 45 CLOSED

now that is some great news!

from frskytelemetryscript.

Hi there. I just switched to crossfire and would like to use CRSF on my Pixhawk but looks like it doesn't support crossfire? How do I go about getting it to work on my Taranis QX7? Thanks for your help so far. Kind Regards. Wimpie

from frskytelemetryscript.

I won't go the MSP over CRSF way but rather passthrough over CRSF, my plan is to have the very same features of the frsky version, fingers crossed!

from frskytelemetryscript.

@yaapu that‘s awesome, looking forward to what you‘ll come up with, thanks for all your great work!

from frskytelemetryscript.

@vierfuffzig @kija @dobje @andyp1per
Testers wanted :-)
https://discuss.ardupilot.org/t/passthrough-telemetry-over-crsf-crossfire/62668

from frskytelemetryscript.

Excellent! I will give it a try on Friday.

from frskytelemetryscript.

Hi great work :)

All the changes should be in processTelemetry() we could do the same thing for the taranis version :)

from frskytelemetryscript.

What telemetry info do you get from MSP over CRSF, and what kind of datarate do you get?

from frskytelemetryscript.

Right now I 'm getting
MSP_RAW_GPS 106 //out message fix, numsat, lat, lon, alt, speed, ground course
MSP_COMP_GPS 107 //out message distance home, direction home
MSP_STATUS_EX 150 //out message Inav related = cycletime, errors_count, CPU load, sensor present, armingflags (that i use for status.statusArmed)
All others infos are from native sensors discovery over CRSF with OpenTX.

I didn't checked yet the rate.

from frskytelemetryscript.

how about flightmode and attitude?

from frskytelemetryscript.

Flightmode, attitude, battery sensor (rxvbat, current, mAh) are from native sensors discovery over CRSF in OpenTx, from Inav telemetry.

from frskytelemetryscript.

I'd love to look at your code, if you don' feel like publishing can you reach me on rcgroups perhaps?

from frskytelemetryscript.

Here is the code. It is still in dev. I want to use vario speed from Inav (From OSD) it is in MSP ALTITUDE.
At first I wanted to remove all the features I was not using like double battery, so that's why there is some code missing. I still need to finish the alarms to use only one pack (3S) or voltage from 3 to x volts (instead of cell voltage). I also had to modify Inav code because it doesn't support MSP over CRSF, I used BetaFlight code for that. That's a mix of lot of code :) That's why I think i need a good coding people.
SCRIPTS_ZINHO.zip
WIDGETS_Zinho.zip

from frskytelemetryscript.

Hi,
I looked at your code, by a quick glance I noticed:

• gps status changes
• flightmode changes
• menu entry changes
• big memory consumption due to external scripts being loaded at boot

it would require some time to do a "clean" implementation.

Can you do a "minimal" mod to make it work based on latest version without removing any code?
Inject only what's required to decode the telemetry packets and leave all the rest intact so I can do a diff with the release

Alex

from frskytelemetryscript.

Yes, I'll do minimal changes to make it work, or I'll try :)
It will take me some time as i'm still learning LUA.
About memory usage, will it be better to include the functions code in the main file ?
external scripts contain all the function for CRSF and MSP.

from frskytelemetryscript.

there's not much you can do for the dependencies from betaflight scripts, you could perhaps remove support for msp over frsky, so including the original scripts is ok, leave them this way for now.
CRSF conversion will probably be much harder to do on the Taranis whereavailable memory is much smaller1

from frskytelemetryscript.

New code is getting good :)
I added a new option in the menu to select protocol (sport or crsf) so it should still work for sport, I took care of not changing any of your code.
I have a question about 2 status, first is landComplete and second one is simpleMode.
There is no such status in Inav. For simple mode I don't know what I need to do with it.
For landComplete, i linked it to Armed status to be able to run the FlighTime ... not sure that's right.
Perhaps, I'll do a function to detect landed state (armed = 0 and timeDisarmed > 30 s and throttle < 2% and altitude < 5 and vspeed < 2) to populate the landed status.
(I don't have the code here with me ... I'm at work)

from frskytelemetryscript.

Hi,
I would not bother and simply link landing status to armed, much simpler and clean.
In ardupilot code landingStatus is linked to isFlying and uses EKF (many sensors fused) to detect it.
SimpleMode can be initially ignored.

Good choice to add menu option, next step is to make the loading of the crsf protocol dynamic (on demand) or even better move all telemetry processing in an external file loaded dynamically.

Are you working on lua files before or after running the preprocessor?

from frskytelemetryscript.

I'm working on lua PP files as I don't have any environnement setup on my laptop to preprocess. (I'm on Windows 10)
I looked how preproc was working and I thought i could use PP files.

About telemetry beeing dynamically loaded I like the idea, but I think You will have to do it :)
Still Lua beginner.

from frskytelemetryscript.

Hi @yaapu
I finaly had some free time to progress in my code mod :)
Widget is starting to work nicely. I'll do some pictures tonight if i have time to show you (I changed a bit the top bar to add extra values from crossfire telem like TX signal quality, RX signal quality, Tx power).

I need to work on flight modes now to match more or less the ones in your script (fligh mode on crossfire/Inav is text, in the script it's numbers refering to text) to make the audio running (sounds files).
I also want to work on some messages to be pushed (like when changing modes as there is some arming status in my actual crossfire flight status, reason to not be able to arm etc..., witch i display on flight mode)
It should still work for frsky protocol. But I can't test it.

from frskytelemetryscript.

Hi @yaapu .
Finaly got time to work on the widget.
Here is the view.
Getting nice :)

from frskytelemetryscript.

Hi, looking good :-)
remember to isolate all code changes from master and document them, that's the only way for you to maintain the code against new releases!

from frskytelemetryscript.

Yes, that's quite clean.
Have you seen up the crossfire values like Tx power (TPWR that can go from 10 to 2000 mw), the Tx and Rx quality levels :-)
In Inav, there is also values for the Batt. I'm trying to get them (like % remaining, mAh remaining, a bit that indicate the batt was full when plugged). I have a lot of ideas :-)
That's close to be a good backup solution if the Vtx fail in flight to get the plane home :)
Only thing is I don't know how to reset the timer after disarming...

from frskytelemetryscript.

Hi, used you script for a while and love it (was used with R9 + Ardupilot), unfortunately today I use crossfire (micro TX) and mostly Inav - would appreciate any hint how to make it work thru the crossfire.

from frskytelemetryscript.

Hi, same here used the script before but due some issues i switched to crossfire also. Is there any progress or idea's how to implement it ?

from frskytelemetryscript.

@Saxin @Wimpie1000 @dobje
Inav is not supported, this is an Ardupilot only project.

Ardupilot does not support native CRSF protocol, nor does it support MSP, there's no easy way to add support for crossfire.
A possible option if you run ardupilot is to enable crossfire radio modem (if your receiver supports it) and use an esp32 running the MavToPT project to connect to the TBS TX via bluetooth.

The ESP32 would then relay mavlink on WiFi and provide passtrough telemetry for my scripts to work.

from frskytelemetryscript.

Since CRSF support is now in ardupilot, this feature might be relevant again!

from frskytelemetryscript.

I am using native mavlink protocol within crossfire, only have to connect the tx and rx and have all the functions. Most of the sensors i see also , but can't use this script either. Would be nice to have support for that.

from frskytelemetryscript.

Since CRSF support is now in ardupilot, this feature might be relevant again!

Hi, do you have a use case?

from frskytelemetryscript.

Not for me personally since I don't have a crossfire (I use DL), but my friends running crossfire are jealous of what I have on my Horus. I got Luatelemetry working for them to some extent with ardupilot crsf, but I think Yaapu is much nicer.

Whatever the crossfire configuration, CRSF, Mavlink, (MSP over serial? I should try this!) it seems some sensors are missing. In the best case (CRSF) I get 23 sensors, of which at least half are just Crossfire sensors. With CRSF, I get attitude, Batt and flight modes. Mavlink is missing flight modes. None of these options have arming information. In the end it would be quite limited in comparison, so maybe not worth the hassle. The better solution is probably for TBS to get in line with ardupilot and your script rather than the opposite.

from frskytelemetryscript.

@yaapu i've been doing some testing along @andyp1per adding crsf RC / telemetry and i too think it'd be an awesome feature added to your script as right now there basically is no crsf-compatible telemetry script streamlined for ardupilot use, and we do have some convention issues (modes, arm-flags, pitch direction etc) when trying to use e.g. INav telemetry script with crsf from ardupilot.
cheers, basti.

from frskytelemetryscript.

@kija @vierfuffzig TBS agreed on sending me a dev unit so I'll be able to work on this soon

from frskytelemetryscript.

@vierfuffzig @kija I've got a working prototype.
Now which is the most usefull signal quality sensor to show? There are many :-)

from frskytelemetryscript.

Yes there are many and I'm not sure which one is best to pick! LQ, RSSI or min(LQ,RSSI) or something else? Before we had CRSF, I used sbus and LQ/RSSI on channel 12, but I found that it moved around less progressively than just LQ or just RSSI - so I switched to LQ only. It seems some popular youtubers such as painless360 and bonafide chose LQ/RSSI (I think it displays the min of both values). I would rather that someone that actually owns a crossfire module jump in on this, since I only have experience via a friend's remote.

Something fancy to display on the remote is the current power of the crossfire, 25mW, 50mW etc... I think that would be nice.
In arduplane with CRSF you are supposed to pick rssi_type 3, but i'm not sure what that actually does on the backend.

from frskytelemetryscript.

It means it takes RSSI from the RC protocol implementation (rather than say a pin). For CRSF this is guesstimate based on the dBm value that TBS gave me.

We are decoding all of the signal quality metrics because they are all in the LinkStatistics packet.

from frskytelemetryscript.

@yaapu most likely isn‘t a „best“ value.

• RSSI imho is the most straight-forward option from a technical pov. the logaritmic scaling needs some practice though, and its significance benefits a lot from SNR being talen into account too
• LQ‘s linearity is easier to read at first glance, requires to take HF mode into account though, and has a tendency to drop quite abruptly in less-than-ideal HF environments

the most comprehensive option likely is to display all three (RSSI, LQ and SNR). if i had to pick one i‘d go for RSSI, but common recommendation afaik is to use LQ as a single value, for being the most easily redable one.

from frskytelemetryscript.

@vierfuffzig we do have quite some "room" in the top bar for multiple indicators, I'll try to put there all I can, on Taranis radios it will be difficult and I'll probbaly just leave RSSI.
@andyp1per having access to links statistics in code let's us modulate the rate of some messages should we detect a switch to mode 1 (50b/s), right now the WFQ scheduler simply adapts to the lower rate but I'm sure that perhaps attitude message priority should be lowered

from frskytelemetryscript.

@andyp1per having access to links statistics in code let's us modulate the rate of some messages should we detect a switch to mode 1 (50b/s), right now the WFQ scheduler simply adapts to the lower rate but I'm sure that perhaps attitude message priority should be lowered

I agree

from frskytelemetryscript.

@vierfuffzig how do the 1RSS and 2RSS behave on diversity receivers, which one would I pick for calculating an RSSI, I'd go with same algo used by @andyp1per in ardupilot which was suggested by TBS: rssi = int16_t(roundf((1.0f - (rssi_dbm - 50.0f) / 70.0f) * 255.0f)) but I need a way to calculate rssi_dbm when 1 or 2 antennas are present, should I simply average them?

from frskytelemetryscript.

@yaapu i'm not using diversity receivers with my crossfire, so my actual experience with handling two RSSI values is based on other RC hardware types. however, the crossfire afaik is using nothing beyond just that - each antenna's received signal strength. based on that i'd suggest to use the value representing the best reception (i'm reluctant to use high and low when talking about a -dBm scale) for a single RSSI calculation, as that's what your link is worth.
differences between antennas will most likely be due to individual positioning on the aircraft and respective polarisation loss (E2 = E1 * cos θ), which can vary to an extent that averaging both values will not result in a representative number in many cases.

please correct me if i'm missing important characteristics of the crossfire's individual diversity handling.

from frskytelemetryscript.

@vierfuffzig what you say makes sense to me, what I've done so far is adding RQly, TQly and RSSi calculated the "ardupilot" way

seems to be fine.
I'll have something to test soon

from frskytelemetryscript.

X9D facing retirement, will test asap!

from frskytelemetryscript.

X9D facing retirement, will test asap!

@vierfuffzig I uploaded the X9D versions with crossfire support :-)

from frskytelemetryscript.

added in 1.9.1

from frskytelemetryscript.

Hello Sir: I have used your script on all of my Drones that have Pixhawks or Cubes and I couldn't imagine flying with out it, but now I'm trying FPV using these small FC's I have built a 10in frame and use a Matek H743 FC put arducopter FW on it with CRSF Rx I have everything working but now want to use the yaapu script but don't know/where how to put the yaapu converter to make the script to work any help or suggestions would be appreciated thanks. Ron Kennedy

from frskytelemetryscript.