[sdiy] MIDI specifications

[Gene Stopp]

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

>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 :)

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...

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. 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.

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

- Gene


-----Original Message-----
From: Magnus Danielson [mailto:cfmd at swipnet.se]
Sent: Wednesday, April 16, 2003 6:02 PM
To: gene at ixiacom.com
Cc: synth-diy at dropmix.xs4all.nl
Subject: Re: [sdiy] MIDI specifications


From: Gene Stopp <gene at ixiacom.com>
Subject: RE: [sdiy] MIDI specifications
Date: Wed, 16 Apr 2003 17:15:27 -0700

> Hey I remember that from my RS-232 datascope days...

OOOoooo - when is that released? ;O)

> Async data means there are no bits on the wire when there is no data being
> sent.

It actually doesn't mean that, but it has that effect in this case. Being
the
nitpick I am here is a little side-track:

Synchronous means that the information of a signal arrives in the same clock
or rate as another signal.

Isochronous means that the information of a signal arrives in the same clock
or rate as other information on the same signal.

Asynchronous means not synchronous, i.e. the information does not arrive in
a
synchronised fashing in relation to some other signal.

Anisochronous means not isochronous, i.e. the information does not arrive in
a
synchronised fashing in relation to previously sent information of the
signal.

(Many confuses all this up, since an isochronous signal is often synchronous
to the clock at the transmitting device, but if you don't have access to
that
clock the property is meaningless and you can only speak of a isochronous
signal.)

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).

For the lack of isochronism (or synchronism with some other signal) in MIDI
(and other normal serial communication) causes the need to bit-synchronise
to
know when the bits comes in a transfered byte, and also when there is a
transfered byte, since that is too unknown when it occurs.

This need for synchronisation and identification of begining of byte calls
for
the start bit/stop bit scheme. You pay a price for not being isochronous or
synchronous.

> Let's say the wire has two states, high and low, and when there is no
> data it's high. The Start Bit is a low for one bit time. The next bit time
> can be either high or low, and that bit is the first bit of the byte
> (usually the one on the left if you write the byte 1001XXXX, for example).
> The rest of the bits continue as either high or low, as expected. The
first
> bit time after the last bit of the byte must be high, and this is the Stop
> Bit. Sometimes you will hear the term "Two Stop Bits", and what this
really
> means is that there is a minimum separation between the last bit of the
> previous byte and the start bit of the next byte of two bit times. In
other
> words, the Stop Bit is really part of the dead time between bytes which
can
> be any amount of time, up to infinity.
> 
> Since the Start Bit is required, and at least one Stop Bit is required,
> every byte on the wire is considered to occupy 10 bit times.

Exactly.

If memory serves me right non-transmission is logical high, start bit is
logical low and stop bit(s) is logical high.

There are even such obscene things like 1,5 stop-bits.

What seems unknown to some people is that UARTs actually make multiple
samples
of the bit and make majority decissions on the bit-value. Since you usually
run
at 16 times the bit-speed on the reference-clock, there is no problem in
placing
3 or some other un-even number of samples. By summing them up an comparing
to
the limit the majority sample-count winns.

Another interesting this is that you never really have synchronous clocks,
but
since a byte-transmission only lasts 10 bits or so, the synchronisation
provided by the start-bit is sufficient so that bit synchronisation isn't
lost
due to clock differances throughout the byte.

HMPF! Why do I know more about this subject than I really think is
necessary?
Life is hard and serial ports is a mess.

Cheers,
Magnus