USB to CAN bus to TTL serial...

[Ricky]

If I were to use CAN bus on the test fixture I\'m planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.

A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I\'m not seeing this.

--

Rick C.

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

 

[Lasse Langwadt Christensen]

søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky:

If I were to use CAN bus on the test fixture I\'m planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.

A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I\'m not seeing this.

no point in using CAN if what you want it UART (over something like rs485/422)

CAN is similar to rs485 but \"ORed\" and with a fixed packet sizes, adresses,Acks, NAcks,CRC etc.

 

[Ricky]

On Sunday, November 6, 2022 at 9:48:30 AM UTC-5, lang...@fonz.dk wrote:

søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky:
If I were to use CAN bus on the test fixture I\'m planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.

A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I\'m not seeing this.

no point in using CAN if what you want it UART (over something like rs485/422)

CAN is similar to rs485 but \"ORed\" and with a fixed packet sizes, adresses,Acks, NAcks,CRC etc.

I would not care about the protocol on the CAN bus. I am assuming the interface to the PC would look like a UART. Or are the interface cards just low level hardware and the PC user code has to manage the low level protocol? By \"look like a UART\", I mean I simply pass data to an interface and receiver replies, without knowing, or caring about the details past that.

If a CAN bus interface can\'t do that, I definitely would not be interested. Even if it can do that, I would only be interested if it could provide some benefit. No one has explained what is better about CAN bus, they\'ve just said I should use it.

--

Rick C.

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

 

[Les Cargill]

Ricky wrote:

If I were to use CAN bus on the test fixture I\'m planning, I would
need a USB cable that looks like a UART to the PC. Then I would need
modules to mount on the test fixture boards that provide a UART like
TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No need
for anything else. It is both small and has a plastic housing, if that
matters.

There are others. That is just the last one I used. I used it for plant
sim with a RasPi.

A quick survey finds lots of modules with wired connectors on both
ends and units in metal boxes. I would need something that requires
zero programming of the unit itself. I\'m not seeing this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.

--
Les Cargill

 

[Ricky]

On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:

Ricky wrote:
If I were to use CAN bus on the test fixture I\'m planning, I would
need a USB cable that looks like a UART to the PC. Then I would need
modules to mount on the test fixture boards that provide a UART like
TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No need
for anything else. It is both small and has a plastic housing, if that
matters.

There are others. That is just the last one I used. I used it for plant
sim with a RasPi.
A quick survey finds lots of modules with wired connectors on both
ends and units in metal boxes. I would need something that requires
zero programming of the unit itself. I\'m not seeing this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.

The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That\'s taken care of, other than needing an interface for CAN. What is required for that?

The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that\'s all taken care of. I don\'t want to have to add anything that involves protocol of the CAN bus. That\'s why I say it needs to look like a UART to the PC. If that\'s so, I can use my existing software and not do extra work.

--

Rick C.

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

 

[Lasse Langwadt Christensen]

mandag den 21. november 2022 kl. 01.10.43 UTC+1 skrev Ricky:

On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
Ricky wrote:
If I were to use CAN bus on the test fixture I\'m planning, I would
need a USB cable that looks like a UART to the PC. Then I would need
modules to mount on the test fixture boards that provide a UART like
TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No need
for anything else. It is both small and has a plastic housing, if that
matters.

There are others. That is just the last one I used. I used it for plant
sim with a RasPi.
A quick survey finds lots of modules with wired connectors on both
ends and units in metal boxes. I would need something that requires
zero programming of the unit itself. I\'m not seeing this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.
The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That\'s taken care of, other than needing an interface for CAN. What is required for that?

The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that\'s all taken care of. I don\'t want to have to add anything that involves protocol of the CAN bus. That\'s why I say it needs to look like a UART to the PC. If that\'s so, I can use my existing software and not do extra work.

if it needs to look like a uart don\'t use CAN, use a uart

 

[Les Cargill]

Ricky wrote:

On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
Ricky wrote:
If I were to use CAN bus on the test fixture I\'m planning, I
would need a USB cable that looks like a UART to the PC. Then I
would need modules to mount on the test fixture boards that
provide a UART like TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No
need for anything else. It is both small and has a plastic housing,
if that matters.

There are others. That is just the last one I used. I used it for
plant sim with a RasPi.
A quick survey finds lots of modules with wired connectors on
both ends and units in metal boxes. I would need something that
requires zero programming of the unit itself. I\'m not seeing
this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.

The current test fixture is a single board, testing a single UUT from
a single PC. The new test fixture will have one PC talking at a rack
of test fixtures, with each one having eight UUTs. The protocol of
communications will be the same. Each message is a dozen or so
characters, including an address of the target, and the command. The
addressed target then responds with the information requested, or
simply acknowledgement of the command, again, some doze or so
characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That\'s taken care of,
other than needing an interface for CAN. What is required for that?

