We certainly can't do anything about the order of signals on the Grove cables. These were locked and in production long before we started this project. It is possible to add a ground trace between the traces on the board, but I don't think this help much. The physical design rules for the PCB won't permit placing a ground trace between tracks where the tracks must come close to each other in the vicinity of the level shifter.
The other way to reduce cross talk is to separate the traces, the usual rule of thumb is, if the separation is 3x the trace width then the cross talk will be quite low. I haven't looked at Sophie's layout but on my board the traces are 0.254mm wide, and the spacing between pins on the level shifters is 0.60mm so the track to space ratio can only be 1.3 in the vicinity of the level shifter pins. The I2C spec does point out that cross talk is really only an issue when the traces are longer than 10cm and the traces on the board are only about 3cm so I don't think the PCB layout is the major contributing factor.
The scope traces you have attached don't make sense to me. The vertical scale says that the signals are 200mV per division, and counting the number of divisions between a low and a high I see almost three divisions. This would indicate that the signal is only 600mV, which I feel is really wrong. The signal should be one of 1.8V, 3.3V or 5.0V. Possibly you are looking at a 5V signal, then the real scale is 2V per division (you need to tell the scope you are using 10x probes so that it correctly displays the volts per division). Adjusting the vertical positions of the traces so that the yellow '1' tag is exactly on the center division, and the cyan '2' tag is exactly on the first division up makes it easier to read the voltages.
I don't think the pulse in the photo (Zoom-In-CrossTalk.BMP) is cross talk, or at least it isn't cross talk on the cable. Signals move down the cable at a velocity of about one foot per nanosecond, you have approximately 1 foot of cable (6 inches to the end, and 6 inches back) so "cross talk" should only last about 1ns. The scope shows a pulse lasting almost 50ns. I think this is more likely the pulse circuit inside the level shifter firing, of course it is firing due to the original 1ns cross talk, so all we need to do is prevent the original bit of cross talk from triggering the level shifter pulse circuit. If the cross talk is on the 1.8V side of the level shifter then maybe there is something we can do in layout, but since separating the wires seems to resolve the problem, I suspect that the crosstalk is on the 5.0V side of the level shifters where we have very little control..
Can you do a few things for me so that we can debug this?: 1) take a photograph of your setup (show the board, the how the probes are connected, and the Grove cable leading to the device). The way the scope probes are connected can affect the measurements. 2) send me a link to the test program you are using to run the I2C bus. I can compile it and run it here. What Grove device are you driving so I can use the same device. 3) send me a link to the patch that enables 16mA drive current on the I2C bus. 4) take a scope trace with 2mA drive, and with 16mA drive. I want to see if we have resolved the marginal low levels. From the traces you included it is hard to be sure, but I think the low levels are much better.
I have attached a picture of how I think you should have the scope probes attached. I used a wire stripper to bare a little bit of wire in the grove cable so that I could clip the probes directly to the signal. I put a pin into the closest ground point and grounded both probes to this pin. Keep the probe wiring and ground wiring as short as possible.
Lawrence King email@example.com Engineer, Sr. Staff/Manager Qualcomm Canada Inc. (905)482-5403 desk (x25403) (416)627-7302 cell
-----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Grant Likely Sent: Sunday, November 15, 2015 10:42 AM To: Srinivas Kandagatla firstname.lastname@example.org Cc: King, Lawrence email@example.com; Mark Brown firstname.lastname@example.org; Akira Tsukamoto email@example.com; David Mandala firstname.lastname@example.org; email@example.com; Gandhi, Ketal firstname.lastname@example.org; George Grey email@example.com; Koen Kooi firstname.lastname@example.org; 96boards-team email@example.com Subject: Re: Sensors board Rev B - call for review (v2)
On Sat, Nov 14, 2015 at 12:15 PM, Srinivas Kandagatla firstname.lastname@example.org wrote:
Thanks for the detailed explanation.
I have done few experiments with 16mA drive strength on Grove Gesture, Grove Digital light sensors and LCD RGB backlight. I hit 2 issues.
Issue 1: (With Digital Light sensor (0x29)) 10K on board pull up:
With the Rev A sensor board what Am seeing is a cross talk between SDA and SCL. The spikes are too high that the ACK is not detected by the master.
Attached are some waveforms to confirm this In the "Not-Detected-Cross-Talk-(0x29).BMP" waveforms we can see spikes which are at the rising edge of the clocks which is worst in the ack clk cycle.
I repeated same experiment by splitting the SCLK out of the Grove ribbon cable. "Detected-with-Split-Cable(0x29).bmp" has the captured wave form. Now the slave gets less spikes and the master can detect it.
Quick read on the internet suggested that the layout of the tracks or the ribbon cable which exceeds 10cm should be something of below order:
SDA - VDD - VSS - SCL
This arrangement would avoid cross talk between SDA and SCL. Grove connector cables are definitely in the order which are prone to cross talk. Not sure if we can fix though :-)
Are we taking care of this at layout level?
References: http://www.nxp.com/documents/user_manual/UM10204.pdf ( Section: 7.5 Wiring pattern of the bus lines)
Am not sure if Rev B is taking care of this or Is it possible to compensate such thing if external ribbon cables are in wrong order?
Issue 2: (With Gesture sensor) 2.2K on board pull up:
I cant detect this sensor, Possibly it might be a faulty one. Waveforms look normal. Will continue to debug with other devices.
Can you show a waveform of the ack cycle? I'd like to know how low the sensor is driving the data line.