Timeout Rant!!

The cable would be exactly the same. What makes it an Ethercon cable is a metal housing around the Ethernet connector to protect it.
You can buy a single Ethercon housing, put it on an Ethernet cable, and voila, you have an Ethercon cable :)
View attachment 49110
The point was that it's not Ethernet, which is a networking protocol... Not a type of cable.

The cable is CAT5 or CAT6 with RJ-45 connectors. The specs and limitations around Ethernet over CAT5/6 may or may not be relevant in the proprietary protocol used by Fractal.
 
But it's not an Ethernet cable because it isn't using the Ethernet protocol.

Fair point. I shouldn't have referenced Ethernet in my post and instead mentioned twisted pair cabling.

However, the points I made are still things to consider because they are all related to the electrical characteristics of twisted pair cabling and data transmission over TP cabling.

The protocol used defines how the 1's and 0's are encoded (ie, Ethernet uses Manchester Encoding), for transmission over the physical layer and should be irrelevant. Although, the protocol used is responsible for maintaining the timing between the sender and the receiver, so that the receiver interprets the 1's and 0's at the correct interval, ie. in the middle of the bit time. The Manchester waveform that Ethernet uses is called a self-synchronizing waveform, in other words, there are enough transitions from low to high and high to low that the receiver can stay in synch. with the sender. That's one of the reasons there is a max. distance for Ethernet cables.

It's possible that the protocol being used between the MFC and the Axe-Fx, over the Ethercon cable is having synchronization issues and thus creating the timeouts, which would be compounded with longer cables.

Let me give you an example of how weird, unexpected, things can happen with twisted pair cabling. When I finished school (over 30 years ago now :-( ), I worked for a short time with GE's instrumentation division. My boss was always looking for contracts. So one day he asked us to go to city hall because they were having issues with their mainframe and mainframe cabling. They had hired electricians to pull twisted pair cabling and terminate the serial ends...what a mess. The other issue they had was the mainframe would hang once in a while and they didn't know why. In those days, you accessed the mainframe via dumb terminals, connected via serial cables (RS-232). Basically, if a terminal had data to send, it would assert the RTS signal and the polling mainframe would see the RTS and send a CTS signal. They were short two terminals, so they would leave the cable on the carpet. I suggested scoping the connector and sure enough, the connector, with nothing connected to it was setting the RTS pin high. So the mainframe would send a CTS signal and wait indefinitely. So now it wouldn't poll the other terminals and the system would hang. It didn't always happen and they said it was worse in the winter, so along with some Belden cable engineers, we concluded the RTS signal was going high because of the static electricity created by the carpet, when the humidity was really low in the winter. We told them not to leave the cable end on the carpet and they never had the issue again.

The other thing I learned from the Belden engineers, is that the dyes used to colour the twisted pair wires affects the characteristics of the wire. For example, some colours have better conductivity than others and therefore are more susceptible to cross-talk. So when they twist the pairs, those pairs are kept away from pairs with higher conductivity dyes.

I realize this is not related to the issue mentioned by the OP, but I think it highlights how certain conditions you may not even think of, can affect twisted pair cabling.
 
Last edited:
Started using my Axe Fx mk I and MFC mk III with ethernet cable, after first timeout switched to midi cable. I have resident gig - 6 days peer week for last year and a half, not a single timeout or anything. So, save yourself troubles and go with the midi :)
 
I still get random timeouts too. I try to always exit Axe-Edit at the end of my jam session. I have tried starting the Axe first and edit second and vice versa..but dont think hat has made any difference. I have tried alternate cables...but no fix yet.

It is frustrating that it locks up all the way to the point of having to cycle power to the axe-fx.

Does that indicate that the Axe-Fx unit is the part locking up and not Axe-Edit.

BTW..I have Mk I and am running Win7
 
Fair point. I shouldn't have referenced Ethernet in my post and instead mentioned twisted pair cabling.

However, the points I made are still things to consider because they are all related to the electrical characteristics of twisted pair cabling and data transmission over TP cabling.

The protocol used defines how the 1's and 0's are encoded (ie, Ethernet uses Manchester Encoding), for transmission over the physical layer and should be irrelevant. Although, the protocol used is responsible for maintaining the timing between the sender and the receiver, so that the receiver interprets the 1's and 0's at the correct interval, ie. in the middle of the bit time. The Manchester waveform that Ethernet uses is called a self-synchronizing waveform, in other words, there are enough transitions from low to high and high to low that the receiver can stay in synch. with the sender. That's one of the reasons there is a max. distance for Ethernet cables.

It's possible that the protocol being used between the MFC and the Axe-Fx, over the Ethercon cable is having synchronization issues and thus creating the timeouts, which would be compounded with longer cables.

