If it does turn out to be a bus length related issue (impedance / baud rate/ etc), then worth checking out the NXP P82B715
A P82B715 is needed on both sides of the bus as shown in the application circuit:
Which can reduce the impedance factors by 10x (which increases the length of the bus by about the same amount).
There are a couple of factors in play; type of wire (twisted = more capacitance), I2C bus speeds, length. So it is hard to say exactly where things will max out, but there you have it.
In a phone call regarding this, it was mentioned that both halves of the chain work, but not when joined. Two Arduino’s and a high speed SPI/UART interface might be another option (between the dev boards).
It would be helpful to see how square the signal is on the I2C bus.
AdaFruit has just released an active terminator for the I2C bus. Demonstrated over 100 feet of cable. Might be worth checking out. Don’t know if Core are stocking this yet.
Based on our conversation of having 3 worker Arduinos managing a section of track each, then having the boss Arduino connect to them via SPI and collect their readings, I have the following that successfully has a Worker run a counter and send the value of it back to the Boss on interrupt.
Is it possible for me to collect values from the sensors, store them in a array and send the entire array on interrupt?
#Boss Arduino
#include <SPI.h>
void setup (void){
Serial.begin (115200);
Serial.println ();
pinMode(53, OUTPUT);
digitalWrite(53, HIGH);
delay(1);
SPI.begin ();
// Slow down the master a bit
SPI.setClockDivider(SPI_CLOCK_DIV8);
} // end of setup
byte transferAndWait ()
{
const byte what = 1;
byte a = SPI.transfer (what);
delayMicroseconds (20);
return a;
} // end of transferAndWait
void loop (void)
{
byte z;
// enable Slave Select
digitalWrite(53, LOW);
z = transferAndWait ();
// disable Slave Select
digitalWrite(53, HIGH);
Serial.println (z, DEC);
delay (1000); // 1 second delay
} // en
#Worker Arduino
int count = 0;
void setup (void){
// have to send on master in, *slave out*
pinMode(MISO, OUTPUT);
// turn on SPI in slave mode
SPCR |= _BV(SPE);
// turn on interrupts
SPCR |= _BV(SPIE);
} // end of setup
// SPI interrupt routine
ISR (SPI_STC_vect){
SPDR = count; // add 15
} // end of interrupt service routine (ISR) SPI_STC_vect
void loop (void)
{
delay(1000);
count++;
} // end of loop
Whoa. Hold up everybody. This could be as simple as correctly terminating the cable run. I think Robyn gets close to the mark when she wonders how square the signal is on the bus. If the cable is not terminated correctly it could look like a dog’s breakfast.
I am not the full bottle on I2C or a lot of the other transmission systems around but I do have a fair bit of an idea when it comes to transmission lines.
Please correct me if in error. I assume the clock is transmitted from the master to all slaves and the data is bi-directional, that is half duplex where transmission takes place one direction at a time.
Any single direction signal needs to be terminated at the receiving end. Half duplex signals need terminations AT BOTH ENDS.
I note on some circuits provided the use of pull up resistors. Because these are returned to ground by what I assume to be a low impedance power supply these could be seen as terminating resistors.
Any terminating method needs to match THE CHARACTERISTIC IMPEDANCE OF THE CABLE, irrespective of any other requirement. The terminating resistors should be as non inductive as possible. The cable impedance could probably be in the order of 100 to 150 ohm. This will have to be determined.
A trick used to extend the transmission range of RS232 for some years may be worth a try. This extended the range from about 3 metres to 70 or 80 metres quite successfully. We used low capacitance shielded cable with 2 separate twisted pairs so the TX and RX lines had virtually their own return instead of the common wire normally used. The 2 “commons” of the pairs joined together at the ends and connected to the “common” pin in the connectors (Signal Gnd).
I would respectfully suggest to Gwen and any others interested parties that some research into transmission lines (after all that is what you have got) be looked into. Put the ideas of all these “satellite” devices to one side, run a single bus around all of your slave devices being sure that each one correctly addressed etc. and correctly terminated and see what happens. Most of your woes may be fixed by some quality cable and 3 or 4 little resistors.
I post this because nowhere in all these replies have I seen mention of cable termination and the effects of standing waves on an incorrectly terminated cable.
In answer to any questions I HAVE experienced this problem before. Data engineer complete with computer sitting alongside rack of equipment, all OK. Real world where same engineer some 80 or so metres away, disaster. Reason, cable termination was about 5000 ohm instead of 120.
Conclusion, no communication between digital and analogue people. Analogue is not dead yet and indeed is needed when information has to be transported from one point to another (Modem???)
One more thing. If anyone wants to look at the quality of the square waves be very careful probing around this sort of thing. Good technique is essential. 10X probe, earth clip as short as possible and remove the mains earth from instrument in case of accidental ground loops. It is quite possible and indeed happens that problems are introduced which are not really there.
Cheers Bob
I would also recommend looking at the schematic for the sensor, and check to see how easy it is to remove the SDA/SCL pullup resistors from the circuit. Might just be a very easy and quick fix, given your time constraints.
Most I2C devices offered in the SparkFun catalog usually include pull-up resistors for the SCL and SDA pins. If you have many I2C devices on the same bus, you may need to adjust the equivalent value for the pull-up resistors by disconnecting the pull-up resistors on a few of the devices. Depending on what is connected to the bus and the design, you can include about 7x I2C devices on the same bus . However, if you are having any issues, you can cut the two traces connecting to the center jumper pad using an hobby knife or remove solder on the three jumper pads using a soldering iron to disconnect the resistors on certain boards.
My thoughts exactly and what I would be looking at if it was my project. But it is not …
I try to offer correct and relevant solutions to questions on this forum, sometimes you get a reply, sometimes you don’t and just wonder how the other person went with their idea. Hopefully I am improving the quality of this forum.
I do enjoy reading what other people are working on and how they approach a certain issue.
Hi James
Sorry, I was not replying to your particular post but to the thread in general. I am sure all contributors try and do the same.
As previously stated I am nowhere the full bottle on I2C or for that matter most of the other systems around. Also don’t know much about the hardware that uses them. Been a long time since I have worked full time. The decision on which protocol to use and which was best for the job was usually made by someone further up the food chain. I usually installed everything in a manner that was going to work and sorted out any problems that came along.
I do know however that irrespective which system is used if you have any sort of master slave situation the ENDS ONLY of the cable run should be terminated. If you have many units connected along this cable in a bussed situation these intermediate units SHOULD NOT have terminations fitted and should connect in a higher impedance bridging manner. If all units are terminated it would not be long before the whole bus is overloaded and the lot ceases to work. That is maybe what is happening here.
As said I am not familiar with any of this hardware bit I note that Robin has pointed out that these “pull up” (terminating ???) resistors are able to be disconnected. If so don’t disconnect some of them but try disconnecting ALL of them except at the very end of the cable run. In the case of the 2 way signals BOTH ends.
Simplex (one way only) terminate receiving end.
Half duplex (2 way coms over single connection, one way at a time) terminate both ends.
Full duplex (2 way continuous coms, requires separate TX and RX connections) terminate recieve ends.
What value are these resistors. If they are indeed meant to be terminations I would expect somewhere between 100 and 200 ohms. One particular cable I have used in the past was quoted as 120 ohms. No matter but the termination MUST be close to the characteristic impedance of the cable to prevent or minimise reflections and standing waves which WILL play merry hell with any signals on the bus.
Note that these reflections and standing wave problems apply to ALL transmission lines. Even to the high voltage power grid where mismanagement can have very disastrous results.
Wrapping up I must say that for longer runs of anything I am a big fan of balanced lines. Unbalanced single wire (like RS232, TX RX and single common) systems have limited use where any distance is involved. You maybe be able to extend I2C capability by trying the 2 individual twisted pair system I described previously which successfully extended RS232 by quite a long way.
Maybe I2C is not the right choice for this job. Instead of trying to add all sorts of things and complicating the issue it could be time to re-evaluate if it cannot easily be made to work.
What do we need to do or what is the end goal? What would be the best coms system to achieve this? How can we interface what hardware we would like to use to this com system? If the sensors are I2C only you may even have to fit little converters of some sort to each sensor but your problem will be solvable.
Follow up.
Just found some info on I2C. It seems that when sending the output is open drain. This means that the pull up resistors are required. Only I believe on the “master” and the “slave” on the end of the cable run. This is where I recommended you put the terminating resistors. These resistors probably won’t be anything like a terminating resistor, probably much higher in value than the cable impedance. This open drain configuration means there is nothing you can do about that and have to take what you get.
If reflections and standing waves cause a problem and it appears your sensors are dedicated I2C you may have to seriously consider converting at every sensor. I would recommend looking at RS485. 1 pair screened balanced. 2 way half duplex comms and 30 odd slave capability with a TX distance quoted 4000ft. Over 1200 metres, should be enough. Plus of course 1 pair for slave power. If this has to happen then you would put a terminating resistor near the same value as cable impedance directly across each end of the transmission cable. Much easier and you will have no transmission trouble.
Cheers Bob
PS. If a converter to RS485 is used on every sensor all sensors will have to have pull up resistors in place to work.
Just a quick note to say this has turned out to be such great dive into some interesting edge cases for I2C. I’ve penned a couple of these ideas for my own use down the track!
