Shared Communications Bus - RS-422 or RS-485

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> The bottom line is, you don't know much about the application, but
> think you can design it better.  Why are you doing this?

You asked for suggestions and I gave some.  

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> How about something like this? 
>
> https://www.digikey.com/en/products/detail/amphenol-cs-commercial-products/RJHSE538B02/1979553

That appears to be an RJ45 like ethernet cables use.  The little locking
tabs break off all the time, and also the cable gets kinked up after
repeated flexing where it goes into the connector.  Strain relief helps
but it happens anyway.  You might buy some ready made ethernet cables
rather than putting those connectors on yourself.  At least with cheap
crimpers, the ready made cables are often more reliable than DIY ones.

They do make those magnetic connectors with varying numbers of pins.

Here is a CAN cable, no idea if that is of interest, but it uses the
OBD connector found in cars:  https://www.adafruit.com/product/4841

XLR or DIN style plugs/sockets might also be something to consider.

There is also this style, popular with the mechanical keyboard crowd:
https://www.pchcables.com/aviationplugs.html

On Thursday, November 3, 2022 at 3:37:43 PM UTC-4, Dave Nadler wrote:
> On 11/2/2022 1:28 AM, Rick C wrote: 
> > I have a test fixture that uses RS-232 to communicate with a PC. It actually uses the voltage levels of RS-232, even though this is from a USB cable on the PC, so it's only RS-232 for maybe four inches. lol 
> > 
> > I'm redesigning the test fixtures to hold more units and fully automate a few features that presently requires an operator. There will now be 8 UUTs on each test fixture and I expect to have 10 to 20 test fixtures in a card rack. That's 80 to 160 UUTs total. There will be an FPGA controlling each pair of UUTs, so 80 FPGAs in total that the PC needs to talk to. 
> > 
> > Rather than working on a way to mux 80 RS-232 interfaces, I'm thinking it would be better to either daisy chain, or connect in parallel all these devices. The protocol is master-slave where the master sends a command and the slaves are idle until they reply. The four FPGAs on a test fixture board could be connected in parallel easily enough. But I don't think I want to run TTL level signals between so many boards. 
> > 
> > I could do an RS-422 interface with a master to slave pair and a slave to master pair. The slaves do not speak until spoken to, so there will be no collisions. 
> > 
> > RS-485 would allow all this to be over a single pair of wires. But the one big issue I see people complain about is getting PC software to not clobber the slaves, or I should say, to get the master to wait long enough that it's not clobbering it's own start bit by overwriting the stop bit of the slave. I suppose someone, somewhere has dealt with this on the PC and has a solution that doesn't impact bus speed. I run the single test fixture version of this at about 100 kbps. I'm going to want as much speed as I can get for 80 FPGAs controlling 160 UUTs. Maybe I should give that some analysis, because this might not be true. 
> > 
> > The tests are of two types, most of them are setting up a state and reading a signal. This can go pretty fast and doesn't take too many commands. Then there are the audio tests where the FPGA sends digital data to the UUT, which does it's thing and returns digital data which is crunched by the FPGA. This takes some small number of seconds and presently the protocol is to poll the status until it is done. That's a lot of messages, but it's not necessarily a slow point. The same test can be started on every UUT in parallel, so the waiting is in parallel. So maybe the serial port won't need to be any faster. 
> > 
> > Still, I want to use RS-422 or RS-485 to deal with ground noise since this will be spread over multiple boards that don't have terribly solid grounds, just the power cable really. 
> > 
> > I'm thinking out loud here as much as anything. I intended to simply ask if anyone had experience with RS-485 that would be helpful. Running two wires rather than eight would be a help. I'll probably use a 10 pin connector just to be on the safe side, allowing the transceivers to be used either way. 
> >
> Hi Rick - I have an RS-485 system on my desk using an implementation of 
> the old Intel BitBus. Works fine for a handful of nodes, limited 
> distance, and very simple cabling - but only 62.5kbaud. Good solid 
> technology for 1994 when I designed it... 
> 
> Why would you use RS-485 instead of CAN? A million chips out there 
> support CAN with no fuss, works at decent speeds over twisted pair, not 
> hard to use. 
> 
> BTW, another option for interfacing to RS-485 from USB is XR21B1411 
> which is what I happen to have on my desk. 

