My A-10C preparation

[Duckling]

So you're saying that the only thing against pots is the limited number of inputs?

 

No. not only. My self I placed quick & Dirty pots in my Homemade Intercom qaud but this more to have something to stick the knobs on :-). Remember that was pre 10C introduction. Had the idea at the time to use add volume adjustment for my PC sound system to the "master" volume position but still pending.

 

The pros for gray encoders is that low cost and rather easy to control a value in SIOC, were you have to put some energy into make the same for the pots. Encoders with a built in switch can be used instead of the pull-to-activate.

 

Depending on feutures implemented in the 10C when it goes Gold I might have to reconsider again

[rocketeer]

I mentioned earlier that OC sells the encoder 288VCC0F161B2. this is a 2 bit binary type with a switch.

I bought one from Leo 288T232R161A2, a 4 bit gray type without switch. Can someone confirm if this one is safe to use for DCS/SOIC?

I'm not sure the diff between 2 bit and 4 bit, and binary vs. gray type.

[PanelBuilder]

I mentioned earlier that OC sells the encoder 288VCC0F161B2. this is a 2 bit binary type with a switch.

I bought one from Leo 288T232R161A2, a 4 bit gray type without switch. Can someone confirm if this one is safe to use for DCS/SOIC?

I'm not sure the diff between 2 bit and 4 bit, and binary vs. gray type.

The difference between 2-bit and 4-bit is that the 2-bit (incremental) gives you a direction of rotation and the 4-bit gives you a value (0-15). The gray type is a special type of 4-bit where only 1 bit position can change a time.

eg: binary 7 = 0111 8 = 1000

eg: gray 7 = 0100 8 = 1100

 

Cheers,

Colin

[Feed]

No, Duckling is seeing where I'm coming from - I fully understand that the real controls are probably in fact pots - but implementation in a sim-pit is going to be much easier with a rotary encoder (even though you won't have the physical stops).

 

