Unverified: Smart Port sensor discovery doesn't work on X4R-SB

[mlyle]

From here: https://forum.dronin.org/forum/d/28-smartport-telemetry-on-lux-flight-controller/12

I'm running OpenTX 2.1.8 on the transmitter.

Yeah it seems like the problem is isolated to sensor discovery and impacts the x4r-sb and not the x8r.

x8r - sensor discovery works, sensor data makes it to transmitter as expected

x4r-sb - sensor data does make it to the transmitter, but the sensors have to be set up manually, by script, or carried over from a sensor discovery pass when the x8r is connected.

Sensor discovery does work on the x4r-sb when the lux is running cleanflight, so I assume the x4r-sb hardware is not faulty, but I don't really know anything about how the sensor discovery protocol works so I'm not sure why the x8r would work for sensor discovery while the x4r-sb fails on dronin.

[jpahka]

I've got 3 x4r-sb that I've used on quanton, sparky[12] and brainRE1, as well as multiple versions of opentx 2.1.x. I've never had issues with telemetry discovery. I'm using this inverter with boards that require one:

http://forum.taulabs.org/viewtopic.php?f=17&t=223&start=40#p3629 http://forum.taulabs.org/viewtopic.php?f=17&t=223&start=90#p5566

[gmcbay]

This issue was made in response to an issue I posted about on the forums. I've installed dronin on a few other quads now and only ran into this issue when combining the lux flight controller (F3, doesn't require external hardware for inversion) with the x4r-sb receiver.

The same x4r-sb receiver on other flight controllers didn't show the issue, an x8r on the lux didn't show the issue.

The x4r-sb and lux flight controller combo that does present a problem for me in dronin works fine in cleanflight (so I don't think it is a hardware issue with my lux flight controller, though I don't have another lux to try to see if that makes any difference).

If anyone else happens to have both a lux and an x4r-sb, I would recommend testing with that specific combo to verify if this issue is reproducible. It is entirely possible there is something unique about my setup that isn't a general problem, but I am only running into it with that specific combo of lux/x4r-sb.

[dustin]

I've been testing tonight with both DTFc and Sparky with both X4R-sb and XSR. I could occasionally get extra sensors, but not consistently.

On the wire (via Saleae Logic), I was able to view data going back and forth between the FC and the RX. e.g. a session on my sparky 1 has a bunch of entries (decoded from logic dumps) that look like this:

< Have 0x1b?
> sensor 0720 -> ffffff9a
< Have 0x00?
< Have 0xa1?
< Have 0x22?
< Have 0x83?
< Have 0xe4?
< Have 0x45?
< Have 0xc6?
< Have 0x67?
< Have 0x48?
< Have 0xe9?
< Have 0x6a?
< Have 0xcb?
< Have 0xac?
< Have 0x0d?
< Have 0x8e?
< Have 0x2f?
< Have 0xd0?
< Have 0x71?
< Have 0xf2?
< Have 0x53?
< Have 0x34?
< Have 0x95?
< Have 0x16?
< Have 0xb7?
< Have 0x98?
< Have 0x39?
< Have 0xba?
< Have 0x1b?
> sensor 0710 -> 7

i.e. it asks for stuff, dRonin answers on 0x1b and sends various sensor results, all of which seem fine.

Sometimes this makes it back to my radio. Most of the time, it just doesn't.

[dustin]

Attached are a couple of samples in Saleae Logic format of a Frsky GPS module vs. recent dRonin on a Sparky.

(this sample may have some of the telemetry items removed, but it doesn't seem to make much difference)

samples.zip

[dustin]

The issue seems to be the serial port not being pulled down, so it's not being picked up well.

Seems to work consistently with this:

-                       .GPIO_PuPd  = GPIO_PuPd_UP
+                       .GPIO_PuPd  = GPIO_PuPd_DOWN

(tested on sparky + x4r)

[tracernz]

That's non-standard, typical for FrSky I guess.

[mluessi]

The pull-down would make sense, as the line is low when idle. On RE1 there is a pull-down as well, because the FPGA inverter input is high-z when idle. Because the line is bi-directional, I assume neither the X4R nor the STM32 is driving it when it is idle, so there needs to be a pull-down.

[dustin]

I'll make a patch.

Without the pulldown it works... sometimes. Maybe in a particular setup, it works reliably. This seems to be a chance thing. I'd occasionally get values, but usually didn't. I've got more testing to do (only tried one RX on one board), but I went from "almost never" to "every time" by turning on the pulldown in the port.

Note that this only matters on single-wire F3. My tests have been on DTFc and Sparky 1 so far with X4R and XSR.