[PinguTS]

"Long-Range" sensor projecs?

Is the long range in the room with us? It is I2C not very well known for long ranges. Especially with motors and electric drives and their EMI I2C is not the best decision.

From the title I was more in "Oh, what type of long range wireless they have opted for?" and didn't expect I2C.

For long range wired I would consider more a RS485 or CAN. Short ranges like in a small robot arm, a small car, and alike I2C maybe enough.

[walrus01]

For "long range", at least longer than wired i2c, I was expecting current gen zigbee, zwave800, or something LoRA based.

[wildzzz]

They offer some sort of booster module for runs up to 30m. Not exactly long range but it is for i2c. Although at that point, I'd rather just do something different than buying two of these extenders for super long runs.

[javawizard]

I really, really wish that CAN had caught on more for sensor networks in the hobbyist community.

It's so much nicer than I2C in so many regards: much longer range, masterless (any node can talk directly to any other node), packet prioritization built-in, deliberately designed to be more or less impossible to wedge, possible to do IC-to-IC on a board without transceivers by using a shared open-drain bus (like I2C, but with only one wire!)... and plenty more.

Really the only downside to CAN is that the spec requires timing that's tight enough that everything has to have a crystal on board. Ah, to have an alternate reality where CAN's timing requirements were relaxed enough for that not to be a requirement and it had caught on as the IC-to-IC interconnect standard instead of I2C...

[casylum]

That would be the LIN bus.

https://en.wikipedia.org/wiki/Local_Interconnect_Network

[javawizard]

LIN bus isn't masterless though, if I recall correctly.

That's the nice thing about CAN: every node is equal, and every node can send a message whenever it wants. As far as I know, LIN doesn't do that: you have one node on a given LIN network that initiates all communication, much like I2C, and the most other nodes can do is reply.

It's fine for what it is, of course, it's just missing some things that I think make CAN really neat.

[donquichotte]

There is really no good reason to ever use I2C, except if that's the only interface your peripheral supports. Debugging a stuck I2C bus, and attempting to un-brick the bus for a stuck slave (disabling ISRs, unhooking DMA, reconfiguring pins to GPIO, clocking the slave out of its coma and then doing everything in reverse) is just not worth it.

EDIT: I was hoping for HaLow WiFi!

[contingencies]

No. I2C is popular for a reason. It is cheap, fast enough, well understood, available everywhere, uses less lines and less physical space than almost all alternatives (excluding one wire buses which are far less standardized and far more limited), and supports multi-drop.

This thing should be called what it is: an I2C multiplexer. Such things are not new.

[wildzzz]

Yeah there's a reason why all of the high reliability chips I use only come with SPI interfaces. The last time I used i2c for anything but hobbyist stuff was in college.