3 ms·

A blanket ban like this isn't particularly useful advice. I2C is perfectly useable in less-than-perfect environments, and LEO isn't really as harsh as people ma

A blanket ban like this isn't particularly useful advice. I2C is perfectly useable in less-than-perfect environments, and LEO isn't really as harsh as people make it out to be. It's really only going to be a problem if you assume that everything operates perfectly all the time, and if you're making those assumptions you're going to have a bad time working on remote systems anyway. Make sure your drivers can handle NAKs and errors on the line. Make sure you can reset subsystems (probably by power-cycling) completely and your system can keep running. Be ready to deal with stale sensor data or having to do a few retries at times. With these and some good testing you'll be fine with I2C, and really there's immense value in having those attitudes in your system design anyway. I was a design EE at Planet Labs for 4 years, have sent something like 200 satellites to space, each with literally dozens of I2C devices on them, and supported them in orbit.

bsder 7y ago
> Make sure your drivers can handle NAKs and errors on the line. Make sure you can reset subsystems (probably by power-cycling) completely and your system can keep running. Be ready to deal with stale sensor data or having to do a few retries at times. By the time you've implemented that, you've negated any advantages of I2C. So, why not go directly to SPI?
- deleted 7y ago
  [deleted]
- patrickyeon 7y ago
  Because a whole bunch of chips you want to use are on I2C. And/or you want to work with a large number of devices, and a chip select per is a lot of GPIO to burn on this. Also you're going to want to handle errors and bad devices on SPI, so it's not like that's new work anyway.
jononor 7y ago
Additionally, sensor data should be oversampled and filtered/fused using a filter that is robust to outliers. This whether coming in over I2C, or not. Robust systems assume failures will occur and manage them in such a way that they still do their job correctly.

bsder 7y ago

> Make sure your drivers can handle NAKs and errors on the line. Make sure you can reset subsystems (probably by power-cycling) completely and your system can keep running. Be ready to deal with stale sensor data or having to do a few retries at times. By the time you've implemented that, you've negated any advantages of I2C. So, why not go directly to SPI?

deleted 7y ago
[deleted]
patrickyeon 7y ago
Because a whole bunch of chips you want to use are on I2C. And/or you want to work with a large number of devices, and a chip select per is a lot of GPIO to burn on this. Also you're going to want to handle errors and bad devices on SPI, so it's not like that's new work anyway.

jononor 7y ago

Additionally, sensor data should be oversampled and filtered/fused using a filter that is robust to outliers. This whether coming in over I2C, or not. Robust systems assume failures will occur and manage them in such a way that they still do their job correctly.