Talking to your PC via switches

[DTWD]

Hello all,

 

I have been reading bits and bobs in here and dreaming about what I would like but I keep comming across a few things that I don't understand. Terms are bandied about and I am not sure if they are relevent to what I looking for or not.

 

Ok so here goes:

 

If I built a panel with a row of push switches, for example like keyboard buttons, that you push and release and they send a signal. I can see this, I could butcher a keyboard and wire in the buttons to certain key presses, or I could butcher say a game controller and do the same.

 

That's fine, I can get my head around it and visualise it.

 

However my questions arise when you start getting onto toggle switches, or rotary's. Surely wiring these up to something like the above would be constantly sending a signal instead of a one off? Most PCs don't like continues button presses (buffers and all that), so how do people do those?

[y2kiah]

You wouldn't send a constant signal to the PC. Whatever micro controller you use to read switch input would have to be programmed to send messages to the PC only when a switch changes position. On the PC side, these events can be handled in software exactly the way keyboard events are handled in win32.

 

If the I/O board is a USB HID client, it will be recognized by your OS as a generic game controller / keyboard type device, and your switch events will appear just like button presses. The more flexible route (but more work involved) is to use Lua on the back end because you have the opportunity to code whatever extra processing you may need before sending input to the sim.

[brydling]

Or you could make a program that reads the data directly from the game controller, and then react only when something changes. This method involves LUA, but LUA is the only way it can be done without flaws. I am planning to use this approach in the beginning. Right now I am developing a joystick board so that I can easily make analog axes and pushbuttons to work. But I have also tried to read the raw data from the joystick board with a C++-program and that works fine. You don't map these buttons in-game, but instead read them with your own software and send commands to the LUA-interface whenever something changes.

 

The method that y2kiah mentioned first has a problem: You can get the real switches out of sync with the simulator. Especially with toggle switches that send the same command both when toggling on and off (for example gear up/down in most sims).

[DTWD]

EDIT: Re-reading this it sounds like a being a bit of a c**k, I am not trying to be. So read it with a smile on your face because I am not meaning to sound like a gimp.

 

y2kiah,

 

You mentioned a micro controller there. See this is what I am on about. You sort of mention it in passing but thats precisly what I have been missing. So these micro controllers, are they something that everything runs through or are they one per switch.

 

And this USB IO board. Can you give me some examples?

 

I really want to do something like this, but with my lack of knowledge on this subject it's a killer for me. And the biggest problem is that the people doing this talk about it as if everyone should know what they are talking about.

 

What I was thinking of doing was something more along what brydling is referincing. I would rather talk directly to the sim, but I don't really know where to start. Although in y2's defence a pre-system start check (starting cold and dark) would be easy enough and preferable to keep "it real". However with missions starting you in a hot pit it would be a pain to check all states are matched with the game.

 

My experience is more tailored to GUI/Touch screen design, but that would have to run on a seperate PC to keep CPU use down on the original machine.

 

However I just love the tactile feedback of a button and would LOVE something like that. What I am thinking of is something that can be a generic set of panels that would happily work just as well for BS and A10 etc.

Edited July 20, 2010 by DTWD

[brydling]

Let's start from the beginning. Are you familiar with PC-programming? Are you familiar with electronics? A microcontroller is a small CPU with inputs and outputs that can be programmed to do anything you want (with very limited resources). This will involve making your own printed circuit board. Would that be something that you are ready to learn or do you prefer hacking a joystick/keyboard or buying finished I/O-cards?

 

Either way will most likely include programming on the PC. If that is not an option, then you could get yourself a joystick card that is able to send one short buttonpress only when a switch changes position. I plan on adding this functionality to my joystick card. This approach is enough for some people, but like previously mentioned you could get out of sync with the game. If this functionality is included, then I will also have a button that you can press to make all switches send their state as if they were moved. That should solve most of the problems, but there is still one case that could lead to trouble (involving toggle switches sending the same command in both directions).

[memento10]

