I agree, we’ll have to test it and see, the telemetry library doesn’t do any checking at all, looks like it sends what is reported by the rangefinder
// rangefinder measurement in cm
attiandrng |= prep_number(_rng.distance_cm_orient(ROTATION_PITCH_270), 3,
the relevant function is
/*
* prepare attitude (roll, pitch) and range data
* for FrSky SPort Passthrough (OpenTX) protocol (X-receivers)
*/
uint32_t AP_Frsky_Telem::calc_attiandrng(void)
{
uint32_t attiandrng;
// roll from [-18000;18000] centidegrees to unsigned .2 degree increments [0;1800] (just in case, limit to 2047 (0x7FF) since the value is stored on 11 bits)
attiandrng = ((uint16_t)roundf((_ahrs.roll_sensor + 18000) * 0.05f) & ATTIANDRNG_ROLL_LIMIT);
// pitch from [-9000;9000] centidegrees to unsigned .2 degree increments [0;900] (just in case, limit to 1023 (0x3FF) since the value is stored on 10 bits)
attiandrng |= ((uint16_t)roundf((_ahrs.pitch_sensor + 9000) * 0.05f) & ATTIANDRNG_PITCH_LIMIT)<<ATTIANDRNG_PITCH_OFFSET;
// rangefinder measurement in cm
attiandrng |= prep_number(_rng.distance_cm_orient(ROTATION_PITCH_270), 3, 1)<<ATTIANDRNG_RNGFND_OFFSET;
return attiandrng;
}
Edit: I checked the code briefly, looks like we’ll get raw values even when out of range, only EKF2 and EKF3 seem to use RNGFND_MAX_CM
Edit: If this is the case I could add a menu option to specify the RNGFND_MAX_CM, with vocal warning when out of range
Sorry Chris I meant that the frsky telemetry library sends the “raw” values reported by the rangefinder without doing any checking wheter they exceed RNGFND_MAX_CM or not.
From my (rather quick) checks appears that only EKF2 and EKF3 libraries do check for max ranges and ignore the value when necessary.
I’ll enable rangefinder display and if necessary add a menu option to configure max range in the script.
This way I can also add a vocal alert when you reach that limit.
This unless there’s a “smart” way to detect out of range values, we’ll see
Hi Henry,
battery level 2 should be lower than level 1, it’s in the docs (defaults are wrong, my fault).
The scripts works all right even with level 1 equal to level 2.
Battery flashing is “sticky” once the battery voltage falls below the configured level the flashing will persist even if the voltage raises above.
Vocal alerts are played periodically only if the voltage is below, as soon as it raises they stop.
What is the exact behaviour that you observe?
As for the imperial version could you provide me with the correct units to use for vspeed, altitude, etc?
An imperial version would be for sure a compile time option.
Hi Henry,
that’s weird, box on the left side of the hud is vertical speed, the vario was also still?
How about altitude, was is correct?
If you configured the airspeed sensor in mission planner then hor speed is airspeed.
Edit: I double checked and ran the script on github on my setup and vertical speed works, but I do not have and airspeed sensor. This to prove that the script displays what telemetry is sending.
Did the OSD display vspeed?
I have a Taranis 9D…the vario is not moving either…today I ran discover sensors and showed them on the second page…vspeed and gndspd were reporting 0…everything else was normal…
sounds like Arduplane is not sending the data?
also, the second digit on current consumption is not showing…thought that was already in the script now…
