Quote from Ron Rollo on May 4, 2018, 8:14 am

Thanks Mark!

Good information and a great guide to cable lengths.  At a quick glance, this guide confirms what I already knew:  The weak link in cable lengths is our USB cables.  It's tolerance for loosing signal and creating issues is much less than the other types of cables we use.

I once read that the maximum USB cable length can not exceed 12' 4" without a powered USB hub or signal loss will occur and bad things will happen.  The funny thing is in my case, I tried to do the right thing and use a powered USB hub to boost the signal and used a 10' long cable from the computer to the hub and a 5' cable from the powered hub to the interface device.  It did not work!  But when I tried a 15' USB cable it did work with no further issues.  (15' is about 5 meters)

Unless you are setting up your sim in a remote garage and setting up your computers in your house,  in other words, a really long distance away from one another, the weakest link in the cable length question is always going to be our USB cables.  The guide you have point to Mark is a great tool that helps illustrate this and trouble shoot any potential problems.

Great looking photo of you hangar bay by the way!  Looks awesome and I bet a joy to fly!

Quote from Mark Speechley on May 8, 2018, 5:42 am

Funny you should mention that even with the powered hub and the 10' cable you were still having problems.

I kid you not. I must have been hit with the windows update stick about 6 weeks ago as I have just had a cascade of USB problems from the four computers. It might have been a self fulfilled prophecy with problems with one computer, then mix and matching different hubs and cables to fix computer one and you end up 'spreading the love around' to the others !

Fortunately I have hit on one fix that you should all store away for a rainy day. Apart from the aforementioned cabling advice from Ron and I, it is a simple windows based fix that may help.

1/ Open up your power plan. Depending on which Windows you have,( which determines where to find it ) go to Power Options and then Edit Plan Settings. Look for Change Advanced Power Settings.

2/ Scroll down to USB Settings and click on the + sign in the little box

3/ Click on USB Selective Suspend Setting. Change setting to Disabled.

4/ Click Apply or OK to save.

The USB selective suspend feature allows the hub driver to suspend an individual port without affecting the operation of the other ports on the hub. Selective suspension of USB devices is especially useful in portable computers, since it helps conserve battery power. In reality what seems to be happening is it can be suspending usb ports and not re-enabling them giving you less usb ports to choose when re-plugging in usb cables.

Worth a try if you haven't had success changing cables/hubs and have uninstalled the usb controller drivers in device manager, with no success.

Mark S.

Quote from Mark Speechley on August 6, 2018, 2:30 am

Well continuing on with the theme of USB issues and cables.

I have had endless problems with USB disconnections this year and have tried to resolve the issues by changing cable types ie USB 2.0 and USB 3.0.I have tried alternating hubs from powered to non-powered. I have tried powered USB 2.0 and 3.0 hubs. finally I narrowed the problem down to my Saitek pedals. I have 2, however one was disconnecting and 'freezing' the mobo, as seen by the clock frozen. Interestingly enough though in P3D 4.2 the Lear would keep flying and the mouse moved with a frozen mobo ! The USB peripherals attached would not function any further and only a hard reset would restore the computer.

The one pedal was throwing up the occasional windows error that there was an overvoltage in the usb port. Oooh not good. After extensive reading the advice was you can right click to go into properties for that usb port and turn off the warning ! Not the best safety advice but it turns out that the tolerance by windows is too sensitive for that slight increase so should be safe.

So what was the fix for the pedal ? Well if you disconnect and reconnect the pedal in the usb hub then windows looks for a saitek driver and loads it OR goes to windows update for it's own driver. The old saitek driver was suspect in the first place with all the windows updates, so I downloaded the 'latest' updated driver from the last 12 months from Logitech. Well when you install the new driver,it doesn't 'take' as windows is still using it's driver which is faulty. So you disable the usb ports for the pedals and reboot. Upon restarting windows defaults to downloading it's windows update saitek driver which is 2010 vintage. If you quickly click on an option in the dialog box to stop downloading and look locally it will find your new driver and load it. Job done. Most of my grief had boiled down to windows and drivers. So the take home message is don't be too hasty to change out your hardware.

Here is an interesting bit of further advice from Rob Ainscough moderator at AVSIM and Prepar3d, given  July 30th 2018, given to another chap with another brand of pedals'  issues. This is worth stashing away in the knowledge base.

" Have you added another USB  device recently?

Connecting disconnecting is a sign of too many USB devices on a single USB chipset where they aren't all getting sufficient power.

An easy test would be to buy a USB 2.0 PCIe card (they're very cheap) and add it to your system and plug the MFG Crosswind into the PCIe card (alone).

Typically I get about 12 USB devices per chipset (regardless of powered hubs or not).

Cheers, Rob."

Interestingly enough the guy with the problems sorted his out by changing the cable. And around we go.

Hope this one day will be of help to someone out there.

Cheers

Mark S.

Quote from Ron Rollo on August 6, 2018, 6:21 pm

Thanks Mark for the info!  I am hoping that with all this knowledge that we are collecting we can stay on top of it all.  Remember, the new path is going to be several Arduino interface cards.  Hopefully we will not have the same type of issues with USBs as we do now.

"Hit and miss" or "keep your fingers crossed" is not the best way to go about interfacing our cockpits!  Getting rid of the Pokeys should resolve most of these issues for us.

Quote from Ron Rollo on October 23, 2023, 6:53 pm

I was talking with DonnyRay about some of his cable management solutions which included "Cable Ladders".  Basically, "Cable Ladders" lift the cables and wires up off the deck of his sim room and channels them over and above everything.  You see stuff like this in server farms or big tech buildings.

We got on the subject of cable lengths, being that some of his cables will be approaching 50 feet in length and DonnyRay had a lot of great insight on why some USB cables work fine and others don't.  If you are like me, you reach into a drawer for a USB cable, plug it in and hope it works, sometimes it doesn't so you grab another one without knowing why the first one failed!

So what is a USB? Straight out of Wikipedia:

Universal Serial Bus (USB) is an industry standard that specifies the physical interfaces and protocols for connecting, data transferring and powering of hosts, such as personal computers, peripheral devices, e.g. keyboards and mobile devices, and intermediate hubs.  Read more HERE

 

A short snip from DonnyRay with real world insight on USB cables:

There is so much poor quality information on the internet regarding longer cables, whether it be VGA, USB, DisplayPort, 1374, FireWire, keyboards (KVM), or even the cable to the lamp on the table.  USB 2.x will run within spec on much longer cables than is generally believed but you must observe a couple of important limitations:

• USB 1.x and 2.x will run at full speed on cables longer than 5 meters but an active cable is required.
• USB 2.x will run at reduced speed on cables as long as 35 meters.  USB 1.x will run at 35 meters at full speed.  An active cable is required.

Active cables provide amplified USB signals to offset losses in longer cables.  There are two kinds of loss:

• DC resistive loss in the physical conductors in the USB cable itself.  This limits the maximum amount of power that can be supplied to the far end device.  For long cables the practical solution to this is to use a locally powered hub at the far end.
• Signal loss of the USB “bits” traveling across the wire.  An active cable offsets this loss. For longer runs in electrically noisy environments it is often advantageous to use an active fiber optic USB cable.  Fiber cables require the use of a locally powered hub at the far end. (Fiber cable cannot pass D.C. current.)

 

But loss is not the only problem.   USB 3.x will *not* run on extended cables, even if active fiber cables are used.  This is due to the signalling rate.  The signalling rate (speed) of USB messages crossing the wires limits the maximum length of any type of cable.  In simple terms it takes a finite amount of time for a message to travel down the wire.  This is called propagation delay.  Propagation delay is a function of the maximum pulse rise and fall times and capacitive loading presented by the physical cable itself.  Active fiber cables eliminate propagation delay caused by copper cable but this does not help with  transit time.

 

At USB 3.x signalling rates on long cables a message cannot make the trip “in time” before the USB 3.x host will assume it is a lost message.   This is also an issue for USB 1.x and 2.x, but *because they have slower signalling rates* they will work over longer distances than USB 3.x before they hit the transit time limit.

 

Each USB software function is designed to hit a specified set of registers (called endpoints).  Each endpoint has a particular transfer characteristic that it supports.  For example, if you were feeding a loudspeaker via USB the data transfer must continue at a constant throughput rate to prevent artifacts in the audio.  Other endpoints may have different characteristics and thus require a different transfer type.  The client driver reads the descriptors from the device and is informed as to the type of transfer required by the device.

USB has the following transfer types:

• Isochronous
• Bulk
• Interrupt
• Control

Isochronous transfer is for devices that require a constant delivery throughput.  For example, when feeding audio to a USB connected loudspeaker.  These are often mistakenly described as “high bandwidth” transfers.  The actual throughput across the USB bus is a function of the device requirements.  It *can be* very high throughput or it may be low throughput at a constant rate.  For example, checking for switch throws must happen at a regular rate, but the actual messages transferred are very small.  Sending something like weather graphics to a display would be a high throughput example.  Those two examples load the USB bus in very different ways.

Bulk transfer is for transferring large blocks of data that have no periodic or delivery throughput requirement.  An example of this is when you send a document to a USB printer.  Even if the data arrives slowly or late, this does not result in lost or corrupted data.

Interrupt transfers are an odd situation.  The classic interrupt driven example is a keyboard.  Each time a key is pressed on a keyboard a *hardware* interrupt is sent to the CPU.  This hardware interrupt causes the CPU to execute software (called an interrupt routine) that services the keyboard (retrieves the value of the depressed key).  Every key press generates a hardware interrupt and the CPU responds the same way each time.  But unless a key is pressed, no interrupt routine is called.  But USB doesn’t have a hardware interrupt line.  A USB device like a keyboard must be polled at a periodic rate to determine if it needs service.  Even when a key has not been pressed a USB keyboard must be polled periodically.  If a key has been pressed the CPU will call a software routine very similar to that of a standard hardware keyboard to retrieve the value of the pressed key. The polling rate is critical.  It must be frequent enough that data is not lost, but not so often that USB bus bandwidth is needlessly consumed.

Control transfers are for specific requests to USB devices.  They are usually used to configure a device upon installation or during device configuration.  These are special USB command messages.  They may be followed by a data transfer and always end with a completion status returned to the host.  These are not high bandwidth transfers.

 

And here’s the point:  These various transfer methods used by USB aren’t all the same.  Some of them don’t even guarantee delivery of the data!  When designing a USB network with many devices it is necessary to KNOW which kinds of transfers are used by each device and then design the USB network to support that configuration.  The idea is to partition the network in a way that does not put a bunch of devices using isochronous or bulk transfers all on the same segment.  “Spread the throughput load across the entire USB network" to avoid traffic congestion on any given segment.  How does this relate to extending cable lengths?  The more traffic there is on any given segment.......the shorter that cable needs to be.

 

For most of us, this is more information than we would ever need to know, but if you find yourself in a pinch where a particular USB cable or two is not working properly, you might find your answer(s) here!