First off, this has been stated before, but: UART is not an appropriate sensor interface here. Pick a different sensor, if possible. I'll assume it's not possible, otherwise you wouldn't be going through all this effort.
I personally think the most important question hasn't really been answered by you:
- Is this some sensor that you query, and it responds, afterwards, or
- Will the sensor continuously send data?
The first case might be the easier one, because it would allow you to take one UART, and multiplex it between multiple sensors, meaning that you connect TX to the first, talk to it, then reconnect to the second, and so on. RX would be shared between all the sensors on the bus, but because it's a query/answer system, you'd always know who's currently talking (the one you asked).
If it's the second case, well: You'll need something that manages each of these onto a more flexible bus.
- get a cheap microcontroller that can talk UART on one side, and I²C on the other, one for each of your sensors. Boards should be small, and the BOM would be < $3, ideally.
- Write firmware that makes it possible to query the sensor via I²C. That means relaying things the "controller" sends via I²C to the device, and storing the data the device sends via UART long enough for it to be requested by the master. That's not a very complex firmware, but it's still a bit to write and debug. It's probable that if you do this on a popular platform (arduino, stm32), someone else has done it before.
- Assign a separate I²C address to each one of your translators.
There's not infinitely many addresses, and not infinitely much bandwidth, so bundle a reasonable amount of sensors via I²C to one bus each. Use a Full-Speed (12 Mb/s) USB capable microcontroller to interface all your translators, and relay the data to your PC. You can have multiple of those.
Also, there might be ready-to-use UARTs that might be usable via I²C as bus extenders.
There's Microcontrollers that have built-in Ethernet controllers. You just need to an Ethernet Phy (there's a standardized interface for that, called MII). Ethernet
- allows for practically arbitrary numbers of devices, and
- ethernet cables can be long,
- ethernet switches cost < 2€/port
- ethernet switches can aggregate a lot of slow, easy to design 10 Mb/s links to one 100 Mb/s or gigabit ethernet link,
- ethernet is actually meant for huge buses,
- and is really easy to connect to – just write network software for you PC (no driver development in any way, just handle raw network packets),
- depending on what the examples from your microcontroller manufacturers offer, you get a complete ethernet stack, including things like autodetection by just letting your firmware periodically send "hey, I'm here" broadcast packets.
I'd go with that solution. The ST STM32F107RC and similar microcontrollers come with said MII interface and up to 5 USARTs. Or go for the NXP LPC1830, which is significantly cheaper, but only has 4 UARTs.
That would be
- one LPC1830 6.17€, connecting four UART sensors at once
- one RMII fast ethernet PHY 0.80€
- Ethernet connector with integrated magnetics 2.70€ (cheaper if you do separate magnetics and connector, but might not be worth the additional assembly effort)
- Power supplies, discretes 2€
- PCB manufactured in China 1.50€ (might be cheaper if you panelize properly)
Firmware: Ethernet example code from NXP, hand-written UART handling
Makes a total of about 13.50€ for 4 sensors, or about 3.50€ per sensor. You need 25 of these to connect 100 Sensors. You need a 24-Port gigabit ethernet Switch, plus another small switch for the rest which adds maybe 50€ to the bill (pre-VAT).
The benefit would be having a system that you can extend arbitrarily. If you're feeling adventurous, use an IP stack on your microcontroller (lwIP, µIP) and make it possible to deploy your devices within any LAN, even across network boundaries such as the internet and so on.
Edit: Turns out NXP ships examples that do the full TCP/IP dance on the MCU. Oh well, all the simpler then.