CyBerkut

BTW, this would essentially take you back to what we talked about way back earlier in the thread... http://forums.eagle.ru/showpost.php?p=612063&postcount=469 http://forums.eagle.ru/showpost.php?p=612063&postcount=470 ;)

Trigger, I think you should remove the check valve (one way valve). If you still wish to keep the resevoir, then substitute an isolation valve instead (for the check valve). What I believe is happening is that when you move the collective in the "up" direction, it is creating a lower pressure on the corresponding side of the fluid loop, and sucking in some (additional) fluid from the resevoir through the check valve. Your current configuration, as I understand it, is not truly a closed loop. It is effectively closed when you move the stick down, and the puts back pressure upon the check valve, keeping it seated. It is effectively semi-open when you move the stick up, since that reduces the relative pressure and allows the check valve to open and let additional fluid get sucked in. To make the fluid loop a closed loop under normal operation, replace the check valve with an isolation valve. That will allow you to keep the resevoir for when you need to do a (re)fill, by temporarily opening the isolation valve... just close it before flying.

Trigger, can you give us a sketch of how your collective's hydraulic system is currently configured? What is the symptom being exhibited of the pressure building up (ie. Resistance to movement in 1 direction, or both directions of movement)? I have a suspicion as to what is happening, but I don't know for certain what your current configuration is.

Great news! Thanks for the update. Now try to have some fun with your gear, Trigger!

Certainly, he does... as do the responders. Sometimes, ridicule is well deserved.

Oh yes... A reclining ejection seat that has a rising calf support, and perhaps retractable holders for a cup and a remote control !!! :D Seriously though, Flim I hope what you are doing pans out. I've been watching the various pit building threads with admiration (and not a small amount of envy), and having someone offering the key components, etc. (at a hopefully reasonable price) could certainly increase the chances of more of us building/having pits of our own. Carry on! :thumbup:

First one for me... MS Flight Simulator 1.x (I think it was 1.0), on an IBM PC (PC2 motherboard) chipped out to the full 256K of RAM, plus the AST Six Pack card to get the RAM all the way up to the whopping maximum of 640 K. I had a CGA monitor for color apps and a (green) monochrome display for text apps (because the text was too hard to read on the color monitor). PC DOS 1.1 (CPM 86 was a better OS, but the IBM / MS juggernaut was not to be denied). I bought it as a barebones unit, and decided to put 2 of the 1/2 height floppy drives (5.25 floppies back then) instead of the standard full height drives, so that I could add a hard drive in to the right hand drive bay later when the prices weren't quite as astronomical. As I recall, I was using a Kraft joystick (basically a thin stick about half the length of a new wooden pencil, with a fire button on top). The base had 2 slider potentiometers for trimming the X and Y axis calibrations, and IIRC another button. :joystick: Later on, with the jump to a 386 and then a 486, Falcon 3.0 and the Mig-29 add-on. F-15 Strike Eagle was fun as well. :pilotfly: I bought/installed Falcon 4.0, but that was when I was hard at getting the ISP business going, so I didn't really have to time to put into it. There were some others along the way, but the above are what stand out in my mind the most. There have been some dry spells along the way, but man have we got it good!!! Of course, I'm still waiting for my flying car, dammit... :mad:

I see from your posts over in your pit thread that you have been busy. I remain amazed at how productive you are! I'm glad you have the .lua stack problem behind you. The ghost switch problem sounds like that could be a persistent nuisance. Hopefully you'll find a clear cause for it so that it is gone for good.

Trigger, it's been a few days... How are you making out, brother?

Well, I know that the sim will work with FFB on the rudder input when there is no FFB joystick on the joystick X axis. When I reassigned the Saitek Cyborg Evo Force's X axis to the rudder axis to see if it would hold trim, it worked. IIRC, I still had the Y axis of the joystick as the Cyclic's Y axis. Trigger, do you have an extra FFB joystick that you can temporarily substitute for your pit's cyclic control? It would be a useful troubleshooting technique to see if the conflict remains or disappears. If you do the above substitution and the problem still occurs, then I would suggest hooking your pit's cyclic control back up, and then substitute the temporary FFB joystick's X Axis for the pit's FFB rudder pedals. If the conflicted behavior exists no matter which input the temporary FFB joystick gets substituted for, then there appears to be a problem with DCS:BS supporting dual FFB controls, which will almost certainly require E.D.'s attention to rectify. (Could be a config / .LUA file, or it might be program code in the executable) If the conflicted behavior exists for one substitution, but not the other, then you can see which of your pit's controllers is the problem.

Interesting article on SSD performance over time: Analysis: SSD performance -- is a slowdown inevitable? http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9132668&source=CWNLE_NLT_AM_2009-05-08

There is one significant benefit to starting from someone else's profile, even if you intend to assign nearly everything differently... you'll already have all those key combinations for the commands that they entered in. You can then just use the pull down list while re-assigning those commands to wherever *you* want them. (This is assuming you are both using the default key combinations for the various commands).

