dealing switch synchronization

[scuba_steve]

I've seen some pretty cool simpits here in this forum, and what simpit would be complete without a bank or two of awesome looking switches!

I've been doing some research online on how to electrically implement switches into a simpit (pulse generation to keyboard encoders, buying game pad controllers that handle switches for you. etc.) but I'm curious how people deal with switch synchronization. How do you ensure the physical switch position in your simpit matches the virtual state of your spacecraft when you start the game?

Also what about loosing synchronization at some point during game play?

I'd be interesting to see what procedures, and hardware/software people are using to deal with this problem?

Cheers...

 

[soundmackdaddy]

hey,

While I personally don't have a simpit as yet I have been doing a bit of thinking about it, so I will share my own view.

From what I can see, creating a system that would allow the computer to automatically detect the position of a switch when orbiter is started up would be kinda difficult, but then again I don't have much programming experience whatsoever.... so it might be possible.

However what I had been thinking of would be to just spend a few minutes creating a checklist that you print off and that perfectly matches a particular scenario you wish to use. So before you startup orbiter you then just go through the checklist in the simpit, setting each switch to the correct initial state that matches the initial state of all the switches in orbiter.

Thats my thoughts so far, its pretty simple and is also kinda cool I guess because it forces you to go through precedures that could be quite realistic. But then again, a form of software based switch-state detection would also be handy...

Many Thanks,

Kristian

 

[insane_alien]

maybe a little dialogue that pops up in an MFD that tells you exactly which switches aren't in the right place for the scenario? obviously this would be an MFD that is only useful at the start of the scenario.

 

[starbird]

It depends on the switches you use. The little box I made uses SPDT switches, which essentially act as 2 individual buttons. In most sims you can assign one button to an on position, and another to the off. This way the switches never go out of sync or anything. The downside is that you only get, say 16 switches per device instead of 32.

I tried out a single triple throw switch. Its interesting, as its wired as 2 buttons. Depending on where the switch is one or the other button will be pressed, or both. I wrote a little plugin for xplane to handle the logic, and it works great.

 

[yagni01]

There are some pros/cons to different switch approaches on the Orbiterwiki http://www.orbiterwiki.org/wiki/Orbiter_cockpits

If you're concerned about synchronization the solution is as starbird suggested - momentary switches like push buttons or rockers/toggles, paired with talkbacks (the tricky part). I found the issue with center off rocker/toggles is that I expect tactile feedback of the switch state (on or off) from those types of switches, so I prefer custom built pushbuttons in those situations.

 

[soundmackdaddy]

I hadn't realised that... clever!

so if you were using toggle switches, would that mean that the switch is constantly sending the state signal (or in this case 1 of the 2 pushbuttons for the switch) to the computer? Is that how it works? Or that the computer registers all the pushbuttons initially pressed when starting up orbiter?

Many thanks,

Kristian

 

[yagni01]

I hadn't realised that... clever!

so if you were using toggle switches, would that mean that the switch is constantly sending the state signal (or in this case 1 of the 2 pushbuttons for the switch) to the computer? Is that how it works? Or that the computer registers all the pushbuttons initially pressed when starting up orbiter?

Many thanks,

Kristian

I don't normally conntect toggle switches to keyboard inputs, but I'm sure its possible to send a keystroke based on the state change (i.e. hi to lo) rather than the actual input value. It would take some additional hardware to create a pulse for each transition, but its doable.

My normal switch handling software will send all current switch states to Orbiter on startup, but after that I'm on my own.

 

[scuba_steve]

My normal switch handling software will send all current switch states to Orbiter on startup, but after that I'm on my own.

what software/hardware do you normally use?

Also, one idea i had is to implement some sort of 'disconnect switch' to the panel. When you activated it, all other switches on the panel would somehow disconnect from orbiter so you could get a switch into a desired position. Then you could 're-connect' the panel and everything would be synced up.

I havn't tried it yet, but i figure it would be a little extra work on the electrical side. I'm thinking some simple gate logic chips would suffice?

 

[yagni01]

what software/hardware do you normally use?

Key encoder is a KeyWiz-Max from GroovyGameGear. Switch interfacing is through Phidgets, for which I've written some custom software to send Orb:Connect messages to Orbiter. I have an LED-Wiz and a Phidget for LED interfacing, running through the same software as the switches.

I get a couple hard-to-find items, namely Boeing/Airbus replica knobs and 45 degree index rotary switches from FlightDeckSolutions.

---------- Post added at 02:34 PM ---------- Previous post was at 02:21 PM ----------

Also, one idea i had is to implement some sort of 'disconnect switch' to the panel. When you activated it, all other switches on the panel would somehow disconnect from orbiter so you could get a switch into a desired position. Then you could 're-connect' the panel and everything would be synced up.

I use a similar system in which one of the inputs is set up as a software "send all" if I want to update/sync Orbiter with the flight deck configuration. Normally I a) configure prior to entering a scenario, b) start up Orbiter paused, or c) pause it early to set the switch configs. One thing you'll find ( flying XR vessels) is that it will be easy to 'unsync' when you do something that requires the APU and its not on. But easy to fix. Checklists are good.