The only way an external frsky sensor can interfere with ardupilot is by responding to the same sensor ID, anoher reason could be the module for some reason is not forwarding ardupilot packets on the sport bus.
To check it you could try to splice the sport cable by making an Y connector and connect rx,gas suite and FC with the same cable all in parallel.
In the end the only way to really know what’s going on is with a logic analyzer trace
Aha!, Ok, didnt realize you could do that. Will do that before I buy a new one. Thanks!
1 Like
Sorta worked. I get ‘sensor lost’ and it’s struggling to see the FC telemetry, although the screen appears to update correctly.
Do you have by any chance a spare FLVSS cell voltage sensor to add to the chain, if you can discover it in OpenTX it would give us some insight if your gas suite is misbehaving.
If you do a sensor discovery do you discover GPS?
Looks like your gas suite is responding to all sensor polls, but again you need a logic analyzer trace to properly debug your issue
Alex do you know if someone is working on injecting S-port to Ardupilot or mavlink ?
I do not have any other frsky sensors. I do see the GPS.
@Implicit Jakob I created a PR to update the frsky scheduler in current HeliPilot master, you might give it a try. I don’t think it will solve your issue tough.
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