Jump to content

Recommended Posts

Posted

Hey guys,

 

Trying to wrap my head around the options for interfacing controls with my pit. I have very limited programming or electronics knowledge, but this is what I understand now from reading the information I've found here and at other sites.

 

As I see it, there are two majors paths I could take:

 

1. Simple interfacing where buttons/switches are assigned to keyboard commands. Easier to do, but the controls would not be in sync and I would not have any data exporting to the pit.

 

2. Solution like EPIC or Opencockpits card and LUA. More difficult, but the pit would be able to "talk" with the sim and pull data from it and keep the controls in sync.

 

I realize there's much more to it, but I am thinking 'big picture' at this point. Since option 2 would be an uphill battle for me, I am leaning towards a simple pit using some of the USB IO cards available for the switches (Bodnar's stuff for example). As long I as manually sync all my buttons/switches before each flight, then this will work right?

Posted

At it's basic level yes those are your two options. Keep in mind that if you ever want any gauges or indicator lights in your pit you will have to deal with LUA export sooner or later. So think about how you might do it before selecting your input cards for option 1, so you can take advantage of it when the time comes.

Posted

There's no problem with using both methods. Start out with option 1 and when/if you reach a limitation of that method and you want more for your pit, you can incorporate option 2. About the uphill battle, you'll find lots of help on this forum and a solution will certainly be posted that you can take advantage of. Most likely you will only need to copy files and edit a few lines of code to get the lua solution going.

 

Also, I'm not sure why there is so much worry out there about out of sync"ness", but It's really not an issue. Any card you use whether its Leo's or OC or some other solution will let you hook up switches in such a way that you get unique events reported for each switch position. Then you would NOT map the events to "toggle" commands but instead use discrete commands like the equivalent "up / down" if available. If only a toggle command is available, use Lua to loop a toggle-query until the desired position is reached if a query is possible. So option 2 potentially could save you there. Sure it's possible that some switches will be in the wrong position at start up, but as soon as you move the switch once the problem is solved. Look at it this way, if the switch is off but it's supposed to be on, just flip it on and the thing it controls will stay on - no harm done, nothing out of sync. If the switch is on and it's supposed to be off, flip the switch off and the thing will stay off.

Posted
Also, I'm not sure why there is so much worry out there about out of sync"ness", but It's really not an issue. Any card you use whether its Leo's or OC or some other solution will let you hook up switches in such a way that you get unique events reported for each switch position. Then you would NOT map the events to "toggle" commands but instead use discrete commands like the equivalent "up / down" if available. If only a toggle command is available, use Lua to loop a toggle-query until the desired position is reached if a query is possible. So option 2 potentially could save you there. Sure it's possible that some switches will be in the wrong position at start up, but as soon as you move the switch once the problem is solved. Look at it this way, if the switch is off but it's supposed to be on, just flip it on and the thing it controls will stay on - no harm done, nothing out of sync. If the switch is on and it's supposed to be off, flip the switch off and the thing will stay off.

 

The problem is there are A LOT (if not a majority) of switches in the shark which match your problem statement. Take the PUI-800 Weapon Status and Control Panel the only keyboard commands available for every switch on that panel are toggle commands. That means you HAVE to have them in the right position at flight start up time or they will not sync unless you pause game or prevent keypress from being created till you sync them. They will not "just stay off" as you put it. To fix this with a keyboard emulator process it would still have to monitor the state of the switch via LUA and then send the correct number of keyboard toggle button presses. If your going to do that it would probably be simpler to just send the switch position in via LUA where you can set the absolute position.

 

Doing simple keyboard mapping of switches will work, but has a limit on how well it will work. I still advise taking a bit to think about it before ordering a bunch of interface cards. If you're ok with those limits then by all means, if not it's probably best to start learning the rest at first so you're not reworking as much.

Posted

