MILAN - Musical Instrument Local Area Network

[Peter Snowberg]

Almost 15 years ago I created a proposal for a communications system that would be able to pass control parameters around an effects environment. To a great degree it was meant as something that could replace the limited and ageing MIDI standard which was never originally intended for prime time.

My proposal was based on the physical layer of Apple's LocalTalk networking system. This is a transformer isolated RS-485 multi-drop network with the ability to connect up to 32 nodes via a single twisted pair of phone cable. This approach eliminates ground loops, allows for runs of up to 4000 feet, and it uses cheap-as-dirt category 3 twisted pair wire which is very easy to work with, requiring no special tools. I used the same IBM invented FM signaling method that Apple did, and set the data rate the same 230,400bps which is over 7 times faster than MIDI. It differed from MIDI in that it was a multi-drop network, rather than the chain of serial point to point links that MIDI is. The change in topology eliminates "MIDI slur" which is deadly to trigger signals and the increase in data rate allowed for the increase in traffic that would be seen on the net topology. 

MIDI was built around the use of an inexpensive and obsolete UART being clocked with an inexpensive 2MHz crystal. There is no reason to use the parameters of these two cheap parts as a base for a standard any more. My standard on the other hand required the use of a serial chip that would encode data using SDLC signaling in order to make use of transformer isolation and the only real commercial solution was the expensive Zilog 8530 SCC. These chips are big, power hungry, expensive, and at times they were difficult to get with a lead time of several weeks. I eventually wrote a software emulation of the 8530 features I needed using a Ubicom SX28, but by that time Ethernet was pretty firmly entrenched and I just hoped that equipment would start to have 10baseT ports.

Although it had a number of things going for it, I never did anything with this proposal. Now here we are in 2006, microcontrollers are cheap and readily available, and it's time the DIY crowd finally got the use of an interface that MIDI never will be.

I'm bringing back my proposal, but in a little different form. I'm dropping the transformer isolation because of the problems with the complexity of the signaling method, but keeping the RS-485 signaling and the 230.4Kbps data rate. If I can get people to agree on what this thing is and how to use it, we'll be able to produce universal control devices and highly integrated control systems that give us options we never had before. Since we're mostly guitarists here, we won't have as much use for note data as the synth crowd does. We're probably going to be more interested in moving control values around to affect effects. This proposed standard will be free for all to use, for DIY or commercial purposes.

_________________________________________________________
Musical Instrument Local Area Network
_________________________________________________________

What is it?

MILAN is a medium speed network specification intended for the inexpensive networking of devices in the instrument-effect-amplifier environment.

Why are you doing this?

MIDI has quite a number of shortcomings such as the use of 7 bit values, it's slow, it suffers from latency problems, it uses big ugly connectors, it's not flexible enough, etc., etc.

MILAN is intended to be a cheap and easy way to get meaningful control data from a user interface into a variety of control devices at the same time while bypassing most of the major issues with MIDI control.

I would like to see a standard interface for controlling presets on analog gear, signal routing in switchers, parameters in DSP effects, and modular user interfaces. Wouldn't it be great if stepping on a stompswitch in a controller made by one company would be able to trigger configuration changes in 25 pieces of gear made by 25 different companies, all at once? With MILAN, this is possible.

How fast is it?

The signaling rate is 230,400 bits per second; roughly 7.3 times higher than MIDI's clock rate. This equates to a maximuim data transfer speed of roughly 23K bytes per second. Network overhead reduces this figure, but signaling is still several times faster than MIDI.

What is the cable & topology like?

MILAN uses a single Category 3 twisted pair for bidirectional signaling between up to 32 devices on a single piece of cable. A single cable segment may be up to 4000 feet long but in practical use it should be limited to less than 2000 feet. Low load drivers can be used to place up to 127 devices on the same piece of cable.

The connector is not specified in the standard. Small form factor devices may wish to use 2.5mm stereo headphone jacks with the tip and ring connected to the twisted pair. RJ-11 phone jacks are a proven solution with locking capability for smaller devices. Rack mount devices may use RJ-11s along with screw terminals, DINs, XLRs, or any other connector system capable of terminating the connection. Devices should provide two connections in order to facilitate easy daisy chaining.

How expensive is it to put MILAN in my device?