I'm using RS-422 because I don't need to learn how to use a "chip".  It's the same serial protocol I'm using now, but instead of RS-232 voltage levels, it's RS-422 differential.  The "change" is really the fact that it's not just one slave.  So the bus will be split into a master send bus and a slave reply bus.  The master doesn't need to manage the tri-state output because it's the only talker.  The slaves only talk when spoken to and the UART is in an FPGA, (no CPU), so it can manage the tri-state control to the driver chip very easily.  

CAN bus might be the greatest thing since sliced bread, but I am going to be slammed with work and I don't want to do anything I don't absolutely have to. 

A lot of people don't understand that this is nearly the same as what I'm using now and will only require a very minor modification to the message protocol, to allow the slaves to be selected/addressed.  It would be hard to make it any simpler and this would all still have to be done even if adding the CAN bus.  The slaves still need to be selected/addressed. 

Thanks for the suggestions.  The part I'm worried about now are the more mechanical bits.  I am thinking of using the Eurocard size so I can use the rack hardware, but I know very little about the bits and bobs.  There will be no backplane, just card guides and the front panels on the cards to hold them in place.  I might put the cabling on the front panel to give it easy access, but then it needs machining of the front panel.  I could simplify that by cutting out one large hole to expose all the LEDs and connectors.  I want to make the design work as simple as possible and mechanical drawings are not my forte. 

-- 

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

On Thursday, November 3, 2022 at 3:53:32 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > The bottom line is, you don't know much about the application, but 
> > think you can design it better. Why are you doing this?
> You asked for suggestions and I gave some.

Ok, thank you for your suggestions.  

-- 

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209 

On Thursday, November 3, 2022 at 4:08:28 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > How about something like this? 
> > 
> > https://www.digikey.com/en/products/detail/amphenol-cs-commercial-products/RJHSE538B02/1979553
> That appears to be an RJ45 like ethernet cables use. The little locking 
> tabs break off all the time, and also the cable gets kinked up after 
> repeated flexing where it goes into the connector. Strain relief helps 
> but it happens anyway. You might buy some ready made ethernet cables 
> rather than putting those connectors on yourself. At least with cheap 
> crimpers, the ready made cables are often more reliable than DIY ones. 

The cable will be three inches long.  I can make more. 


> They do make those magnetic connectors with varying numbers of pins. 
> 
> Here is a CAN cable, no idea if that is of interest, but it uses the 
> OBD connector found in cars: https://www.adafruit.com/product/4841 

If you are talking about the big, black connector, it is bigger than the board.  This will be a Eurocard rack with 4HP or 0.8 inch spacing.  RJ-45 barely fits. 


> XLR or DIN style plugs/sockets might also be something to consider. 

DIN?  You mean those things that are used on Eurocards with some 96 pins?  What would mate with it?  What's actually wrong with RJ-45? 


> There is also this style, popular with the mechanical keyboard crowd: 
> https://www.pchcables.com/aviationplugs.html

Way too much work.  This is a jumper connector to go between boards that are 0.8 inches on centers.  It simply doesn't require that much effort.  They will be plugged and unplugged, on average, 1.1 times a day.  I think RJ-11 will hack it.  I'd rather have something that breaks and is very easy to replace, than something that breaks less often, but is much harder to repair or replace. 

-- 

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> DIN?  You mean those things that are used on Eurocards with some 96
> pins?

No I meant the circular connectors like you see on old PC keyboards,
similar to the aviation style one that I linked.

>  What would mate with it?  What's actually wrong with RJ-45?

1) the plugs break and the cables get munged up, but as you can say you
can replace them when they do.

2) the sockets also break, maybe not as often, but replacing them
might be harder, depending

If both of those are ok with you, then maybe it a good choice.

On Thursday, November 3, 2022 at 7:50:13 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > DIN? You mean those things that are used on Eurocards with some 96 
> > pins?
> No I meant the circular connectors like you see on old PC keyboards, 
> similar to the aviation style one that I linked.
> > What would mate with it? What's actually wrong with RJ-45?
> 1) the plugs break and the cables get munged up, but as you can say you 
> can replace them when they do. 

I suppose the plugs can break, but I've never seen a broken RJ-45, other than the catch breaking.  That's nearly always a result of pulling on a cable through a tangle rather than freeing it gently.  On the other hand, I have seen broken DIN mouse connectors.  The way they protrude, they get bumped and one or the other is damaged.  I think the metal on the chassis mounted connector is optional or something, that can make it more fragile.  Anything can break, but I need to be concerned with significant problems.  I think RJ-45 will be very adequate. 


