Open collector differential signalling, choosing the better option

[Infraviolet]

I'm looking at a situation where I want to have multiple sending devices able to pass a differential signal through a long distance in a potentially noisy environment to a receiver. As there are multiple senders I want to ensure electrically that there is no possibility of over-current damage from one sender taking a line low and the other taking it high (via push-pull signalling) at the same time, so I'm going to be using some form of open collector. I have got "protocol" stuff at higher levels to deal with making sure that actual data sent by different devices doesn't clash with one-another, so this forum thread is just about the electrical level.

So, for open collector differential signalling I've got two choices. I can have, for a differential pair, both as NPN collectors operating in opposition, or I can have one as an NPN open collector and the other as a PNP open collector. As far as the comparator at the receiving end is concerned there's no real dfference, but in terms of the type of output used to do the sending, and whether each line of the pair has a pulldown to Gnd or a pullup to the positive voltage rail, there is a difference.

Which then, see the diagram attached, is the better choice for noise immunity? Or if they are equivalent in that regard, which is "better" by other measures, for example the dual NPN type would always be consuming power supply current through one or the other pullup at any given time, while the NPN+PNP one would consume twice as much current when the PNP line was driven high (and the NPN driven low) and no current when in the other logical state (PNP released to be pulled low and NPN released to be pulled high).

Which choice is "better", and if noise immunity is identical then for what reason is one of them a better option.

Thanks

[Infraviolet]

Any thoughts, I can't seem to find anything when searching regarding differential signalling with open-collectors. All the results I find seem to just be about push-pull differential versus open-collector with a single wire. Thanks

[langwadt]

CAN bus ...

[Infraviolet]

Thanks for suggesting looking at CAN bus instead of searching for open collector and differential signalling specifically, CAN looks to use the mixed "nppn" and "pnp" method. I guess that's the "better" choice then, if CAN chooses to use it, is there a reason why for this over the all-npn-method though? Thanks

[langwadt]

Thanks for suggesting looking at CAN bus instead of searching for open collector and differential signalling specifically, CAN looks to use the mixed "nppn" and "pnp" method. I guess that's the "better" choice then, if CAN chooses to use it, is there a reason why for this over the all-npn-method though? Thanks

mixed one state both + and - is driven other is pull up, with all npn both states have one or the other side only pull up

the first CAN transceivers where basically RS485 transceivers using the enable pin for data and the data pin fixed low

[Kleinstein]

The case with both NPN would have current flowing through ground, not just the differential pair. The PNP NPN combination avoids the ground current. As a downside one still needs to make sure the lines are not swapped anywhere.

Ideally a long line should be terminated and the swiching transistors would be pretty low impedance. One may want some extra current limit, possibly just a current signal, so that the termination is passive on both ends and not from the drivers.

[selcuk]

Is this circuit for experimental or educational purposes? If it is for an actual device, I recommend you to use a CAN transceiver. They have measures for bus collision, high common voltages, ESD, fast rise times etc. A reliable solution with discrete components will need a good amount of PCB space.

[Infraviolet]

Thanks, I've just had an extra thought too.

I suspect PNP together with NPN also has the advantage that the "long" transition time is in the same place for both circuits (the NPN drops fast when the device outputs low but rises more slowly due to capacitance in the line and the resistance of the pullup putting a limit on the current, the PNP rises nearly instantly but drops more slowly when it returns to being low). With NPN and PNP your slow transitions are together, whereas with dual NPN one channel would make a slow transition while the other was making a fast, and you might get logic glitches unless some very major hysteresis was applied to the receiver?

[PGPG]

What is 'long distance' for you?
Do your devices are in the same room, same building or in different buildings.

If long distance means different buildings than your solution to not work only until first storm certainly needs galvanic isolation (assume few kV difference with high current efficiency between building grounds).

It looks that you are fixed on making it from discrete elements. The simplest solution ensuring isolation is the current loop.
You can do the loop with its wires being not isolated from receiver but isolated from all senders. In receiver you do current source from + supply and send it into loop. Returning current can go through small resistor to ground and voltage at resistor can be used to determine if current in loop flows or not.
The current in loop can go through output transistors of optocouplers in all senders. Each of them can transmit data by interrupting current in loop.

For connection of up to 50 devices in one building I use not isolated RS485, but with seriously protected inputs (you should assume up to 50V ground difference).
In past for connections between buildings and up to 1km I was using isolated RS485.
In 90s for connections up to 1.2km I was using 20mA current loops.

