hi the rates are the ones reported by the debug script
wind is frame 0x500C so you’re getting wind info @0.8Hz, there’s no way to tune the rates nor disable unused ones, they are fixed, IMO while sailing it should not be an issue but I understand that while turning the windvane by hand it might be too slow.
When it errors out in refresh() it means the radio killed the script for excessive cpu usase.
You should use the main screen for wind direction, it’s there as an arrow, and it’s realtive to your heading so it’s true wind, lower left you have the speed i.e. 5.7 in the screenshot
There’s also the apparent wind information but I’ve found an issue an opened a PR to fix it
Once the apparent wind telemetry frame is fixed I should be able to provide both true and apparent wind info such as in this experimental layout
Hi Alex, many thanks once again! The experimental layout you showed would be fantastic, I look forward to that!
I’m not an experienced R/C sailor, but in my experience so far in lake sailing, rapid wind shifts are common and it is one of the reasons I went down this path. So I’m definitely interested in getting that rate up. In the boat I am building, space and weight should not be an issue, so what would give best telemetry performance for apparent and true wind (once those are available)?
I have been researching online and I’m learning but do not yet have a clear understanding of all this. I’m guessing ELRS would be faster than CRSF. What about SiK or some other dedicated telemetry radio and a GCS? Also I’m a little unclear if the true and apparent wind can ONLY be obtained using passthrough telemetry, which (I think) would basically require Yaapu. I don’t want to eat up your time, if you know a good source of info I can access I’m happy to do some work to get a better understanding. This is all new to me - on my drones I have (until now) just taken the telemetry data in my OSD for granted! Cheers, Chris
Hi, as I told you the rates are locked into ardupilot code, if you need faster rates you have to use mavlink and a mavlink capable RX/TX combo, mavlink has built in rate control so you can go as fast as your link allows.
RC telemetry on the contrary is intended as a way to get vehicle status not as a mean to get near “real time” data, that’s the reason why we don’t push it too fast.
Comparison with OSD in unfair since OSD runs “on the vehicle” and has direct access to all sorts of information in real-time.
Mavlink here is off topic but you can for sure try a mavlink capable RX/TX combo, this would mean go mavlink all the way or keep your current CRSF RC link paired with a mavlink radio.
Ah, thanks again. That gives me a new perspective as well as clarifying some specific points. I’m gradually progressing from “no clue” to “limited understanding” and I really appreciate your help!
I do have one other question: in the wiki Screen Layout page it says screen type 7 and 8 are like HUD screen 1 but customizable from menu. I can add screen 7 or 8 but cannot seem to find a menu to customize them from. Is it referring to the main screen/screen [2]/screen [3] center/right/left panel options in the Yaapu Config lua script? Or is there some other menu? I am on a TX16S running EdgeTx. Thanks!
Hi, thanks to all for the impressive work
Maybe i missed it:
Is it possible to control what messages are passed through over CRSF to limit the traffic to only what messages I need?
Hi, I am stock with my issue for a month now,
I have SuperP 14Ch 2.4Ghz RX ELRS on CSFR CH13 active
& TX16S radio with Yaapu telemetry
I am using pixhawk 3DR arducopter 4.5.7
I am using HW 130A OPTO V4 Platinum ESC and external BEC castle 20A
I don’t know where is the telemetry port for that RX (superP 14CH 2.4Ghz)
There is no Fport or smart port!
The Manual saying nothing about how to wire the telemetry.
The ESC have P signal ( single cable on the side of the unit that should connect to the telemetry FC)
Currently there is no telemetry in the radio.
also when I switched to CSFR the servos not working since its no Sbus,
so I have to connect all the servos to the RX and that is not good, since the Sbus will allow me to connect the servos to the Pixhawk directly.
Hi Alex, in all of my airplains is your script working well, but now I’ve put together a plane, where I see on the screen a different value of RS: 64-72/2. For all other plains it is 100/2. I checked all telemetry sensors, all is the same. The radio is TX16S with OpenTX, Rx are Crossfire nano or nano diversity. Please, is the first RS value RQly? Do you have an idea why can it be different?
RSSI is calculated just as ardupilot does and evaluates both antennas (if present)
// apply same algo used by ardupilot to estimate a 0-100 rssi value
// rssi = roundf((1.0f - (rssi_dbm - 50.0f) / 70.0f) * 255.0f);
rssi_dbm = math.abs(getValue("1RSS"))
if antenna 2 exists then
rssi_dbm = math.abs(getValue("2RSS"))
end
rssi = math.min(100, math.floor(0.5 + ((1-(rssi_dbm - 50)/70)*100)))
Thank you very much, Alex. I found that the cable to one antenna (nano diversity Rx) was broken inside. After antenna replacement I have RS: 100/2. Great, that a faulty antenna can be detected using this value.
good question, you are indeed right, the algo used to scale the value is the same, the criteria to select the second atenna should also be “similar”, value may differ if you choose to use link quality as rssi though
