to recap:
- FC + GAS SUITE: GPS OK
- FC + 3 FLVSS: GPS OK
- FC + GAS SUITE + 2 FLVSS: GPS OK
- FC + GAS SUITE + 3 FLVSS: NO GPS
Do you have the gas suite script running while you do the testing?
1234 is the way it works
no i don’t have the script running
the only time i run the script is to set the prams or set the smart port ID that is set to 17
i did try it with FC + 5 FLVSS and it worked worked with out the gas suite
Colin, does passthrough telemetry work in use case 4, or both passthru and gps do not work?
passthru works just the GPS stops
There might be an issue in physical ID 0x1B being used by both the gas suite and ardupilot.
I think the gas suite uses physical ID 0x1B by default, at least this is what the GAS suite lua script uses.
This also implies that the suite responds to polling for ID 0x1B just as ardupilot does.
From the docs it looks like you can change the gas suite default physical id with the FreeLink app.
I’d try with an ID between 10-20 (before changing it better take note of the current one even if the “default settings” button is there)
These are the sensor IDs that OpenTX knows about.
// Default sensor data IDs (Physical IDs + CRC)
#define DATA_ID_VARIO 0x00 // 0
#define DATA_ID_FLVSS 0xA1 // 1
#define DATA_ID_FAS 0x22 // 2
#define DATA_ID_GPS 0x83 // 3
#define DATA_ID_RPM 0xE4 // 4
#define DATA_ID_SP2UH 0x45 // 5
#define DATA_ID_SP2UR 0xC6 // 6
If everything else fails you’ll probably need a logic analyzer to dump the traffic and debug it.
i did try other ID
Hmm i think i may have logic analyzer
i did have an issue with ardupilot on the I2c locked up
and i had to run a dump for Andrew Tridgell and he fixed the issue i was having with i2c bus
Just curious, what IDs did you try?
from this image looks like the default is 22 not 0x1B 
17 and 16 and 26 and 14 I will setup the logic analyzer later no tonight
Sorry, but in the sun I can’t read a red value of FLVSS in my x10, It’s not possible change color?
Thanks
Hi Colin,
Because I have 2 Helicopter with each having a X8R-RX and the Yaapu Telemetry v 1.8.0-rc2 perfectly working.
On a VTOL plane I am using now the Frsky long-range R9-RX (900mhz). Between the RX and the converter cable is a FLVSS unit before connecting to the cube. I have not got the Yaapu Telemetry working on this plane. That cable has been checked, working on the other aircraft.
Did you had to overcome a problem with a R9-RX or did it work straightaway as it did with the other Receivers like the X8R.?
yer i having lots issues i think it may be ArduPilot plane i going to put chopper on my plane and test that
With the long range R9-RX I have the same trouble.
The Yaapu telemetrie is not correct working.
It starts and after a couple of minutes it get interrupted.
I suggest the problem on the firmware of the R9-RX.
The normal 2.4 GHz RX working without problem.
All this testing is done with out Yaapu Telemetry script running
i am using RX8R pro i will try S6R and rx6r and X8R and R9
well same thing get interrupted
so i tried to down grade opentx to 2.2 no good
then i tried ArduPlane 3.8.0 and chopper 3.8.0
so latter on i will try just a Teensy 3.1
well it all works fine with Teensy 3.1 i have all telemetry sensors mavlink and 4 FLVSS and the Gas and Gps and suite working
it looks like its ardupilot’s frsky passthrough protocol ?
thats only thing left
Hi Colin
mhmm interesting, one difference between the teensy and ardupilot passthrough is the way bandwidth is used.
Ardupilot native passthrough responds to each poll from the rx thus using all available bandwidth allocated to physical sensor ID 0x1B, when there are no scheduled packets to be sent it sends attitude info to keep the hud smooth.
The teensy responds to polling requests only when a packet is scheduled to be sent and does not fill “empty slots” with attitude.
Another potential difference is the timing of the response to the polling request but only a logic trace can reveal the differences.
If you can reproduce this reliably please open an issue on ardupilot’s github.
Ideally you should provide a trace with a logic analyzer of both the working and non working configuration.
Hi Antonio,
it sure is possible, I’ll look at a better color combination 
Alex
@FRED_GOEDDERT, @master-of-desaster-8 did you also try with a shorter range RX like the R9 slim or mini by any chance?
I’m bench testing an R9 mini and s.port is working fine at least for my initial pretty limited testing!
1 Like
i have been looking for info on doing a logic trace on frsky smart port but i cant fine any info i have only done a trace on I2C so i don’t know where to start on wiring it up
Hi Colin,
wiring is in parallel, so probe on s.port and probe ground to, well, ground 
Keep cables short.
Configure capture for uart/serial half duplex (single wire) inverted signal at 57600bps.
I usually capture at a much higher sampling rate even up to 1Mhz, dump a few seconds.
A successfull dump will show something like this
short packet is the polling, long packet is the response.
There should be about 11ms between polling packets
Alex
No, I have not tried the R9 SLIM.
The full size R9 rx is already mounted at the end of the wing from that plane.
This way I have the original Antennas 90 degree mounted at the wing tip.
Everything is working between the RX and the CUBE. The signals( SBUS+2ch-pwm+SPORT) are going through Shielded wires. (800mm- High quality Ethernet cable). I wonder if the length of the Smart-port cable could be a problem?
I will try now the R9 slim tx first to see if that works, close to the cube (short S-port cable).
I Will do testing in few days I have an apoimet with a surgeon