HDMI Breakout (instead of Ribbon cable?)

I have a project on the go where I need to send 18 digital outputs and 18 digital inputs (twice, so 36 of each), and to a different location 30 of each (so 60 more), plus a few analogs (it's a series of ir beams for a racing system). In total I have >100 inputs/outputs in 3 locations.

I worry about using ribbon cables in a high traffic area. I can use Rj45 breakouts, but that still has me sending a large number of cables to each location. Runs of perhaps 15 feet from a central controller.

Can I use HDMI? I haven't found an HDMI breakout yet, but I guess I could fab one. HDMI-B has 29 connectors, which would be phenomenal. If I understand correctly, it's a low-voltage/amp wire, but if all I'm sending is a base current for digital high/low (and ramping it up with transistors to drive leds/photodiodes), would that work?

If not, any other suggestions for high-density cabling? Any other way to breakout DVI/SCART/some other 20+pin cabling?

You could multiplex the signals and send them over less wires with RJ45 (eg. I2C or SPI interfaces).

nb. You need an Arduino at each end of the wire.

fungus:
You could multiplex the signals and send them over less wires with RJ45 (eg. I2C or SPI interfaces).

nb. You need an Arduino at each end of the wire.

You don't necessarily need an Arduino at each end. You can use an IO Expander (either I2C or SPI) at the far end to act as an addressable, bi-directional shift register. I2C has a length issue (It was only designed for short runs on a PCB, at most across a backplane.) I've been thinking of developing a little module that has an RJ45 connector and an I2C buffer/driver chip (and all the support components) on small board with down-ward pointing headers for a drop-in SIP or DIP I2C "line driver" over standard CAT-5 cables. Just need to clear a few more projects out of the pipe first.

A note of caution to the OP:
Depending on how far your runs are, you may run into problems using a cable like HDMI. Not only finding them on the market long enough, but even if you make your own wire gauge is very important. Most HDMI cables are designed for short runs (around a room) so have fine wires inside the cable to keep the cable bulk down. On long runs the resistance of the wire starts becoming significant and will attenuate your signals. On the idea of networking (and this will require an Arduino at every end point), why not use Ethernet? This way, with the proper APs and antennas, you can run very long distances w/o any wires. But that number of Arduinos with Ethernet (either built in or on a shield) might potentially break your budget, not to mention the supporting networking hardware... But (especially if) the network already exists, with a sufficiently deep budget to put an Arduino at each point with either one master control Arduino or a master control computer, you can take over your little corner of the world. ]:slight_smile: And it expandable! ]:smiley:

The budget's not as much of a concern, as is additional complexity/troubleshooting. I can ebay megas for $20 each, which is fine at least at this prototype stage.

Already, I have an 2 arduino megas (1 in each lane), each with a centipede shield. I have a mega as a main controller. I have an uno running the scoreboard. And I have a wireless judge's remote.

Adding another 2 MCs worries me a bit.

I have a 50' hdmi cable at home and it's fairly heavy gauge. As I do more research, of my cited examples it appears that DVI is my likely best bet. I guess my question is more elementary: Is there any magic about HDMI/DVI/etc? I know they're fancy digital, and incorporate HTCP and all that, but in the end is it still nothing more than a bunch of copper pins pinning out nicely on both ends? I'm tempted to just pick up a cheap DVI, cut off both ends, and experiment with a batterypack/resister+led.

dirtyharry2:
I guess my question is more elementary: Is there any magic about HDMI/DVI/etc?

Copper wire is copper wire.

fungus:

dirtyharry2:
I guess my question is more elementary: Is there any magic about HDMI/DVI/etc?

Copper wire is copper wire.

Well, there may be differences in the layup inside the cable. Which pairs are twisted, how many twists per inch, which wires are next to other wires, etc. All these thing effect things like characteristic impedance and cross-talk. While I know these things exists, I don't know enough engineering to know what effects he is going to have to watch out for with his application, nor do I know the specifics of the layup of the cables he is asking about.
So, yes, copper wire is copper wire but the arrangement also matters, particularly for high-speed digital data with the high speed rail-to-rail transitions and short pulse widths.

Sembazuru:
Well, there may be differences in the layup inside the cable. Which pairs are twisted, how many twists per inch, which wires are next to other wires, etc. All these thing effect things like characteristic impedance and cross-talk. While I know these things exists, I don't know enough engineering to know what effects he is going to have to watch out for with his application, nor do I know the specifics of the layup of the cables he is asking about.

I just googled it. It uses twisted pairs with individual shielding. The main difference between Cat.1 cables and Cat.2 cables is wire gauge (24 vs. 28).

Maybe the four main twisted pairs would make a good SPI interface. :slight_smile: I bet you can get cable with four twisted pairs cheaper than HDMI though.

For 36 separate signals you're going to need a lot of HDMI cables.

