Multiple Teensy and MIDI serial Tx Rx

Status
Not open for further replies.

ghostintranslation

Well-known member
Hi,

I'm looking at connecting together multiple Teensy via their Tx and Rx pins so they can communicate using MIDI.

I'm wondering if I can do this:
excalidraw-2020122135316 (2).jpg

So basically connecting all of their Tx and Rx together. They would all act as Masters so they can possibly all send and receive (like the 3 at the top in the picture).
I'm not sure if that's called a "Multi-drop" architecture, if someone can confirm/or not?

What's not apparent on the picture is, they would have diodes on their Tx, so Tx would only send and not receive.
Also they would have their ground connected together.

Because they would use MIDI, messages are broadcasted to everyone but they have a "channel" number so only the devices listening on the same channel would react.

Is that something possible? Without involving more electronic than just wires and diodes?

Thanks
 
coming from more of an audio world, isn't there a chance that by just splitting the data signal to several ddevices all with their own impedance, you might end up with too little current for the receiver to register? you migght need a simple buffering circuit.

you want to look ad "midi merge" and "midi thru" circuits maybe, even though what i know is just "classical" midi involving optocouplers etc so not sure if that pertains to direct serial connections.

i am currently building a synth that needs a bunch off MCUs to communicate via midi as well, started out on DIN with midi thrus, then moved to serial but writing/adapting the midi protocol/nrpn parsing for some of the boardsd was too tedious and losingg packets etc, then i tried midi over usb which worked great for a while but ultimately, in conjunction with my real PSU and the usb power pluggin led to a giant system breakdown so nnow i'm back to good ole DIN midi and won't dabble in anything else for a while. you could say i'm burnt on homebrewn serial.
 
coming from more of an audio world, isn't there a chance that by just splitting the data signal to several ddevices all with their own impedance, you might end up with too little current for the receiver to register? you migght need a simple buffering circuit.

you want to look ad "midi merge" and "midi thru" circuits maybe, even though what i know is just "classical" midi involving optocouplers etc so not sure if that pertains to direct serial connections.

So worst case most of the messages would be lost but it should not burn the Teensy? If there is no risk of destroying the Teensy I'll give it a try keeping in mind what you said.

i am currently building a synth that needs a bunch off MCUs to communicate via midi as well, started out on DIN with midi thrus, then moved to serial but writing/adapting the midi protocol/nrpn parsing for some of the boardsd was too tedious and losingg packets etc, then i tried midi over usb which worked great for a while but ultimately, in conjunction with my real PSU and the usb power pluggin led to a giant system breakdown so nnow i'm back to good ole DIN midi and won't dabble in anything else for a while. you could say i'm burnt on homebrewn serial.

I could do a MIDI Thru style but I'm trying to avoid it because it means having all the Teensy in serial instead of parallel, so that means the more device the more latency. And also if I want to change the devices order I will need to reconnect all of them properly.

Thanks for your answer.
 
MIDI does not provide bus arbitration.
So how could you prevent two Teensy from transmitting on the bus the same time, destroying the signal? Limiting resistors would at least prevent the output drivers from being destroyed as well.

A connection like shown on your sketch looks more like a CAN bus. This does provide bus arbitration and can be quite fast on short connections. The only drwback is, it is asynchronous and anisochronous , so if you use this, you may need a bus-independent master clock.
 
What's not apparent on the picture is, they would have diodes on their Tx, so Tx would only send and not receive.
Also they would have their ground connected together.

If 2 or more transmit at the same time, or similar enough time that any part of their messages overlap, all devices will receive corrupted data (ones altered to zeros). Even though each transmitter will have an opportunity to hear whether its message was sent as intended, all the other listeners will not be able to discern good data from bad, because MIDI doesn't use CRC checks or parity bits or any other way to verify message integrity. The efficient binary nature of MIDI protocol means a wide variety of random binary data may be parsed as valid messages. When you factor in the possibility of conflicts appearing as false start bits (more bytes than intended received) or corrupted stop bits (fewer bytes received), bits from each transmitter not aligned to the other transmitter's baud rate, and the possibility that future messages using MIDI's running status feature could be interpreted as the data payload from previously corrupted bytes, there are a lot of failure modes where all the other receivers hear wrong MIDI messages they can't be reliably reject or distinguish from the correct messages.

Even if you avoid transmit collisions, there's also the electrical issue of noise margin. Normally 3.3V logic signals are not used over long distances. In this case, the forward voltage drop of those diodes eat away at your noise margin for logic low. It can probably be made to work electrically if you're careful. The longer the distance, the more problematic it can become.

