| Electronics > Projects, Designs, and Technical Stuff |
| EMF pickup from amplifier in I2C line causing glitches. (Now with scope trace!) |
| << < (27/31) > >> |
| Starlord:
--- Quote from: janoc on July 14, 2016, 02:04:19 pm ---It is great that you are doing what you love to do, but I think you would have been better off trying to update the skills you actually have first, solve your financial problems and only then try to start a business. --- End quote --- Trial by fire. If I had not needed to find a way to make money six years ago when all my software endeavors failed to make ends meet, I wouldn't have picked up an Arduino and I wouldn't have been motivated to learn the black art of electronics. --- Quote ---Or at least recognize that you are way out of your skill level and get help early. --- End quote --- You think I just jumped into this without doing any research? One of the first things I googled was whether or not I2C could be made to work over long distances. The consensus was yes, it can. I then did the math, and according to the spec, I was good to go. http://electronics.stackexchange.com/questions/106265/maximum-i2c-bus-length --- Quote ---If your wire is 20pF/30cm and you have another 50pF of stray and input capacitance, you're limited to 2.25m of cable length. --- End quote --- --- Quote ---I work for a company making sensors. Most of them are based on I2C sensor chips, those devices can be split in two, so you can install the CPU part in one place and the sensor part in another. We conducted quite a lot of tests on the I2C connection between the device CPU and the I2C sensors. At 100 kHz, with a good error recovery protocol, 25m can be easily reached using basic wires. We were even able to reach 100m once with CAT5 cable. --- End quote --- --- Quote ---IIC is a synchronous protocol, and as such, it can be run arbitrarily slowly to meet system requirements with respect to distance and noise. There are many examples of using IIC over a cable, all the way from ACCESS.bus back in the 1990s to how it is used today to retrieve EDID information from video displays. --- End quote --- --- Quote ---The insane sounding lengths like 10,25, and 100m are perfectly possible, and i use the method often(with uart not i2c, but the method stands) when i need to put stuff together quickly. --- End quote --- Yes, there is one dissenting opinion there, talking about how it is designed for only short runs on a PCB, but overwhelmingly the response was that it can work. And I think I've proved that. It doesn't work WELL, without special driver chips, but it can work. Speaking of which here is an application note from NXP describing different drivers that can be used to make it work over long cables: http://www.nxp.com/documents/application_note/AN10658.pdf |
| engineer_in_shorts:
I do not understand why you are arguing about IIC on long cables. Since it clearly is not suitable because you have communication issues, and what's more is that you have been able to identify these as line transmission issues. Secondly you didn't look very hard at your own sources of research as they are talking about 100kHz rate, not 400kHz. |
| CJay:
--- Quote from: engineer_in_shorts on July 14, 2016, 04:46:29 pm ---I do not understand why you are arguing about IIC on long cables. Since it clearly is not suitable because you have communication issues, and what's more is that you have been able to identify these as line transmission issues. Secondly you didn't look very hard at your own sources of research as they are talking about 100kHz rate, not 400kHz. --- End quote --- Confirmation bias, he's possibly unwittingly chosen to read the best out of the messages, one of them even says it's not about I2C but using a UART, another talks about cable capacitance but he's not qualified the cable, another talks about using an error correction protocol which to my knowledge isn't part of standard I2C and yet another mentions slowing down the bus speed until it works. None of those messages prove his point, at best, they prove that a protocol that was also known as Inter Integrated Circuit bus can possibly be bodged to work over greater distances |
| Starlord:
--- Quote from: engineer_in_shorts on July 14, 2016, 04:46:29 pm ---I do not understand why you are arguing about IIC on long cables. Since it clearly is not suitable because you have communication issues, and what's more is that you have been able to identify these as line transmission issues. --- End quote --- It clearly IS suitable, IF you drive the signals properly. Saying I2C can't be used with long cables is WRONG, and might lead someone to think they can never use an I2C chip on any board that is remotely located from their microcontroller. But you can, IF you use an appropriate buffer chip. Is that a hack? Sure, I guess one could make that argument. But it'll work nonetheless if the companies selling those chips are to be believed. Naturally, one should take into account the cost of using said buffer chips versus the advantages of using I2C instead of SPI. But if the chips you want to use are all I2C, or SPI versions are all significantly more expensive, or you can't spare all the extra CS lines you'll need, then using those buffer chips may just make sense. I suppose one could use an IO expander to circumvent the issue of requiring multiple CS lines, but then you may be no better off in the cost department than using the buffer chips. --- Quote ---Secondly you didn't look very hard at your own sources of research as they are talking about 100kHz rate, not 400kHz. --- End quote --- And you didn't pay very close attention to this thread because 100KHz vs 400KHz made absolutely no difference in this case, and furthermore no matter how much I slow the I2C bus down, the slew rate will remain the same; out of spec for both 100KHz and 400KHz with the pull-up resistor sizes I chose. |
| Starlord:
--- Quote from: CJay on July 14, 2016, 05:05:15 pm ---Confirmation bias, he's possibly unwittingly chosen to read the best out of the messages, one of them even says it's not about I2C but using a UART, another talks about cable capacitance but he's not qualified the cable, another talks about using an error correction protocol which to my knowledge isn't part of standard I2C and yet another mentions slowing down the bus speed until it works. None of those messages prove his point, at best, they prove that a protocol that was also known as Inter Integrated Circuit bus can possibly be bodged to work over greater distances --- End quote --- I read all the messages. Even if half say it works, and half say it doesn't, and there were far more saying it works, who am I to believe? I can't tell who has more experience. And the people who say it doesn't work perhaps have never even tried it. While the people so said they got it to work clearly did try it, and succeeded. This compounded with the official I2C spec itself having sections suggesting the best way to route I2C signals over twisted pairs and long cables, could lead me to only one conclusion: it must be possible. And they were right. It is possible. I got it to work. It's glitchy when there's noise, I'll give you that. And it's way out of spec and whether it will be 100% reliable is certainly questionable. But it works. And if I had only FM+ devices on there where I could use stronger pullups, perhaps it would have been immune to noise. Or, perhaps if I had used a shielded cable it would have been immune to noise. Or, I could have used one of several buffer chips to make it immune to noise. So how you come to the conclusion that it doesn't work, when it clearly does, and there are clear ways which it could be made better and much more reliable, I don't know. I mean I get why you would shy away from it if possible since it's not as immune to noise as other protocols. But in my particular usage scenario, it made the most sense. Kind of like how using a 4017 decade counter to animate some LEDs makes sense, even though the thing can barely sink any current, if you are a beginner and need something really simple and cheap and easy to implement. That's where I got my start actually. |
| Navigation |
| Message Index |
| Next page |
| Previous page |