characteristic impedance and cross-talk. While I know these things exists, I don't know enough engineering to know what effects he is going to have to watch out for with his application, nor do I know the specifics of the layup of the cables he is asking about.
So, yes, copper wire is copper wire but the arrangement also matters, particularly for high-speed digital data

I've come to accept I'll need to have devoted decent cabling to run the 4 Sharp IR sensors per lane. They have enough problems with noise, and they're analog. But that's comparatively few wires so less of a concern.

For 36 separate signals you're going to need a lot of HDMI cables.

Why? That was my point. HDMI-B (although I've decided DVI is better as it has more pins, if the idea works at all) has ~30 pins. 30 pins = 30 wires, = 30 arduino pins.

All I care about is having the Arduino being able to read a TON of digitalhigh/low 5v signals at ~15-20feet from IR photodiodes. The sheer number of signals sought is what's causing me cabling problems, given that this is an installation that will be setup/taken down repeatedly, and by people who aren't me.

Should I just strip the jackets off a bunch of RJ45 and then heatshrink them together? Can I somehow wrap 30pin ribbon cable into a useeable round formfactor?

Any other suggestions for "one cable, many sensors"?

dirtyharry2:
30 pins = 30 wires, = 30 arduino pins.

You're going to need a ground wire as well. 30 wires = 29 Arduino pins.

dirtyharry2:
Should I just strip the jackets off a bunch of RJ45 and then heatshrink them together? Can I somehow wrap 30pin ribbon cable into a useeable round formfactor?

Why strip it?

dirtyharry2:
Any other suggestions for "one cable, many sensors"?

You don't say how often your sensors change (bandwidth), how accurate the timing needs to be (latency), etc. So it's hard to help.

For few wires you can send the data serially over (eg.) SPI. You only need five wires for that and you can send as much data as you want. The number of sensors doesn't matter.

If that's too geeky, try the HDMI cable. It will probably work, 15 feet isn't really very far.

why strip it?

Just thought I'd be able to reduce cable bulk. 5 cat5 bundled together is thick and messy, and a huge amount of that bulk is the outer shielding.

bandwidth/latency is a different issue. Each mega is checking around 20-30 digital sensors/ms (and choosing which 20 to be sampling each ms based on which section of the course I now have dogs in). Once a photodiode reads low once, it won't likely read low again for between a few ms (worst case on only one particular pair) and ~2s (most photodiodes)

If I have time this weekend I'll give DVI a test with some leds.

dirtyharry2:
bandwidth/latency is a different issue. Each mega is checking around 20-30 digital sensors/ms (and choosing which 20 to be sampling each ms based on which section of the course I now have dogs in).

Millisecond accuracy? Unlikely to be a problem.

dirtyharry2:

why strip it?

Just thought I'd be able to reduce cable bulk. 5 cat5 bundled together is thick and messy, and a huge amount of that bulk is the outer shielding.

Well, before doing that to poor innocent cat5 cable, it seems you aren't phased by putting your own connectors on the ends. You might want to look at bulk multiconductor cable. For reference, this is what DigiKey has in stock (any where from 2 conductor to 50pairs):
http://www.digikey.com/product-search/en/cables-wires/multiple-conductor-cables/1638739?k=cables&stock=1

It is a bit fiddly to work with, but "round ribbon" cable is (or at least was back in the '90s) available. I've seen round ribbon up to 50 conductors for attaching 50-pin IDC connectors to for SCSI.

Choose your connectors well to avoid accidental plugging something in wrong as well for durability, especially if other people will be working with them.

bandwidth/latency is a different issue. Each mega is checking around 20-30 digital sensors/ms (and choosing which 20 to be sampling each ms based on which section of the course I now have dogs in). Once a photodiode reads low once, it won't likely read low again for between a few ms (worst case on only one particular pair) and ~2s (most photodiodes)

Well, for discretely wired photodiodes, the bandwidth wouldn't be how often you poll them, but how often they switch. A "few ms" really doesn't sound that quick to me. But, what causes most noise with digital signals is the ringing once a new state is reached. The faster the transition, the worse the ringing (usually). Unless you have really highly spec'ed photodiodes, the transition speed probably isn't enough to cause significant ringing. For your application, KISS tells me that you might be on the right track with discrete wires for the photo diodes. I don't know how you have things laid out, but I suspect each mega isn't sensing a cluster of 20-30 photodiodes in one place. I suspect you have the photodiodes strung out along the side of each segment of track, right? Maybe you can get away with multiple cables going to smaller clusters of photodiodes (say 5 for ease of counting). A single cat5 (cheap, easily available, many lengths available, easy to make custom lengths) would handle 5 of them no problem (+Vcc, GND, 5 signals, 1 spare for whatever). I'd also probably run the photodiodes at a higher voltage than +5VDC (maybe +12VDC?) to extend the length of cable you can use before the cable length attenuates the signal. Then near each mega (ideally in the same housing) you would have a bunch of RJ45 receptacles and the circuitry to translate a more than +5VDC signal to something that is safe for the +5VDC inputs of the mega (I'd even future proof it to be able to also translate down to +3.3VDC in case a Due is ever used where you are using the megas).

Reviewing earlier posts, I see you already threw out the idea of multiple cat5's. I left the above just so you could see where I was originally going with it... And you are using a centipede shield. I just checked what those are, and I'm not sure if they are compatible with the Due... But, because the analog inputs of the mega (and most if not all of the analog inputs of the due) can be used as digital I/O, I'm not sure if the centipede shields are necessary. Both already have 54 digital I/O (call it 52 to reserve D0 and D1 for the serial port for troubleshooting) so you would only need to use 12 of the analogs for digital I/O to replicate the centipede shields. (Not sure what else you want plugged in tho.) The centipede shields are actually doing what I had mentioned earlier with I/O extenders (just locally instead of remotely).

Without sketches or diagrams of the full layout (where individual sensors are, what type of sensors they are, where Arduinos are planned to be, etc), it is difficult to help advise here for both KISS and reliability.

How are the various Arduinos communicating to each other (or to the master Arduino)?

Thanks for the help :slight_smile:

My layout is Scoreboard XXX XXX XXXXXAA
YYY YYY YYYYYAA

where each lane has "light gates" setup in 3 locations on the track. In this "schematic" the Ys would be the photodiode, and the X's are IR-Leds lensed to the photodiode accross the 3' track. Groups of 3 allow me to calculate things like velocity and acceleration at various points. The group of 5 is the startline (it' dog racing; they start, do the run and "boxturn" and get a ball, and return, passing nose-to-nose with dog 2/3/4. If any start or pass is early, it's a fault and the run doesn't count. The course is 55' (so a run is 110')

As I don't know how tall any given dog is, each X/Y consists of pairs at 6 different heights (every 4" from 4"-24"). I can get away with running a flat cat-5 from the X-Y under the mat. I don't want to leave the IRLEDS on all the time, just for safety reasons as well as battery power. So yes, I'll be sampling 18/ms most of the time, and when I'm around the startline it'll be 30/ms + some analog sampling for the rangefinders (which I'll sample as often as possible, even though they only update at 20hz, to deal with analog noise/averaging).

The AA's are sharp rangefinders, going from 3'-15'. I'm analyzing how close the "pass" is between Dog A and B, as the dogs move fast enough that one will often still be covering the startline when the other approaches (nose-to-nose passes are sought and often obtained).

I haven't interfaced the two lanes yet. If anything, I'm thinking wired serial/softserial is fine, as I can setup a lot of the equipment between the 2 lanes, so a wired connection's fine. Generally, they don't need to have much if any connection with each other. Right now I have the lanes wired to the light-tree. I'll likely have the lanes not even have any communication with each other, but have each communicate with the light-tree, so I can get start/fault type information that way.

The light-tree (picture drag-racing red/yellow/green/GO lights), hasn't been made to scale yet, but is just a YELLOW/YELLOW/YELLOW/GREEN tower, with red toppers on each side for displaying a fault indicator.

At the end of each lane is a scoreboard. I've found 7" single digit 7 segments, and will use those (it needs visible at ~100'). I'm thinking a simple RF will be fine. Very little data sent to that unit (so it'll be an uno or less). A board for each lane, 5 digits and a fault indicator. A slightly smaller board with 3 digits for showing pass-times.

