You can read this, http://playground.arduino.cc/Main/I2CBi-directionalLevelShifter

There are no pull-up resistors for the I2C bus.However, the internal pull-up resistors of the Arduino microcontroller are enabled in the library.They are a lot more than 10k (About 20k...50k, it depends on the microcontroller), but with a slow I2C bus they are (barely) enough to make the I2C work.You can alter the library, or disable them after the Wire.begin() function.

You can read this, http://playground.arduino.cc/Main/I2CBi-directionalLevelShifter

There are no pull-up resistors for the I2C bus.However, the internal pull-up resistors of the Arduino microcontroller are enabled in the library.They are a lot more than 10k (About 20k...50k, it depends on the microcontroller), but with a slow I2C bus they are (barely) enough to make the I2C work.You can alter the library, or disable them after the Wire.begin() function.

Ahhh, they are internal to the microcontroller chip itself. But they can be disabled; I'll check out the documentation. Because the device I'm sending data to has 4K7 resistors to 5 V, maybe disabling the internal ones will help with comms problems.

I don't think so.The 20k...50k will be no problem.The 4k7 is the right value, it should work.

Perhaps you have a few breakout boards with pull-up resistors on every breakout board, the total pull-up could be below 1k. That would be too low.

Perhaps you have long wires, say more than 50cm, and they are close to each other, that could be a problem.

Perhaps the decoupling is not good. The I2C device should have 100nF for the supply voltage.

Perhaps you use a breadboard. They don't make good contact a lot of times.

The I2C lines drive only one module. They are individual wires about 15 cm long each. They connect the UNO's A4 and A5 pins to the module. The module has both 4.7uf and 0.01 uf caps from the power supply to ground. Power is supplied from the UNO board.

I DO use a solderless breadboard. I suppose I could move the connections along the board, and I'll do that.I have talked to several others about this problem, but they seem unable to tell me HOW to find the trouble, and so they drop off the thread.I thought the problem might be the actual data values being sent, but the tests do not fail consistently. Its a very peculiar problem.

That seems all good, except the breadboard.So many people have bad connections with breadboards.

What I2C chip are you using ?What is your code ?

I've moved the module on the breadboard, but there is no change.The manual and chip datasheet can be found here: (http://www.gravitech.us/i2c1kto68pro.html)The schematic is attached. The manufacturer replaced the switches with solder bridges: OE on, Address 0x2E, I2C pullups enabled. Power LED enabled.The module is sent two bytes of data that correspond to a frequency that the LTC6904 chip must produce. The data format is stated in the datasheet.The sketch is attached. Error codes often occur: 2- address error, 3- Data error, 4- Other error, but sometimes things work. Especially when I download the sketch and then power down the UNO and the module, .....but not always.

The problem is simply that sometimes the module's output frequency doesn't change.

That code will only set the modules output frequency to one value once per run only. Therefore if you run the code again it will not change. Only when you power it down will it change.

Quote

but sometimes things work.

That points to decoupling problems. Where are the output wires going to? Maybe this is causing interference that is being picked up. I would add extra decoupling capacitors to the supply.

Mike... Another almost identical program sets it to the lowest frequency. High=0x00 and Low=0x00. Even if you send the same code, Wire.endTransmission()should not return an error.The output wire - the CLK signal - goes to the scope only. Its about an inch long. In fact all the wires (there is no CLK~ or OE wire) from the board go to the breadboard and they are also about an inch long. For this current situation, the supply is the UNO board itself, and the module has 4.7uf and 0.01uf caps from the supply to ground, on board. What size cap must be applied in addition and where? All components are surface-mount technology.

I would check that the pull ups are actually enabled as that could cause those sorts of problems as well.I would use a large capacitor across the supply at the module end. Start with 47uF and work up to 1000uF.The other thing that could cause this is the I2C clock geeing too fast but I don't see how that can be the case.Can you examin the waveforms on a scope?

I would check that the pull ups are actually enabled as that could cause those sorts of problems as well.I would use a large capacitor across the supply at the module end. Start with 47uF and work up to 1000uF.The other thing that could cause this is the I2C clock geeing too fast but I don't see how that can be the case.Can you examin the waveforms on a scope?

To Grumpy_Mike.I refloated the solder bridges for the pull-ups. SDA and SCL look good on the scope: 0V-5V swings for both. I tried the I2C address scan. It recognized two addresses: 0x17 and 0x7E. Now 0x17=(0x2E>>1). This is the address of the module. I have no idea what 0x7E might mean.The program reports no errors.I tried 3 caps from +5V to ground at the module wires, but the scanner reports the same addresses.

Welli am running out of ideas. Any chance of posting a photo of your setup?

here are some photos:1 of the set-up. I can't get closer and stay in focus.1 of the wave forms while the scanner sketch is running.

Just a note: The scanner sketch miss-reports the device address. Normally the device address is shifted right one bit before passing it to the Wire.beginTransmission(address) method. The Wire lib then shifts it left with 1 for a read, or 0 for a write before sending it out.:----------------see twi.c, line 144: // build sla+w, slave device address + w bit twi_slarw = TW_READ; //TW_READ=1 twi_slarw |= address << 1; //twi_slarw=twi_slarw ! (address<<1)------------------The passing program keeps the unshifted address. Ex: -------------const byte i2cAddress =(0x2E >>1); // Wire lib shifts back left for IO;...Wire.beginTransmission(i2cAddress);------------------------------However, the scanner sketch passes raw unshifted address. So for the reported 0x17, Wire believes it to be 0x2E. For 0x7E, its 0x2F. These are the proper read and write addresses for the module. Once the sketch is corrected the correct addresses are reported. See the attachment.