UNO board I2C pullups? Can be enabled/disabled?

After a lot of reading: does the UNO Rev 3 board have on-board pullup resistors for the I2C lines A4 and A5; 10K from what I read?
I can't find them on the schematic.

Also can these pullups be disabled - i.e. programmatically or manually disconnect the resistors from the two lines?

You can read this, Arduino Playground - 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.

Erdin:
You can read this, Arduino Playground - 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.

Thank you.

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.

1 Like

Erdin:
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.

I have a scope and DMMs and can do some soldering.

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 ?

What exactly is the problem you are having.
Can the arduino "see" the I2C device, try an I2C scanner program to see what addresses it picks up. Often it is the address that you are using that is wrong.

Erdin:
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.

I2C_OSCHexFreqSetterHigh.ino (726 Bytes)

I2C-OSC_Schematic.pdf (25.7 KB)

Grumpy_Mike:
What exactly is the problem you are having.
Can the arduino "see" the I2C device, try an I2C scanner program to see what addresses it picks up. Often it is the address that you are using that is wrong.

The problem is simply that sometimes the module's output frequency doesn't change. There is no real pattern to the errors (2, 3, 4) in Wire.endTransmission.

As for the UNO seeing the module, one could say that it sees it sometimes and not at others. I'll try the address scan, but I don't think it will give us any more information.

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.

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.

Grumpy_Mike:

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.

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?

Grumpy_Mike:
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?

Grumpy_Mike:
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.

I2CAddressScan.png

I2CScannerV2.ino (1.69 KB)

The scanner sketch miss-reports the device address.

No it doesn't it reports the address you must use in an Arduino environment, this like many other implementations of the bus do not include the R/W bit as part of the address.
It is difficult to tell much from the photos as they are too blurred.

Were those traces from your code? The data does not look to match what you have posted as your code.

Things to try:-
The code on the module's web site.

A different I2C library

It could be you have a faulty module.

It is difficult to tell much from the photos as they are too blurred.

Can't do better, I'm afraid.

Were those traces from your code? The data does not look to match what you have posted as your code.

The traces were from the I2CScanner code. As you can tell from the code, the program puts out many addresses. The scope is triggering on the SDA trace (blue), but it could be for any address.

Things to try:-
The code on the module's web site.

Did that some time back.

A different I2C library
DssCircuits.com is for sale | HugeDomains

I'll try it.

It could be you have a faulty module.

I think that's the problem. When I first used the module, it worked fine. Then I put an 8 ohm speaker on the output. I read the manual later and it implies that the output should not be loaded at all - even the scope probe had to great an input capacity (some 100 pf). Since then its been misbehaving. But I didn't think the I2C system would be damaged.

Then I put an 8 ohm speaker on the output.

Yep that would screw it.

But I didn't think the I2C system would be damaged.

Well you never know what is going to be damaged because you don't know how the die is laid out.

Grumpy_Mike:
Well you never know what is going to be damaged because you don't know how the die is laid out.

. Yet the chip has a 10 ohm resistor at the output, and the manual's cautionary note was for good waveforms at high frequency ... but after trying the decoupling, I can think of no other reason.

Just as a follow up:
I obtained a few samples of the LTC6904 chip and wired one up to the UNO in the same way as the module was. The changes in frequency are more reliable than with the 1st chip, but that reliability goes down with the greater frequency coming out of the chip. Changes in low frequency, say in the range of 200 KHz appear the work just fine; in the range of 60 MHz, the change attempts often cause I2C errors.

In addition, the new chip seems to have a much higher frequency jitter at its output than for the 1st chip.

I think I'm going to look for another, more reliable, chip than the LTC6904. Its a bit of a nuisance.

Thanks.