So at least J1939 is 29 bits of address and 16 bytes of payload. It is
not equivalent to a serial port. There will be a proprietary API to send
one PDU and to receive PDUs.

The PC has a control program which will be modified to handle the UUT
addressing. My concern is to not have to muck with programming in
regards to anything about the CAN bus. The current interface is a
simple UART, which is handled by system software and becomes two
interfaces, one for sending data and one for receiving data. Again,
that\'s all taken care of. I don\'t want to have to add anything that
involves protocol of the CAN bus.

I suspect you will have to. It\'s not like 485 or 422.

That\'s why I say it needs to look
like a UART to the PC. If that\'s so, I can use my existing software
and not do extra work.

You will need to adapt your existing commands to and onto the
proprietary API.

--
Les Cargill

 

[Ricky]

On Sunday, November 20, 2022 at 7:16:48 PM UTC-5, lang...@fonz.dk wrote:

mandag den 21. november 2022 kl. 01.10.43 UTC+1 skrev Ricky:
On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
Ricky wrote:
If I were to use CAN bus on the test fixture I\'m planning, I would
need a USB cable that looks like a UART to the PC. Then I would need
modules to mount on the test fixture boards that provide a UART like
TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No need
for anything else. It is both small and has a plastic housing, if that
matters.

There are others. That is just the last one I used. I used it for plant
sim with a RasPi.
A quick survey finds lots of modules with wired connectors on both
ends and units in metal boxes. I would need something that requires
zero programming of the unit itself. I\'m not seeing this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.
The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That\'s taken care of, other than needing an interface for CAN. What is required for that?

The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that\'s all taken care of. I don\'t want to have to add anything that involves protocol of the CAN bus. That\'s why I say it needs to look like a UART to the PC. If that\'s so, I can use my existing software and not do extra work.

if it needs to look like a uart don\'t use CAN, use a uart

What interface to the software does CAN use? I thought you were one of the people, who in another thread were suggesting I use CAN?

I just don\'t want to have to program a bunch of CAN protocol in my application. I would expect drivers to handle that. On the test fixture I would expect a chip to provide a UART on one side and CAN on the other.

This is not important. I see no reason why RS-422 or RS-485 would not be a good choice. It\'s actually the USB that presents the bottleneck from the polling rate.

--

Rick C.

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

 

[Ricky]

On Sunday, November 20, 2022 at 7:32:37 PM UTC-5, Les Cargill wrote:

Ricky wrote:
On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
Ricky wrote:
If I were to use CAN bus on the test fixture I\'m planning, I
would need a USB cable that looks like a UART to the PC. Then I
would need modules to mount on the test fixture boards that
provide a UART like TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No
need for anything else. It is both small and has a plastic housing,
if that matters.

There are others. That is just the last one I used. I used it for
plant sim with a RasPi.
A quick survey finds lots of modules with wired connectors on
both ends and units in metal boxes. I would need something that
requires zero programming of the unit itself. I\'m not seeing
this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.

The current test fixture is a single board, testing a single UUT from
a single PC. The new test fixture will have one PC talking at a rack
of test fixtures, with each one having eight UUTs. The protocol of
communications will be the same. Each message is a dozen or so
characters, including an address of the target, and the command. The
addressed target then responds with the information requested, or
simply acknowledgement of the command, again, some doze or so
characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That\'s taken care of,
other than needing an interface for CAN. What is required for that?

So at least J1939 is 29 bits of address and 16 bytes of payload. It is
not equivalent to a serial port. There will be a proprietary API to send
one PDU and to receive PDUs.
The PC has a control program which will be modified to handle the UUT
addressing. My concern is to not have to muck with programming in
regards to anything about the CAN bus. The current interface is a
simple UART, which is handled by system software and becomes two
interfaces, one for sending data and one for receiving data. Again,
that\'s all taken care of. I don\'t want to have to add anything that
involves protocol of the CAN bus.
I suspect you will have to. It\'s not like 485 or 422.
That\'s why I say it needs to look
like a UART to the PC. If that\'s so, I can use my existing software
and not do extra work.

You will need to adapt your existing commands to and onto the
proprietary API.

Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.

--

Rick C.

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

 

[server]

On Sun, 20 Nov 2022 16:34:02 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>What interface to the software does CAN use?

The CAN frame consists of two main fields:
* CAN identifier (11 or 29 bits)
* Payload (0-64 bits, 0-8 bytes)

Especially with 29 bit CAN-ID you could allocate a few bits for slave
address and a few bits for function code. In the simplest case the
interface would contain a 32 bit CAN-ID ad an 8 bit payload for both
reading and writing.