The signaling is based on the built-in USART in certain members of the Atmel AVR microcontroller family. The other components required are an RS-485 transceiver like the LTC485, the jacks for making the connections, and a few discrete passives for bypassing, filtering, and coupling. The other requirement is that the master oscillator must provide an accurate bit clock. For AVRs, this will require an oscillator of 1.8432, 3.6864, 7.2738, 9.216, 11.0592, 12.9024, 14.7456, 16.5888, or 18.432MHz. If you're already using a capable AVR, the additional cost is roughly $2 for a generic implementation.

Can I use other microcontrollers?

All you need is to be able to send and receive serial data at 230,400bps using the special 8N1 format provided by Atmel for Multi-Processor Communications Mode. The polarity of the stop bit is used in this mode to signal whether the byte contains a network address or data. This format was chosen for efficiency and to take advantage of special functionality provided by the Atmel USART.

Where do I go from here?

Short answer: nowhere, but keep this stuff in mind when you design new gadgets.

The early versions of this standard were somewhat different and all those notes have been lost for some time. The format of the communications is still being formulated but it will consist of 127 possible node addresses and up to 127 possible broadcast "group" addresses. Dynamic addressing with name look-up will be used to allow for plug-and-play functionality.

=============================================================================

Let's start talking about ways to make our devices work together. At the very least, it would be great if standards for remote configuration can be developed. Every device will be different, but there should be a standard way of saying, "hey everybody, switch to global preset #12".

Here are a couple links on RS-485:

http://en.wikipedia.org/wiki/Rs485
http://www.lammertbies.nl/comm/info/RS-485.html
http://www.rs485.com/rs485spec.html
http://www.national.com/an/AN/AN-979.pdf#page=5


What do YOU want MILAN to accomplish? 
.

[David]

Horshack here.  OH!  OH!  OH!  Holy cats, Peter!  How come you never pursued this?  You could have been retired by now!

Here's what I'd like to see MILAN accomplish:

1)  Have a conversion methodology to at least be able to send MIDI note numbers,  "start note" and "all notes off" commands so it can play MIDI synths

2)  Perform the selection logic on an Omnidrive so its settings could be treated like "patches" or "loops"

3)  Select 1 of N ROG preamps

4)  Select "Zombie", "Clone" or Mark Hammer "Badge" mode on a Zombie Chorus

5)  Switch between hard and soft clipping on a diode and op-amp distortion

6)  Flip a wah into wah, volume or autowah modes.  Also engage or disengage input and/or output buffers

7)  Assign an expression pedal to one of the effects units in your rig

Last)  Use a momentary switch to select a different effects loop and hold that loop as long as the switch is depressed

[The Tone God]

I want it to make me sound like Hendrix but without the practice and talent.

ok...I got nothin'

Andrew

[A.S.P.]

 

[Peter Snowberg]

I want it to make me sound like Hendrix but without the practice and talent.

Does that mean you don't want to take the time and effort to sound like Hendrix, or do you want to sound like an unpracticed and untalented Hendrix? 

Here's what I'd like to see MILAN accomplish:

1)  Have a conversion methodology to at least be able to send MIDI note numbers,  "start note" and "all notes off" commands so it can play MIDI synths

Easy to make with a single AVR. Some have two hardware serial ports making this really easy.

2)  Perform the selection logic on an Omnidrive so its settings could be treated like "patches" or "loops"

As long as you can make a preset interface to the analog circuitry, no problem.

3)  Select 1 of N ROG preamps

Piece O' cake.

4)  Select "Zombie", "Clone" or Mark Hammer "Badge" mode on a Zombie Chorus

More cake.

5)  Switch between hard and soft clipping on a diode and op-amp distortion

Still more cake.

6)  Flip a wah into wah, volume or autowah modes.  Also engage or disengage input and/or output buffers

Again, more cake.

7)  Assign an expression pedal to one of the effects units in your rig

Want some cake?

Last)  Use a momentary switch to select a different effects loop and hold that loop as long as the switch is depressed

...and finally, cake again.

[DavidS]

OK, here's something I'm having some issues and confusion about. I've just gotten my STK500, and I've dinked around with it a little, but I'm feeling a bit lost with this whole programming methodology. I'm used to high-level languages, and sugary features like event handlers.

So, how exactly would you handle something like a held-down button programmatically? Do you just keep sampling the thing to make sure it's held down in some sort of sub-loop, or can you link a digital input up to an interrupt or something? So much of this stuff seems like an event-driven system would make sense, though clearly it works without it.

