MILAN - The Physical Layer

[Peter Snowberg]

MILAN - The Physical Layer - Version 1.0

The Musical Instrument Local Area Network (MILAN for short), is an open standard for the inter-operation of devices in the instrument-effect-amplifier-stage environment.

MILAN uses industry standard EIA-485 (also called RS485) for signaling. Volumes have been written about EIA-485 so I will only provide a brief overview and mention some specific points as it relates to our needs as effects builders and users.

EIA-485 allows up to 32 transceivers to share a single twisted pair of wire which may be up to 1000 feet long (using a bus topology) at the transmission speed of MILAN. By using differential signaling, MILAN provides high noise immunity over very long cable runs. In differential signaling the difference in voltage between two conductors is used instead of the absolute DC voltage between a single conductor and ground. Noise that enters the cable via magnetic coupling will affect both of the signal lines in the pair by a roughly equal amount, preserving the difference between them and thus the data flowing over them.

One requirement of EIA-485 is that the twisted pair transmission line must be terminated at the ends by a resistor (called a terminator) that has roughly the same resistance as the characteristic impedance of the cable (roughly 120 ohms). This simply involves adding two resistors to the line, one at each end. These resistors literally eat the excess signal as it reaches the end of the line and stop it from bouncing back towards the transmitter where it provides significant noise. In fixed installations of EIA-485, the resistors are commonly just hardwired at the ends of the line.

After initially resisting to include the connectors in the standard, I've now gone in the other direction. I am specifying three standard connectors; the 3.5mm TRS (tip-ring-sleeve, a.k.a. headphone connector), 1/4" TRS (a.k.a. phono connector), and 5 pin XLR. Both TRS connectors will use the following connections:
  _
/ \  <- Tip; MILAN+; used for positive network wire
\_/
|_|  <- Ring; MILAN-; used for negative network wire
| |
| |  <- Sleeve; optionally used for ground
| |
#####
#####
#####
#####
#####
#####
#####
###

I've settled on TRS for several reasons including:

- the connectors are ubiquitous
- inexpensive
- fairly rugged
- very high quality makes are available
- they're easy to solder
- no special tools required
- multiple terminations can be made within the same plug
- PCB mounted parts not required
- only round holes needed in chassis
- off the shelf cables are available
- two 3.5mm jacks can fit easily in most effects
- switching jacks allow for automatic termination

Let's consider that last one. The most traditional topology for an EIA-485 network is a long bus with a terminator at each end. By using normally closed switching jacks, it becomes very easy to implement automatic termination. Each device providing automatic termination will provide two connectors, each one having a 120 ohm resistor connected between the ring and switched tip connections. When plugs are inserted into both jacks, both resistors will be disconnected. If only a single jack is connected the other jack in the pair will still have its resistor across the line, providing termination. Removing the need for manual termination of the network provides plug-and-play operation and reconfiguration.

I considered many other connector systems but the only other one I see as important for MILAN is XLR. A 5 pin XLR connector would be preferred for a highly robust implementation where locking connections are desired. 5 pin XLR is commonly used in stage applications for lighting equipment using the DMX standard. DMX also makes use an EIA-485 physical layer. By using 5 pin connectors instead of 3 pins, microphone cables which may be using improper wire will not be mistakenly plugged into MILAN connectors.

MILAN uses a transfer rate of 230400 bits per second.

Next installment: Addressing and Data Transport. 

[David]

Peter:

You may throw rotten eggs at me for this suggestion, but you could always substitute 5-pin DIN cables...
... also known as MIDI.  You have to admit they're easy to find.

[Peter Snowberg]

No rotten eggs, but I will explain my reasoning. 

MIDI cables don't use twisted pair wire so they're the wrong animal for an EIA-485 based network. Additionally, DIN connectors are bulky and much harder to find than stereo TRS connectors.

In a stage application where the 5 pin XLR would be preferred for the locking connectors, you can already find extra cables which are specifically made for EIA-485. Just ask the lighting crew.

In home or garage band use, the TRS system is an advantage for the reasons outlined above.

Plus.... I hate DIN plugs. 


Side Note: I used to work for the guy that started Avab America. They made the first microprocessor controlled stage lighting dimmer on the market and they also introduced the technology that finally became DMX which is the standard for lighting now. If a stage worthy connection is required then XLR is it based on what the world has already gravitated towards.

[genie]

Peter,

Why don't consider extended EIA-485 with speed up to 1Mbps?? It's called CAN-bus, and also cold as the most innexpensive way in serial communications. Developed by Bosch, ISO-11898. Please read the following.

Why CAN in general? http://netsynth.org/forum/index.php?topic=83.msg229#msg229

genie

[Peter Snowberg]

CAN is really built for industrial control in places like cars or complex machines where simple control messages are sent between points of a strictly defined environment. It's is great for that type of thing but we need something a little more plug and play friendly which is designed for the task.

I considered faster speeds but chose 230.4Kbps as a data rate because it gives a nice trade-off between cable distance, flexibility in network topology, and data rate. Since this system is based on the Atmel AVR USART hardware, the data rate also ends up influencing the minimum CPU clock speed and that directly influences power consumption. A 230.4K data rate requires a minimum clock speed of 1.8432MHz where as 921.6Kbps requires 7.3728MHz. The reason behind the slightly odd numbers is that the same oscillator will also support standard baud rates.