I was in your shoes about a year ago and it all seemed so foreign but just keep reading and researching.

 

Bottom line is that instead of hacking a keyboard, you can buy some parts that do a much better job at controlling a cockpit.

 

For example, this company makes boards that you just connect to your switches, then plug their board into your computer by USB cable. You then use their software to say the switch connected to input X controls... the gear lever or whatever.

http://www.opencockpits.com/catalog/electronic-cards-iocards-master-digital-inputsoutp-c-21_27.html

 

Perhaps a little over simplified but if you're willing to spend about $200 into the project, you can control about 70 switches and 38 lights. ( 1 UsbExpansion card, 1 master card with input and output boards).

 

Then every additional 70 switches and 38 lights would be around $150 (1 mastercard with input and output boards).

Edited July 20, 2010 by memento10

[brydling]

For example, this company makes boards that you just connect to your switches, then plug their board into your computer by USB cable. You then use their software to say the switch connected to input X controls... the gear lever or whatever.

http://www.opencockpits.com/catalog/electronic-cards-iocards-master-digital-inputsoutp-c-21_27.html

 

Perhaps a little over simplified but if you're willing to spend about $200 into the project, you can control about 70 switches and 38 lights. ( 1 UsbExpansion card, 1 master card with input and output boards).

 

Then every additional 70 switches and 38 lights would be around $150 (1 mastercard with input and output boards).

 

For switches and outputs, Opencockpits boards may be good enough. I wouldn't recommend them for anything else though. I am working with NovelAir on converting two real sawed-off cockpits to simulator use. We have been using Opencockpits solutions for a long time, and we have also wanted to get away from their solutions for a long time. Better things can pretty easily be made if you know programming.

Edited July 20, 2010 by brydling

[y2kiah]

And this USB IO board. Can you give me some examples?

 

One example would be one of Leo Bodnar's joystick boards. Another example can be found here http://www.pjrc.com/teensy/index.html

 

And the biggest problem is that the people doing this talk about it as if everyone should know what they are talking about.

 

Don't worry about that too much, no one is born with the knowledge. Best thing to do is when someone mentions something in passing that interests you, find out more about it on your own. I think most people aren't going to explain things in great detail unless they are specifically asked, but there is plenty of information out there already on these subjects.

 

The method that y2kiah mentioned first has a problem: You can get the real switches out of sync with the simulator. Especially with toggle switches that send the same command both when toggling on and off (for example gear up/down in most sims).

Has nothing to do with the method that I mentioned, it has everything to do with the use of the "toggle" sim command. I didn't suggest he map the switch events to a toggle command. It's a given that if a separate "up" and "down" command exist, that those be used. If only a toggle command exists, Lua can be used to do a set->read loop until the correct setting is reached. The game controller would have to send different events for each toggle switch position, or expose the positions as unique buttons for things to be done right.

[brydling]

Has nothing to do with the method that I mentioned, it has everything to do with the use of the "toggle" sim command. I didn't suggest he map the switch events to a toggle command. It's a given that if a separate "up" and "down" command exist, that those be used. If only a toggle command exists, Lua can be used to do a set->read loop until the correct setting is reached. The game controller would have to send different events for each toggle switch position, or expose the positions as unique buttons for things to be done right.

 

By "the first method that you mentioned", I mean't without using LUA. The second method that you mentioned was using LUA. Without LUA, the synchronization problem can always exist.

[y2kiah]

By "the first method that you mentioned", I mean't without using LUA. The second method that you mentioned was using LUA. Without LUA, the synchronization problem can always exist.

Ah, yes of course. Sorry about that

[DTWD]

Let's start from the beginning. Are you familiar with PC-programming? Are you familiar with electronics? A microcontroller is a small CPU with inputs and outputs that can be programmed to do anything you want (with very limited resources). This will involve making your own printed circuit board. Would that be something that you are ready to learn or do you prefer hacking a joystick/keyboard or buying finished I/O-cards?

 