But I don't see any way to handle the case of collisions using only MIDI protocol. To make this work you'd probably need to implement a much more robust protocol, where each message has error detection, where each transmitting device verifies its message didn't collide with any others, and in the case of collision some sort of scheme where each transmitter retries in some way where they aren't likely to collide again. Or a "token passing" system where each device gets a well defined opportunity to transmit. That's not impossible, but it gets complicated quickly...
 
If you connect the Teensy like shown on your sketch, you will need limiting resistors on the TX lines. The RX lines have an impedance high enough so the signal will get through.
A solution to the arbitration problem oculd be you add a second wire B connecting Teensy 1 with 2 and 3 and high via pullup resistor. A teensy just needs to check if that line B is high, meaning the bus is free, and the set B to output low, do the TX and set B to input again, allowing others to transmit. If you want to make this arbitration scheme really safe, make a third line C that is used as a pre-allocate and use different step timings from pre- to main-allocate, each with a check and step-back on race.
The connections to B (and C) need limiting resistors as well, just in case of congestion or race condition.
 
I see, there will be so many messages at the same time it seems too tricky to do just a simple "free-bus flag". And I don't want to encapsulate this into another protocol to keep it compatible with regular MIDI on the same wire (so it can be used with a commercial midi device too). I'll forget about connecting them like that...

Then connecting them in serial would be the proper way, like that:
excalidraw-2020122135316 (5).jpg

Each device send the messages that are not for it in addition to its own messages.
So that brings in latency but I will have to try it. I'm planning on having about 10 Teensy so I'll test the latency, I can probably get around by sorting the devices so the ones that needs clock messages (we don't want latency on those) for example are next to each other to limit latency on them.

And so in this way of connecting the Teensy together, should I worry about impedance or electrical issues, I would just have the diode on Tx and it is very low distances (about 15cm for each wire)?

Thanks for all the answers, that helps a lot.
 
Yes, but then you have latency between them, because every Teensy receives am message, processes it and forwards it. The usual MIDI-problem.
I thought you wanted to get rid of that by making a star-topology.
One thing to keep in mind:
With the connection like above, you will instantly flood the MIDI line, because every message gets transmitted round and round infinitely, if you do not implement some kind of sorting-out before retransmit/forward.
 
Yes, but then you have latency between them, because every Teensy receives am message, processes it and forwards it. The usual MIDI-problem.
I thought you wanted to get rid of that by making a star-topology.
Yes I'm trying to prevent too much latency so I'll give the serial a try, but if there is too much latency then I'll have to find another way.


One thing to keep in mind:
With the connection like above, you will instantly flood the MIDI line, because every message gets transmitted round and round infinitely, if you do not implement some kind of sorting-out before retransmit/forward.

Ah right, Then I would have to make a chain and not a loop, like that:

excalidraw-2020122135316 (6).jpg

But in that case Teensy2 cannot speak to Teensy3 and Teensy1 cannot speak to Teensy2 nor Teensy3.


So another solution would be to have a Teensy acting as an active patch bay:

excalidraw-2020122135316 (7).jpg

When a device send messages, the Patch Bay broadcast those messages to the other devices. That's it, no midi thru.
So the Patch Bay would queue the messages when 2 devices sends things at the same time.

I think that one makes more sense, what do you think?
 
Absolutely.
Then all the devices connected to the Teensy#4 definitely need to be configured so they do not retransmit. Some keyboards, for example, are configured by default to retransmit and a single device doing so will flood the patch bay instantly, so there is big chance for trouble.

Or the trick will be for the Teensy#4 to sort out forwarded "mirrored" messages of the individual other devices, so a sophisticated packet-inspection/state-engine will be needed.
 
Yes, simplest is just to not retransmit, there is nothing in the MIDI library that automatically retransmit thing, you have to code it if you want it. So the devices will just send and receive, as usual, and a Teensy would be the patch bay, broadcasting the incoming messages to everyone just 1 time.

That makes this project even more interesting :)
 
to keep it compatible with regular MIDI on the same wire (so it can be used with a commercial midi device too)

Yes, if you just connect your own Teensy devices, that is all very simple. But if you connect other devices, like you wanted to do (see quote), that could cause the mentioned problems, if the patch bay does not filter forwarded messages.
Good luck!
 
Yes, if you just connect your own Teensy devices, that is all very simple. But if you connect other devices, like you wanted to do (see quote), that could cause the mentioned problems, if the patch bay does not filter forwarded messages.
Good luck!

Well usually the MIDI thru is separated from the MIDI out, so that would only happen if the device has a merged MIDI thru+MIDI out, but I imagine that in those devices there would be a setting to activate/deactivate the forwarding (not actually sure about this because I don't have such devices). If that's the case then just connecting the MIDI out from external devices will not cause any problem.

Thanks!
 
Status
Not open for further replies.
Back
Top