I need to get some books on uC programming... Recommend any?

Sorry, probably should have started a new thread for this...

[rockgardenlove]

In all honestly, I just don't get the point.  Seems to me you'd just be transplanting the stomp circuit and controls to an external controller...why?  Is it somehow advantageous to put all the controls in a central spot?  If you're just adding some more advanced controls(setting memory and scrolling type stuff) why not just put it inside the actual pedal...?  I can see the value in turning on multiple FX with one stomp, but maybe I'm just not understanding the concept of what it actually would do.

[DavidS]

How about synchronizing all of your LFOs? Or having a set of preprogrammed "patches" like in a multi-fx unit? Or having your settings on your pedals be programmable? Or generally being able to program your entire setup and alter multiple parameters in realtime with a single control, across multiple devices? And generally be able to pull off lots of complex studio-esque tricks live, and all by yourself?

[David]

In all honestly, I just don't get the point.  Seems to me you'd just be transplanting the stomp circuit and controls to an external controller...why?  Is it somehow advantageous to put all the controls in a central spot?  If you're just adding some more advanced controls(setting memory and scrolling type stuff) why not just put it inside the actual pedal...?  I can see the value in turning on multiple FX with one stomp, but maybe I'm just not understanding the concept of what it actually would do.

Think outside the box.  If we can design a common interface protocol, we can stick any pedal in any position on a pedalboard and the controller can select pedals, select chains and change stompbox parameters.  It would be ASMOP on steroids.

This has absolutely head-spinning possibilities!

[R.G.]

It's really cool to envision what can be done once you step in to the digital domain. In fact, that is one of the things that is so seductive about digital - you can, with some assurance, state that whatever you think of can be done. Even previously scifi stuff.

However, there is a massive problem when you actually have to fit the old-school everyday practicalities into the new Digital Millenium(tm) setups. You can't instantly change the history of the world or replace it.
As David says...

Here's what I'd like to see MILAN accomplish:
1...2...3...4...5...6...7...

and as Andrew notes:

Piece o' cake... cake... cake...

but he also notes:

As long as you can make a preset interface to the analog circuitry, no problem.

And that's the bit of ugliness hiding inside.
To get to the anything anytime forever kind of setup that's lurking in these ideas, you have to change the pedals themselves to listen to the digital network. And in a dull, painful, difficult and tedious way, that will likely be the downfall of this kind of setup being done all at once.

It's really not much of a stretch to do any one of the practical things involved - setting a pot digitally, sending a LFO frequency digitally, sending switch configuration digitally and so on, but the Devil is very much lurking in the details. F'rinstance - there are not an infinite number of digital pot values, nor tapers available. You'll probably have to tweak every pedal to work with the digital pots that are available. You'll certainly have to adapt the pedals to new pots. Setting the LFO to a specific frequency requires either an on-board digital LFO generator for the LFO and the matching redesign of the pedal  to include that, or some kind of pot-and-feedback setup to let the controller that's running the show read back and correct the LFO to the right frequency - and THAT requires some kind of smart sensor of frequency and the ability to send the frequency back over your network. Setting switches is the easy part, but every switch has to be replaced by an electronically controllable switch.

So you wind up redesigning every pedal to be put into this thing with either fairly elaborate onboard digital controls(this is what I was referring to as changing the history of the world), or some very elaborate A/D conversion and feedback to the controller on the network (this is what I meant by replacing it) - or both.

It is, of course, possible to design up a generic digital wrapper, very much like the analog wrapper concept I have on GEO where there is a layer of automatable stuff around the effects circuit that takes care of all the mess. But that then becomes a necessity for every pedal, and you have to design in enough complexity on the wrapper to take care of any pedal you want to wrap up in it.

I'm not sure what's the bigger problem - a unique retrofit to every pedal you want to put into this design, or a single digital wrapper that will do any ( or almost any) pedal you want to hook into it. The first is never ending, the second is probably never starting, and likely never ending.

A very clever, very fast communications network for effects use is a great start. But there's a ton of work to get the effects ready to work with it.

And I didn't even touch on how complicated it will be to make this setup so a human can tell it what to do. The human interface is maybe the worst of all. Dealing with the HUMANs is really, really hard, picky, and frustrating when you have to tell a machine how to do it.