> 2) the sockets also break, maybe not as often, but replacing them 
> might be harder, depending 

I've never seen an RJ-45 plug broken.  They are used widely in the telecom industry as RS-232 connectors for consoles. 


> If both of those are ok with you, then maybe it a good choice.

Yeah, I'm fine with a cable I can make to any length I want in 5 minutes, with most of that spent finding where I put the parts and tool.  Oh, and costs less than $1. 

If there was an easier way to make a DIN connector, I'd be ok with that.  Anything crimp or solder pin is going to be a PITA.  Heck, I'd be ok with a ribbon cable actually, but it would be larger than an RJ-45 since the smallest I'm likely to find is 10 positions.  That's a half inch, plus the extra width of the female part.  It's easy to bend those pins and it's not easy to extract the things without the extraction levers which make it even larger.  As long as I put it in the back of the card, that's not a big deal, but I'm thinking of putting the connectors on the front to make access easier when pulling a card out of the cage.  If power is in the front, it's totally easy.  Of course, using an actual back plane is even easier, but that's a lot more work to get all the specs to make that happen.  I wish I had one of the card cages in front of me to look at and see how they are constructed.  

I have a similar card with a front panel.  That is pretty straight forward with 8.5 inches clear space on the front panel.  Not sure where to get these particular parts though.  I wish the cards were a bit larger in each direction.  I can get 8 UUTs on one 6U, size B card, but it will be tight with the other stuff (FPGA, buffers, power supplies).  We've always had trouble ejecting the daughter cards as the two friction fit, 20 pin connectors are tough to get apart.  It's easy to damage the connectors removing them.  I have some ideas, but nothing that's rock solid.  It will be important for the test fixture card to be well supported when removing the daughter cards.  Having some extra room around the UUTs would help.  The next standard size up from the size B (233 x 160 mm) is 367 x 220 mm.  That's a large card!  Turns out it's not so much money if made at JLCPCB.  20 of them for $352!  That's pretty amazing! 

-- 

Rick C.

+-- Get 1,000 miles of free Supercharging
+-- Tesla referral code - https://ts.la/richard11209

Il 03/11/2022 16:26, David Brown ha scritto:
> On 03/11/2022 14:00, pozz wrote:
>> Il 03/11/2022 12:42, David Brown ha scritto:
>>> On 03/11/2022 00:27, Rick C wrote:
>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
>>>>> On 02/11/2022 20:20, Rick C wrote:
>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown
>>>>>> wrote:
>>>>>>> On 02/11/2022 06:28, Rick C wrote:
>>
>>
>>> You are correct that reception is in the middle of the stop bit 
>>> (typically sub-slot 9 of 16).  The first transmitter will be disabled 
>>> at the end of the stop bit, and the next transmitter must not enable 
>>> its driver until after that point - it must wait at least half a bit 
>>> time after reception before starting transmission.  (It can wait 
>>> longer without trouble, which is why faster baud rates are less 
>>> likely to involve any complications here.)
>>
>> Do you mean that RX interrupt triggers in the middle of the stop bit 
>> and not at the end? Interesting, but are you sure this is the case for 
>> every UART implemented in MCUs?
> 
> Of course I'm not sure - there are a /lot/ of MCU manufacturers!
> 
> UART receivers usually work in the same way, however.  They have a 
> sample clock running at 16 times the baud clock.  The start bit is edge 
> triggered to give the start of the character frame.  Then each bit is 
> sampled in the middle of its time slot - usually at subbit slots 7, 8, 
> and 9 with majority voting.  So the stop bit is recognized by subbit 
> slot 9 of the tenth bit (assuming 8-bit, no parity) - the voltage on the 
> line after that is irrelevant.  (Even when you have two stop bits, 
> receivers never check the second stop bit - it affects transmit timing 
> only.)  What purpose would there be in waiting another 7 subbits before 
> triggering the interrupt, DMA, or whatever?

There's no real purpose, but it's important to know exactly when the RX 
interrupt is fired from the UART.

Usually the next transmitter starts transmitting after receiving the 
last byte of the previous transmitter (for example, the slave starts 
replying to the master after receiving the complete message from it).

Now I think of the issue related to a transmitter that delays a little 
to turn around the direction of its transceiver, from TX to RX. Every 
transmitter on the bus should take into account this delay and avoid 
starting transmission too soon.