RS485 drivers are protected against damage when more then one is driving the bus and by standard tolerate up to 7V ground voltage difference between elements on the bus.

[langwadt]

make the receiver a current source driving a resistor connected to +/-, make each transmitter short +/- using an optocoupler?

[BrianHG]

In the past, to do this, I just used a 5v PIC microcontroller's  comparator's +/- inputs.

To receive, I read the PIC's internal comparator.
To transmit, I output enable the pins high or low, or make them inputs to acquire tri-state mode.

I managed 19.2kb throughout hundreds of feet of wire with 20 modules on the bus, each with their own PICs as receivers and transmitters, each one sharing the home made RS485 bus.

I just added a few series resistors with protection diodes for static charge, with a weak pull-up & down to default the bus into a null state when there were no active transmitters + a parallel cap for noise.

The PIC's 5v IOs could sink and source 25ma which was plenty.  The comparator's differential receiver took care of common mode noise in the wiring.  The PIC did all the negotiations through a software UART on the home made 485 bus while the hardware UART was used to link with a PC to talk on the bus.

[dukelec]

Compared to CAN, I recommend RS485.
Using RS485 allows you to use open-drain drive during the arbitration phase and push-pull drive during the data phase, balancing both arbitration functionality and data rate:

https://www.eevblog.com/forum/microcontrollers/the-small-open-source-ic-allows-us-to-use-rs485-as-full-duplex/

[Infraviolet]

"Long distances", maybe I used the wrong wording. I'm thinking up to ten metres of wire length, straight line distances being rather less and more like 3m maximum. But in proximity to various motors which may generate noise. I was definitely thinking about situations that would involve a branching topology though, not the sort of "loops only" situation which CAN is designed for. And situations where devices might be physically connected or removed during running, again not something a loop of current would be ok with?

P.S. dukelec, nice work on that RS485 stuff. I'm not yet sure if it is applicable to my questions, but It's definitely got my interest for reading through, if not for this then for future situations.

[PGPG]

Using RS485 allows you to use open-drain drive during the arbitration phase and push-pull drive during the data phase

I looked briefly at thread you linked. My first impression is that what you describe is trying to solve not existing problem.
We use RS485 since 90s. Those time we accepted 100 devices on bus up to 1000m working with 57600. Years later designing bus for new system we changed it to 50 devices and 115200 at 300m bus.
If each frame (except broadcasts) is confirmed you can just accept collisions. Risk of collision is very small. When device decides to enter bus it switches driver on and 2us later issues start bit of first byte of frame. These 2us are for stabilize the state so the first edge will be delayed at bus the same as others (first edge is used by receiver to set checking state moments for each bit).
To estimate collision risk we need to know the average distance between devices that can potentially collide. Our typical bus is shorter then 300m. If one dev is at the end than average distance to the second device is bus length/2. If one is in center then bus length/4. Assuming bus length/3 can be reasonable.
Adding 2us + driver/receiver delay time + propagation time we get max about 4us time after which the second device that also want to start its frame notices that someone else started so it will not send his frame. So looking from one device point, the situation is such that the collision risk period of making decision to enter a bus is 8us length (4us before to 4us after the second device decision).
If there are no polling frames on the bus then bus can be really quiet. For example how many people can access few doors during each second? In such system assuming 1 frame per second will be high. But let us assume 100 frames being send at bus per second by other devices and our device want to send its frame between them. In each second there are only 100x8us=800us when decision of entering the bus will result in collision with others frame. The only effect of collision is that device after 20..40ms not receiving confirmation will repeat its message.
To avoid situation when many devices waiting bus being idle and then will try to enter it at the same time you can use random delay (say 0..31 number multiplied by 8us).
For short buses you can reduce 2us to much smaller time. Fast drivers will have short propagation times (I considered slope limited drivers). Propagation time in short bus will also be much smaller. So instead of 8us you will get 1us or less and of course random delay can work with smaller raster.

[dukelec]

Hi PGPG,

If the bus data volume is not large and small probability collisions are acceptable, then the traditional method can indeed suffice.

However, if there are requirements for transmission efficiency and real-time performance, then data packet corruption due to collisions and inefficiency caused by introducing random delays cannot be accepted.
This is also why people originally chose the CAN bus over RS485.

Moreover, an additional benefit of using the CDBUS hardware controller is that it can simplify the software.

[T3sl4co1l]

You might also consider differential I2C, at least conceptually if nothing else.  Same idea as CAN: line idle is zero (or pulled slightly negative), active is symmetrical driven.