[R.G.]

OK, here's something I'm having some issues and confusion about. I've just gotten my STK500, and I've dinked around with it a little, but I'm feeling a bit lost with this whole programming methodology. I'm used to high-level languages, and sugary features like event handlers.

So, how exactly would you handle something like a held-down button programmatically? Do you just keep sampling the thing to make sure it's held down in some sort of sub-loop, or can you link a digital input up to an interrupt or something? So much of this stuff seems like an event-driven system would make sense, though clearly it works without it.

Actually, you have put your fingers on the issues already. There are really only two ways to deal with events - polling and interrupts. Actually, now that I think about it, there's a third way - interrupt driven polling.

Programming in applications level languages hides the details of what is happening in real-time events by hiding behind an interrupt handler. And you WANT it that way, because you don't want to have every single line of programming have to know about the real time events. But you have to either be programming right down at the bare metal or highly disciplined and modular to deal with it.

Here's how you handle real time events in any computer.
Whatever suffices for an operating system is always a never ending loop. It starts at "MAIN" and ends with a "GOTO Main", or the structured equivalents "WHILE  TRUE" and "WEND", or other ways to say the same thing in different languages. You either check the event status by polling the I/O once or more times per main loop, using an interrupt handler to break into and out of the main loop, or using a timer to break out of the main loop at regular intervals to poll the external event.  Just thinking about it, I don't think there are any other than those three ways.

Polling is ugly, nasty, and only suitable for tiny applications where you know with no doubts that your main loop always executes in less time than you need between polling events.

Interrupts are ugly, and nasty, but they are suitable for getting the offending real world event out of your hair so you can concentrate on what you're doing (either interrupt code or main loop code) and not have to worry about the other all the time.

Timer interrupts are ugly, but they offer a way to deal with the real time event while restricting the amount of time in the main loop spent on it, and still letting you separate real time events from interrupting events in your head.

Notice that only purely interrupt driven stuff can cope with real time events as quickly as the computer can respond. Polling, even interrupt polling, will on average respond to the real world even in half the polling interval, and as bad as the entire polling interval. So you have to be sure that your real-time event can stand for you to wait the polling interval before servicing the event.
Modular block structured programming is a good fit to the human mind. We compartmentalize and analogize incredibly easily. If you have to do something, whether incredibly minute or gigantically complex, you name the whole process, and deal with it as a unit. We deal with "First do this, then this, then.... then this and now start over" very well. The "this" things can be big or small. They just have to be non-interacting, or more properly, interacting only at entry and exit points.  If there are two processes that interact in detail that can't be separated out so they interact at entry and exit points only, then they are really not two processes, and should be handled as one.

That was part of what I was trying to get across with one of my recent polemics on programming here. MODULARIZE.

Once it's modularized, you can always get some help on how to write the modules.

In the case of any uC, if the main loop task is short enough, you can simply check the real world event once per main loop, or even sprinkle tests on the real world event throughout the main loop.  It is possible to write the main loop so that it always takes the same amount of time to execute, no matter what. This is so-called isochronous code, and is a marvel of elegance. The top octave generator code that you may have heard me talk about is isochronous code.

Isochronous code is perhaps the worst of all possible code to write, leaving aside self modifying code, wihch is itself a death wish.

If the main task is too long for the polling time, I would set up a timer interrupt and use that to tell me when to poll. When the timer goes off, go look at the event you're watching.

If I absolutely, positively have to be on top of the event the instant it happens, nothing except pure interrupt driven will work. Sometimes that's not fast enough if you have a complex interrupt handler. The interrupt latency, the time between the interrupt signal being asserted and the time when you actually service the event, can be too long in some situations.

You have to know how often the real world event happens, and how long you can wait to service it before you can deal with writing code for it. Fortunately, humans and mechanical devices are slow compared to computers.

For instance, sensing the state of a momentary switch. Humans push switches. Human reaction time (that is, the human interrupt response time) is somewhere longer than 1/20 of a second. Faster than that is not detectable from instant by most humans in most circumstances. Human mechanical response time, (as in pressing a switch based on seeing a light) is on the order of 100mS to 250mS if the human is not   o o o n n  n n   d r u   g s, ill, or otherwise indisposed. So if you can respond in under 0.02 to 0.2 seconds, you usually are fast enough for humans. Switches bounce. You ... can ... not... tell if a switch is making, unmaking, or bouncing in less time than the switch bounce clearing time. There have been books written about debouncing switches.

