All sensors can stream potentially together at the same time. So you'll need a communication system with inherent collision detection and/or priority management mechanisms. CAN seems a good option as it's designed as a noise-resistant, long-distance communication system. But requires separate MCUs (w/ CANbus support) at each node, and each node should have a unique ID to use during transmission. 4-5KB/s(kilobytes/sec) means 40 kbps max. So running CAN at 128 kBaud will meet your needs without problems. I can't imagine the performance of I²C HS mode with the existence of long wires.

I think there's a misunderstanding: "all sensors can stream at the same time" means they can't be connected to a bus, because there would be collisions. Unless the master can tell each sensor when to transmit, so they would do so one at a time, without collisions. So, are your sensors "free-running" and transmitting whenever they feel like it, or can they buffer data and wait to be told to transmit?

Thanks for the response Rohat. I had thought of CAN as an option but I would need to handle the collision part when more than one sensor wants to send out info(bus arbitration part). I was hoping I could avoid that. I think I need to rephrase the part where all sensors can potentially stream at the same time. What I meant was that I would like to poll all the sensors and get the data in near real-time from all of them(Since its not one to one communication). So the speed of polling the data from each would have to be fast enough. I agree that I2C HS mode can have issues with longer wires.

@bobflux I seem to have posted before your comment. What you mentioned is correct I cant have all streaming and be on a common bus. I have edited the question. The sensors can buffer data and wait(as little a time as possible).

@dev_000 I had thought of CAN as an option but I would need to handle the collision part when more than one sensor wants to send out info(bus arbitration part). CAN nodes are capable of avoiding collisions and releasing the line to a node with higher priority (determined by frame ID) during transmission. In both situations, the nodes that lost the arbitration before will try to re-transmit their messages as soon as the bus gets idle. You don't have to worry about this. CAN nodes (i.e. MCUs with CAN hw) deal with it.

OK, do your sensor chips already use a specific protocol like I2C or SPI, or are they microcontroller based, so able to be programmed to use whatever you want?

@rohat That seems hopeful. I was under the wrong impression about CAN then(Yes it does add CAN transceivers on both ends, which I would ideally like to avoid but it's still a solution). Any issues you foresee with CAN implementation with these many sensors pushing data through? Would there be a case where one sensor can never win the bus as CAN commn is initiated from the sensor and not the central controller(I maybe wrong on this too regards to CAN).

@bobflux Microcontroller based. I can design the sensor to talk in any format I want. Calling it a sensor is a misnomer I suppose. It collects data and can repackage it to any format.

@dev_000 Well, normally the frame with lower ID has higher priority. So it's unlikely to see a node that can never win the arbitration. In your application, I understand that each node will pack the data and transmit periodically. A CAN message transmission takes less than 3ms at 125kBaud. So, it will normally take less than 100ms if each node transmits their messages with no delay between each other. If you set the transmit period large enough (like 200ms) then each node will have enough time to listen and re-transmit their messages in case of lost arbitration. In cars, CAN works quite well.

25-30 sensors, 4-5 kilobytes per second. That's up to 1.2 megabits per second. With I2C you also have addressing overhead and you can't just put 30 I2C devices on a 60cm bus as it would likely exceed the capacitance rating and not many MCUs have support for that high speeds over I2C anyway. Just why did you ruled out UART in the first place for wrong reasons, RS-485 bus would make perfect sense here.

Thanks Rohat for clarifying. CAN seems to be suitable for the use case albeit with extra transceivers @JustMe I guess I was wrong to rule UART so quickly. Somehow UART for me, was only point to point, and not a master to many. I completely forgot about RS485 and its multidrop. I need to read up more on that and come back. Thanks for suggesting. Anything else specific to rs485 I would need to worry about for this application use case? I do see an answer which mentions this as well.

If you use a bus and you have many sensors, then you have to consider addressing overhead. The master must send a packet like "sensor#x you can talk now" for each sensor, and if each responds with one byte, you've multiplied the total bit rate by 2 or 3. So you'll need them to transmit several bytes at a time to amortize the addressing overhead, which increases latency, and adds a "length" byte. This may or may not matter, depending on your needs, and depending on the bus bitrate. But it can't transmit several bytes before the bytes are available. So, please tell us how low you want latency.

Also I would like to know about the wiring, and how things are connected. Can you draw a diagram? How many wires do you have available in the cables, what kind of cables, twisted pair? (to get an idea of bitrate) Is there one cable per sensor, or a few cables each going to a board with several sensors on it? I mean if you're going to manufacture 30 little sensor boards it makes sense to think ahead about it to avoid making a mess with the wiring.

Also, if you have 30 sensor boards, that adds 30 CAN chips ($$$) but if you have 10 sensors per board maybe you can add a micro to gather the data locally and only connect this to the bus, which would use much less CAN/485/whatever chips.

@bobflux Initially when I was thinking i2c, I was thinking of time-slicing and polling each sensor. Then get the entire 4-5KB in one shot and move on to the next. If my transmission rate was high enough, I could circle back to the first sensor(after going through everyone) by the time the second block of data was available in the first sensor.

Regarding wiring, I would love it if I can do it with 2 twisted-pair cables(Power, GND, 2 Data Lines). Currently, I was thinking to daisy-chain the bus with pass-through connections with all 4 lines commonly accessible to each of the 30 odd sensors. I cant club 2 sensors blocks together so it will be 30 separate blocks. You are right moving to CAN or RS485 would mean adding 30 extra transceiver chips. It will be costly. If possible I would like to avoid that. I did like the async serial link which jayben was mentioning. For that, I would need to handle collisions and bus control via code.

Is this a one-off or will you manufacture? RS485 chips aren't that expensive. But... if you talk about transmitting complete blocks, then you're okay with quite high latency then? Do the sensors need to be time-synchronized with each other?

@bobflux Its not for a one-off design so cost is definitely a consideration. In the ideal scenario, I would like the sensors to be time synced among themselves when read. I know that the polling behaviour of i2c wouldnt have allowed that to happen. In the best case scenario, I would have loved to have 1 reading(say 2bytes every 300us) read from each of the sensors at a particular instant of time and transmitted to the controller as a block in the least possible time. Hope this makes sense.

What's the fastest speed on the UART in the sensor micro? You're gonna need something like 2 Mbps or more, that's pretty fast for a UART! Might push you into a more expensive micro... gotta consider total cost, including the micro in the sensors... does it have a SPI interface? That could be better. Forget about the CS pin for now. Or just post a link to the datasheet of that micro.

TBH, I haven't finalised the micros. Most micros can do up to 1Mbps on UART. Initially, I was specing based on i2c speeds. All the SAMD(11,21,51) series chips from Atmel/Microchip does full speed i2c at 3.4Mbps. Now that I think of it, even if I go with RS485 chips, I will be bottlenecked by micros UART pin baud rates right?