I don't recommend crafting your own drivers.  There are many EMC issues to resolve.  Simpler to use something standard if at all possible.  Even if you aren't using CAN, a CAN interface may be compatible, and you might fall back on an RS-485 transmitter (which is, AFAIK, how CAN was developed anyway).  I suppose DI2C is a little too special (it's not just a PHY, the interface is I2C) but an option if you like I2C's organization instead.

Tim

[PGPG]

data packet corruption due to collisions and inefficiency caused by introducing random delays cannot be accepted.
This is also why people originally chose the CAN bus over RS485.

I'm not sure of what I write here but I suppose:
- with RS485 (with well terminated bus) more than one bit can travel the same time in bus,
- in any process of arbitration bit stage have to stabilize at whole bus.

May be possibility of working with higher speed can compensate other time looses.
I didn't understood description perfectly but I sow there something about issuing state 0 for some time before sending a frame while we start sending frame at once.
But of course collisions reduce throughput.

[MarkT]

As there are multiple senders I want to ensure electrically that there is no possibility of over-current damage from one sender taking a line low and the other taking it high (via push-pull signalling) at the same time, so I'm going to be using some form of open collector.

Doesn't make sense - you need to impedance match anyway so every transmitter will have series resistors for that already, you don't need to worry about devices fighting each other in a transmission line used for signalling, the hardware won't mind, but you will need to recognize a collision.

Open collector is usually fairly slow due to the pull up (a current source is a better pull-up, note, but doesn't work on a transmission line as its not impedance matched), but you can do clever things with open-collector - checkout how OneWire bus works for instance to allow device enumeration over a vast address space in very short time span...

[T3sl4co1l]

Doesn't make sense - you need to impedance match anyway so every transmitter will have series resistors for that already, you don't need to worry about devices fighting each other in a transmission line used for signalling, the hardware won't mind, but you will need to recognize a collision.

Open collector is usually fairly slow due to the pull up (a current source is a better pull-up, note, but doesn't work on a transmission line as its not impedance matched), but you can do clever things with open-collector - checkout how OneWire bus works for instance to allow device enumeration over a vast address space in very short time span...

Two shortcomings:
1. The source doesn't need to be matched. And in general (among interfaces mentioned), it isn't, it's much lower.  RS485 isn't that much lower to be fair, but it is on the low side, so that a 2.5-3V transmitter still makes 1.5-2V into a double-terminated bus.  For TTL buses for example, this ensures adequate signal level for all receivers; for differential receivers like this, signal level isn't as important, but it does need to be conserved for purposes of unit loading and line length.

Conversely, CMOS point-to-point links prefer source termination, so that full signal level arrives at the receiver without drawing continuous source current when driving electrically short traces (i.e., fractional clock pulse duration).  This doesn't work so well for multi-drop or stub buses, however, where end termination is preferred.

At least one termination is required, therefore any source impedance will do for an end-terminated multidrop bus, as long as it delivers adequate signal level.

2. There's nothing inherently slow about OC compared to any other terminated bus driver.  The bandwidth of the bus is dictated by its cross-section (waveguide mode breakup), consistency (signal quality), and losses.  The bandwidth of a transmitter will be lower than this due to capacitance, or whatever equivalent impedance it has.  Capacitance can be peaked out to a modest degree, and we can choose higher-FoM devices (minimum size Si BJT or MOSFETs; SiGe; GaN), or apply RF techniques (but then, maybe a distributed amplifier isn't very digital anymore ).

The same basic architecture is used for 100BASE-T, for example.  Two OC drivers, in push-pull, are terminated into 50Ω each, locally.  The transformer couples this to a 100Ω line, terminated at the far end, so the drivers see a 12.5Ω load, each.  At a typical 100-200mA current consumption, signal level is around 1.5V, as specified.  This could just as well be driven single-ended by a totem pole circuit (and 6V supply), which I suppose was how it was done back in the coax days (or maybe not: transformers were in common use back then, too), or bridged into differential directly (which is in part how Gigabit does it).

Tim

[dukelec]

Hi PGPG,

issuing state 0 for some time before sending a frame

This refers to sending a break character, which is for the BreakSync mode.
This break character serves as a synchronization signal, which is only needed when the bus has been idle for a long time.
All nodes will receive this synchronization signal and then wait for different durations before sending data to avoid collisions.

The default mode is Arbitration mode, where frames are sent directly.
During the transmission of the first byte, each bit is read back sequentially for arbitration.