Pixracer: Configurable single-wire

[LorenzMeier]

Pixracer: Configurable single-wire

[LorenzMeier]

@kd0aij If you agree my first proposal would be to hook it up and see how the signal behaves, then to read the data on the bus to ensure we get everything on our side, then write something after the frame from the RX (just anything so we see if the signal looks good).

That would be enough to call the hardware good. Sending real sensor data (like battery voltage) is a bonus.

[kd0aij]

frsky_telemetry daemon on port ttyS6 is sending altitude (looks like lpos.z) successfully to a Taranis X9D through a D4R-II RX
That's with the PixRacer TX connected directly to the D4R RX, of course. PixRacer RX was not connected for this test.

[pkocmoud]

With a diode connecting the TX to the RX from the PixRacer, the Voltage of the TX signal is +2.4v. The waves appear very square. Mark is proceeding with updating the frsky_telemetry application to use the X-Type signaling.

[pkocmoud]

[LorenzMeier]

@kd0aij @pkocmoud Do you have an update on the status? I'm getting more and more user requests, including questions for where the S.Port cable is.

[pkocmoud]

The cable is a tough question. We provided the cable we did so it could be spliced as the user requires. FrSky uses one 4 pin connector on the X series receivers, yet on the connected FrSky devices use a standard 3pin .1 Servo style female connector. I think the best approach is I will order both cable and offer to sell as accessories on the site.

[kd0aij]

@pkocmoud My signals (with RX connected directly to TX) look better than yours. I suggest you test with the diode shorted to see if I'm right.

[kd0aij]

WIP on SmartPort telemetry daemon is here: PX4/PX4-Autopilot#3529

[LorenzMeier]

A couple of observations: This here would be how to do single-wire properly behind the inverter that we already have:
https://github.com/dword1511/onewire-over-uart

We never have non-inverted single-wire. So we could shut off the the TX line together with the inversion signal and use a block like the one below for FrSky and for S.BUS:

[kd0aij]

"singlewire" there is just a junction? and your intent is to be able to run the uart in full-duplex mode also?

I think Phil's goal is to change R13 so that it's an optimal implementation, but that depends on whether we require both full and half duplex or just half duplex

[LorenzMeier]

The link in my post above has the full schematic for "SINGLEWIRE".

[LorenzMeier]

We only have two configurations:

• Non-inverted UART
• Inverted, single-wire UART

I would not be aware of anything in the RC space that would depart from that scheme.

[kd0aij]

clarifiying the RC space requirements

1. non-inverted UART (RX only): DSM, STM24, SUMD
2. non-inverted UART (bidirectional) through inverting transceiver: SBUS2 (RC in and telemetry out) and SmartPort (poll in and telemetry out)

[davids5]

I sure am lost in the words.

How about a requirements chart (rich spread sheet) that list all the Protocols and has TX, RX listed and the sense with respect to the CPU.

Like:

PROTOCOL	TX (out)	RX(in)	Circuit
TTL Serial	NON-INVERTED	NON-INVERTED	insert image
INVTTL Serial	INVERTED	INVERTED	insert image
DUM	NC	NON-INVERTED	insert image
DEF	NON-INVERTED	NC	insert image

Then add a column for existing interface solution for only that protocol where it says insert image

[davids5]

Also it would be nice to have bit rates listed too.

[kd0aij]

good idea. The requirements must specify precisely which protocols must be supported by the hardware and which are mutually exclusive (one element of a set must be chosen and whether that selection must be made at compile time or deferred to run time).

If this isn't already written down, I suggest that the hardware should support CPPM, DSM or SBUS input (selected at runtime based on which decoder succeeds), and SmartPort output compiled in. Nothing else. Once this is agreed upon, the remaining tasks become well-defined.

[LorenzMeier]

@davids5 The key is to have ownership here. Its not a technical problem. I gave you the complete spec already (we need plain serial or inverted single-wire serial and nothing else). @kd0aij If you would like to create the complete list (which will reduce to just the two things I provided above again) I'm fine with it, but I want to know who assumes responsibility in validating the interface. I feel you're up to speed now so you could certainly handle that.

@davids5 Its not necessarily helpful to discuss the full specs with everybody, since they only make sense if everybody understands virtually every radio protocol out there. We don't have the luxury to be able to train several people in all those, and so the table will remain meaningless.

[kd0aij]

And the R12 hardware can provide the bidirectional 1-wire support on the USART8 pins (with the right cable) with no hardware change at all. Further testing of PX4/PX4-Autopilot#3553 is invited.

I'll look further into singlewire mode and the circuit recommended by the Taulabs here: https://github.com/TauLabs/TauLabs/wiki/User-Guide:-FrSKY-S.PORT-telemetry
especially since they mention using a direct connection to the TX pin on STM32F3. Perhaps that would free up a couple of GPIOs

[LorenzMeier]

The F4 has no hardware inverter. It's older than the F3 family.

[LorenzMeier]

Can you put up a photo in the PR of the cable so people can rebuild it and know where to connect it on the RX?

[kd0aij]

Thanks, I hadn't looked at the F3 yet.
:) you don't want to see my cabling. Bare wire clamped together with logic analyzer probes.
@pkocmoud Did you make a diode-free cable yet?

[pkocmoud]

I did, it works fine. I asked Nick to post a graphic.

From: Mark Whitehorn [mailto:[email protected]]
Sent: Thursday, January 21, 2016 10:23 AM
To: PX4/Hardware [email protected]
Cc: Phillip J. Kocmoud [email protected]
Subject: Re: [Hardware] Pixracer: Configurable single-wire (#39)

Thanks, I hadn't looked at the F3 yet.
:) you don't want to see my cabling. Bare wire clamped together with logic analyzer probes.
@pkocmoudhttps://github.com/pkocmoud Did you make a diode-free cable yet?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-173623112.

[nickarsov]

[kd0aij]

So if we don't change the smartport logic of R12 at all, we can also use it as a non-inverted TTL uart port.
Because we have a pin dedicated to the FrSky_inv control. That gives the FrSky I/O pins an additional function which is not yet recognized by the firmware. As long as the 1K series resistors don't conflict with this other function, that port is fine.

[nickarsov]

Agree......+ if we separate the PB0 and PC7, and connect PB0 directly to RC_INPUT, our RC_INPUT port is fine too. That means we can proceed with R12 with just fix of a track.