[sdiy] MIDI specifications

[Magnus Danielson]

From: Gene Stopp <gene at ixiacom.com>
Subject: RE: [sdiy] MIDI specifications
Date: Thu, 17 Apr 2003 07:23:53 -0700

Gene,

> Hey nice list of synchronization methods - I think I'll keep this email here
> at work for future use!

Thanks! ;O)

That was the short-story only relevant to this particular problem. There are
more definitions which helps to lay out the field in more detail. When you dig
into synchronisation issues for telecom equipment and try to define things you
end up having to learn the propper definitions. I've even been sitting on a
standardisation commission working on a Terms and Definitions document, with a
pair of old and friendly german colleages, and this forced me to relearn some
of the definitions, while I helped clean up some others (I had great fun when
opposing on the ITU definition of telecommunication - it was not a definition
to start with and was open for a grave correction - even the Philips EE-series
books where more accurate than ITU on that definition, which should give you a
hint on how bad it was).

> >MIDI (and most of the time V.24/RS-232)
> >is large-scale anisochronous (i.e. we
> >don't know when the next byte comes)
> >and small-scale isochronous (we do know
> >when the next bit come within the transfer
> >of a byte).
> 
> The link layer chips should have been called ULSASSIRT's but that wouldn't
> fit on the datasheets :)

Oooo.... he said "link layer"... so there's still people out there that believes
in the ISO OSI layering crap? (The OSI layering caused more headache than it
solved, the OSI degeneration with the IP world leaves even more to be desired.)

But yes, it is a bit long.

> The start/stop overhead does not really need to be considered other than for
> line utilization and bandwidth calculations, since the chips take care of
> this for you. Unless you make your own from scratch...

Exactly. He was trying to push things out of a CPU/MPU if I recall things, so
then he does need to know.

Also, you where incorrect on another thing, in RS-232 you actually have three
levels, and if you don't understand this you won't easilly grip why turned of
equipment causes other equipment to malfunction. 0V is the "break" level, having
a totally distinct meaning from that of logical high and logical low.
In MIDI there is fortunatly only two levels. However, three-level signals make
the world tick (PDH tends to use it, besides all those RS-232 stuff).

> One thing that is useful when thinking about these things in MIDI is the
> true culprit behind the "minimize the MIDI thru connections" advice. When
> the chain of MIDI thru connections consists of physical layer repeaters, as
> shown in the MIDI spec for example, there will be cumulative bit distortion
> for each current-loop-to-logic-level-to-current-loop interface.

Exactly. You do get what the DWDM-people call "2R" - i.e. Reamplify and Reshape.
Since you go through logic gates and not just linear amplification you do get
reshaping. However, that only gets you so far.

> If enough thru connections are daisy-chained, the UART at the end won't be
> able to frame the bytes properly and you'll get 16x sampling errors and
> probable mis-interpretation of the commands. In other words, stuck notes.
> It's not a delay thing, it's a distortion thing. Unless the MIDI device frames
> the bytes and re-transmits - this will regenerate the bit edges offering
> potentially infinite thru-chain hop counts, but now you will see delay
> issues since the process will be store-and-forward.

Right, you need what the DWDM-people call "3R" (please note that I have a 3R
STM-16 DWDM node on top of my screen as I write this, and a few more lying
around here and there...) where the third R is really Reclocking.
For isochronous signals you just to clock-recovery and send the data through a
DFF. For anisochrounous signals like MIDI you must to a synchronisation also,
but if you implement that then you could also do 3R with only half-a-bit up to a
bit or so of added delay.

Now, what is the *real* issue here? Well, it's jitter. The problem you have with
transmissions like this is that the transmission-path (drivers, contacts, cable,
contacts, opto-isolator, receiver) will smooth out the signal some, this will
cause previous bits moving the DC offset and this will cause the trigger point
for the bit-synchronisation (regardless of this being a *real* clock-recovery or
the RS-232/MIDI synchronisation detection) to move in time. When it moves in
time the sampling will be less optimally, closer to eather of the transition
periods. This is really how the fundamental bit-error tends to occur. It is
very well analysed and telco people care *alot* about it while datacom people
recently started to care (they have cared, but then it was on the level "broken"
and "not broken" device almost).

You can solve such issues by carefull design throughout, but MIDI being such a
cheapertronic interface I have no hope that it will be fixed "for real".

> Uh oh, I'm lapsing into work-speak.

Me too. ;O)

Cheers,
Magnus - into synchronisation, line encoding, jitter and wonder issues