Either way will most likely include programming on the PC. If that is not an option, then you could get yourself a joystick card that is able to send one short buttonpress only when a switch changes position. I plan on adding this functionality to my joystick card. This approach is enough for some people, but like previously mentioned you could get out of sync with the game. If this functionality is included, then I will also have a button that you can press to make all switches send their state as if they were moved. That should solve most of the problems, but there is still one case that could lead to trouble (involving toggle switches sending the same command in both directions).

 

Yes I am familiar with programming. I did several years at college and uni with C (Turbo C to be precise) and Java. I now do the odd bit of AS3 (Action Script) but I am fairly ok (with a bit of a brush up) with object programming.

 

Electronics I am not much use with. I can re-wire a plug and have done car audio plenty of times, but anything much beyond that I am lost. I did (many moons ago) print a basic circuit board and wire it up, but it was a one off thing and I wouldn't know where to start now.

 

I would prefer hacking something apart, or purchasing a proper IO card. I wouldn't mind learning the whole electronics thing though as it could be a nice life skill to have.

 

I was in your shoes about a year ago and it all seemed so foreign but just keep reading and researching.

 

Bottom line is that instead of hacking a keyboard, you can buy some parts that do a much better job at controlling a cockpit.

 

For example, this company makes boards that you just connect to your switches, then plug their board into your computer by USB cable. You then use their software to say the switch connected to input X controls... the gear lever or whatever.

http://www.opencockpits.com/catalog/electronic-cards-iocards-master-digital-inputsoutp-c-21_27.html

 

Perhaps a little over simplified but if you're willing to spend about $200 into the project, you can control about 70 switches and 38 lights. ( 1 UsbExpansion card, 1 master card with input and output boards).

 

Then every additional 70 switches and 38 lights would be around $150 (1 mastercard with input and output boards).

 

I am willing to spend money, especially as this is fast becoming my main hobby and I will have something I can use and re-use for different things. Plus it looks cool and uber geeky, which fits right in with me :D.

 

Lights are actually something I was wanting to connect up as well. I was wanting to maybe have all the switches have a surround that lit up, but when you "switched it on" or selected a state it changed colour. So at a quick glance you could tell if your fuel pumps were on by the colour of the light, and if one switch was red in a bank of green switches you knew you had missed something. As I said I don't plan on making this match any specific aircraft, just something where I group things together that make sense to me, and make me feel cool as I press loads of buttons :D.

 

Thanks for the help guys.

[memento10]

Hi DTWD,

 

What you describe is easily done with the solution I proposed. It is a fun and challenging hobby. The other guys in this forum know much more than I do so listening to their opinions is very valuable. This forum has been great to learn from, most solutions to problems you will face can be found by searching this forum... Good Luck!

[brydling]

Ah, yes of course. Sorry about that

 

Absolutely no problem :)

 

Yes I am familiar with programming. I did several years at college and uni with C (Turbo C to be precise) and Java. I now do the odd bit of AS3 (Action Script) but I am fairly ok (with a bit of a brush up) with object programming.

 

Electronics I am not much use with. I can re-wire a plug and have done car audio plenty of times, but anything much beyond that I am lost. I did (many moons ago) print a basic circuit board and wire it up, but it was a one off thing and I wouldn't know where to start now.

 

I would prefer hacking something apart, or purchasing a proper IO card. I wouldn't mind learning the whole electronics thing though as it could be a nice life skill to have.

 

 

 

I am willing to spend money, especially as this is fast becoming my main hobby and I will have something I can use and re-use for different things. Plus it looks cool and uber geeky, which fits right in with me :D.

 

Lights are actually something I was wanting to connect up as well. I was wanting to maybe have all the switches have a surround that lit up, but when you "switched it on" or selected a state it changed colour. So at a quick glance you could tell if your fuel pumps were on by the colour of the light, and if one switch was red in a bank of green switches you knew you had missed something. As I said I don't plan on making this match any specific aircraft, just something where I group things together that make sense to me, and make me feel cool as I press loads of buttons :D.

 