The nice thing about CAN is that the hardware does the arbitration
between frames based on the CAN-ID. Thus, you can send out broadcast
reads and collect all responses. You could also send out requests to
multiple slow devices at once and collect the responses room diff rent
devices when ready, without having to worry about collision handling.

he problem with half-duplex RS-485 is the line turnaround delays and
waiting for slave responses, which quickly degrades throughput at high
line speeds. On CAN the line mutilation can be quite high and at 1
MBit/s the throughput can be better than on RS-485 at higher speeds.

 

[Ricky]

On Monday, November 21, 2022 at 1:39:45 AM UTC-5, upsid...@downunder.com wrote:

On Sun, 20 Nov 2022 16:34:02 -0800 (PST), Ricky
gnuarm.del...@gmail.com> wrote:

What interface to the software does CAN use?
The CAN frame consists of two main fields:
* CAN identifier (11 or 29 bits)
* Payload (0-64 bits, 0-8 bytes)

Especially with 29 bit CAN-ID you could allocate a few bits for slave
address and a few bits for function code. In the simplest case the
interface would contain a 32 bit CAN-ID ad an 8 bit payload for both
reading and writing.

The nice thing about CAN is that the hardware does the arbitration
between frames based on the CAN-ID. Thus, you can send out broadcast
reads and collect all responses. You could also send out requests to
multiple slow devices at once and collect the responses room diff rent
devices when ready, without having to worry about collision handling.

he problem with half-duplex RS-485 is the line turnaround delays and
waiting for slave responses, which quickly degrades throughput at high
line speeds. On CAN the line mutilation can be quite high and at 1
MBit/s the throughput can be better than on RS-485 at higher speeds.

I have no interest in getting involved in the CAN bus protocol. To me it\'s something that needs to be invisible, a way to transport characters, in the same way I use a serial port under Windows.

Your description of RS-485 is not important to me. You have either not been part of the previous conversations where I described the use case, and some details of the hardware, or you would realize that the issues you present have no relevance to my design. The speed limitation has nothing to do with the RS-485 or RS-422 buses. The limitation is in the 8 kHz polling rate, which sets the limit on the number of messages which can be handled on the USB interface. The limit is messages, not bits or characters.

Your post presents all the reasons why I have no interest in using CAN. I don\'t want to even be aware of the messages on the CAN bus. The PC should have software that hides all that and presents a port like a COM port, in fact, it should emulate a COM port. On the slave end, I would want a chip, or better, a module that provides a CAN bus interface with a virtual UART interface on the other side, or a serial port would suffice. The FPGA already has the UART in it. BTW, there are no slow devices on the bus. Every device responds within fractions of a microsecond, depending on the baud rate setting.

Right now, the test fixture talks to the PC through an RS-232 USB cable. I\'m looking for something that can take it\'s place pretty much without software changes. So far, everyone talks about programming though an API, which is of no interest to me.

--

Rick C.

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

 

[John S]

On 11/20/2022 7:37 PM, Ricky wrote:

On Sunday, November 20, 2022 at 7:32:37 PM UTC-5, Les Cargill wrote:
Ricky wrote:
On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
Ricky wrote:
If I were to use CAN bus on the test fixture I\'m planning, I
would need a USB cable that looks like a UART to the PC. Then I
would need modules to mount on the test fixture boards that
provide a UART like TTL interface.

A Total Phase Komodo would provide a UART interface via USB. No
need for anything else. It is both small and has a plastic housing,
if that matters.

There are others. That is just the last one I used. I used it for
plant sim with a RasPi.
A quick survey finds lots of modules with wired connectors on
both ends and units in metal boxes. I would need something that
requires zero programming of the unit itself. I\'m not seeing
this.

You\'re probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a \"Wireshark\" for CAN.

But when you say \"test fixture\" I think of nodes actively
participating and that requires programming.

The current test fixture is a single board, testing a single UUT from
a single PC. The new test fixture will have one PC talking at a rack
of test fixtures, with each one having eight UUTs. The protocol of
communications will be the same. Each message is a dozen or so
characters, including an address of the target, and the command. The
addressed target then responds with the information requested, or
simply acknowledgement of the command, again, some doze or so
characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That\'s taken care of,
other than needing an interface for CAN. What is required for that?

So at least J1939 is 29 bits of address and 16 bytes of payload. It is
not equivalent to a serial port. There will be a proprietary API to send
one PDU and to receive PDUs.
The PC has a control program which will be modified to handle the UUT
addressing. My concern is to not have to muck with programming in
regards to anything about the CAN bus. The current interface is a
simple UART, which is handled by system software and becomes two
interfaces, one for sending data and one for receiving data. Again,
that\'s all taken care of. I don\'t want to have to add anything that
involves protocol of the CAN bus.
I suspect you will have to. It\'s not like 485 or 422.
That\'s why I say it needs to look
like a UART to the PC. If that\'s so, I can use my existing software
and not do extra work.