I hear you. I didn't mean to say that it's a problem that doesn't have to be solved. On the contrary, I believe it's a problem that *always* has to be solved, and in that way it's not really an issue, more of an inherent part of pit building. It really has nothing to do with option 1 vs. 2, it all comes down to the sim command being a toggle. However you interface your switches, if you only have a toggle command available, you will need to solve it with scripting trickery. I'm not really convinced option 1 in this case is the "simpler" of the two because assuming you want the pit to work right, it actually becomes more of a hassle than just using Lua. Option 2 doesn't solve the problem for you, but it's a convenient place to create your solution. My comment about systems staying on or off with the first flick was clearly assuming that the switch sync problem HAS been solved - just pointing out that start up conditions don't matter much as long as the switches work right.

Posted

OK, thanks for the feedback. I like the idea of starting out with what I can manage at this time and then adding to it later. I have no problem re-building the pit if I ever reach a point where I want more functionality from it. My main goal at this point is to control as much as I can with switches/button and not having to use the mouse any more than necessary.

 

While I would love to some day have both a hog and shark pit, I will be starting with the A-10. When (and if) I do a shark pit, I imagine it will be more of mini-pit. Don't have the space for two full-size pits... plus the wife would kick me out of the house!

 

And who knows what aircraft DCS will release next! :D

 

I also imagine (hope) that some of you who are clearly more skilled with all of this will release a "turn key" type of solution. I'd love to learn it myself, but life just has a way of always interupting my hobbies.

 

Thanks!!

Posted

Well I wouldn't say turn key always = $$$... turn key w/o compromise = $$$... turn key w/ comprise = $$ and build everything yourself = $.

 

Everyone takes this hobby to different levels. Some folks buy real panels and gauges then adapt them, demand 100% dimension accuracy and milspec switches. The other end just wants a few radio shack push buttons to have fun, and there are many more in between.

 

Unfortunately the market is pretty small and their are not many (any?) high polish solutions to do the hardware interfaces. There are many options with a lot of elbow grease.

Posted

yah if this hobby was just about buying things ready made I probably wouldn't like it so much. If I want to drop lots of money I'll just go fly a real plane. I like the DIY aspects the best. It is what you make it - it's flight simulation, it's (life size) scale model building, it's collecting (real panels and stuff), it's electronics, computer programming. So many disciplines rolled into one. Some just want to have a pit and don't really want to build a pit though, and I respect that too.

Posted

Don't get me wrong... I like the DIY myself, but I do fly real planes so money can get tight with that and I have a CNC that I'll be making my panels with. I just know if I wait to start on the pit until I know how to use LUA and work with the electronics needed, I problably won't get anything done before the next DCS aircraft is out! :D

 

When I said turnkey, I was thinking more of someone saying "here's the code you can use with this hardware (electronics)" - thus saving me the time/effort of bumbling around writing my own code.

Posted
High end IO board are out there pricey but some of the first cockpit builder use it :music_whistling:

 

EPIC System by R&R Electronics

 

I actually had an EPIC card a few years back, but could never get it working - lack of knowledge/skill I guess.

Posted

There are some coding examples that can get you started here but as far as I know they are all based on LUA and OC cards. I am personally trying to use some working examples provided by other people with BS that I can learn and adapt from for A-10. Problem is, there isnt a whole lot I can do programming wise until A-10C comes out because noone has a clue what the mappings will be for each system. Best I can do is to try to understand how current iterations work with BS so that later it can be implemented with A-10. If you choose option 2, now is actually a really good time to get started with this. If you have some understanding of programming, much of the LUA coding will make at least some sense. I dont know the first thing about lua but going off of C++ experience, I can still mostly understand what its trying to do. Obviously, any programming experience you might have will be greatly helpful here.

Intel i7 990X, 6GB DDR3, Nvidia GTX 470 x2 SLI, Win 7 x64

http://picasaweb.google.com/sweinhart

Posted

That's a good point. Better to experiment before the A-10 is out. I have some HTML, PHP, Javascript experience, but it was very limited and several years back. I don't think the programming concerns me as much as the IO cards. No experience there and I have been having a hard time determining which hardware would be the best choice if I were to go that route. I've heard good and bad things about all of them.

 

I'll have to give it all some more thought and I appreciate all the input you've guys have made. I imagine even if I do bit the bullet and pick up some hardware, I'll be able resell it if I fail to get it working.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...