And it gets down to

I need to get some books on uC programming... Recommend any?

Yes - I did. My reference to the PIC list area. Even if you're not doing a PIC, go read the examples in the PIC list on how those people solved things like switch detection, timing generations, math, table lookup, sensing a pot, A/D, etc. You usually don't have to know PIC assembly, as the comments (remember those!!) tell you how the code works, and there is usually liberal teaching along with the code.

It's hard to overestimate how much learning is stored there in the PIC list site. There may be a comparable site for Atmel, but I have not yet found it.

Sorry, probably should have started a new thread for this...

No biggie, but yeah, I think we should.

[David]

R.G. -
I don't think anyone is expecting it to be easy.  If we wanted easy, we'd be buying stuff from Musician's Foe instead of Small Bear.
I also knew that it would be a big, difficult job wrapping digital control around various discrete analog pedals.  Bring it on.
There's strength in numbers.

Having admitted those things, here's how we might get around or at least mitigate them.  Let's create a finite list of pedals that we would
want to retrofit with digital control and set about figuring out how to do that.  Actually, this is the kind of thinking I was trying to create with
my list of MILAN requirements.  I'm not the teacher you are,  though, and I certainly can't use the Socratic method.

[R.G.]

I understand - I'm into replying to the audience today. You certainly don't need what I was saying.  I agree, bring it on.

[David]

You certainly don't need what I was saying.

Oh, yes I do.  Where were you when I was studying computer science?  Reading your stuff is a hell of a lot easier than reading Knuth or Djikstra!

Now, if we are going to pick some victims, let's start with a short, simple list of the stuff guitarists would use most.  This is all purely my own opinion, submitted to spark discussion and further research (And no, I'm no expert at any of this stuff - including software development.  I do, however, do a pretty good job of getting people to respond - unfortunately, not always in a positive way.)

