Yeah, I spoke to Chris about it. I’ll start by loading your script onto my old Taranis and see if that will make any difference.
Ill also order a battery sensor.
I can do a build of latest HeliPilot master too with the updated scheduler. I have it in my test helicopter, but not any public builds right now.
@Implicit I think your problem is related to the gas suite box not providing a passthru for other sensors and duplicate sensor ID’s on the bus. The gas suite “invents” a bunch of other sensors by using the fuel flow sensor to provide for fuel remaining, yadda yadda. I don’t use any of that because I found the fuel flow sensor to be highly inaccurate and since I know the fuel burn anyway the clock tells me how much fuel I got left. The rpm, high temp thermocouple and low temp sensor turned out to be useful though.
The fuel flow sensor seems to work on a turbine where you need a pipeline direct to OPEC to have it idling at 115cc/min fuel flow, it goes to 175cc/min when you spool up the rotor and 230cc/min when you lift off. But with piston engines that only burn 17-22cc/min in cruise flight there’s not enough fuel flow to turn the the little spinner in it very reliably.
Yeah, I was actually looking for alternate options.
This was the smallest gas resistant flow sensor I could find, but then it would require hooking it up to an arduino or similar to generate the telemetry.
That sensor might work with the gas suite. It is the same type of sensor. But the accuracy of it is advertised as +/-2% which is 20cc per liter. The clock is more accurate than that once you measure your fuel burn. In all aircraft from ultralights to airliners fuel burns by the clock, not by the gauge. If you file a flight plan and tell FSS that you got 4,000 gallons onboard they don’t care about that. They want to know how many hours and minutes of fuel you got onboard.
Regardless, when you discover the sensors, if you get rid of those extra sensors that the Gas Suite “invents” and use a y-cable to hook it up I think you’ll get it to work with the passthru. I’m using it on a Taranis, not a Horus. But it shouldn’t be any different.
Hi @yaapu,
What telemetry rates should we set in Arducopter? In case you are using Temetry1, these parameters:
SR1_ADSB
SR1_EXT_STAT
SR1_EXTRA1
SR1_EXTRA2
SR1_EXTRA3
SR1_PARAMS
SR1_POSITION
SR1_RAW_CTRL
SR1_RAW_SENS
SR1_RC_CHAN
Which ones are used and how much can your script process? I am using the Horus with MavlinkToPassthru on a Teensy.
Hi David,
this is a good question but you would be better asking it in the mavlinkToPassthru thread.
The latest version of the MavToPT code roughly queues a frsky packet for each corresponding mavlink packet, since the Horus can process between 40 to 60 packets per second you should be able to tune your rates accordingly.
It also depends on the speed of your radio modem, as an example for dragonlink@38400 the recommended rates are
SR2_EXT_STAT 1
SR2_EXTRA1 5
SR2_EXTRA2 5
SR2_EXTRA3 1
SR2_PARAMS 10
SR2_POSITION 3
SR2_RAW_CTRL 1
SR2_RAW_SENS 1
SR2_RC_CHAN 1
cheers,
Alex
i would like to thank Alex for all the hard work this year merry Christmas and happy new
1 Like
Thank you Colin, and a merry Christmas to you too!
Hi Alex,
Thanks for the great work. am doing a new build HexCopter, so I do not have a reference like “it worked before”. I am still in the shack, doing the desk function testing. I have the full passthrough telemetry working, but I observe the following: when I force a bad signal (rssi below 35 using range function on my Taranis), telemetry is obviously lost. However, passthrough telemetry and the GPS coords do not recover after signal gets back to max. RSSI and RxBt do get back, as they are generated by my receiver.
The polling and response on the S.port is not interrupted, and keeps on running, so I would assume this has nothing to do with any scheduling mechanism. Loaded a picture of my poor man’s scope the poll/response view is always the same, when telemetry is received but also when it is lost. Off/On on my radio does not recover telemetry, it recovers only when I power off/on my receiver, not touching my FC.
When I loose the telemetry, values in the yaapu9 screen are not updated, but also no message that there is no telemetry. When I reset telemetry, it states “no telemetry” And as said earlier, only full receovery when RXSR is power cycled.
Would be great if you or any of the colleague readers can point me in the right direction.
Some relevant portions of my setup: Pixhawk4 running ArduCopter 4.0.0-RC5, Taranis XD9SE+2019, RXSR, OpenTx2.3.4, ACCESS/EU/LBT. RXSR powered through BEC, smooth power, no ripples.
Tnx,
John
Hi John,
what you describe looks more like a bug in the ACCESS firmware than an issue in the passtrough code.
When you loose telemetry+RC does your RSSI drop? Since the script does not detect a link loss probably RSSI is frozen at a good/high value.
You see the polling on the RX side but I bet that it’s not sent down the radio link after the link is restored.
Early R9M firmware suffered the same issue, you would loose telemetry+RC but only regain RC control.
To rule out ardupilot you could connect a real frsky sensor like an FLVSS and check if that works after telemetry is restored.
Unfortunately I cannot replicate your exact setup for I do not have an rxsr nor a pixhawk4.
Alex
Edit: you can validate your setup by flashing your receiver to ACCST which should not have any telemetry bug
Tnx Alex for superfast response. I will verify the RSSI on the Taranis side when I simulate the gradual signal drop. I have a spare RXSR which I will flash back to ACCST tomorrow, and replicate the same. Will keep U and the crowd posted, as I will not likely be the only one with such setup. And if it is an ACCESS “feature” I know where to address it 
unfortunately, I do not have any Sport frsky sensors, but it is good one to plug such in for further troubleshooting. I’ll see if I can get one.
Grtz,
John
1 Like
Does the Frsky R-XSR have analog RSSI pad
Hi Yak, nope it does not…
Hi All,
It looks like I too start experiencing script freezes. Every time after about 10-20 seconds I get no telemetry coming in (and the screen is not updating).
I use X9d+, X4R and Kakute F7 AIO.
It used to work, but now it does not. I have switched logging on FC completely, swapped cards in FC and TX, reformatted… Same result.
I found that to recover telemetry (for another 15 seconds) I need to turn TX off completely, wait a minute or 5 and turn it all again. No power cycle for FC or RX is needed.
Hi Anton,
I do not have any open issues for script freezes so who else is experiencing freezes that you know of?
What did you change on your setup? There’s no reason for it to stop working
Alex,
It might be not “freezes” as such, but pretty similar to the issue with loss of telemetry that was discussed here (at least to me it looks similar).
There was no change as far as I am aware, I might have created new models on TX but that’s pretty much it.
All reported “freezes” were due to radio/firmware issues or opentx model misconfig.
Can you please create a new model from scratch on your OpenTX radio?
When you experience script “freeze” is the GPS sensor updated (flashing asterisk on sensor page)?
Updated radio, recreated model. Same. Asterisk for GPS was flashing, then disappeared and shortly after I got a Sensor Lost message.
What really strange is, everything worked couple of months ago.
Ok, you need to identify the root cause for the telemetry link loss.
It can be the flight controller that for some reasonafter a while does not respond to polling, some sort of desync/delay. By rebooting the TX you stop the telemetry polling and once it’s back on the polling starts again, the FC responds for while and again a desync and stops.
Or it can be radio firmware related, you would need a real frsky sensor like an flvss to test it, so no FC on the telemetry chain.