So I usually implement a short delay before starting a new message 
transmission. If the maximum expected delay of moving the direction from 
TX to RX is 10us, I could think to use a 10us delay, but this is wrong 
in your assumption.

If the RX interrupt is at the middle of the stop bit, I should delay the 
new transmission of 10us + half of bit time. With 9600 this is 52us that 
is much higher than 10us.

I know the next transmitter should make some processing of the previous 
received message, prepare and buffer the new message to transmit, so the 
delay is somewhat automatic, but in many cases I have small 8-bits PICs 
and full-futured Linux box on the same bus and the Linux could be very 
fast to start the new transmission.


>> I wouldn't be surprised if the implementation was different for 
>> different manufacturers.
>>
> 
> I've seen a bit of variation, including 8 subbit clocks per baud clock, 
> wider sampling ranges, re-sync of the clock on edges, etc.  And of 
> course you don't always get the details of the timings in datasheets 
> (and who bothers measuring them?)  But the key principles are the same.
> 
>>
>>>> None of this matters to me really.  I'm going to use more wires, and 
>>>> do the multi-drop from the PC to the slaves on one pair and use 
>>>> RS-422 to multi-point from the slaves to the PC.  Since the slaves 
>>>> are controlled by the master, they will never collide.  The master 
>>>> can't collide with itself, so I can ignore any issues with this.  I 
>>>> will use the bias resistors to assure a valid idle state.  I may 
>>>> need to select different devices than the ones I use in the 
>>>> product.  I think there are differences in the input load and I want 
>>>> to be sure I can chain up to 32 units.
>>>>
>>>
>>> OK.  I have no idea what such a hybrid bus should technically be 
>>> called, but I think it should work absolutely fine for the purpose 
>>> and seems like a solid solution.  I would not foresee any issues with 
>>> 32 nodes on such a bus, especially if it is relatively short and you 
>>> have terminators at each end.
>>
>> In my experience, termination resistors at each end of the line could 
>> introduce other troubles if they aren't strictly required (because of 
>> signal integrity on long lines at high baud rates).
>>
> 
> RS-485 requires them - you want to hold the bus at a stable idle state 
> when nothing is driving it.  

But this is the goal of *bias* resistors, not termination resistors.


> You also want to have a bit of load so that 
> you have some current on the bus, and thereby greater noise immunity.

Of course, but termination resistors are usually small (around 100 ohms) 
because they should match the impedance of the cable. If you want only 
to introduce "some current" on the bus, you could use resistors in the 
order of 1k, but this isn't strictly a *termination* resistor.


>> The receiver input impedance of all the nodes on the bus are in 
>> parallel with the two terminators. If you have many nodes, the 
>> equivalent impedance on the bus is much small and the partition with 
>> bias resistors could reduce the differential voltage between A and B 
>> at idle to less than 200mV.
>>
>> If you don't use true fail-safe transceivers, a fault start bit could 
>> be seen by these kind of receivers.
>>
> 
> Receiver load is very small on modern RS-485 drivers.

ST3485 says the input load of the receiver around 24k. When you connect 
32 slaves, the equivalent resistor would be 750 ohms, that should be 
enough to have "some current" on the bus. If you add *termination* 
resistors in the order of 100R on both sides, you could reduce 
drastically the differential voltage between A and B at idle state.

On 04/11/2022 08:45, pozz wrote:
> Il 03/11/2022 16:26, David Brown ha scritto:
>> On 03/11/2022 14:00, pozz wrote:
>>> Il 03/11/2022 12:42, David Brown ha scritto:
>>>> On 03/11/2022 00:27, Rick C wrote:
>>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown wrote:
>>>>>> On 02/11/2022 20:20, Rick C wrote:
>>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown
>>>>>>> wrote:
>>>>>>>> On 02/11/2022 06:28, Rick C wrote:
>>>
>>>
>>>> You are correct that reception is in the middle of the stop bit 
>>>> (typically sub-slot 9 of 16).  The first transmitter will be 
>>>> disabled at the end of the stop bit, and the next transmitter must 
>>>> not enable its driver until after that point - it must wait at least 
>>>> half a bit time after reception before starting transmission.  (It 
>>>> can wait longer without trouble, which is why faster baud rates are 
>>>> less likely to involve any complications here.)
>>>
>>> Do you mean that RX interrupt triggers in the middle of the stop bit 
>>> and not at the end? Interesting, but are you sure this is the case 
>>> for every UART implemented in MCUs?
>>
>> Of course I'm not sure - there are a /lot/ of MCU manufacturers!
>>
>> UART receivers usually work in the same way, however.  They have a 
>> sample clock running at 16 times the baud clock.  The start bit is 
>> edge triggered to give the start of the character frame.  Then each 
>> bit is sampled in the middle of its time slot - usually at subbit 
>> slots 7, 8, and 9 with majority voting.  So the stop bit is recognized 
>> by subbit slot 9 of the tenth bit (assuming 8-bit, no parity) - the 
>> voltage on the line after that is irrelevant.  (Even when you have two 
>> stop bits, receivers never check the second stop bit - it affects 
>> transmit timing only.)  What purpose would there be in waiting another 
>> 7 subbits before triggering the interrupt, DMA, or whatever?
> 
> There's no real purpose, but it's important to know exactly when the RX 
> interrupt is fired from the UART.
> 