Thanks for the help guys.

 

I like teaching people about things that I am interested in. Feel free to add my MSN account (farbror_brydling@hotmail.com) and I'll answer your questions. Since you have a programmers background, you don't have that much to learn if we skip the electronics. I am a programmer and an electronics engineer and love doing this for a hobby.

[Scudslaker]

just get a good HID USB controller board, as stated in other threads i build some modules for different sims and am usning a solution from CodeMercenaries called Keywarrior. havin 16x8 matrix you are able to connect 128 buttons and via a smart programing tool you can easily program the functions you want..

 

 

verry comfortable !)

 

i m sure different brands do have same good possibilities

[digital_steve]

I was like you DTWD, except less motivated and decided i had better uses of my time... so i ended up getting some goflight stuff and using their software to send the keystrokes

http://www.goflightinc.com/BrowseProducts.aspx?DepID=2

 

The T8 module works a treat

[Scudslaker]

lol, you can have 128 switches for that price with 3 functions each!!!

 

no solution for me...

[DTWD]

Thanks for the info chaps, brydling I will add you on MSN.

[KungFuCharlie]

My .02 on the subject...

 

LUA can do a lot. It can also significantly decrease the performance of the sim. Similarly, running a program on the same PC as the sim to read in signals and trigger the proper keystroke (like joystick software) adds additional load to the CPU. It might not be of any significance to many but if you are trying to squeeze every bit of power for your sim, then these are not good ideas.

 

If you can do the processing externally with a microcontroller then that is usually the best solution. The microcontroller then sends a signal via USB to a driver that has a very small memory footprint to convert the signal into a keystroke command. HID drivers already do that for you. So now you have all the intensive state machine code running on separate hardware that does not impact the performance of the sim at all.

 

The learning curve to do something like this can be moderate to extremely high. If you don't have the digital design skills or have no interest in learning them, then you can get a pre-fab board like Phidgets, Arduino, etc and all you have to do is write the embedded code. That is much easier than it sounds if you've already got a grip on programming and even easier if you already know C or ASM. If you don't, then go to Radio Shack or jump on the internet and order a microprocessor starter kit that comes with a board, some sensors, and a book with lots of examples that teaches you how to interface with each of the sensors. You can get a kit like this for under $75 USD.

 

Again, just my 2 cents on the topic coming from my experience in computer engineering.

[brydling]

My .02 on the subject...

 

LUA can do a lot. It can also significantly decrease the performance of the sim. Similarly, running a program on the same PC as the sim to read in signals and trigger the proper keystroke (like joystick software) adds additional load to the CPU. It might not be of any significance to many but if you are trying to squeeze every bit of power for your sim, then these are not good ideas.

 

 

I disagree. With an external C/C++-program, you have to do an awful lot of things to have even a noticeable effect on the sim if you're only dealing with reading inputs. Of course, you can do things in a very stupid way and have a performance hit, but one must assume that the programmer does things right. If a 12 MIPS microcontroller can do it, then the PC can do it without problems. Add to that, alot of people have at least one unused core.

 

I agree about LUA however. Being a scripting language that runs in the same thread as the game engine, it can have a significant impact. It's best to do logic things in a "real" programming language and just let LUA handle reading values from the external program and writing them to the sim.

[y2kiah]

I guess I have a lot to say on this topic, I agree with both of you because both your points are completely valid.

 

I have embedded Lua in my own graphics engine, written in C++. Lua is considered to be one of the faster script environments, hence its widespread use in games. When comparing native vs. script in a vacuum, sure native will run faster. In practice, the lines are blurred a little because:

 

#1, A significant portion of the sim's logic is already written in Lua, so adding a few more lines of your own code probably isn't going to have a drastic overall impact on performance.

 

