- Tue Nov 28, 2017 12:20 pm
#72133
I tried changing the clock to 100 and 400 and back to 100. For some reason, changing the setting has broken I2C completely. Now just connecting directly to the ESP results in no connection. I'll try again this evening.
Moderator: igrr
- Wed Nov 29, 2017 5:37 pm
#72173
In order to compare I2C to SPI I had to change libraries. After installing the BlueDot BME280 library I was able to get SPI working immediately. The example sketch allows for 4 sensors out of the box. The sensor works fine with short cable lengths but does not function with longer ranges. It appears to me that I need to change the default clock rate or something as SPI is purportedly more robust at range.
That said, if I can't get better range from SPI, I'm thinking that sourcing a I2C range extender might be an option. They don't look that expensive and would only be needed for 2 sensors I think (so only 1 module needed).
That said, if I can't get better range from SPI, I'm thinking that sourcing a I2C range extender might be an option. They don't look that expensive and would only be needed for 2 sensors I think (so only 1 module needed).
- Wed Nov 29, 2017 9:14 pm
#72175
On the products I design, if I2C is ever brought out of the box I always use line buffers/level translator.
I had one product where we initially didn't, but the supplied interconnect cable was only four feet long so I didn't bother buffering the signal. But one day my boss had someone else test it with a longer cable and it worked so that is how they started shipping it. And soon after there were field failures, and then I was to look at why. When I found out that they were using a longer cable I had to control myself from calling them fucking idiots. I took some scope captures to show them how badly they were violating the timing specifications. But hey, it worked on the bench for them so it must have been ok. No.
So now whenever I have I2C leaving the box I always design in buffer/level translator chips, sometimes isolated buffers.
I had one product where we initially didn't, but the supplied interconnect cable was only four feet long so I didn't bother buffering the signal. But one day my boss had someone else test it with a longer cable and it worked so that is how they started shipping it. And soon after there were field failures, and then I was to look at why. When I found out that they were using a longer cable I had to control myself from calling them fucking idiots. I took some scope captures to show them how badly they were violating the timing specifications. But hey, it worked on the bench for them so it must have been ok. No.
So now whenever I have I2C leaving the box I always design in buffer/level translator chips, sometimes isolated buffers.
- Thu Nov 30, 2017 1:49 am
#72183
out of experience i2c can be working on shielded cable up to 3-5m.
If using cat5 don't use the same pair for sda and scl and don't use one pair for either signal and gnd.
spi with clockrate in MHz range won't give you any reasonable choice on cable and length matching your situation.
If using cat5 don't use the same pair for sda and scl and don't use one pair for either signal and gnd.
spi with clockrate in MHz range won't give you any reasonable choice on cable and length matching your situation.