Pots are hooked up like joystick axes, and return a value relative to their position - you need an A/D port for each one (on Leo's cards, each pot will take an axis, there are 4 axis available on the OC USB expansion, etc.) ... rotary encoders return a value based on which direction they're turned, and at least on the OC cards, require just 2 inputs (the same sort of inputs used for buttons). Not sure how other interface options would deal with encoders.

 

Personally, my plan would be to use rotary encoders with built-in pushbuttons. The pushbutton could be set up to toggle the on/off value for the control (or perform whatever function the simulator has), and the rotary can handle whatever function rotation does (if it's implemented in the future, or used with a different sim, etc.).

 

I think one of the big challenges to these sim-pits is not only making them feel right, but getting the simulator to interpret what's supposed to happen correct, as well.

[Feed]

Also, having seen another real panel online, I think you guys may be right about the push/pull thing ... even though the panel I've got is push on/push off. Another panel I saw had the little raised ring around the edge, which would seem to indicate a need to grasp and pull the switch. Can anyone confirm the function of the actual switches?

[Avilator]

This is the description of one knob, from the manual. All of the descriptions are similar.It does not say which position is which, but if I had to guess, I would say that pulling the knob out enables audio.

 

Also, having seen another real panel online, I think you guys may be right about the push/pull thing ... even though the panel I've got is push on/push off. Another panel I saw had the little raised ring around the edge, which would seem to indicate a need to grasp and pull the switch. Can anyone confirm the function of the actual switches?

 

I can: See my previous post.:thumbup:

[Deadman]

It all ready was confirmed by some one with a real panel pull on push off rotates for volume control acts like an equlizer with a master volume

http://forums.eagle.ru/showpost.php?p=1024177&postcount=335

 

Also, having seen another real panel online, I think you guys may be right about the push/pull thing ... even though the panel I've got is push on/push off. Another panel I saw had the little raised ring around the edge, which would seem to indicate a need to grasp and pull the switch. Can anyone confirm the function of the actual switches?

[rocketeer]

The difference between 2-bit and 4-bit is that the 2-bit (incremental) gives you a direction of rotation and the 4-bit gives you a value (0-15). The gray type is a special type of 4-bit where only 1 bit position can change a time.

eg: binary 7 = 0111 8 = 1000

eg: gray 7 = 0100 8 = 1100

 

Cheers,

Colin

 

Thanks for your explanation about 2 bit and 4 bit. So does it matter which of the two CTS288 to use with OC cards? Is it just a matter of slight change in coding or if one will work better?

[sweinhart3]

I think 2bit would be better.

A. Less wiring.

B. Less inputs required.

C. DCS likely will use commands similar to 'Left-mouse click'/'Right-mouse click' to change position.

[rocketeer]

thanks sweinhart. by less inputs you mean only 2 inputs instead of 3 if we use 2 bit?

[rocketeer]

some progress on the right console.

 

 

Still some work to do for the top half of the console, but I'm glad several panels are done.

 

Looking forward to start the front console. :)

[Feed]

MAN that looks great ...

[rocketeer]

 

Cheapo pit in progress...

[Deadman]

Look very good:thumbup: what color paint are you using on your knobs?

[rocketeer]

Thanks. flat gray enamel from OSH, but they have stopped producing that! Now I have problem finding other gray that'd match, else my front console and other knobs may look too light or dark.:mad:

[Deadman]

Rust-Oleum Painters Touch Ultra Cover 2X Satin Granite matches FS36231 witch is the ejection seat color. I have some knobs that match that color as well. It would all so be the color of all of the cockpit as far as i can tell so far.

 

The yellow for the ejection handle is John Deer yellow and John Deer green works for the bail out bottle.

The only thing special i picked up was on sale was the yellow green aluminum primer it was on sale for $3.00 a can i picked up two cases

http://www.skygeek.com/a901.html#top

[Feed]

Man, Rocketeer - I tell you that your 'pit is an inspiration to me to keep going - I just need more time! Really nice progress, there ...

[rocketeer]

Thanks Feed. For the panel drawings I took from Duckling's excellent website (thanks Gus!), and added the EW and CDU, and the leftmost panel (safe, arm, oride) myself. If you have problem sourcing knobs I'd try to help.

 

Thanks DM for the info about the paint.

[MudRat02]

I've been watching this for a while, very nice progress!

 

I'm thinking about doing one, how are you going to interface the switches/rotaries to your computer though? I was thinking of using one of Leo Bodnar's chips but I thought there might be a better way of interfacing switches rather than treat it like a joystick.

[rocketeer]

thanks mudrat. there is no guarantee that all switch functions will be assigned key commands by ED. Thus if you are building a full pit, and if there are no key commands assigned to some of the panels, then using Leo boards you'd be stuck. But if you use open cockpit and its SOIC software it's proven that it works for every kind of switch, buttons, rotary switch, encoders etc. all even output lights. SOIC will work with lua even if no key commands are assigned. so that'd be the safe route to go.

 

Besides, leo boards are quite expensive compared to OC cards. If you use leo boards you may need 10-15 such boards! And then it still doesn't handle outputs like LED, LCD, 7 segments.

[Gadroc]

thanks mudrat. there is no guarantee that all switch functions will be assigned key commands by ED. Thus if you are building a full pit, and if there are no key commands assigned to some of the panels, then using Leo boards you'd be stuck.

 

That's not true at all. You can use other software to interface between the LUA export functions and DirectX controllers just like you use the SIOC software to interface between OpenCockpit controllers and the LUA export functions.

 

People shouldn't be afraid to start with a joystick emulation board as it is much easier to start with than the OpenCockpit solutions, as you can start mapping directly inside DCS and later add software to do more advanced things.

 

That being said the rest of your argument is valid around cost per switch, and ultimately it will take the same skill sets to work either to their full potential.

[MudRat02]

OpenCockpit / SIOC actually looks like a good choice given that the capability, although complex, is there from the start as opposed to Leo Bodnar's chip and additional software.

[rocketeer]

what I am saying is that it's easier to make LUA and SOIC talk than leo boards and LUA (at least for me) as we have ample examples from the OC users here. Even then there's much figuring out work for the various types of switches. And I have no clue how to use LUA if not for SOIC.

 

By the way Gadroc can you can some insight as to how Helios will work with real switches, eg people like us intending to use OC cards? I posted this question at SCSimulations forum and no one bothered to answer it for a week now. If Helios configuration is mostly graphical, then the less programming inclined will find it useful to use Helios as a interface layer between SOIC and LUA, to avoid figuring SOIC coding and LUA to get our switches to work in DCS.

[Gadroc]

what I am saying is that it's easier to make LUA and SOIC talk than leo boards and LUA (at least for me) as we have ample examples from the OC users here. Even then there's much figuring out work for the various types of switches. And I have no clue how to use LUA if not for SOIC.

 

By the way Gadroc can you can some insight as to how Helios will work with real switches, eg people like us intending to use OC cards? I posted this question at SCSimulations forum and no one bothered to answer it for a week now. If Helios configuration is mostly graphical, then the less programming inclined will find it useful to use Helios as a interface layer between SOIC and LUA, to avoid figuring SOIC coding and LUA to get our switches to work in DCS.

 

Sorry about the delay. I've been sick a couple weeks and other things have kept me off the boards as much as I would like. Basically Helios is drag and drop for this... aka Drag "Push ABRIS Button 1" DCS action list onto "Button 1 Pushed" trigger from the direct x controller. It should be MUCH simpler than all the scripting everyone has to do today. I have attached two screenshots showing bindings for Touch Screen controls to Falcon and one for a joystick to DCS.

 

The desire is to replicate this ease of functionality with other physical input types like PHCC and OpenCockpits. Once I have the Beta underway (targeting end of the month to start), I will be ordering some OpenCockpit cards to start experimenting with. I can't say for certain how exactly we'll implement that integration yet, but I hope to keep the simplicity you see with the bindings of the touch screen controls and direct x controllers.

[rocketeer]

Thanks Gadroc. This is very impressive and exciting! Just drag and drop an action to a switch. Wow! I have read and understood the steps to make an easy toggle switch work with SOIC and LUA as per Oakes' example. And was prepared to learn the more advanced steps for rotary switches, pots and encoders, and then even more advanced steps for output LEDs, LCD and seven segments. But your Helios example makes it like a normal joystick configuration, really simple. If so, it'd save me a ton of time figuring out the coding for hundreds of switches!