DISTORTION:    Muffer
MODULATION:   EZ Vibe
FILTERING:        Maestro Boomer 2 wah/volume
BOOST:              Sparkle Boost
COMPRESSION:  Aussie Compressor
AMP SIM:           Ruby / Prof. Tweed / Eighteen (I don't know - you guys pick some!)

This ought to provoke some discussion...   

[The Tone God]

Not to hijack but Just a side note. Programming stuff is coming soon. Alittle more patience.

Andrew

[Peter Snowberg]

Programming stuff is coming soon.

And I didn't even touch on how complicated it will be to make this setup so a human can tell it what to do. The human interface is maybe the worst of all. Dealing with the HUMANs is really, really hard, picky, and frustrating when you have to tell a machine how to do it.

This is why I'm bringing this idea up now. I figure that by the time the first couple of practical real-work examples are ready, there should be some kind of simple kludge user interface available to.

Thanks for making a new thread out of your above post. Very cool stuff.

In all honestly, I just don't get the point.  Seems to me you'd just be transplanting the stomp circuit and controls to an external controller...why?  Is it somehow advantageous to put all the controls in a central spot?

Imagine David Gilmore having to dance around between all the pedal combinations he uses while the boxes are all in front him, keeping him back 6 feet from the microphone.

If you're setting up for a gig it's much easier to set your pedal box/board down, connect it to your amp(s), and run a single little wire to a little box of stompswitches sitting by your feet to switch settings. Lots of stages just are not all that big if you're into using 14 pedals.

If you're just adding some more advanced controls(setting memory and scrolling type stuff) why not just put it inside the actual pedal...?  I can see the value in turning on multiple FX with one stomp, but maybe I'm just not understanding the concept of what it actually would do.

You would want all the specific controls for a pedal to inside the pedal. MILAN allows for an easy way to put those settings under remote selection or control, depending on the capabilities of the individual pedal.

It doesn't have to any more complex than being able to switch a preset bunch of pedals on or off via a MILAN controlled switchbox to provide big value. If you can have an expression pedal by your feet that can be remapped to control different effects, that's icing on the cake.

MIDI is just too brain-dead to be as useful as it could have been. It's ironic that it was intended for amateur piano players buying cheap gear, yet it has been pushed to center stage in professional venues. It could have been so much better, but it's not.

How about synchronizing all of your LFOs? Or having a set of preprogrammed "patches" like in a multi-fx unit? Or having your settings on your pedals be programmable? Or generally being able to program your entire setup and alter multiple parameters in realtime with a single control, across multiple devices? And generally be able to pull off lots of complex studio-esque tricks live, and all by yourself?

You've got it.

Synchronizing LFOs at will is very cool.

Programmable patches of analog circuits is also cool.

Now being able to alter multiple parameters across multiple devices in real-time with a single control, that's just uber-cool!

Once you add MILAN controllability to a DSP sub-system () you can start doing all kinds of amazing mixing and morphing between analog and/or digital devices and do it in a 100% repeatable way.

[DavidS]

R.G. -

Thanks for the reply. Your answer is sort of what I was afraid of! But now that I KNOW it's going to be ugly, I'll stop wasting time looking for a "pretty" solution.

DavidS

[dano12]

I like this idea very much--if we can ever get to a point where digital control of analog devices can move more easily into the DIY realm.

Agree the MIDI with its latency and nasty old connectors isn't the way to go. Regarding the physical layer, are there ruggedized versions of the RJ connectors? The standard ones you use to hook up your computer wouldn't stand up to pedal board or road use.

I think that moving forward with MILAN would need to be baby steps at first--before the .1 spec is finalized, pick one or two types of controls in a typical pedal that it could interact with. Come up with a workable DIY circuit for a digital pot and maybe some kind of CMOS switch. Get those two running in a typical circuit that is easily identifiable, like a fuzz clone or phaser. Then let the community start playing how to actually control that pot, get its current reading, save its value etc.

Your concept is very cool, and very ambitious, sounds like a perfect collaborative project for the DIY community.

[Peter Snowberg]

There are ruggedized RJs. Gibson is using the EtherCon series from Neutrik to do their RJ-45s for MaGIC. In fact, you can pick them up at Mouser.

I decided to leave the connector out of the spec so that it could get implemented in the way most suitable to the application.

If you had a floor controller that sat by the mic, I would encourage the use of ruggedized RJs link to link that to a box with all the effects in it. The effects box would also have a rugged RJ. Inside the box, I can see using 3.5mm TRS headphone connectors for space constraints inside the individual effects. I could also easily see some 1/4" TRS jacks in there that would allow for MILAN patch cords to jumper to the amplifier(s) for switching there.

Plain vanilla 1/4" TRS jacks have a number of advantages, but they're bulky too. In any case, I could easily see a floor controller linked via 1/4" TRS as having the exact same durability as the analog connection it would replace. The big advantage for 1/4" I see off the top is that if you were at a gig and somebody kills your MILAN cable, you can probably substitute a regular stereo patch cord for the duration of the show without anybody knowing. It's also easy to quickly make up a replacement cable without tools. OK, RJs don't need soldering, they're ideal for differential data connections, and now you can get RJ-45 tools at every home center, but how many musicians know how to make data cables? You normally you have to solder 1/4" plugs, but in an emergency you can just wrap some twisted pair onto the connector lugs and you'll get a working MILAN cable. I've seen fairly large RS-485 networks operate for months with only ONE of the two data wires in tact.

Dano, I think you're right about baby steps. There is still some work to do in reconstructing the MILAN protocols and I'll do that before we start talking about any specific builds. The first issue of a network is how to address the nodes. Apple did a really great job with AppleTalk and since I've got lots of experience with it, I'm going to "borrow" lots of key concepts. Apple used English naming to identify unique devices. I'm doing the same. This eliminates lots of potential addressing problems and gives plug-and-play functionality. The key sub-protocols include MARP (MILAN Address Resolution Protocol) and MDDP (MILAN Datagram Delivery Protocol). These allow for a node to come on line, find a free address, and get to work without messing with DIP switches, requiring devices to have displays, etc.

The first MILAN devices will be a foot-controller with digital switches and indicator LEDs, and an 8 loop effects switcher which allows up to 7 loops to be used at a time, in any order. 

We'll deal with analog control later, but I will say now that I'm going to standardize on 16 bit control values.

Thanks everyone for your interest.

I know we can put this technology to use around here for all of our benefit.

[R.G.]

Things can either be rugged at some cost, or easily replaceable.

If you're thinking about RJ connectors, make your standard the ethernet patch cable, which is both cheap and has replaceable connectors. Buying a few of these and a crimping tool is probably cheaper than buying a ruggedized version of the RJ's.