Joining two UART TX outputs directed to a third UART RX input   - Page 1
Forum section: electronics / beginners

author: Back2Volts
author_rank: Unknown
timestamp: April 23, 2020, 02:47:16 pm
content: I am working on this project where there is an existing setup where an MCU has a TX line to the RX of another. It is a radio remote receiver passing received commands to an sprinkler controller. The project involves adding my own MCU to feed commands on the same line, while keeping the existing connection. The chance of command collision is practically non existent because I am the user. The idea is to use the iPhone on the new path.The signal is 4800BPS, 5V idle high and the wire is on the open a screw terminal. I wonder if I can just OR the signals, or if I would need for a more elaborate mechanism, like some switching when the new MCU needs to use it.Any ideas will be appreciated

author: Manul
author_rank: Super Contributor
timestamp: April 23, 2020, 03:06:13 pm
content: Based on your description, you can use AND gate I think.

author: magic
author_rank: Super Contributor
timestamp: April 23, 2020, 03:29:39 pm
content: An idle UART actively drives its TX line high so you cannot simply connect another transmitter and send something.A relatively simple solution is to route the existing line to the MCU and make it repeat received messages to its own TX.

author: pqass
author_rank: Super Contributor
timestamp: April 23, 2020, 03:35:28 pm
content: You're going to need to break into the existing TX-RX line.If your new TX forces the line low, you'll be fighting the existing TX which is trying to keep it high. This is bad news for both transmitters.Similar to a level shifter where HV=LV and each transmitter gets a LV resistor and mosfet.And where the receiver has the single pullup resistor.This works because if any transmitter is low then their mosfet is on; forcing a low on the HV side. However, if a transmitter is high, then their respective mosfet is disconnected; so the HV resistor will pull the line up if no transmitters are low.It's okay to have multiple low transmitters; they're not shorting the power supply. In this arrangement, you'll never have one transmitter high while the other low [while both are connected to the receiver].

author: Manul
author_rank: Super Contributor
timestamp: April 23, 2020, 04:05:27 pm
content: Quote from: magic on April 23, 2020, 03:29:39 pmIf added delay is not a problem. In some cases it may crash existing comms. Anyway, this solution by magic or AND gate. Collision while using AND gate will cause corrupted data, but no damage. In OP it is said, that collisions can be made to not happen.

author: Back2Volts
author_rank: Unknown
timestamp: April 23, 2020, 04:17:06 pm
content: Quote from: magic on April 23, 2020, 03:29:39 pmIt would be an option. I may be using an Rpi Zero W, rather limited in UARTs...

author: Back2Volts
author_rank: Unknown
timestamp: April 23, 2020, 04:23:38 pm
content: Quote from: pqass on April 23, 2020, 03:35:28 pmI like this solution because now I realize that I also have to deal with the fact that my MCU will have 3.3V output, so I could set one of the paths with 5v/5v and the other with 3.3v/5v

author: magic
author_rank: Super Contributor
timestamp: April 23, 2020, 08:57:05 pm
content: Quote from: pqass on April 23, 2020, 03:35:28 pmIt doesn't work because this circuit is bidirectional. When one TX goes low, the HV side is driven low and then the other LV side is also driven low while the other UART is driving it high.If anything, make it simply a pullup resistor on the HV side and schottky diodes from HV to each of the LVs.editSorry, that won't work if one of the UARTs runs at 3.3V.But the 74HCT logic is made for such interfacing jobs, its inputs accept either 3.3V or 5V as high and its outputs are 5V when high. 74HCT08 is the AND gate. If you can't stand the big chip of which only 1/4 will be used, truth is that 74LVC1G08 will almost certainly work too even if it isn't guaranteededit editHaha, they make the old HCT family in SOT23 too. So you could use the 74HCT1G08.

author: pqass
author_rank: Super Contributor
timestamp: April 23, 2020, 09:18:36 pm
content: Quote from: magic on April 23, 2020, 08:57:05 pmDoh! You're right. Don't listen to  me.Maybe go with schottky diodes like this diode-AND gate:But if one TX is 3.3V, I'm not sure you can rely on that TXs built-in diode to clamp the 5V coming from the RX side.

author: Manul
author_rank: Super Contributor
timestamp: April 23, 2020, 09:39:22 pm
content: In that case why not use a TTL compatible family (like HCT, AHCT) gate? Powered from 5V it would accept 3.3V logic. So it would be a gate and a level shifter. Something like SN74AHCT1G08.

author: Back2Volts
author_rank: Unknown
timestamp: April 24, 2020, 12:57:07 am
content: I think I will go for a 74HCT gate. I will start with a 14-pin large package because, at least for now, this is going into a through hole solder breadboard. May be later on a custom PCB.Thank you guys for all the ideas and the discussion.

author: David Hess
author_rank: Super Contributor
timestamp: April 24, 2020, 09:02:46 pm
content: A gate will work but gives no indication of which sender is the source. So a bistable latch could be added and if the bistable latch does not produce a stable output, then there was a collision.The next step up uses an edge triggered flip-flop or latch to connect whichever source sends first while blocking the other. Then at the end of the message, the MCU resets it to wait for the next message.

author: Back2Volts
author_rank: Unknown
timestamp: April 25, 2020, 02:52:53 am
content: Quote from: David Hess on April 24, 2020, 09:02:46 pmThat would round it up, but the chances of collision are very small. If I felt I really needed it, I could feed the other line to the RX pin of the same UART just as a control, if not even to plainly forward it as suggested in a previous post.The application is an alternate iPhone remote path for a existing home sprinkler controller, which is normally doing its thing. There is occasional need to override it, but when it happens it always involves multiple interactions which I would like to queue at once with a better interface, and which is where the design challenge is starting to shift...Thinking aloud, may be I may just try to read/forward the line... I'll make the decision when I fully understand the remote protocol for which I am preparing a headless Rpi with pulseview to hookup in the garage. From what I have read, the controller never talks back to the remote, but I have not seen that myself...