Shared Communications Bus - RS-422 or RS-485

On 11/2/2022 1:29 AM, John Walliker wrote:
> On Wednesday, 2 November 2022 at 08:06:52 UTC, Don Y wrote:
>> On 11/1/2022 11:25 PM, whit3rd wrote:
>>> Apple's old (1980's) LocalTalk scheme does this, using RS-422 style
>>> transceivers and transformer coupling. You can get Keyspan balanced-pair
>>> USB/serial ports and (used to be) PhoneNet transformer boxes off-the-shelf
>>> to use telco-style twisted pair wiring. For short spans, not even
>>> twisted.
>> Yeah, but they were klunky -- especially by today's standards.
>> Like running orange hose would be! :> [Sheesh! It's mind-boggling
>> to consider the changes that we've just taken for granted!]
>>> But, to get speed, you need an MSI serial port as smart as the Z8530 was to
>>> do the encoding/decoding for the transformer coupling to work. With simple
>>> paired wire (no transformers) your protocol would still need a
>>> high-impedance state for the transceivers.
>> Or, a dominant/recessive configuration that the protocol can
>> examine to ascertain if active, or not.
>>> That's why open-collector and I2C and its brethren are usually used.
>> It would seem that CAN would be the off-the-shelf solution
>> all the way up *into* the PC/controller. With CAN-enabled
>> MCU's readily available and "volume" markets like automotive
>> driving their development, rolling your own seems like an
>> exercise in futility.
>>
>> [Unless, of course, your operating environment is far WORSE than
>> that of a motor-vehicle!]
> 
> The automotive market seems to be moving towards single pair ethernet,
> but CAN will undoubtedly be around for a very long time.

Yes.  And, you can buy silicon, today -- along with protocol
stacks, PCI cards, APIs, etc.  Make a "sugar-cube-sized" protocol
adapter at each target and forget about the comms to the controller!

Rolling your own is just a colossal waste of time -- where are the
"savings"?

We designed a serial network in the early 80's -- when all you had
were UARTs and their upscale brethren.  No libraries, no standards,
etc.  Trying to imagine all of the ways things could get borked
was a huge effort (no technical support folks on-hand -- retail PoS
application -- so if the network went down, the business was losing
money until it could be brought back up!)

We ended up designing fused connections in each drop so that the
"master" could deliberately electrically isolate an offending
node (impress a high voltage and wait for the fuses to open).

And, different "backup" scenarios to ensure we could fry the
offender, even if he was "clever" and foresaw the pulse coming!
E.g., a protocol command to force him to stay on the wire -- after
having told everyone else to get off it -- so we could toast his
interface.

On Wednesday, November 2, 2022 at 12:34:52 AM UTC-7, Ricky wrote:
> On Wednesday, November 2, 2022 at 2:25:53 AM UTC-4, whit3rd wrote: 
> > On Tuesday, November 1, 2022 at 10:31:03 PM UTC-7, Ricky 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. 
> > Apple's old (1980's) LocalTalk scheme does this, using RS-422 style transceivers and transformer coupling. 
> > You can get Keyspan balanced-pair USB/serial ports and (used to be) PhoneNet transformer boxes off-the-shelf to use telco-style twisted 
> > pair wiring. For short spans, not even twisted. 
> > 
> > But, to get speed, you need an MSI serial port as smart as the Z8530 was to do the encoding/decoding for 
> > the transformer coupling to work. With simple paired wire (no transformers) your protocol would still need 
> > a high-impedance state for the transceivers. 
> > 
> > That's why open-collector and I2C and its brethren are usually used.
> I2C is slow. Isn't the fast version only 400 kbps? Besides, that's not generally used off board. The whole reason for worrying about this is because the boards are in a rack, but not with a "proper" back plane and the PC controlling it is a few feet of cable away. 
> 
> Better to use the RS-422, but transformer coupling is overkill. That would be useful when the devices are plugged into different outlets in different rooms, perhaps, to deal with more pronounced ground issues. 