Refer to this thread: http://forums.eagle.ru/showthread.php?t=35202 The glove is indeed something that you build. Basically, a momentary pushbutton switch in the fingertip that activates a (ideally) 950nm wavelength IR LED that is battery powered. The Wiimote detects the lit IR LED's position and reports it to the whiteboard software (which also interprets a lit IR LED as a left mouse click). It's a pretty cool project if you have a display surface that you don't mind pushing against.

My TrackClip Pro's USB plug also has a pass-through USB recepticle, so it doesn't really use up a USB port.

It's officially listed for sale on Natural Point's web site $149.95 for the TrackIR 5 $169.95 for the TrackIR 5 with TrackClip Pro From http://www.naturalpoint.com/trackir/02-products/trackir-product-comparison.html TrackIR Model TrackIR 5 MSRP $ 149.95 Head Position Tracked 6 Axes (6 DOF) Horizontal Field of View 51.7° Sample Rate (FPS) 120 Raw Sensor Resolution 640 x 480 Sub-pixel Resolution 1/150th pixel Reporting Range 96,000 x 72,000 Resolution/Horizontal Field of View Degree 1850 subpixels/degree TrackIR Model TrackIR 4 MSRP $ 99.95 Head Position Tracked 6 Axes (6 DOF) Horizontal Field of View 46° Sample Rate (FPS) 120 Raw Sensor Resolution 355 x 288 * Sub-pixel Resolution 1/20th pixel Reporting Range 7,100 x 5,760 Resolution/Horizontal Field of View Degree 154 subpixels/degree * Subsampled up to 710 x 288 using NaturalPoint's Resolution Doubling Technology. View Resolution Comparison Video Unit Size (without base)

In the thread over there, Seth indicates that May 1st is the official launch.

Oddly enough, an examination of the FreeTrack community's experience will clarify one benefit. Mainly, that web cam based solutions impose a higher processing load upon the CPU than the specialized hardware alternative(s), and have a much lower frames per second (talking about the tracking, as opposed to the game display FPS). FreeTrack has alternatives to web cam use, which allows one to see the direct effect of using different hardware with the same software. Older versions of FreeTrack supported the TrackIR hardware. Web cam setups typically got aound 30 FPS whereas TrackIR hardware with FreeTrack would get around 100 FPS. The later versions of FreeTrack support another hardware option, namely the use of a Wiimote instead of a webcam. Wiimote usage with FreeTrack also typically yeilds approximately 100 FPS tracking, and also imposes virtually no load upon the CPU. It's all tradeoffs. If Cachya is getting the job done to your satisfaction, cooll! Some folks will inevitably want to offload the processing from their CPU, or be able to play in a room without visible lighting, or ...

See message #1 in this thread. ;)

Happy 40th, Trigger! Welcome to the other side of the hill. :smartass:

Yes, what USSR Rik said. ;) Two things mentioned in the original statement seem at odds with one another... the described problematic behaviour vs the test page results. The X-52 does indeed use Hall sensors. A while back, someone offered up a mod that involved changing the arrangement of the magnets inside the stick: http://forums.eagle.ru/showthread.php?t=21199 It occurred to me that your magnet(s) or hall sensors may have somehow shifted a bit, causing the resulting output curve to shift. The above mod might be worth looking into. Even if you do not elect to do it, it may at least give you better insight into how your stick develops the X and Y axis outputs, and may let you spot a problem if your magnets or hall sensors have physically shifted somehow.

Done. (6th, I suppose).

Well, depending on what fuel they use, you might be able to move "backwards" by launching Vihkrs and/or rockets. Maybe even get a little "left", "right", "up" and "down" impulse control by aiming the gun off of center. Guess those mirrors could finally become more useful! :smartass: Re-entry is going to be one helluva auto-rotation maneuver though... ;)

Morsmortis, it sounds like you're off to a good start, but that does seem like a lot of hurdles left to be cleared. It would definitely be nice to have an alternative. The one thing that truly keeps me stuck in the MS Windows world on my home machines is gaming. I don't hate Microsoft, but I'd like to see Linux finally get enough of the desktop market share to warrant game software developers attention. I know it's not what you asked about, and it doesn't take Windows out of the equation, but I'm wondering how much of a performance hit would result from running DCS:BS in a Virtual Machine. There are a number of choices out there for Virtual Machine Managers... some of them use Linux as a host OS, and some use a stripped down Linux kernal as a "bare metal VMM (hypervisor)". I wish I was well versed in Linux / WINE / Cedaga enough to be helpful to you, but alas that is not the case.

Trigger... you left out the link to Mark (surname)'s home page! :) (Well, you indicated I should be more direct... sort of...) :music_whistling: Seriously though, the controls are coming along great! :thumbup: It's certainly educational to see how you solve various challenges. That was a good point about the VCR gears. I'm pretty sure I've got at least one dead one sitting around out in the garage... I may just have to give that a look.

I temporarily set my Saitek Cyborg Evo FFB X axis to be the rudder/yaw and it held the trimmed position, so I would say that DCS:BS supports FFB (for trim purposes) for the pedals.