According to this thread the reliability of the dedicated I2C port on the RIO is suspect. Is it still the suggested SOP to use the MXP I2C breakout instead?
Also, datasheets indicate that the maximum length for I2C is < 3ft. We were hoping to use an i2c based sensor on the end of our manipulator which will necessitate a cable run longer than that. Are there such things as I2C extenders?
I’m not sure “suspect” is the right word. It should really just be considered permanently broken at this point. The MXP one is the recommended alternative, though (anecdotally) I’ve seen teams with issues using that one as well, just with significantly lower frequency.
I have successfully run one I2C device on the MXP port. More than one device failed at least with the 2022 images.
With good wiring practices you should be okay to put one device out a few feet. There are plenty of references on the Internet. Here’s the wiring section from a training class I put together. It’s just stuff I copied off the Internet. I’m not an electrical engineer - I just read stuff on the Internet.
If you have a cable selected to use and a wiring diagram, I’d be happy to review it.
WIRING
You are trying to keep SCL and SDA far apart to minimize one interfering with the other (crosstalk).
Nomenclature:
Vcc and Vdd are positive voltage (typically 5v or 3.3v or sometimes lower 1.8v or 1.2v).
Vee and Vss are negative voltage (typically ground GND or 0v).
Sda is data (typically 0 to 3.3v or 0 to 5v).
Scl is the clock (typically 0 to 3.3v or 0 to 5v).
I2C is not designed for long cable lengths but for the few inches between components in the PCB. Theoretically, low capacitance cable might work to several meters but practically, depending on the cable type used, 2 meters of cable (more or less) might already cause problems.
Range extenders for the I2C bus are available and can extend the range to 100’s of feet. They require more electronics and more power or slower speeds.
In general, the wiring pattern of the bus lines must be chosen so that crosstalk and interference between bus lines is minimized. The bus lines are most susceptible to crosstalk and interference at the HIGH level because of the relatively high impedance of the pull-up devices.
Two additional circuits may be seen for interrupts and auxiliary power. In a ribbon cable, for example, they would be:
Round Cable
For short lengths round cable can be used. Keep the SDA and SCL as far apart as possible – on the diagonal and not adjacent.
Ribbon Cable
If the length of the bus lines on a PCB or ribbon cable exceeds 10 cm and includes the VDD and VSS lines, the wiring pattern should be:
If only the VSS line is included, the wiring pattern should be:
These wiring patterns also result in identical capacitive loads for the SDA and SCL lines.
If a PCB with a VSS and/or VDD layer is used, the VSS and VDD lines can be omitted.
Twisted Cable
Do not twist the SCL and SDA together – that’s the opposite of what you are trying to accomplish and causes the most errors.
If the bus lines are twisted-pairs, each bus line must be twisted with a VSS return.
Alternatively, the SCL line can be twisted with a VSS return, and the SDA line twisted with a VDD return. In the latter case, capacitors must be used to decouple the VDD line to the VSS line at both ends of the twisted pairs.
If the bus lines are shielded (shield connected to VSS), interference is minimized. However, the shielded cable must have low capacitive coupling between the SDA and SCL lines to minimize crosstalk. What this coupling means is unknown to team FRC 4237 and has been ignored when twisted shielded pairs are used. Pull up resistors may be involved.
Shielded cable should be grounded at one end. Which end usually doesn’t matter. This is a controversial topic with ardent advocates and detractors of “ground both ends,” “ground one end,” ground the other one end.” The team FRC 4237 has typically grounded only the end nearer the power supply (the master-receiver end) – not the sensor end (the field end).
That’s a really neat writeup. Is it implied then that adding the decoupling caps to both ends of a twisted pair then we’d be able to have a much longer cable? Putting this on the end of our arm is going to be about 7’ of cable.
Again - I am not an electrical engineer. My interpretation - that is what I would try if I had to - is to get a low capacitance, 2 twisted pair cable such as 68902 . Besides this example, I’m sure there are several others available but the cables on Amazon might be hard to prove their capacitance as data sheets tend to be brief on Amazon.
The ground would be with both the pairs and the decoupling capacitors should not be needed.
Then run a separate power conductor. Check the game manual for how close the power conductor has to appear with its ground. I think we wrapped them together with tape or split loom cable management.
I’m not sure of the capacitance of the communication cable we used but we did have some troubles with long runs and shortened them as much as possible and were successful. It’s been awhile but I think we did okay at 4 feet with not cheap but still unknown capacitance cable.
If your device needs high power in bursts you may need a capacitor by the device for the power circuit. The Lidar-Lites needed that and we followed the manufacturers recommendation.
There are posts on CD and I think official WPILib I2C adaptors/eliminators with an inexpensive RPi that you could put on the end of 7 feet and maybe there is a protocol that would work if I2C doesn’t. I’ve run RS-232 hundreds of feet. The bit rate is slow to make it work.
We were having trouble running I2C over a 10 foot cable to RevRoboics’ 2meter distance sensor.
The problem was solved by adding a $11 LTC4311 I2C Extender/Active Terminator from Adafruit (ordered via Amazon). The hardest challenge was locating the right connectors (tiny “Stemma QT/Quiic” connectors) and soldering them onto the long cable and onto a 4-pin flat Mod connector that we cut off from an old I2C cable. We let the enable pin float
It was a relatively simple solution and it worked great for last weekend’s district competition in Glen Allen, Virginia.
Had the port been fixed in the roborio 2 or are there the same problems?
It’s my understanding that the I2C implementation in the roborio can’t be fixed. Our team has had enough trouble with it that we pretend it doesn’t exist.
