Electronic – Source for parts to make a BlinkM I2C bus cable? (from todbot blog)

Based on the fact that you able to communicate with one i2c sensor but not another, I would start investing the following:

Focus on reading the WHO_AM_I register because it is a simple test for reads and the answer 0x3A is fixed.

• Check that the slave's I2C address matches the hardware, i.e. is the pin SA0 pulled high or low? Are you using the slave address 0x1C or 0x1D?
• Check that you are terminating your reads with NACK. A master's read sequence must end in a NACK according to I2C, but not all vendors care too much. IIRC Freescale does.
• Check the I2C bus length and pullups, i.e. if you have more than a few cm of cable, your pullups should be for example 1k rather than 10k. This will depend on the timing etc characteristics of the device.

I've written a blog post about I2C a while ago where I've also outlined common I2C problems and given more details: http://chipscoop.blogspot.fi/2012/08/understanding-ic-and-some-typical-uses.html

IIC is going to be problematic. You are sending a clock signal out to the remote devices and that clock signal (when it arrives) clocks back data to the master and the master reads the data by clocking it back in but the clock the master is now using bears little resemblance to the delayed clock at the sensor and the data coming back is delayed even more. This has to mean running as slow as you can get away with.

Given that you have interference issues I'd suggest running clock and data down coaxial cables - at least try it to see if it helps - it won't help the data be more aligned to the clock at the master but it might stop interference giving you a hard time.

I had to send SPI bus to a remote device at 10m - data was being sent from the master only so both clock and data were properly aligned (cable length same distance) - I was using 2MHz clock but I decided that the only way it would work reliably was with differential drivers and receivers on both clock and data. It worked of course and I might have got away with coax but I'm sure regular unshielded cable and single-ended data and clock wouldn't work reliably.