I don't know if faster speed is required. We'll have to see by experimentation. The present speed should allow for a maximum of about 3,500 16 bit parameter updates every second (with error checking). This should accommodate the live manipulation of several knobs simultaneously while maintaining update rates in the 100s per second. By low pass filtering control changes we can get even smoother results.

If this isn't fast enough, there are multiple speed-bumps built into the hardware and the transceivers are good to a much higher data rate. Inexpensive 16MHz AVRs can run with data rates up to 1.8432Mbps in this network scheme but the cabling becomes a serious consideration at these speeds. 20MHz parts are capable of running at 2.304Mbps. At the much slower 230.4Kbps, communication is very rock-solid in highly adverse environments even with shoddy cable.

I'm working away on the protocols now. Things are progressing nicely. 

[DavidS]

How do the speeds listed above stack up to MIDI?

[Dave_B]

MIDI runs at 31,250 bits per second in one direction (requiring two cables to handle in and out).
MILAN runs at 230,400 bits per second, and is bi-directional. 

[Peter Snowberg]

Once you add protocol overhead to the picture it gets harder to make direct comparisons. As Dave pointed out, the base bit rate is 7.37 times faster so now lets talk protocol a little. MILAN requires a "quiet time" on the bus of at least 2 byte periods before beginning a transmission. Add to that an 8 bit address, 8 bits of function code, and 8 bits of checksum. MIDI doesn't have to wait for any bus idle time; it just sends a 7 bit opcode followed by 14 bits of data contained in 16 bits of data.

In the end to send a controller value:

MIDI:
opcode + data1 + data2
(24 bits data + 6 bits framing) @ 31.25Kbps = 960 microseconds

MILAN:
(rest_period) + address + function code + data1 + data2 + checksum
(40 bits data + 30 bits framing) @ 230.4Kbps = 304 microseconds  - Roughly 3 times faster

Now what about sending 5 controller values?

MIDI:
op1 + d1 + d2 + op2 + d1 + d2 + op3 + d1 + d2 + op4 + d1 + d2 + op5 + d1 + d2
(120 data bits + 30 bits framing) @ 31.25Kbps = 4800 microseconds

MILAN:
(rest) + address + fc1 + d1 + d2 + fc2 + d1 + d2 + fc3 + d1 + d2 + fc4 + d1 + d2 + fc5 + d1 + d2 + checksum
(136 data bits + 50 bits framing) @ 230.4Kbps = 808 microseconds  - Roughly 5.9 times faster

As you can see the protocol overhead is higher with MILAN so minimizing the number of packets greatly accelerates the transfer rate.

When we're sending a single 14 bit MIDI controller value vs. a single 16 bit MILAN controller value, MILAN is roughly three times faster than MIDI (at max). When you transfer more than one value per packet the MILAN overhead is reduced so in the 5 value example MILAN is approximately 5.9 times faster than MIDI (at max).

MILAN is also providing 16 bit data rather than MIDI's 14 bits, 8 bit of data rather than MIDI's 7 bits, and it has error checking built in.

It's very early in the morning so I hope I got the numbers right. 

[The Tone God]

I agree with Peter that CAN is not appropriate for our application. Also I think it is important to keep atleast the uC stuff processor independent so for those who worship at the altar of a different processor can still interact with other hardware when it is established.

Awhile back I thought about something similar but I used a primitive version of SPI which could even been done with simple logic ICs so those without the uC background or just the lack of need for a basic piece of hardware could skip the uC portion. It could be done using two stereo cables for the bus. It would not offer up the features of what Peter is working on.

I want to be able to interface with this:



as I eventually want to the build this:



Too obscure ? UK fans may need to apply.

Andrew

[DavidS]

That was a rude little toaster. Poor Lister, last man alive and he has to deal with unpleasant, disaffected appliances...

[aron]

Hmmmm I think it might a harder sell for a protocol that's only 3-5 times faster.... Personally I don't like the rest period myself ( is this a requirement? )

Also, what about system exclusive packets - I mean large ones?

[Peter Snowberg]

Hmmmm I think it might a harder sell for a protocol that's only 3-5 times faster.... Personally I don't like the rest period myself ( is this a requirement? )

Also, what about system exclusive packets - I mean large ones?

On the SysEx question, yes. There are datagrams available with a length of up to 64K bytes.

The rest period is just a requirement of CSMA (Carrier Sense Multiple Access) networking. Different transmitters will not be inherently in sync so when one node decides to transmit it needs wait a small amount of time to make sure the bus is not already in use. This is the purpose of the rest. If you wait two byte times and don't see any traffic there is a good chance you can transmit without causing a collision. In the end the consistent tiny delay if what you get for the benefit of a topology with zero slurring of the time sync between nodes.

The downside of a CSMA bus versus the ring topology of MIDI is that performance degrades as the amount of traffic goes up. MIDI runs into a wall, but bus networks degrade.

I started thinking about this network a long time ago as a MIDI replacement but then recently brought it back as just a method of passing stompbox control values. I'm amazed by how long MIDI has clung on so maybe there is still some room to push MIDI aside? Hmmm... Perhaps a speedbump is in order.

If the bitrate gets bumped to 921.6Kbps and LTC1485 (or equiv.) transceivers are specified, the cable length can be roughly 450 feet which should be fine for most uses. The downside is that the lowest clock speed would be 7.3728MHz... hmmm..... still inside 8MHZ.  I guess that's not too bad.


Thanks everyone for the comments and questions. Keep them coming. I'm getting pretty close to the transport that I've been hoping for.