Sigh. I didn't say there was a limit at 20-30cm - I said start worrying.
Gary Stewart wrote:
so keeping distances as short as possible ... is a good
idea.
If you're considering running this over much more than a short distance, you need to start taking additional concerns. You can't just take (any) pair of wires and expect it to work over 3m, nor even a meter (not that I would try - I would pick RS232 for this distance).
From experience, even at distances of around 30-40cm, running at 400bkit/sec with I2C devices from reputable manufacturers, you have to start
taking care (and sizing your pull-up resistors appropriately for a decent waveform).
BTW - I2C is a great protocol - and is therefore the ubiquitous choice for good reason and virtually every electronic item beyond a flashlight probably uses it.
For end product-to-end-product comms (where you may want a distance between them) there are better options.
Sigh. I didn't say there was a limit at 20-30cm - I said start worrying.
Gary Stewart wrote:
so keeping distances as short as possible ... is a good
idea.
If you're considering running this over much more than a short distance, you need to start taking additional concerns. You can't just take (any) pair of wires and expect it to work over 3m, nor even a meter (not that I would try - I would pick RS232 for this distance).
From experience, even at distances of around 30-40cm, running at 400bkit/sec with I2C devices from reputable manufacturers, you have to start
taking care (and sizing your pull-up resistors appropriately for a decent waveform).
BTW - I2C is a great protocol - and is therefore the ubiquitous choice for good reason and virtually every electronic item beyond a flashlight probably uses it.
For end product-to-end-product comms (where you may want a distance between them) there are better options.
Start worrying is not a very informative reply, the follow up is much better.
Well, post #6 (your post) actually had zero "informative" quality for the original question, yet you chose to criticise my post for this exact reason.
Maybe that irony was lost on you.
As for your (self-stated) "useful" post above:
"not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter or logic probe in any way tell you if what is on the line is the correct data at any given time"
By the way, I didn't suggest using a multimeter or logic probe if that's what you're implying. I stated (fairly clearly, but maybe there is a language problem), that this is all some hobbyists will have.
Also your comment: "The protocol is not the problem, the physical interface is"
The physical layer is a protocol. It defines the voltages that you expect on the lines amongst other parameters. I2C only has two layers.
Finally your comment: "that allows the master to read back the data it sent for say 10 to 20 minutes while counting the number of errors to make sure it is working properly."
Really.. I'd run it constantly for (at the very very least) days non-stop to ensure I got absolutely zero errors, if I really was attempting to run it over cable (shielded or not) over any significant distance - not that I would design like this. 10-20 mins is insignificant. And sure you can build in reliability in your final code too by error detection/correction, but I'd at least start with a reliable hardware design and test it thoroughly. I'm not so sure there is any benefit or pleasure in discussing this futher with you. Have a good day.
He was right, the concept for I2C was for short distances, and if you are new to the I2C "sport", then start short, get everything working and then extend.
Some manufacturers make special chips to aid in making long runs.
He was right, the concept for I2C was for short distances, and if you are new to the I2C "sport", then start short, get everything working and then extend.
Some manufacturers make special chips to aid in making long runs.
Best of luck
There is nothing in the I2C specification from Philips (the originator of the I2C bus) that says it is only for short distances. The fact that it is designed to work
with a 400 pF capacitive load (max.) and that the description in the specification mentions using it for a keyboard interface (keyboard cables are longer that
Well, post #6 (your post) actually had zero "informative" quality for the original question, yet you chose to criticise my post for this exact reason.
Maybe that irony was lost on you.
As for your (self-stated) "useful" post above:
"not really sure how a multimeter/logic probe helps here since multimeters are usually bandwidth limited to about 1 KHz and neither the multimeter or logic probe in any way tell you if what is on the line is the correct data at any given time"
By the way, I didn't suggest using a multimeter or logic probe if that's what you're implying. I stated (fairly clearly, but maybe there is a language problem), that this is all some hobbyists will have.
Also your comment: "The protocol is not the problem, the physical interface is"
The physical layer is a protocol. It defines the voltages that you expect on the lines amongst other parameters. I2C only has two layers.
Finally your comment: "that allows the master to read back the data it sent for say 10 to 20 minutes while counting the number of errors to make sure it is working properly."
Really.. I'd run it constantly for (at the very very least) days non-stop to ensure I got absolutely zero errors, if I really was attempting to run it over cable (shielded or not) over any significant distance - not that I would design like this. 10-20 mins is insignificant. And sure you can build in reliability in your final code too by error detection/correction, but I'd at least start with a reliable hardware design and test it thoroughly. I'm not so sure there is any benefit or pleasure in discussing this futher with you. Have a good day.
The only irony missed here is that you still seem to think that "start to worry" is informative in any context.
No the protocol is not the physical interface. A physical interface is the electrical specification for sending/recieving data across some physical
medium, RS-232RS-232 vs RS-485 as an example. The protocol determines how the data is sent across the physical interface - addressing, byte order,
error detection/correction (which can be done in hardware or software) etc. and it resides in one or more layers above the physical interface.
For a hobbiest, which is what this is aimed for, 10 to 20 minutes will tell you if it is working with reasonable reliability. A 20 minute test at
100 KB/s will have sent/recieved ~ 100,000,000 bits. If you need better reliablity, run the test for a longer time.
You are right about one thing, this conversation has become a waste of time.
Running for "DAYS" may seem like a good alternative, but its not really, its just mostly a waste of time. It only tests one setup, in one place, one time.
The right way to do it is to build in error correction, so that if your "tested for days system with no errors", suddenly starts getting errors due to sudden circumstances beyond your control like a thunderstorm or simply something has been placed near your cables, or taken away, or a big motor is started or stopped within a mile of where it is, of just ANYTHING, the error correction just cuts in and fixes the poroblems.
To get error correction to work, you also need to actually find out that an error has occurred, so you may need to understand how parity works, plus longitudal error detection as parity will not find a double error always, but its a start.......
I have read all the posts and actually, they all seem to be trying to help the OP, and they also demonstrate to me at least to have more understanding than some here...
Do please remember that someone asked a question, killing the messenger is not helpful or friendly....try to be slightly more forgiving please to those trying to help who maybe did not appear to be "helpful enough" in YOUR eyes.....OK?
Running for "DAYS" may seem like a good alternative, but its not really, its just mostly a waste of time. It only tests one setup, in one place, one time.
The right way to do it is to build in error correction, so that if your "tested for days system with no errors", suddenly starts getting errors due to sudden circumstances beyond your control like a thunderstorm or simply something has been placed near your cables, or taken away, or a big motor is started or stopped within a mile of where it is, of just ANYTHING, the error correction just cuts in and fixes the poroblems.
To get error correction to work, you also need to actually find out that an error has occurred, so you may need to understand how parity works, plus longitudal error detection as parity will not find a double error always, but its a start.......
I have read all the posts and actually, they all seem to be trying to help the OP, and they also demonstrate to me at least to have more understanding than some here...
Do please remember that someone asked a question, killing the messenger is not helpful or friendly....try to be slightly more forgiving please to those trying to help who maybe did not appear to be "helpful enough" in YOUR eyes.....OK?
I agree with you that a very long test may not be that informative but there are also (reasonably common) cases when error detection does little to help. If, for example, the system timing is marginal it may got from an error rate of less than 1 bit in 1E9 to 1 bit in 1E2 as the temeperature changes from 20C to 30C. Error detection folowed by re-transmission probably won't save you. It's still a very good idea to have it because it's a big step on the way to measuring and ultimately dealing with the source of the problem.
I would expect a professional designer to check the bus timings/waveforms with a scope but of course this may not be possible for many hobby engineers. The answer there is to be careful to work well within specs, try to conform with common good practice (short spans and error correction) and be perapred to be innovative in your debugging.
I agree with you that a very long test may not be that informative but there are also (reasonably common) cases when error detection does little to help. If, for example, the system timing is marginal it may got from an error rate of less than 1 bit in 1E9 to 1 bit in 1E2 as the temeperature changes from 20C to 30C. Error detection folowed by re-transmission probably won't save you. It's still a very good idea to have it because it's a big step on the way to measuring and ultimately dealing with the source of the problem.
I would expect a professional designer to check the bus timings/waveforms with a scope but of course this may not be possible for many hobby engineers. The answer there is to be careful to work well within specs, try to conform with common good practice (short spans and error correction) and be perapred to be innovative in your debugging.
MK
If the error occurs frequently, error checking and retransmission may not help and will certainly slow down communications which could cause other problems. If it is only occasional, then it will help
and in both cases it will alert you to the fact that there is a problem.
A scope is really the only way to know what is really going on and is 2nd on my list of must have tools for serious hobbiest, the multimeter being first. 20 MHz scopes (works with I2C and probably
most Arduino debugging) are fairly inexpensive but knowing how to use them does require at least some knowledge of AC and digital waveforms.
