Hi,
I’m sending download links to those who asked, if I forgot someone please send me a reminder PM
This is the layout of the test version:
Cheat sheet:
long press [MDL] to enter configuration menu
short press [SYS] to toggle min/max value display
short press [ENTER] (encoder button) to cycle voltage sources
encoder up/down to display mavlink messages
When reporting back success or failure a short video of the script running is usually helpfull, I do not own an Horus so the more feedback I get the better!
EDIT: Please use PM so I can track the feedback better!
EDIT 2: Beta testing is focused on functionality, cosmetic and/or color scheme changes will be addressed once the engine is proofed and functioning
Can someone explain the relationship between Craft and Theory and this project? I get they both use FrSky Passthrough from Ardupilot, but why would CT be asking for script changes?
Can someone explain the relationship between Craft and Theory and this project? I get they both use FrSky Passthrough from Ardupilot, but why would CT be asking for script changes?
Hi all,
I’m adding a vertical vario indicator on left side of the hud
The scale is logarithmic with 10 m/s as full scale, so even small changes around 0 get detected, I have no experience with planes so what is a reasonable full scale value?
I think 10m/s is a fair number, but some high-performance would need 20-30m/s. It would be nice to see some hash marks or something to quantify that rate of ascent/descent (especially since it’s not a traditional linear scale).
In my opinion for planes , battery is less important than with copter while Gps speed, Airspeed , baro alt and another Alt , Lidar or Gps Alt are the informations I would like to have .
Gps speed and Airspeed give you an information about how much wind you are flying
Lidar or Gps alt gives you an idea how much your baro is wrong.
Hi Luca,
the protocol designed by C&T does not send raw sensor values but rather the EKF fused ones, so for instance altitude is nor baro neither GPS altitude it’s the EKF altitude calculated by fusing baro, gps, imus, etc
Airspeed and ground speed are different.
If the user configures an airspeed sensor in missionplanner then the speed reported by the telemetry protocol is airspeed otherwise it would be GPS ground speed.
It’s not be possible from the telemetry stream to automatically detect the airspeed sensor presence but I could add a menu item to declare it.
Once enabled the reported gps coordinates could be used to calculate the average ground speed in the last 2 seconds (with a big approximation since gps coords are reported at 0.5Hz) this way I’d be able to display both airspeed and ground speed.
I could also display a trip distance estimate with the same technique.
Anything else would require an extension of the current protocol implementation.
You are right baro altitude is not available with passthrough protocol .
Altitude from Home so the Ek2 altitude but also the range finder altitude and GPS altitude are all available.
Altitude from home and Range Finder altitude would be very interesting to have IMO.
Both ground speed and Airspeed seems to be both available .
A menu to declare the airspeed sensor availability would be great.
P.s. C&T as far as I know did not design the passthrough telemetry protocol, they design a Frsky app.
Altitude from Home so the Ek2 altitude but also the range finder altitude and GPS altitude are all available.
The problem with GPS altitude is that is absolute.
I could probably detect a GPS reference altitude at takeoff and use it to show relative GPS altitude from home
EDIT: this would not work see
and you’re right there’s a rangefinder value, already parsed by the script, ROTATION_PITCH_270 should be the projection pointing down. I can sure find a place for it and display it!
If you have a rangefinder fitted I’ll have you as a tester for I don’t have one yet!
Reading the tread you linked it seems that Altitude from home is available, only it is wrongly describe in the protocol spreadsheet .
With rangefinder Alt , Home Alt is what is really needed since it is what the TECS consider as the actual altitude of the plane
Yes , I have a rangefinder mounted on my plane and also other Lidars , if you want to play with Lidar I can lend you a Benewake TF Mini .
If I had to choose about speed I would say Airspeed but if you could set a menu and let user choose which one it would be great.
Reading the tread you linked it seems that Altitude from home is available, only it is wrongly describe in the protocol spreadsheet .
that is yet another problem, docs are outdated I had to look at the source code to corrtectly parse the altitude frame.
Yes , I have a rangefinder mounted on my plane and also other Lidars , if you want to play with Lidar I can lend you a Benewake TF Mini .
thanks for the offer but I could not resist and had to buy a tfmini
If I had to choose about speed I would say Airspeed but if you could set a menu and let user choose which one it would be great.
Airspeed if availbale takes precedence over ground speed so it would always be shown, I could try to show a ground speed from gps coordinates if the user “notifies” the script that what telemetry sends is airspeed…
Hi,
new version on github for the X9D and QX7 radios, some minor fixes and a couple enhancements:
vertical variometer gauge on left side of hud and cell detection override from menu up to 12s.
