Picking a cable/connector setup for an off-board I2C sensor

[dkonigs]

So I'm working on a project where I'll have a main "device" that contains the microcontroller, display, and most of the guts. However, attached to this device via a cable, will be a small "sensor pod."  The sensor pod is likely to contain an I2C sensor of some sort, a button (to trigger a sensor reading), and not much else.  The cable for this attachment is likely to be no more than 1m long, though it will obviously be "external".

I expect this cable to be "captive" on the sensor pod side, plugged into some sort of socket on the "device" side, and probably needs at least 5 conductors (+V, GND, SCL, SDA, button).

That being said, I have some questions I'm trying to nail down good answers to...

• What sort of connector should I use to connect the sensor pod's cable to the main device?  I want something that won't break easily (e.g. RJ-11), and something that won't wiggle loose if the cable flops around too much. Also preferable if the socket can be PCB-mounted. Of course it would be nice if this was something relatively cheap and easily available (I'm not a cost nitpicker on this, but I've seen some fairly expensive stuff from TE out there.)
• What sort of cable should I use for this?  Shielded, unshielded, straight, twisted pair, etc.  Bonus points if I can buy a premade connector+cable assembly for the "sensor pod," as some of these things tend to not be so easy to make a quality crump on.
• The MCU and sensor are likely to be 3.3V devices. For the cable run itself, is it recommended to use I2C buffers that can run signals over that cable at 5-12V? On a similar note, is it generally a good idea to also incorporate some sort of ESD/TVS protection at the device connection point?

I hope this mult-part question made sense, and was clear enough.
Thanks.

[dkonigs]

I know I didn't get any replies on this topic, but I figured I might as well provide an update.

After a bit too much searching around, it seems like my only real connector options for this always come back to M12 or Mini-DIN. With M12 tending to see a bit too bulky and expensive, I think I've decided to go with 6-pin Mini-DIN. (Not sure if I actually need the 6th pin, but I found an optional use for it so I'll at least hook it up.)

My biggest concern with Mini-DIN was simply confusion with a PS/2 mouse/keyboard port. That being said, I've simply decided to use a similar pin-out for my cable (even if it obviously won't be compatible.)

I've also decided to run all signaling over the cable itself at 5V, converting where appropriate on either end. I'm not sure this is really necessary, but it'll hopefully keep things more stable and let me have a cleanly regulated 3.3V inside the "device."

While I'm fairly sure that I'll attempt to put some ESD/TVS protection inside the main unit where this device plugs in, I'm still not sure whether or not there's any point in adding similar protection inside the device itself. (The device itself won't be independently grounded, so all of its electrical paths will likely be through the cable.)

[l0wside]

For a similar purpose, I have used Phoenix´ PTSM series before. Neither the smallest nor the cheapest, but readily available and quite robust. Would even carry some amps if required.

[Renate]

The JST XH series of connector is my go-to for miscellaneous stuff.
http://www.jst-mfg.com/product/detail_e.php?series=277

You didn't say whether a chassis interface was necessary.
You can also just lead the cable through a gap in the case sections, with or without a grommet or strain relief.

[T3sl4co1l]

0. Don't.  I2C is terrible in between-board and off-board situations.

1. At the very least, plan on using shielded multiconductor cable, and put the shield through one or more pins of the connector, or preferably the connector shell itself.

2. What other requirements do you have?  This is very ambiguous so far.  Does it need to be IP rated (dust or water sealed)?  (Your looking at M12 might suggest so, but DIN not so much.)

What's wrong with cheap and abundant DE-9?  More pins than you need, so what, 3-wire serial is still in common use on them..

Mini-DIN will be quite compact and cheap, is shielded, and... I'm not sure if you can get any with retention clips or locks, that'd be something to look into I guess.

Even just plain old Molex SL or KK family, can be used in through-chassis application, but obviously you aren't getting anything close to IP67 with them.

3. Yes, ESD is probably a good idea (at both ends?), and filtering.  2.2k pullups, 100 to 470p cap to GND, and a ferrite bead (300 ohm or so, 0603 or bigger?) towards the cable, is recommended.  I2C is awful for off-board connections but with shielding, filtering and protection, you at least have a better chance at success.

4. If you're hard set on saving the button pin, you might do some signal abuse, like, leaving off the pull-ups on the host side, and tying them to the button on the sensor end.  So the lines are default low, until the button is pressed, pulling them up and permitting communication.  Presumably the button cannot be pressed for less time than a bus cycle takes (this can be enforced with the help of a capacitor), so when the host detects both lines going high, it tries talking.

Note: I don't recall what LL --> HH transition means to a normal I2C host, if it'll get confused by that or what -- worst case I think, you'll have to disable it, monitor the lines in software, then when it becomes available, enable and reset the controller.  And put a timeout on it, so it doesn't try and wait forever for the sensor to deliver data that it can't because the button's let go.

Another possibility is just a big fat pulldown resistor, and monitoring supply current to the sensor.  This potentially limits selection (you can't use a sensor that draws more than [threshold] mA), and puts a hard limit on maximum cable length (but even for thin wires, this should be much longer than the 1m typical length given).

A more refined method might look at fluctuations in supply current, so that an oscillator (at the sensor end) draws pulses periodically, or pumps charge back and forth through the supply; less current is consumed, and there's no absolute (DC) threshold, so that much more load current can be drawn.  Downsides: higher complexity, and the sensor itself can generate interfering signals (i.e. its current consumption probably isn't perfectly stable, but fluctuates while it works).

Probably, the cost of one measly wire isn't going to outweigh the complexity of any of these methods, and that's alright.

Tim