Let me give you an example of how weird, unexpected, things can happen with twisted pair cabling. When I finished school (over 30 years ago now :-( ), I worked for a short time with GE's instrumentation division. My boss was always looking for contracts. So one day he asked us to go to city hall because they were having issues with their mainframe and mainframe cabling. They had hired electricians to pull twisted pair cabling and terminate the serial ends...what a mess. The other issue they had was the mainframe would hang once in a while and they didn't know why. In those days, you accessed the mainframe via dumb terminals, connected via serial cables (RS-232). Basically, if a terminal had data to send, it would assert the RTS signal and the polling mainframe would see the RTS and send a CTS signal. They were short two terminals, so they would leave the cable on the carpet. I suggested scoping the connector and sure enough, the connector, with nothing connected to it was setting the RTS pin high. So the mainframe would send a CTS signal and wait indefinitely. So now it wouldn't poll the other terminals and the system would hang. It didn't always happen and they said it was worse in the winter, so along with some Belden cable engineers, we concluded the RTS signal was going high because of the static electricity created by the carpet, when the humidity was really low in the winter. We told them not to leave the cable end on the carpet and they never had the issue again.

The other thing I learned from the Belden engineers, is that the dyes used to colour the twisted pair wires affects the characteristics of the wire. For example, some colours have better conductivity than others and therefore are more susceptible to cross-talk. So when they twist the pairs, those pairs are kept away from pairs with higher conductivity dyes.

I realize this is not related to the issue mentioned by the OP, but I think it highlights how certain conditions you may not even think of, can affect twisted pair cabling.
Yeah... 30+ years in IT myself. I've seen and heard of all kinds of weird stuff.

My gut tells me that most of the Ethernet limitations don't apply in this case. My reasoning is simple: the midi cable which is effectively doing the same job (especially if you are using phantom power over 7-pin midi) doesn't care about twisted pairs, etc. Those are straight, pin to pin wires.

The one case I can think of that would is length. I've experienced issues with phantom power when the midi cable is too long.

Recently, I bought a 5 to 7 pin breakout cable so I could phantom power my MFC with my Axe Fx III.

I ordered the cable from BTPA and could only buy a 20' cable as they will not support anything longer due to "issues" with those and return rates.

I get my be cable, plug everything in, connect the original MFC power supply... And my MFC lights every LED solid red and will not function. If I connect the same power supply directly to the MFC everything works.

So, the original power supply is 9vAC 1000ma. I have another older power supply from some other effect unit that is 9vAC 1300mA. I connect that and everything works totally fine.

Where is the fault? Maybe the original PS is slightly under current spec? Maybe the cable is adding some extra load?

I had similar issues with my Gordius Big Little Giant before the MFC. Phantom power over midi is fickle.

Why this issue only affects some users is the real question... And it sucks for those users.

I ran my Axe Fx II mkII and MFC over XLR to the FASLink adapter at the Axe Fx side, which then connected to the EtherCon port for years, never had a glitch. When I got my XL+, I did the same (even though I could have use FASLink all the way) because my rack didn't allow enough room for the XLR cable.
 
My gut tells me that most of the Ethernet limitations don't apply in this case. My reasoning is simple: the midi cable which is effectively doing the same job (especially if you are using phantom power over 7-pin midi) doesn't care about twisted pairs, etc. Those are straight, pin to pin wires.

However, with the all the twists, I can't recall the exact TPI, you're adding a fair bit of length to the wires, as opposed to a straight run, therefore, the impedance will increase faster on a per foot basis, compared to wires that are straight through, like in a MIDI cable.

Distance has a huge impact on the ability to deliver power over a long distance. That's why high-voltage transmission lines are at 230,000 volts. It also allows them to use smaller wire because the current is stepped down inversely to the stepped-up voltage.

I tried buying what's called, 'poor-man's' POE connectors so I could run my IP cams over TP, didn't work worth a crap. Anything over 10' or so and the IP cam wouldn't even power-up. The only way to make it work would be to increase the voltage at the supply end and to use more than one pair of wires for the positive and negative voltage, which would increase the total cross-section of wire, thereby decreasing the impedance.

In the case of your power supplies, one may have been regulated and the other was un-regulated (think Boss ACA and PSA adapters), so the one that worked was most likely a regulated PS, ie., the voltage remains constant as the load increases.
 
I have the Mark III MFC and the Axe FX II Mark II, both with up to date firmware.
OK. Then I suggest you check out the FASlink adapter. You would only need one at the Axe side and this "should" get rid of all the problems. But just try running the system with as short an Ethernet cable as possible and see if the timeout persists or not. Because even with an adapter, you're going to have a short ethernet cable run.
 
You've probably done this already, but if not, check your mfc settings:

Totalsync: On
Axefx Mode: Matching your unit type
Port: Expansion
 
never had this happen once, so weird. Why not go to a midi cable and see if that fixes it?
Midi doesn't provide power... Unless you use 7 pin cable and the power supply + phantom power jack... And that is yet another finicky setup prone to its own issues :(
 
Midi doesn't provide power... Unless you use 7 pin cable and the power supply + phantom power jack... And that is yet another finicky setup prone to its own issues :(

Indeed, and in the Fractal Online Shop there is no sign of any 9V power supply as stipulated in the MFC-101 manual
 
You've probably done this already, but if not, check your mfc settings:

Totalsync: On
Axefx Mode: Matching your unit type
Port: Expansion

Yes, I have checked the whole settings ting, but a good reminder as it is often the most basic things that get overlooked!
 
Tonight's episode was a 'message timeout' while re-loading the latest firmware. Not had that before. The MFC was nowhere in sight so it may well be that there is an issue with Axe Fx unit itself.

This was then followed by timeouts when simply moving patches to different locations while using Axe Edit.

I'm off now to chew my own foot off, as the Monty Python guys would say.......
 
when you get the timeouts, do you also have a USB connected to a PC / Mac at the same time?

the only communication issues I get happen when I run an aggregate audio interface in Logic
what happens is that Axe Edit will not communicate with the Axe when Logic is open and using an aggregate audio interface
when I switch Logic back to a single audio interface, close and reopen Axe Edit, Axe Edit runs normally
note though that this only affects Axe Edit and not the MFC..

maybe this is a red-herring.. but it is a communication issue [but I've always assumed it was something in my Mac causing this]
 
when you get the timeouts, do you also have a USB connected to a PC / Mac at the same time?

Only when I am using Axe-Edit; at gigs there is nothing else connected to the Axe-Fx and just one expression pedal connected to the MFC101
 
Back
Top Bottom