#2, typically the overall performance of a simulation loop has very little to do with the performance of individual routines, and a LOT to do with the slowest routines (a.k.a. bottleneck). You can make great strides improving the performance of certain function, cut its processing time in half, only to find out that you haven't improved the frame rate at all - your bottleneck is somewhere else. In a game, very often your CPU bottleneck is in the graphics area. It's unclear to many people, that even with modern GPUs doing our vertex and pixel processing, there is significant overhead on the CPU to send data to the GPU each frame. If you take out the part of your loop that renders graphics, you could probably run the AI logic, physics, and all other CPU tasks at hundreds of frames per second. Throw in graphics, sound, etc and you're quickly down to 30 and below :-)

 

#3, for anything that you should need to do for a home cockpit besides displaying more screens with graphics, if you are significantly affecting performance, you are doing something very wrong. If you've done things right, you should only have to poll a buffer (TCP, serial, or whatever) once per frame. If something exists in the buffer, parse it and process it. Let's say your sim is running at 30 fps. If you can flip more than one switch in 1/30th of a second, please please make a video, because you're a superhero. My point is, most frames you will be processing ZERO commands, otherwise ONE or TWO commands at the most. If you absolutely must, you can always give yourself a time budget (say 2 or 3ms), and yield your process once you've exceeded that budget. Next frame, pick up where you left off. This can be effective in preventing frame rate stutter.

 

#4, just get it working, cuz I want to see videos!!

 

edit: I forgot to conclude. I'd say whatever you can get away with writing in script (Lua), do it because the time saved and ease of maintenance far outweighs the performance impact. If you have a certain thing with significant processing overhead, it's time to start thinking about coding that thing in native code, or on its own microprocessor. Just be ready to recompile/reflash every time the smallest detail changes.

Edited July 22, 2010 by y2kiah

[KungFuCharlie]

but one must assume that the programmer does things right.

 

By making that assumption you have already made a huge mistake. If programmers do things right then a lot of QA engineers would be standing in the welfare line instead of making bank each year. There would be no need for beta testers. I could go on but I am sure you get my point. And I know I am taking your comment to the extreme boundary of your point but that was, in effect, to make another point. Now take into account we are all addressing our comments towards a person who is new to all of this and you can pretty much say, for a fact, that the programmer (new programmer that is) isn't going to do it right. Not until at least revision 100 or so. :)

 

All of that being said, I agree that you do have to do a lot to impact the processor. It's also pretty easy for people new to interfacing with devices to create wait conditions or deadlocks that will.

 

You don't have to do a whole lot to impact memory though. Even salty programmers get memory leaks from time to time. Add a GUI to make your key mappings and you're using more memory. Program it in JAVA and you'll be shot, er, I mean, you'll use even more memory.

[KungFuCharlie]

#1, A significant portion of the sim's logic is already written in Lua, so adding a few more lines of your own code probably isn't going to have a drastic overall impact on performance.

 

Agreed. A few more lines. :megalol: Seriously though, so long as you're not running large loops and functions each frame then you should be OK. It's always good to break things down into 1Hz, 5Hz, and 10Hz functions and maybe even have multiple functions of the same timing that run staggered. Thus you end up with an average load instead of spikes at certain cycles.

 

In a game, very often your CPU bottleneck is in the graphics area. It's unclear to many people, that even with modern GPUs doing our vertex and pixel processing, there is significant overhead on the CPU to send data to the GPU each frame.

 

Agree with you 100%. When I upgraded my graphics card a while back my frames didn't improve at all. After I upgraded my CPU they skyrocketed. Fancy video card doesn't always mean great performance. :doh:

 

#3, for anything that you should need to do for a home cockpit besides displaying more screens with graphics, if you are significantly affecting performance, you are doing something very wrong. If you've done things right, you should only have to poll a buffer (TCP, serial, or whatever) once per frame.

 

I started to disagree with you but after re-reading what you wrote I have to agree. You had the proper exclusions (additional screens) in there. :thumbup:

 

Just be ready to recompile/reflash every time the smallest detail changes.

 

