Hello all,
Quick question to anyone regarding USB driver updates. In my previous posts I have complained about engine gauge lags and freezes and think my USB speed is a direct result. I am thinking a USB driver update my increase the data speed (??)
Anyway, I am going to run "USB.DRIVERBOOST" to see if my drivers are up to date and then move forward from there.
Before I push the button on this, I am a little worried that my USB devices, plug nd play rudder pedals, goflight MCP pro, and 3 Open Cockpits DC Servor motor boards, will be greatly affected by this.....again I am not sure if this is going to cause more problems than this is worth.
So the question is will a USB driver update give me headaches, or should the devices not be affected and boot up normally once the update is complete...
thanks!
-Jim
I would not trust any driver update sites or software unless they are from the manufacturer.
A speed increase from a driver update would be minimal, I would look for other causes of freezing or lagging.
Do a backup or set a system restore point in Windows before you change anything just in case.
I have to agree with mickc. I would not trust a driver update software of any kind. And for issues the first thing that comes to mind is a "re-stacking" of the USB which would change all the ids and screw up and FSUIPC programing you have done.
Thanks guys.
I am going to heed your advice and not update my USB driver information. I will live with a sticky gauge or two.
Once again thanks for the information
-Jim
What type of gauge do you have? Is it an RC servo type or other that might be going bad or needs some lubication on the gearing, if it's not the motor itself?
John
Hello John,
The gauges are B747 gutted and modified with an RC servo motor(s) and operated with an Open Cockpits DC servo motor board. The gauge is fine, I have actually done some troubleshooting and changed outputs and the problem followed the other gauges.
In actuality, if I put a lot of stress on the computer, then all the gauges slow down...so it is definitely a USB data transfer rate problem. Some days its hardly noticeable and other days very noticeable.
I was only interested in the USB driver update as many internet posts say it can speed up the transfer rate by 30 percent...however I am not going to risk re jigging all my protocols in the event the driver update goes south.
I have two USB hubs coming off the Master computer. (I do not have the hubs connected to one another, but rather one computer USB output to one hub, and the other computer USB output to another).
Off of one hub I have the three SIOC open cockpits DC servo motors board outputs.
Off the second hub I have my rudder pedals, MCP, Nav 1 and Nav 2 outputs..
The main computer also displays the Captains and First Officers flight instrument panels through a video splitter. and also the outputs to a LAN hub for the wide view clients (7 separate computers).
-jim
Jim,
I can tell you that I am running 16 usb devices on my one PC and X-plane 10, no slow data at all. I also was running opencockpits servo cards on a networked PC running 2 servo cards and 8 servos with no delays. There is something less obvious causing a slowdown in data transfer to SIOC to servo card to servo.
Rob
What version type/data rate of the USB ports are on the computer versus the hubs? 1.0, 1,1, 2.0, 3.0? It's better if the hubs match the computers's USB port version...
John
Thanks for the input guys,
I think you are getting close to the solution. I used to have my computer hardware information handy here at my desk, will have to dig and find it then post.
The USB hubs I am using are not the most expensive, so maybe there is a problem with the hub itself.
Anyway, will dig some more and post and hopefully solve this problem.
Rob, it is good to hear you do not have any slowdowns on your USB data...i always assumed my setup might have been òvertaxed``...would love to see what it will do if there is a simple solution to this problem.
-Jim
Jim,
Just checking here, but do your hubs have power supplies and are they plugged in/working? If they're not powered, they then draw power from the the computers power supply through the computers USB port, so when you use more items requiring power, that might affect them. Of course that all depends on what's plugged into the hub plugs and if they're drawing power as well.
Also, there are some BIOS that have settings where you can change the USB type from 1.1+2.0 or just 2.0; this makes the USB backwards compatible for legacy hardware under 1.1. You mjight not have 1.0 or 1.1 hubs, but you never know.
Lastly, have you looked into your Device Manager lists too see if there are any yellow flag indicators before or during use of your sim? Look at the driver numbers and port info under properties of each USB item by right mouse clicking each, one at a time, and then select properties.
John
Hello John,
Yes, my USB hubs are powered from there own 5 volt adapters, however the adapters are plugged into the same surge protector bus as the monitors and some other items..
I will check the BIOS settings when i get home from work along with the device manager.
I may not be able to interpret the information, so I will include a screen shot on my next post.
-Jim
Here are some screen shots,
Here is a pic of my USB information, I am assuming since the directory says "enhanced" that it is indeed USB 2.0 (?).
The other two shots are probably of no use, but they are the two hubs running SIOC and the other devices....each has a separate 5 volt supply.
Can anyone make any headway with this information so far?..
Open to more suggestions,...John..I am not sure where to check the BIOS settings
-Jim
Ok...to add to the information.
When I click on "[port 4] device connected" one of the SIOC USB outputs I get this information in the first pic.
As you can see it says;
bcdUSB 0x0100
and.....when I click on the usb information relating to the Bodnar interface board it says;
bcdUSB 0x0200
Is this telling me version 1 or 2.0 for the USB information?
Just a quick observation, why aren't the red power lights lit up on the USB hubs? Are you sure you have the right power supplies plugged into their respective hubs?
More answers too follow...
You have an 1.0 and a 2.0 hub in use; you are correct bcdUSB 0x0100 is 1.0 and bcdUSB 0x0200 is 2.0. Read this:
http://superuser.com/questions/388174/show-usb-speed-for-all-devices-in-windows-7 (http://superuser.com/questions/388174/show-usb-speed-for-all-devices-in-windows-7)
You need some new hubs and get both exactly the same...
John
Your opencockpits/SIOC cards are plugged into the slower 1.0 hub and that is slowing things down. I must ask do you have an external power supply connected to your DC Motors Card, as shown in the manual, on page 4:
http://www.opencockpits.com/uploads/manuales/IOCard_USB_DcMotors_Manual_2012_REV2.0_English.pdf (http://www.opencockpits.com/uploads/manuales/IOCard_USB_DcMotors_Manual_2012_REV2.0_English.pdf)
If not you should have...
As for the BIOS settings, I don't think that will help, but if you have the motherboard manual and/or the motherboard model number, I can look it up.
John
John,
Are you saying that the function of the SIOC outputs running on a USB 1 level are the product of the hub itself?
If so this should solve my problem if I swap out the hub (?)...and if this is the case is there a specific type of hub I should be looking for?
I was unaware that the usb hub would cause the data transfer to slow down.
Maybe I am misinterpreting your post.
And yes, I do have a separate 5 volt supply for the open cockpit boards
The hub pics were taken with no power on...thats why the rid lights are not on.
Thanks John,
I may be getting very close to solving this problem...fingers crossed
I'm pretty sure OC stuff is USB 1 or 1.1
John,
He doesn't have the USB motors card. He is using the USB Servo card.
Rob
Actually guys....just ran downstairs to check...I made a mistake on my last post...
So the hub that outputs to the 3 open cockpit boards is the same hub that outputs to the Bodnar interface board (BUO836X). This means that Rob is correct in his post that OC operates off 1.0, (as the 836X shows bcdUSB x0200, and the OC boards off the same hub show bcdUSB x0100)
So I am back to square one :(
Yes, the USB # of either 1.0, 1.1, 2.0 or 3.0 stands for the data transfer rate. 1.0 is really slow dating back into the 1990's. You could have a 2.0 device like a card that rated for 2.0 plugged into a 1.0 hub, and it could work if that card is backwards compatible with the older/slower 1.0. If it is, it will run at the slower speed of the hub. If it's not, the card would not work.
So, your computer's USB ports is likely rated at 2.0 or 3.0. For your 2.0 hub they match and that is why you see Full. With the 1.0 hub, your computer switches its port speed too match the hub of 1.0, slowing it down so things can work, hence the Low value.
If you switch hubs around, you're just moving the problem onto your Bidnar Card, and it will slow things down with your rudder pedals, MCP, NAV1 and NAV2...I would not do that at all.
Do you have the motherboard model number or manual, that way we can determine your USB Ports standard or native speed. Then, you buy hubs that match that same native speed. In other words, if your computer's USB ports are 2.0, you buy 2.0 hubs.
John
I can't find your SIOC code you sent me, could you resend please. I would also like to see your sioc config file ini I still don't think this is a usb problem. You are just not transferring enough data for this to be an issue. From my SIOC days, I had a pretty large file running with several cards on a USB 1.1 set-up and no lag. Not saying there isn't a problem with yours, just that it shouldn't cause a problem.
Rob
Looking at your pics, your Bodnar Card is connected too your 0x0200 or 2.0 Hub and the OC stuff is plugged into the 0x0100 or 1.0 hub.
Thanks Rob for pointing out he has the USBServos card...he would still need an external power sources at the card though, right? Which I think he has.
I had this problem years ago with hubs and if Jim has the time he could search for those posts under my name. It would be some good reading. I have OC USBServo Cards for my OC gauges, and those with my FDS Cards would not work with the older hub I had. I purchased some new 2.0 hubs and no more issues.
In the end, his computer USB port speeds is where it all comes down too. Some motheboards don't like legacy USB speeds and having to slow down for them. As silly as it sounds, I think it's the old saying "if you have new, stay new or if you have old, stay old". So, my suggestion is by matching hubs...
John
Edit:
A way to test the theory is switch the hubs, but that will screw up his USB assignments, like Bob said earlier. Still, if he is thinking about buying new hubs, he'll have too reassign them anyway...if it were me, I would switch them around just too see if that fixes things first; albeit, doing the reassignments would suck!
John,
you wrote:
"Looking at your pics, your Bodnar Card is connected too your 0x0200 or 2.0 Hub and the OC stuff is plugged into the 0x0100 or 1.0 hub".
This is true, however the bodnar card and the OC cards are connected to the exact same hub. That was my mistake on previous post(s) that I probably eluded they were from different hubs, but they are not.
Rob, I re-sent that SIOC information to your raflyer address. I will take a pic of the SIOC_INI and post it here as well.
-Jim
Oh, okay... I still believe it is related to USB versions/hubs.
How about this, please post the name/brand and model number of the two hubs, as well as your name/brand and motherboard model number.
John
Rob,
Here is the SIOC_INI file (notepad text).
-Jim
John,
I am gathering the hub and motherboard information right now...will be my next post
-Jim
Sorry Rob I sent the txt file twice...
John,
the hubs and motherboard are as follows
one is a Trendnet 7-Port High Speed, and the other is a Dynex 4 port USB 2.0 hi-speed hub. The dynex is the hub that connects the 3 OC boards and the one Bodnar board
My motherboard is an M2N-SLI deluxe motherboard...in fact here are all the computer specs in case there is some information I am missing;
OCZ gold XTC PC2-6400 4 GB DDR2-800
AMD athlon 64 x 2 dual core 6000+ socket AM2
PNY XLR8 9800GT 1024 video car
M2N-SLI Deluxe Motheroard
EG465p-VE power supply
Rob and John,
Will check back with you tomorrow afternoon. Got to get to bed, 4am check in and the weather is supposed to be lousy tomorrow.
I appreciate all the information and help...hopefully I will be able to eliminate this lag in the engine gauges.
Possibly John is correct as well that these USB hubs need to be changed out regardless...they are not the most expensive.
Still wondering why OC would use a USB 1.0 protocol as opposed to a 2.0 (?)
-Jim
One more thought before I go.....
Is there any chance the Servo motor boards inside the gauge could be suspect. That is to say I am using Hitec servo motors from Servocity. I am using the servo motor, and control board from the servo but not the servo`s own potentiometer. Instead I have connected that board to the actual gauges potentiometer.
Jim,
Okay, here is the link to your motherboard manual:
http://static.highspeedbackbone.net/pdf/Asus_M2N-SLI-DELUXE_Manual.pdf (http://static.highspeedbackbone.net/pdf/Asus_M2N-SLI-DELUXE_Manual.pdf)
You need to read page 1-12, as well as page 4-30. On 1-12 it reads that your motherboard only supports 2.0 and 1.1. Now, you say that you have the OC stuff plugged into the Dynex 4 port 2.0 hub, and Rob says the since OC is at 1.0 or even 1.1 it should work. However, you need to go to the BIOS see page 4-30 and enable the Legacy USB which will turn 1.1 on for your computer, as by default it is turned off (it will be the last option on page 4-30.
As to your question about the mix-match of parts, you say it does work correctly sometimes, so that too me suggest it's a data bottleneck occuring somewhere downstream of the cards in the USB channel. The other thought I have is what are the potentiometer from gauges voltage requirements? You're only getting 5 volts from the USB Servos card per servo output, and correct me if I am wrong, but aren't real gauges using 24volt? This is where Rob comes in, as he is the expert at interfacing real aircraft items.
My point is, if you need 24 volts and you're only getting 5 volts, they could move, but really slow or if at all. Still, since it does work sometimes it could be either hubs or power requirements...
John
John,
Thanks for the response and the information. I will read the text as per the motherboard manual and make the adjustments accordingly, then update both of you guys on any change. (Will get home tomorrow nite so will do that then and email you).
As for the aircraft instruments, the gauge itself does not require any power as the servo motor board is just getting information from the gauges actual potentiometer, which is somewhat similar to the supplied pot in the Hitec servo, but allows a greater latitude of degrees.
I don`t think gauge power is an issue as most of the gauges work perfectly with no issues whatsoever.
I am inclined to agree with the USB data `botttleneck`theory.
-jim
Hello guys,
Here is an update.
I went in to the computer's BIOS to the USB settings and the "legacy" USB function for 1.0 and 1.1 was already enabled.
-Jim
Hi Jim,
At this point, I think it's either the hubs or what Rob is leaning towards...the SIOC coding. However, the thing that's perplexing is how it works sometimes and then not...
Since you found the BIOS location for the USB legacy, try it with it disabled. I know that sounds backwards, but I have seen a lot of weird things when dealing with computers.
One last thing, how long are your USB cables from the computer to the hubs and from the hubs to the devices? There are length limitations when dealing with USB.
John
PS If you have an antivirus program turned on, turn it off and then try it...
Hello John,
I will try and 'disable' the BIOS legacy setting and see what happens.
Also you might be on to something regarding the hubs or the cable distance. The cables are 6 feet in length.
Also I have disabled the anti-virus some time ago as I thought it might be a contributing problem.
-Jim
Jim,
What happens when you run just one servo card? Then add the 2nd? Then add the 3rd? What are your FPS on the sim?
USB cable length, well all I will say is I have one 15' long and one 12' long with no issues. I also have 4 hubs full and 6 ports full on my PC. Thats a total of 20 usb devices on one PC, no disconnects, no data loss, and lots of back feeding of voltage and gnd's LOL :o
This is my :2cw: from a former OC user. Step away, sell, regroup and go to arduino. Why? Way cheaper, powerful, Ethernet, and darn near trouble free. I'll admit right now that for the time being, i still have an OC usb outputs card, and you know what, it cause random issues in my overhead from poor circuit design. Whwn I bulb test, some of my switches go nuts.
Rob
Rob
Rob,
I think I am going to have to agree with you, when I first hooked up my OC servo boards, I used the same 5 volt power supply to operate the cards (all three) and also the same supply to illuminate the internal gauge lighting.
The gauges worked fine until I turned on the gauge lighting and some of the gauges went nuts, and actually increased beyond there pot limit(s) causing me to have to disasemble the gauge and physically move the needle back into the pot authority limits.
I will have to look into the Arduino product. Do you think it will be a big hassle to change over?
For now I am thinking my cheap USB hubs might be the contributing factor ...
-Jim
Rob, (and John),
Also disconnected two of the three OC boards and the remaining gauges, (specifically the engine 2 TGT gauge), ran smoothly, with no lag or freeze issues.
So basically the board is OK, it has to be a data issue..
So the question remains why...however will upgrading my USB hubs make any difference?
-jim
Quote from: Mach7 on January 21, 2016, 08:37:40 AM
Rob,
...
I will have to look into the Arduino product. Do you think it will be a big hassle to change over?
....
-Jim
If you've been able to learn how to program a SIOC script....you can learn how to program in c.
This is true KyleH, however it took a lot of help form the outside to get to this point....and I am not 100 percent sure how it all works but it does.
A follow up question for all;
I am thinking about moving my 836 bondar board usb connection to the other USB hub...(the one that has all the USB 2.0 devices), and allow the other Hub to output to the three SIOC OC boards only....
My question is this...if I move my USB plug from one port to another...is it going to screw up my bodnar board offsets for throttle, ns steering, flight controls etc etc?...or will the computer just recognize the port and adjust accordingly.
In other words, will I have to reset all the Fs9 offsets?
-Jim
If windows sees it as a joystick, then yes you will need to redo your axis/button settings.
Another update,
I moved the 836x bodnar board connection to the other USB hub and left the three outputs to the SIOC OC boards on the other hub alone.
Started the engines and found the exact same lag and freeze occured in engine 2 TGT gauge, and even a bit in the engine 1 TGT gauge.
So....back to square one again.
I think your issue has something too do with the OC card power supply voltage now. You had the problem in the past where you had to adjust the needles and such. Currently, one will freeze and the other will lag behind, but if you do just one gauge it works. I think your OC power supply has the voltage but not enough amps.
Where did you get the power supply? What is the power ratings for it? Are you sure it is 5 volts and not less, and how many amps does it put out? Please post a pic of it showing the model and ratings...
John
Hello John,
The power supply is an OMRON S8JX model. It delivers 5 volts at 20 amps.
I don't think the power supply is suspect
-Jim
Hi Jim,
Okay, is your voltage adjuster turned on? See link and *5:
https://www.ia.omron.com/products/family/1989/specification.html (https://www.ia.omron.com/products/family/1989/specification.html)
You've tried so many things thus far, but too me, the time you had everything all hooked up to one power supply and turned the lights on, causing the servo motors to go beyond their limits says it was too much power. I do a lot of RC stuff and when something like this hapoens it means you likely destroyed the controllers in the servos.
However, since you can hook up one gauge and it works, that makes me think otherwise. Therefore, how about this; hook up each gauge seperately to see if all three work individually. Next, hook up two at a time and see if two out of three will in fact work. If they don't then you need too get out a multimeter and test the amps and voltage load from the card.
I once fried an OC board by applying too much voltage to it, so if your power supply over applied voltage to the card it could've done something too it. Earlier, I thought bottleneck of the data, but like Rob says, he has way more devices hooked up without any issues. Pretty much the same with my stuff as well; I have a mulitude of devices running on the USB channels. Your cable length is well within limitations, so it's not that.
My suggestion is try a different power supply, as you've already tried the hubs. Also, try plugging the USB Hubs cable to PC USB port to a different port on the PC. Basically, you need too eliminate one thing at a time or also called "creative trubleshooting"...lol.
John
Jim,
What happens with no lights running and just the gauges?. Think you need to
minimize what you are driving. If it works ok then I would suggest getting a separate
P/S to drive lights and then see what happens.
It seems to me you have two problems, one of lag and things get screwed up when lights work.
Les
Hello John,
The (omrn) power supply reads 4.97 volts. I too checked the supply and even went so far to ensure this supply is dedicated to the OC boards and nothing else.
I also have tried unplugging the USB input to 1 board, then two boards to see how the board with the engine 2 tgt gauge reacts. When two out of three boards are 'on line' there is no lag or hesitation, however once you connect the third board, the engine 2 tgt gauge will freeze and lag.
I am pretty sure it is a data transfer problem because when you go to start engine 2, all engine gauges relating to that engine will run up normally with engine 2 tgt gauge lying "dormant" until all the other gauges have reached there limits...then the engine 2 will run normally to its stabilized value.
If you now increase power very slowly, engine 2 tgt will follow, however if you move the engine throttle fast, the gauge will again freeze for a couple of seconds and move once the other gauges have reached there value.
I should point out that, while engine 2 tgt displays the visible lag and freeze, sometimes fuel flow 4 will hesitate a bit...but only sometimes.
Again, I have 3 OC cards;
Card 1 controls all 4 N1 gauges and engine 1 and 2 tgt gauges
Card 2 controls engine 3 and 4 tgt, and all 4 N2 gauges.
Card 3 controls all 4 fuel flow gauges and one flap indicator gauge.
Now....if you disconnect one of the cards, say card 3 that outputs to fuel flows 1 thru 4, and the flap indicator , then all lag and freeze disappears.
All lag and freeze also disappears if you disconnect card 2, (card 2 outputs to tgt 3 and 4, and N2's 1 thru 4).
It seems to me it is definitely a data speed bottleneck.
@iwik,
The lights are no longer an issue as they run off a separate power supply. I have ensured that the OC cards have a dedicated 5 volt supply.
Jim,
Did you try this yet:
In the hub shown in the attached pic, you have the Bodnar card and the 3 OC Cards, unplug the Bodnar card and operate sim...what happens now with the OC Gauges?
If everything is still the same, unplug everything from the other hub, plug in OCCards/Gauges, operate sim...what happens?
If you do this, it will screw up your assignments, so you will have too adjust them. Also, you might need a keyboard to control the throttle in order to rev up the engines and etc, if your throttle gets disconnected.
Doing this will tell you if it's the hub that actually has the problem.
John
John,
I did that this afternoon as well. I unplugged the bondar board USB output from the hub and connected it to the other hub, leaving only the 3 OC board outputs connected to the respective hub.
After re-programming some assignments I started the engines, however the problem remained with no improvement.
Jim,
Something that should be considered is the 'In Rush" current. 16 motors starting up
could be quite high. Can you please power the 3rd card from a separate power supply
and see what happens.
Les
Les,
I Will give that a try tomorrow and report back.
-Jim
Jim,
You did the first part of removing the Bodnar card, but you stayed with the same hub for the OC cards. Now, unplug everything from the other hub, plug the 3 OC into it and nothing else. Do not plug in the Bodnar either. The point is, just do the 3 OC cards only...if they work correctly, I would say it's the original hub they were in and if they don't it's power supply for the OC Cards.
John
Hello John,
I removed all of the USB outputs from both hubs then moved the OC ouputs to the other hub, re assigned SIOC, and gave it a try.
It ran a bit better, but engine 2 tgt is still lagging behind when rapid increase/decrease thrust lever movements are made.
Here is another observation I have made:
If I have a lot of freezing and lag in engine 2 tgt, (and some hardly noticeable lag in the other gauges, namely engine 4 fuel flow) by shutting down FS9, and closing the SIOC control window, and pulling out all of the OC usb outputs then pushing them back in. The guages (namely eng 2 tgt) work better...that is to say when you start engine 2 the TGT begins to rise as per normal as opposed to not moving at all until the other gauges have reached there limits, however will still lag behind on rapid throttle movements.
This of course does not hold much water, as the sim can be shutdown for a couple of weeks, and when I fire it up the engine 2 tgt gauges will sometimes freeze....however the above seems to work for excessive lag and freeze.
As stated in my previous post, at one point al the engines were up and running, however engine 2 tgt remained dormant. I decided to pull the lead from port 6 of the OC board that was directly connected to the gauge. When I reconnected the gauge it came to life right away, as if you opened the drain on a sink.
So, though process of elimination, and general observation, here is what we know so far.
Engine 2 TGT gauge is not suspect as switching the leads to another gauge moves the problem to that gauge.
The power supply has been replaced and checked at a nominal 5 volts, and does not power any other aircraft sub systems
Engine 2 tgt freeze and lag happens but a various degrees of severity, that is to say on some days it is hardly evident as long as you don't move the throttles too quick, on other days it is extremely evident.
By unplugging one or two OC boards around the engine 3 board, the gauge works fine, with no freeze or lag, even at very fast throttle movements.
I have observed that the gauge on the last port(s) of every OC board has some hesitation to it, (with the exception of engine 4 N2)with engine 2 tgt being the worst. That is to say. engine 2 tgt is connected to port 6 on OC board 1, fuel flow and the flap gauge are connected to ports 4 and 5 respectively on OC board 3. If you try and move the flaps at the same time you are increasing thrust, the flap gauge will move but not as fast as if the where stabilized with no increase/decrease in thrust. I have also pointed out that there is sometimes a lag or freeze on fuel flow number 4, but it does not occur all the time.
I have disconnected/deleted the anti-virus, as the computer is not connected on line, and I do not download directly to it.
The windows firewall has also been shutoff.
I am not sure when the last windows update was, but the computer has not had a windows update in a very very long time. I just find that the updates can sometimes play havoc on ones system.
If you over tax the computer, that is to say you put fs9 scenery at maximum and then try and fly, all the gauges will lag and hesitation. For this reason I run this computer at minimal scenery with my FSPanel studio gauges overtop.
Could the OC board possibly be suspect?...all the other gauges off that board run fine.
Ok...another update,
After unplugging, plugging back in, changing power supplies and restarting the computer a million times, today the all the gauges worked perfectly with no lag or hesitation....but I know the problem will return.
I am totally baffed.
I think I might just live with the problem for now, as it there seems to be no consistentcey with this issue.
I want to thank all for there inputs, and open to more suggestions.
-Jim
Hi Jim,
After reading your post, I thought the OC Cards were the problem, but the one thing you said is when you use a lot of scenery on FS9 they all hesitate or slow down. Too me the answer is not the hardware of the OC Cards, power supplies or hubs, it all lies either with your computer running everything or FS9.
Somehow, whatever is the most active gets the attention...when you plugged the gauges in and they work normally, but later they go back to slowing down. I just wonder if the USB controller on the motherboard is causing the issues. Let me ask you this, do you have any screen savers or power saver modes active? If you're computer goes too sleep and wakes up it could cause the problem. Check and make sure you have all power savings and screen savers off for now.
Since you redid everything and it's all working, you'll have too wait until it starts happening again. In the mean time, do nothing for now, fly it and have fun. Who knows, maybe the problem will not come back...
John
Hello John,
Yes, I do have both power and screen saver modes active on this computer, so I will disable them and see if that makes a difference.
I want to thank you once again for you input and help. This has been an on-going issue for me, but hopefully it will be solved, or solve itself one day.
I will continue to post any issues good or bad.
Thanks again to all who contributed for the help as well!
-Jim
Hi Jim,
Before you call it fixed or not, you said this on Jan 22:
Quote from: Mach7 on January 22, 2016, 09:06:38 AM
Ok...another update,
After unplugging, plugging back in, changing power supplies and restarting the computer a million times, today the all the gauges worked perfectly with no lag or hesitation....but I know the problem will return.
I am totally baffed.
I think I might just live with the problem for now, as it there seems to be no consistentcey with this issue.
I want to thank all for there inputs, and open to more suggestions.
-Jim
What power supply did you change? Was it the one for the OC Cards and then everything worked fine? I mentioned about your power supply having a voltage adjuster that is either turned on or off, your manual talks about it, so I was thinking if it was on, it would be causing voltage adjustments. Based on what was going on how the gauges would go slow or lag, as well as how the flap gauge would slow diwn when the other gauge(s) was working all says voltage power or actually amperage.
In the sense that the drain on the power supply was not enough to power all the gauges at once or at least in a full fashion. However, if you changed the power supply for the OC Cards and it all works fine, after a lot of restarts and etc, that says the power supply change was what fixed it...
Best Regards,
John
Hello John,
No...the voltage supply was changed out sometime ago, not because it was suspect, but I wanted the OC gauges to have there own dedicated power supply. The power supply in question is the Omron 5 volt unit.
The voltage adjustment is just a green screw like potentiometer on top of the unit (Omron) that you can increase/decrease voltage by a small amount. I usually don't touch this as the factory settings seem adequete at between 4.95 and 5 volts.
-Jim