Go Down

Topic: I2C fails Using UNO and LTC6904 module (Read 1 time) previous topic - next topic

louarnold

Feb 13, 2013, 10:55 pm Last Edit: Feb 13, 2013, 11:30 pm by louarnold Reason: 1
This problem occurs with the Arduino UNO and a oscillator module I2C-OSC. I2C is used to send a two-byte count to the oscillator module. The count controls the output frequency. At times the count does not seem to get to the module.

The included program sends the maximum count to the module, then delays for several seconds, and then sends the minimum count to the module. The max count is often set successfully, but the min count is not. I have to power the module down and up and then push the UNO reset button to change from the max count. Sometimes the oscillator output is shutdown altogether.

Wire.endTransmission() returns: 2=NACK on address transmission, 3=NACK on data transmission, and 4=Other Error, with the NACK on data transmission being more frequent. With the 2 changes, the results are in pairs: sometimes 4 and 2, and 2 and 3. Sometimes 2 is the only error response.
How does one diagnose this?

On the other hand, The 2nd attached programs (I2C_OSCDecimalFreqSetter.ino) never shows an I2C error

Documentation:
See http://www.gravitech.us/i2c1kto68pro.html
and find the User Manual and data sheet for the LTC6904 chip on which the module is based.
The data format is described in the data sheet.
I have attached the Arduino program that I'm using to test the set-up, and the schematic for the module itself.
I'm using the Arduino 1.0.1 IDE.
I have an oscilloscope.

Nick Gammon

What is the debugging output from the sketch that works?
http://www.gammon.com.au/electronics

Nick Gammon

Quote
Power Supply Bypass

In order to obtain the accuracies represented in this datasheet, it is necessary to provide excellent bypass on the power supply. Adequate bypass is a 1?F capacitor in parallel with a 0.01?F capacitor connected within a few millimeters of the power supply leads.


Do you have those components installed?
http://www.gammon.com.au/electronics

pylon

Are the pull-ups on the I2C-OSC module enabled (they have switches in the schematics).

louarnold

#4
Feb 14, 2013, 11:49 pm Last Edit: Feb 14, 2013, 11:56 pm by louarnold Reason: 1
@ Nick Gammon
The debug output from the I2C_OSCDecimalFreqSetter.ino sketch is:
18.0490
42
88
The first is the frequency to set and the next two are the high (first) and low (second) bytes sent to the module. The frequency is set in the program, and the two bytes are calculated from that frequency. The scope measures a frequency of 18.0053 KHz. Once the program is the UNO, you can press the reset button any time and you won't get an error output from the program.

The module gets its power from the UNO board. The filtering shown on the schematic exists on the module's PCB. I think the problem is more with I2C than hardware. I have problems changing the frequency, but once set the frequency is stable and accurate.

@pylon:
I bought the board already assembled. The schematic shows switches but they are, in fact, soldered:
- OE Enabled.
- Pull-up resistors as on the schematic.
- ADR=GND => I2C address is 0x2E.
- Green power-on LED enabled.


Nick Gammon

I'm just wondering if 0xFF and 0xFE (from your other debugging) is out of range for the device.
http://www.gammon.com.au/electronics

louarnold


I'm just wondering if 0xFF and 0xFE (from your other debugging) is out of range for the device.

I tried a slightly modified "I2C_OSCDecimalFreqSetter" sketch that sends out only FF and FE, the count for 68MHz. When all went well, the scope showed a frequency of 67.3MHz. When it failed, it gave a Wire.endTransmission() error of 3 or 4.

Nick Gammon

So the frequency is influencing the results?
http://www.gammon.com.au/electronics

louarnold


So the frequency is influencing the results?

Hmmmm. You chose wording that implies that the oscillator frequency affects the success of I2C; that the frequency interferes with the I2C communication. I don't know how to respond to that.

I guess I can freq hop to see at what point the interference starts, but once achieved, how does one shield the low-freq side from the hi-side. The board is quite small and so those two sides are in close proximity. Is the solution to connect the output to coax? The output will handle only a 15 pf capacitive load.

Nick Gammon

The original (working) sketch does one frequency change. Yours does two. The working sketch seems to select a different frequency to the problem sketch.

I am hypothesizing that either the second change, or the different frequency, is causing problems.
http://www.gammon.com.au/electronics

louarnold

#10
Feb 16, 2013, 07:52 am Last Edit: Feb 16, 2013, 08:07 am by louarnold Reason: 1

The original (working) sketch does one frequency change. Yours does two. The working sketch seems to select a different frequency to the problem sketch.

I am hypothesizing that either the second change, or the different frequency, is causing problems.
The problem sketch is only the attached one now. It sets one frequency - 68MHz - and then generates errors when trying to set the same frequency thereafter. Although I thought the problem was only with I2C, we have now enlarged the problem to include RF interference, but have yet to definitively prove its cause. How do I do that?

Another trial: I had the attached program send out 00 00. The frequency changed to 63MHz without an error, and repeated settings to the same count caused Error 2. The frequency remained at 63MHz.

BTW: the ".ino" files can be opened by a text editor; one doesn't need the Arduino IDE.

louarnold

Well..I still don't know what to do with these problems. How do I prove which is causing the problem?

Go Up