I am sure you know about ways to abstract it enough that you can minimize the number of times you have to do that once you've got the project to a stable state. And if you do it right the reflashing part is as simple as turning it on and letting the bootloader handle it.

[y2kiah]

I am sure you know about ways to abstract it enough that you can minimize the number of times you have to do that once you've got the project to a stable state. And if you do it right the reflashing part is as simple as turning it on and letting the bootloader handle it.

 

True, though micros are dedicated devices and likewise usually run dedicated code. My plan for abstraction is to have a generic system run on the micro that can parse commands, debounce inputs, basically handle all of the basic input polling and output stuff. The PC will be responsible for passing messages to enable pins and begin polling, or set up for output, etc. So when building the pit, if I add a new switch all I'm going to have to do is wire up the pin and add one line to my setup script on the PC - nothing to change on the micro side. I think this will strike the best balance for my purposes.

[KungFuCharlie]

I think that is the best way to go myself. The design that I had worked up has a single master card which plugs into the PC and multiple slave cards that talk to the master via a bus (I2C or CAN). Each slave would have a few jumpers to set its ID. When the master sends data up to the PC, the PC software just looks at the configuration script to see what the data means. This kind of layout makes it easy to extend the simpit without having to plug more than one thing into the PC's USB bus.

 

But out of sheer laziness I will probably end up buying a few cards instead of designing my own. Too much work for something this simple. :)

[Gadroc]

My .02 on the subject...

 

LUA can do a lot. It can also significantly decrease the performance of the sim. Similarly, running a program on the same PC as the sim to read in signals and trigger the proper keystroke (like joystick software) adds additional load to the CPU. It might not be of any significance to many but if you are trying to squeeze every bit of power for your sim, then these are not good ideas.

 

If you can do the processing externally with a microcontroller then that is usually the best solution. The microcontroller then sends a signal via USB to a driver that has a very small memory footprint to convert the signal into a keystroke command. HID drivers already do that for you. So now you have all the intensive state machine code running on separate hardware that does not impact the performance of the sim at all.

 

The learning curve to do something like this can be moderate to extremely high. If you don't have the digital design skills or have no interest in learning them, then you can get a pre-fab board like Phidgets, Arduino, etc and all you have to do is write the embedded code. That is much easier than it sounds if you've already got a grip on programming and even easier if you already know C or ASM. If you don't, then go to Radio Shack or jump on the internet and order a microprocessor starter kit that comes with a board, some sensors, and a book with lots of examples that teaches you how to interface with each of the sensors. You can get a kit like this for under $75 USD.

 

Again, just my 2 cents on the topic coming from my experience in computer engineering.

 

From your experience you should know better than to prematurely optimize a system. :) (Just to be clear that is a very tounge in cheek comment).

 

There are many available resources on a modern computer even when running Black Shark full out. It really depends on where the bottle neck is. In particular BS 1.0.2 is a 32bit dual threaded application which can access at most 2GB of ram. Assuming you have a quad core processor and 4GB of ram you have ALOT of ram and cpu to use with out ever impacting the simulation.

 

Even extra displays can be done with out significant bottle necks on most systems, assuming you have a secondary video card. At that point the bottleneck would be possible saturation of the PCI-e bus, which is probably not a major concern. Even using the same video card with Direct2D or WPF on Vista or above can be fairly efficient in not forcing swap of video memory all the time.

 

The biggest impact on the DCS engine is where you execute your loop in LUA and their engine design which forces secondary displays (ABRIS, Shkval, etc) as part of the same large video space. Polling at the beginning and end of each frame is the most costly while moving them to a lower cycle rate using a co-routine can help on lower end system. This is really a trade of of the latency of your inputs and indicators vs performance and has nothing to do with the processing of the data for your display.

 

You're warnings areas are good, if not a little dire in wording. Saying the best solution is to create new hardware using custom micro-controller is way overkill for many scenarios. There is plenty of room for even running some heavier weight systems like managed C#/WPF or Java on many systems.