I think it is extremely rare that this is important.  I can't think of a 
single occasion when I have thought it remotely relevant where in the 
stop bit the interrupt comes.

> Usually the next transmitter starts transmitting after receiving the 
> last byte of the previous transmitter (for example, the slave starts 
> replying to the master after receiving the complete message from it).
> 

No.  Usually the next transmitter starts after receiving the last byte, 
and /then a pause/.  There will always be some handling time in 
software, and may also include an explicit pause.  Almost always you 
will want to do at least a minimum of checking of the incoming data 
before deciding on the next telegram to be sent out.  But if you have 
very fast handling in relation to the baud rate, you will want an 
explicit pause too - protocols regularly specify a minimum pause (such 
as 3.5 character times for Modbus RTU), and you definitely want it to be 
at least one full character time to ensure no listener gets hopelessly 
out of sync.

> Now I think of the issue related to a transmitter that delays a little 
> to turn around the direction of its transceiver, from TX to RX. Every 
> transmitter on the bus should take into account this delay and avoid 
> starting transmission too soon.

They should, yes.  The turnaround delay should be negligible in this day 
and age - if not, your software design is screwed or you have picked the 
wrong hardware.  (Of course, you don't always get the choice of hardware 
you want, and programmers are often left to find ways around hardware 
design flaws.)

> 
> So I usually implement a short delay before starting a new message 
> transmission. If the maximum expected delay of moving the direction from 
> TX to RX is 10us, I could think to use a 10us delay, but this is wrong 
> in your assumption.
> 

Implementing an explicit delay (or being confident that your telegram 
handling code takes long enough) is a good idea.

> If the RX interrupt is at the middle of the stop bit, I should delay the 
> new transmission of 10us + half of bit time. With 9600 this is 52us that 
> is much higher than 10us.
> 

I made no such assumptions about timings.  The figures I gave were for 
using a USB 2 based interface on a PC, where the USB polling timer is at 
8 kHz, or 125 µs.  That is half a bit time for 4 Kbaud.  (I had doubled 
the frequency instead of halving it and said the baud had to be above 16 
kBaud - that shows it's good to do your own calculations and not trust 
others blindly!).  At 1 MBaud (the suggested rate), the absolute fastest 
the PC could turn around the bus would be 12 character times - half a 
stop bit is irrelevant.

If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs 
between reception of the last bit and the start of transmission of the 
next message, your code is wrong - by nearly two orders of magnitude. 
It is that simple.

If we take Modbus RTU as an example, you should be waiting 3.5 * 10 / 
9600 seconds at a minimum - 3.65 /milli/seconds.  If you are concerned 
about exactly where the receive interrupt comes in the last stop bit, 
add another half bit time and you get 3.7 ms.  The half bit time is 
negligible.

> I know the next transmitter should make some processing of the previous 
> received message, prepare and buffer the new message to transmit, so the 
> delay is somewhat automatic, but in many cases I have small 8-bits PICs 
> and full-futured Linux box on the same bus and the Linux could be very 
> fast to start the new transmission.
> 

So put in a delay.  An /appropriate/ delay.

