Dumb idea: connect every sensor with USB. There are some pretty cheap fullspeed USB micros around. Cables are cheap. You'll need hubs, but they're cheap too. USB frame timing gives you synchronization, and you can use interrupt transfers for low latency.
OK, no USB.
30x 5kB/s = 150 kB/s = 1.2Mbps without overhead, which is a bit expensive for an UART.
Here's an idea:
The 4-wire cable:
- Clock twisted with GND
- Data twisted with VCC
So we have two single-ended twisted pair lines in the 4 wire cable. There shouldn't be any need for differential over a short length like 60cm, if I read the question correctly, and 60cm is the total length, and you don't have thirty 60cm cables...
Let's use SPI without chip selects.
You need a sensor micro that has a SPI peripheral with MISO and MOSI connected to both ends of the shift register, so when it is configured as slave, bits come in MISO, travel through the shift register, then exit on MOSI, to be sent to the next sensor in the chain, and finally to the master micro.
So, let's make a protocol.
Clock line is connected to all the sensor micro SPI clock inputs, but on any decent micro, that pin is also a GPIO. So we'll use the clock line to communicate from the master to the slaves. If the micro has a pinmux that can turn this pin into an UART RX, then a simple serial protocol can be used, otherwise, bitbanged UART.
The master can send commands to all the slaves, for example "identify" and "transmit data".
Then, the slaves load the requested data into their SPI shift registers, configure the SPI peripheral as output, and switch the Clock pin from GPIO/UART input to SPI SCK input. Master pulses the clock lines enough times, the shift registers do their job, and all the data is shifted and received by the master.
Since the slaves are daisy-chained, no extra data is required to identify which slave sent which byte. This is determined by the position in the bit stream.
Once all the slaves have shifted their data, they should switch SCK back to GPIO or UART input, and wait for a new command.
These commands handle synchronization automatically since all the slaves receive them at the same time.
Now, each slave will have to send the same number of bytes as the others, since they're all read at the same time. I guess you could come up with a simple protocol to solve that issue, for example a value representing "I have nothing to send" or something like that.
In this case, there isn't even a need for a command to request the slaves to send data. You just need the slave to set a timeout on the clock pin (with a timer), for example the timer is reset if the pin is 1, and when it stays at 0 for a while, the timer fires an interrupt. So when the clock stops pulsing for a certain time, the slaves reload a value in their registers, and then the master sends another sequence of clock pulses to shift out all the values.
I think that's the cheapest solution...
With this, the sensors can even know their own position in the chain: suppose the one at the end of the chain has a pulldown on MISO. The master sends "enumerate" command, and all slaves load a value like "1" in their shift register. Then the master sends 8 clocks, shifting all the registers from one sensor to the next. The first sensor, having MISO pulled low, reads a zero, so it knows it's first. Then the master sends 8 more cycles, and the zero reaches the second sensor, so it knows it's second. Etc. When the zero reaches the master, it knows the number of sensors in the chain is equal to the number of 8-pulses it sent.