You will need to adapt your existing commands to and onto the
proprietary API.

Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.

+1

--
Dogs make me happy. Humans make my head hurt.

 

[Clive Arthur]

On 21/11/2022 00:37, Ricky wrote:

Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.

What was wrong with just diodes on the UUT Tx with a pull-down on the PC
Rx, possibly with buffering on the PC Tx?

RS232 idles -ve, and AIUI, only 1 UUT can talk at a time and they don\'t
respond if not addressed.

--
Cheers
Clive

 

[Ricky]

On Monday, November 21, 2022 at 11:48:51 AM UTC-5, Clive Arthur wrote:

On 21/11/2022 00:37, Ricky wrote:

Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.

What was wrong with just diodes on the UUT Tx with a pull-down on the PC
Rx, possibly with buffering on the PC Tx?

RS232 idles -ve, and AIUI, only 1 UUT can talk at a time and they don\'t
respond if not addressed.

This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can\'t think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that\'s not an advantage.

I had pretty well settled on an RS-422 based approach with the master the only talker on one pair, and the addressed slave replying on the other pair. Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus. The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn\'t look like that is a significant limitation.

So I\'m happy with RS-422. If I want to get fancy, I could adjust the protocol so messages can overlap, in the sense that the master can address multiple slaves without waiting for any one to respond. The slaves will need to manage their collisions, but that should not be an issue, since they can reply within a fraction of a microsecond. By the time the second slave has received a command, the first slave will be nearly finished with its reply and the second slave only needs to monitor for the end of message (/n I believe). The only problem is if there are too many overlapped at one time, multiple slaves might be waiting for the end of a response to start its own response and two start at the same time. To sort that, either some delays need to be added to the master, or the slaves need to be aware of who the master is talking to and who has replied. Too much complexity, even if it\'s not hard to make work. At 1 minute per test on 256 units, this will be around 512 times faster than a human running the tests, so I think we are good.

The real gold in this is the handling of boards are reduced. We have been plugging a board into the test fixture to test, then plug it into the burn in chassis, the the test fixture again. The connectors are pretty much crap for such use and we have a hard time training people to be gentle enough with them. On removal, the narrow board twists in the fingers, bending/braking pins on the test fixture, and breaking connectors on the UUT. Cutting the insertions and removals to one, with 1,000 tests in between, will go a long way to improving our throughput.

I think I got a bit off topic. My point is, the RS-232 approach doesn\'t seem to have any advantage over RS-422 and multi-point operation with RS-422 is well known and well established. I only was asking about CAN because a couple of people said it was a good way to go for this. Now that I have more info, I\'m not so sure.

--

Rick C.

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

 

[Clive Arthur]

On 22/11/2022 00:36, Ricky wrote:

<snip>

This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can\'t think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that\'s not an advantage.

The advantage is that you could have been up and running for the last
couple of weeks with pretty much your existing hardware AIUI. The main
disadvantage is the chance of a faulty UUT buggering up the whole deal.
Don\'t let perfect be the enemy of good.

--
Cheers
Clive

 

[Ricky]

On Tuesday, November 22, 2022 at 4:51:12 AM UTC-4, Clive Arthur wrote:

On 22/11/2022 00:36, Ricky wrote:

snip
This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can\'t think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that\'s not an advantage.

The advantage is that you could have been up and running for the last
couple of weeks with pretty much your existing hardware AIUI. The main
disadvantage is the chance of a faulty UUT buggering up the whole deal.
Don\'t let perfect be the enemy of good.

How could I have been up for the last couple of weeks? The new test fixtures aren\'t even designed yet. I\'m not sure what you are talking about with \"a faulty UUT buggering up the whole deal\"? The UUT is not on the bus. The test fixture is. The purpose of the test fixture is to test the UUTs. I expect the procedure will be to install 8 UUTs onto a test fixture, perform one round of testing to determine if any units fail. Failing units are replaced until all 8 work. Install the test fixture into the chassis. Rinse, lather, repeat, until the test chassis is fully of test fixtures with UUTs that initially pass test. They are then left to burn in over night. The next morning the results will be checked for failures. UUTs without failures will be labeled and shipped with the results of the final test saved as a record.

What are you picturing, exactly? I don\'t see how a tristated RS-232 interface is any different from an RS-422 interface except that the RS-232 interface won\'t run as fast and is not specified to actually work well, given the pull down resistor required.

What am I missing?

--

Rick C.

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