The LocalTalk transmitters (AM26LS31) were RS-422 compliant, with high-Z enables on each (four drivers
per chip).   They'll drive a twisted-pair backbone, with 110  ohm terminations on each end.  If you're sure
rack boards only talk to the host, and listen to the host, then... yeah, you can chain all slaves to listen on pair 1,
and talk on pair 2, but the master to talk on pair 1 and listen on pair 2.   But, the wiring has to be
in series (master and two terminators, slave 1, slave 2, ... slave N, and two terminators) .
Heck, Cat5 has four pairs, you could U-turn at the end and put all the terminators at the master.

On 02/11/2022 05:30, Ricky 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.

<snip>

I've done similar, though with many fewer nodes, simply by paralleling 
the RS232 inputs and diode oring the outputs.  I imagine you might need 
to buffer your PC output and maybe not expect very high speeds.

-- 
Cheers
Clive

On 2022-11-02 06:30, Ricky 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.
> 


I've built test systems like that, without any PC master timing problems.

Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.
Use independent RX and TX. On PC side enable TX at all times.
Use a 120R terminator on each end of each pair.
Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.

On the device side use separate RS485 RX and TX, enable TX only when replying (and turn off AFTER the stop bit).

Use Hi-Z RS485 chips, they can handle multi drop up to 256 connections.

Worked perfectly, even with up to 5V ground differences.
Tested in production environment, CRC error counters stayed zero.

Arie

onsdag den 2. november 2022 kl. 12.34.03 UTC+1 skrev Arie de Muijnck:
> On 2022-11-02 06:30, Ricky 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. 
> >
> I've built test systems like that, without any PC master timing problems. 
> 
> Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX. 
> Use independent RX and TX. On PC side enable TX at all times. 
> Use a 120R terminator on each end of each pair. 
> Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle. 

which is basically RS-442

On 2022-11-02 13:05, Lasse Langwadt Christensen wrote:

> onsdag den 2. november 2022 kl. 12.34.03 UTC+1 skrev Arie de Muijnck:>> I've built test systems like that, without any PC master timing problems.>>>> Use a 2-pair RS485 bus, one pair for PC TX, one for PC RX.>> Use independent RX and TX. On PC side enable TX at all times.>> Use a 120R terminator on each end of each pair.>> Use one 560R pull-up and 560R pull-down on the RX pair to keep the RX bus noise-free when idle.> > which is basically RS-442> 
If you meant RS-422: no, that has no three-state so cannot be used for multi-drop.
The two-pair topology is indeed like RS-422 but made multi-slave with RS-485 drivers.

Arie

On Wednesday, November 2, 2022 at 4:06:52 AM UTC-4, Don Y wrote:
> On 11/1/2022 11:25 PM, whit3rd wrote: 
> > Apple's old (1980's) LocalTalk scheme does this, using RS-422 style 
> > transceivers and transformer coupling. You can get Keyspan balanced-pair 
> > USB/serial ports and (used to be) PhoneNet transformer boxes off-the-shelf 
> > to use telco-style twisted pair wiring. For short spans, not even 
> > twisted.
> Yeah, but they were klunky -- especially by today's standards. 
> Like running orange hose would be! :> [Sheesh! It's mind-boggling 
> to consider the changes that we've just taken for granted!]
> > But, to get speed, you need an MSI serial port as smart as the Z8530 was to 
> > do the encoding/decoding for the transformer coupling to work. With simple 
> > paired wire (no transformers) your protocol would still need a 
> > high-impedance state for the transceivers.
> Or, a dominant/recessive configuration that the protocol can 
> examine to ascertain if active, or not.
> > That's why open-collector and I2C and its brethren are usually used.
> It would seem that CAN would be the off-the-shelf solution 
> all the way up *into* the PC/controller. With CAN-enabled 
> MCU's readily available and "volume" markets like automotive 
> driving their development, rolling your own seems like an 
> exercise in futility. 
> 
> [Unless, of course, your operating environment is far WORSE than 
> that of a motor-vehicle!]

Where would the CAN enabled MCU go???  There are no MCUs in this design and I'm looking for lowest effort here.  I'm not adding anything more than was is required.  I think an RS-422 chip is a lot simpler than CAN bus. 

-- 

Rick C.

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

On Wednesday, November 2, 2022 at 4:18:07 AM UTC-4, Jan Panteltje wrote:
> On a sunny day (Wed, 2 Nov 2022 01:00:43 -0700 (PDT)) it happened Ricky 
> <gnuarm.del...@gmail.com> wrote in 
> <2824b7ce-7727-4dcb...@googlegroups.com>:
> >Why would I want to fuss with all that programming? I've got enough on my plate 
> >as it is.
> mmm
> >That's just what I need, buggy eBay crap devices.
> Well I have many, all work. 
> I did have not working chips from ebay on occasion, got a refund. 
> Bad connectors too.
> >By the time I'm done, this test fixture may be more work than the respin of 
> >the daughter card.
> I have used euro card racks, big projects, no problems. 
> 
> Have fun :-)

