HelloI was trying to look at the I2C bus. I downloaded the master and slave sketches from the tutorials and adapted a "poor man's person's oscilloscope" Processing sketch I found on the internet to have two traces. The arduino part is:

Although the "scope" does appear to draw what is finds on the bus it seems to be way too slow to get the I2C signals or it is losing messages. I am not sure which. The signals are both just permanently high with an occasional (extremely) brief dip.

Hi CrossraodsThanks for the reply. I am running the master writer slave reader sketches on two Arduinos from

http://arduino.cc/en/Tutorial/MasterWriter

I have my Arduino no1 with the above sketch connected to the I2C bus along with them. The slave reader is receiving the information as it is printing it on a serial monitor on another serial port so the bus is definitely active.

As regards your comment about 100kHz or 400Khz does that mean I cannot slow it down by setting TWI_FREQ to 100L?

To capture I2C a logic analyser would be better. Here is my simple attempt at a single channel device using an UNO & processing. I was thinking of updating it to 2 channels but lack of interest means it's not a priority ATM.

Your sketch looks very useful. It seems to approach the problem in a dfferent way, reporting changes rather than using samples so there are less messages. I may update what I have to do a similar thing (once I have worked out how). I have never used interrupts so it will be a good learning experience.I had seem the SUMP thread but it is way beyond my current level of knowledge as I am just a beginner.

From the datasheet: 22.5.2 Bit Rate Generator UnitThis unit controls the period of SCL when operating in a Master mode. The SCL period is controlled by settings inthe TWI Bit Rate Register (TWBR) and the Prescaler bits in the TWI Status Register (TWSR). Slave operationdoes not depend on Bit Rate or Prescaler settings, but the CPU clock frequency in the Slave must be at least 16times higher than the SCL frequency. Note that slaves may prolong the SCL low period, thereby reducing the averageTWI bus clock period. The SCL frequency is generated according to the following equation:

This little tool is great for looking at this kind of thing:http://www.saleae.com/logic

Shows you the signals, can make fine time measurements, and it also decodes the bursts of data to show the byte being transmitted with every burst.Save yourself up some money and pick one up if you can.I used mine recently to fine tune some SPI.transfer code & confirm my code was able to spit out data really fast!SPI can send data out with 8 MHz clock. 8 bits, 2 clock cycles/bit = 1uS per byte - I had 41 bytes going in 46uS, so pretty close to as fast as possible.

Thanks for this, robtillaart. I think it would be much quicker to do it this way and use the two relevant bits in the port C register as I do not really care about having an analogue reading. I had not thought of that. This only leaves taking care of the time axis ...Maybe I could use a timestamp in some way on the Arduino or Processing as I won't have a regular supply of samples?Thanks againMrs Z.

The speed of 100kHz is fixed in the Wire library, and it is used in the Wire.begin() function. It is passed to the twi.c file which sets the TWBR register.

The TWBR register can be set faster and slower.It is a 8-bits register and it is default 72.The value of 72 makes it easy to change the speed without the need to change the prescaler.A value of 255 makes it three and a half times slower.A value of 18 makes it four times faster.

Thank you everyone for the help. After much experimentation using ports and all sorts, I now think I see the problem. My processing sketch refreshes the screen at 60Hz. The I2C bus runs at 100kHz. Even at one third of the speed (thanks for this Erdin - I was using the wrong variable) there is no chance of monitoring the bus in real time and being able to see what is going on. The best I could hope for would be to capture some data for half a second and plot it later.