> 
>>> I wouldn't be surprised if the implementation was different for 
>>> different manufacturers.
>>>
>>
>> I've seen a bit of variation, including 8 subbit clocks per baud 
>> clock, wider sampling ranges, re-sync of the clock on edges, etc.  And 
>> of course you don't always get the details of the timings in 
>> datasheets (and who bothers measuring them?)  But the key principles 
>> are the same.
>>
>>>
>>>>> None of this matters to me really.  I'm going to use more wires, 
>>>>> and do the multi-drop from the PC to the slaves on one pair and use 
>>>>> RS-422 to multi-point from the slaves to the PC.  Since the slaves 
>>>>> are controlled by the master, they will never collide.  The master 
>>>>> can't collide with itself, so I can ignore any issues with this.  I 
>>>>> will use the bias resistors to assure a valid idle state.  I may 
>>>>> need to select different devices than the ones I use in the 
>>>>> product.  I think there are differences in the input load and I 
>>>>> want to be sure I can chain up to 32 units.
>>>>>
>>>>
>>>> OK.  I have no idea what such a hybrid bus should technically be 
>>>> called, but I think it should work absolutely fine for the purpose 
>>>> and seems like a solid solution.  I would not foresee any issues 
>>>> with 32 nodes on such a bus, especially if it is relatively short 
>>>> and you have terminators at each end.
>>>
>>> In my experience, termination resistors at each end of the line could 
>>> introduce other troubles if they aren't strictly required (because of 
>>> signal integrity on long lines at high baud rates).
>>>
>>
>> RS-485 requires them - you want to hold the bus at a stable idle state 
>> when nothing is driving it. 
> 
> But this is the goal of *bias* resistors, not termination resistors.
> 

Yes - but see below.  Bias resistors are part of the termination - it 
just means that you have terminating resistors to 5V and 0V as well as 
across the balanced pair.

> 
>> You also want to have a bit of load so that you have some current on 
>> the bus, and thereby greater noise immunity.
> 
> Of course, but termination resistors are usually small (around 100 ohms) 
> because they should match the impedance of the cable. If you want only 
> to introduce "some current" on the bus, you could use resistors in the 
> order of 1k, but this isn't strictly a *termination* resistor.
> 

If you have a cable that is long enough (or speeds fast enough) that it 
needs to be treated as a transmission line with controlled impedance, 
then you do need impedance matched terminators to avoid reflections 
causing trouble.  Usually you don't.

A "terminating resistor" is just a "resistor at the terminator" - it 
does not imply impedance matching, or any other specific purpose.  You 
pick a value (and network) appropriate for the task in hand - maybe you 
impedance matching, maybe you'd rather have larger values to reduce 
power consumption.


> 
>>> The receiver input impedance of all the nodes on the bus are in 
>>> parallel with the two terminators. If you have many nodes, the 
>>> equivalent impedance on the bus is much small and the partition with 
>>> bias resistors could reduce the differential voltage between A and B 
>>> at idle to less than 200mV.
>>>
>>> If you don't use true fail-safe transceivers, a fault start bit could 
>>> be seen by these kind of receivers.
>>>
>>
>> Receiver load is very small on modern RS-485 drivers.
> 
> ST3485 says the input load of the receiver around 24k. When you connect 
> 32 slaves, the equivalent resistor would be 750 ohms, that should be 
> enough to have "some current" on the bus. If you add *termination* 
> resistors in the order of 100R on both sides, you could reduce 
> drastically the differential voltage between A and B at idle state.
> 

If you are pushing the limits of a bus, in terms of load, distance, 
speed, cable characteristics, etc., then you need to do such 
calculations carefully and be precise in your specification of 
components, cables, topology, connectors, etc.  For many buses in 
practice, they will work fine using whatever resistor you pull out your 
box of random parts.  For a testbench, you are going to go for something 
between these extremes.

On 03/11/2022 21:08, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>> How about something like this?
>>
>> https://www.digikey.com/en/products/detail/amphenol-cs-commercial-products/RJHSE538B02/1979553
> 
> That appears to be an RJ45 like ethernet cables use.  The little locking
> tabs break off all the time, and also the cable gets kinked up after
> repeated flexing where it goes into the connector.  Strain relief helps
> but it happens anyway.  You might buy some ready made ethernet cables
> rather than putting those connectors on yourself.  At least with cheap
> crimpers, the ready made cables are often more reliable than DIY ones.
> 

On some testbenches that we have made that are used for cards with RJ45 
sockets on the card, we made posts with an RJ45 on the end, with a small 
spring at the base.  The RJ45 connector had its tag removed, of course. 
  The DUT slid in on rails.  For high-usage testbenches, you don't want 
any flexible cables attached to the DUT - you want bed of nails and 
spring-loaded connectors as much as possible.