I'm only using Eurocard for the size and mechanical details.  I wish I knew more about the details.  There seems to be a lot of hardware to support it, but I'm not sure which bits I need and which I don't or even what bits are out there.  

-- 

Rick C.

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

On Wednesday, November 2, 2022 at 5:09:00 AM UTC-4, whit3rd wrote:
> On Wednesday, November 2, 2022 at 12:34:52 AM UTC-7, Ricky wrote: 
> > On Wednesday, November 2, 2022 at 2:25:53 AM UTC-4, whit3rd wrote: 
> > > On Tuesday, November 1, 2022 at 10:31:03 PM UTC-7, Ricky 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. 
> > > Apple's old (1980's) LocalTalk scheme does this, using RS-422 style transceivers and transformer coupling. 
> > > You can get Keyspan balanced-pair USB/serial ports and (used to be) PhoneNet transformer boxes off-the-shelf to use telco-style twisted 
> > > pair wiring. For short spans, not even twisted. 
> > > 
> > > But, to get speed, you need an MSI serial port as smart as the Z8530 was to do the encoding/decoding for 
> > > the transformer coupling to work. With simple paired wire (no transformers) your protocol would still need 
> > > a high-impedance state for the transceivers. 
> > > 
> > > That's why open-collector and I2C and its brethren are usually used. 
> > I2C is slow. Isn't the fast version only 400 kbps? Besides, that's not generally used off board. The whole reason for worrying about this is because the boards are in a rack, but not with a "proper" back plane and the PC controlling it is a few feet of cable away. 
> > 
> > Better to use the RS-422, but transformer coupling is overkill. That would be useful when the devices are plugged into different outlets in different rooms, perhaps, to deal with more pronounced ground issues.
> The LocalTalk transmitters (AM26LS31) were RS-422 compliant, with high-Z enables on each (four drivers 
> per chip). They'll drive a twisted-pair backbone, with 110 ohm terminations on each end. If you're sure 
> rack boards only talk to the host, and listen to the host, then... yeah, you can chain all slaves to listen on pair 1, 
> and talk on pair 2, but the master to talk on pair 1 and listen on pair 2. But, the wiring has to be 
> in series (master and two terminators, slave 1, slave 2, ... slave N, and two terminators) . 
> Heck, Cat5 has four pairs, you could U-turn at the end and put all the terminators at the master.

Hmmm... Cat5 cable is just what I want.  I've been thinking about various connectors, but that's the ticket!  

Unfortunately, the master is a sealed cable.  But that's ok, Cat5 cable is definitely the way to go. 

-- 

Rick C.

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

On Wednesday, November 2, 2022 at 6:12:19 AM UTC-4, Clive Arthur wrote:
> On 02/11/2022 05:30, Ricky 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.
> <snip> 
> 
> I've done similar, though with many fewer nodes, simply by paralleling 
> the RS232 inputs and diode oring the outputs. I imagine you might need 
> to buffer your PC output and maybe not expect very high speeds. 

I believe most such transceivers are rated to drive up to 32 loads.  I guess that's more of a DC level thing.  The cards can be connected to buffer the signals, to reduce the capacitive loading.  This would accumulate propagation delays.  I'd need to check that out a bit. 

-- 

Rick C.

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