Breakout box to test custom instrumentation cables

[Tinkerer_Automotive]

Hello,

I've been tasked at work to design a breakout box to test our "custom" instrumentation cables, essentially test the continuity of the pins, whilst being able to identify if a pin has lost connection (i.e. wire broken).

We have two groups of cables, the ones that connect in the sensor's side and the ones that connect in the logger side, additionally we have extension leads which sandwich in between both cables in case we need to cover more distance between test equipment and DAQ.

For the sensor side cables we have 4 different models, they all have unique connector on one side (to cover the different sensors we have), and the connector on the other side is common (our chosen "standard" department connector).

For the logger side cables we have 4 different cables, one for each kind of logger we use. The other connector is communised in all 4 cables, which is the opposite gender to the common connector in the sensor cables.

The connector with the highest number of pins for the sensor cables is 7 pins. And for the logger cables is 14 pin.

So the idea is to have 4 fly leads with the opposite gender connector for each sensor cable sticking out on one side of the box. And on the other side of the box have the panel mounted opposite gender connector for the logger side cables.

Then looking at the top of the box have 7 LEDs grouped on the left and 14 LEDs grouped on the right, each LED wired to the corresponding pin of the sensor side (for the 7 LEDs) and for the logger side (14 LEDs). Then have 7 push switches wired to the corresponding 7 LEDs of the "sensor side".

Some of the instrumentation cables we plan to test, have 1, 2 or even 3 wires linked together on the "logger side" connector, hence we could have 1 pin on the sensor side giving continuity to 2 or 3 pins on the logger side. That's why I wanted to have one push switch per LED of the sensor side connected and let the circuit complete with whatever is connected on the logger side connector; but still be able to identify which LED/pin has continuity so as to diagnose possible faults in the cable.

The way I want to power the box up is with a 12V 30W power supply via a jack port.
The LEDs I've got are 12V and have the resistor already integrated in them.

Now the problem I've got which is why I'm posting this; is that I realised having all this wired internally in series won't work, because as soon as I've got 2 LEDs illuminating at once (1 of sensor side pin and 1 of logger side pin) the 12V supply is not enough.

As a first solution to avoid having to purchase different LEDs and/or power supply, I've tried to think if I can redesign the schematic to have the LEDS in parallel instead as in series connected inside the box, but I cannot get my head around of how to do it. I've been thinking all evening and cannot see the solution.

The other solution could be to just purchase another power supply, as this is only £15 rather than getting 21 LEDS which costed £180. Would a power supply of say 48V work? And then just add resistors in series with the LEDS where needed ? So that I can keep the LEDs I've got, and resistors should be "cheap".

If someone could please help me to come with a solution of either redesigning to a parallel circuit if it is possible. Or just changing the power supply and adjusting/limiting the current with the resistors.

As last resort I suppose I could go back to the drawing board and think of a way to do it all with an Arduino and a screen, which would look pretty cool, but obviously is a lot of work and would need guidance from you too.

Thanks and any help is much appreciated.
Roman

 

[For The Popcorn]

You might think about something like this. Use two MCP23017 port expanders, which have 16 i/o pins. One of the chips would be set for outputs, the other as inputs. A cable would be connected between the two chips using adapter cables.

Each input bit would be asserted in turn and the output bits checked for the proper response. This would check for both proper connections and shorts.

I would output the results to a PC via a USB - UART adapter. This would allow a map to be generated and rapid automated testing.

The schematic is a quick draft but it should illustrate the concept.

Thinking a bit more, I'd add 10k pulldown resistors to all lines, and check all non-active outputs and inputs for high levels.

 

[Tinkerer_Automotive]

Thanks for the information.
The idea is that even a technician without a PC should be able to test the cables. So I would probably use a LCD screen with the Arduino to show the results of the checks for each pin.
Would an Arduino Nano work for application?

 

[For The Popcorn]

I believe so. The MCP23017 chips use an I2C interface (up to 8 on one interface using only 2 port pins) so any Arduino supporting I2C should be up to the task.

You might consider an ESP8266 or ESP32 (both use Arduino code) to handle a graph LCD display. You might add an I2C EEPROM to hold cable configurations.

 

[aliarifat794]

Wire the LEDs in parallel. Your 12V power supply is sufficient, and since the LEDs have built-in resistors, no additional resistors are required.

 

[eTech]

What are the specs for cables?
Are the required to operate thru a specific frequency range? DC only? Resistance test?
Crosstalk test?

 

[rjenkinsgb]

I built a rough "clockwork" level cable tested some decades ago, using either 74 series TTL or 4000 series CMOS (Can't remember which).

An oscillator feeding a binary counter, running cascaded binary decoder ICs (like eg. 74LS138, 4028, 4514, 4515) from the 3rd counter output onwards.

Each output from the overall 1 of N decoder goes to a socket for one end of the cable. The other end socket connects to LEDs, each with it's own series resistor, with all those connecting to a common load resistor.

A pair of comparators monitors the voltage across that common resistor. If it's above or below that caused by a single LED being on, the output is active.

That's gated with the state of the first two counter bits, and if the comparator is set when it reaches state "10" state, so after settling time but before the rest of the (main decode) counter bits change, the oscillator is blocked.

The counter that feeds the main decoder is left at the first number wire that has a fault, if there is one. That could have it's own display, either binary or decoded to a readable number.

Otherwise it just cycles endlessly if no fault is detected.

(That's as best I remember it, it was around 1980).

If you want to check different pin count cables, you could take a counter reset from the first unused decoded output.