At one side of the lanes is the "controller". It's got an SD shield and handles all the data crunching. Knows from a database which dogs are running, in which position, and keeps track of all the relevant data from their run, for later analysis. That one will have the real UI on it. It'll be the last part of my project to hit fruition.

The multiconnector wires are new to me and look promising. Additionally, I kept thinking, and came up with DB25 (parallel, basically old printer cables) which seem like they might work very well, and there's breakout boards already on ebay for like $3.00 each. I'll likely run DB25 to each "set", and then a cat5 to each singleton (I want to keep components hot-swappable as much as possible, so if for example an led burns out during a tournament, it can be easily remedied).

I need millisecond timing, and consistent, so I'm using a Chronodot temperature-compensated RTC.

As each lane has a minimum of 4A and 66digital inputs to be read, plus outputs for all of the 66 leds (although I can power them in series in some fashion), plus the RTC and communication with the other units etc, I decided I needed a centipede, or mess around with port expanders omore directly.

It's a fairly involved project :slight_smile:

Hi,

you didn't consider to output the data to an Android tablet?
I'm working on a similar project, but with less sensors, as I don't need velocity, only the heat and race results.
I was thinking of outputting the both lanes data to the fieldcoaches android tablets.

Once the system is up and runnig, I would like to search for some mini high speed cam modules, to snap the passings with a PIR and project them to the linejudges tablets.

But for now, that's thinking to the future of the system, right now i'm just discovering the world of arduino (and I must say i like it)
I still have a whole lot to discover and learn (i'm not an ingeneer, just a freak in flyballing)

Enjoy your wonderfull project (as we say over here : measuring is knowing)

Yves,