brydling

We at NovelAir have ordered several boards from Leo, I'm sure you will get them.

This is a must-have for a realistic cockpit. The CDU is the first thing that I have started building. If it's not going to be possible to include the screen in it, I will probably not make an A-10C pit.

The X is a lot easier to connect buttons to. You don't have to make a matrix with diodes to connect them. With BU0836(A) and with the joystick card that I have designed you have to make this matrix with diodes, but the design is a lot cheaper if you want to have many buttons. I have 240 buttons on my joystick card, and the cost to build the whole thing is probably around $20. Using the same method as in BU0836X, my card would have needed a lot more IC's and would not be nearly as cheap. You could of course include the matrix on the PCB and get a card that is both easy to use and cheap to build, but I don't see a problem wiring a diode in series with every switch. I also don't need a GND for every switch since I find it nicer to have only one GND line to every box, than to use two cables for every switch.

Oh, I am ashamed :smilewink: Sorry for the question! And about the pico projector thing.. We have that in our simulators for the radar screens. Works like a charm. I don't know which brand and model we have though.

Then all you need is a joystick controller and FSUIPC :) You could even slaughter an old joystick if you don't need like 20 switches or more. I have made my own joystick card with support for 240 buttons.

I guess this has been asked before, but I couldn't find any thread discussing it. Will we be able to remove the virtual cockpit to use A-10C as the base for a simpit? The ultimate thing would be if there is a HUD-only view.

For pushbuttons you would be great with a joystick-controller. You could also read data from the joystick from a custom program and implement more advanced things like on-off-switches. If you are going to use FSX, I think FSUIPC can do that for you. Then you would be fine with a simple joystick-controller that has support for lots of buttons.

If you have some electronics and programming knowledge, you should try doing the interfacing yourself. It's alot of fun. I cannot recommend Opencockpits' interfacing electronics. Easy to get started with and therefore the only option for some people, but full of bugs and small annoying things.

I think it's awesome with a community where we have so many experts that knows everything about the software without ever having seen a single line of source code! If all software projects had people like you guys, then all software problems in the world would be gone. How cool is that!? :megalol: Seriously now, don't ever say what can and what can't be easily done again. You are insulting the team and embarrasing yourselves.

Hehe, I saw the picture in front of me of how the "rotation" would look and thought "He can't be satisfied with that?" ;) Good thing you found the problem BEFORE manufacturing :)

Very nice work! How will you make the small ones rotate continously?

Add me on msn and we'll talk about it. farbror_brydling@hotmail.com _Edit_: Maybe someone else wants to know some of these things too. The buttons are connected in a 15x16-matrix and the connectors are eight 40-pin IDC flatcable-males (like the ones on a computer motherboard for an old IDE-disk). Connections are easier than BU0836/A, since there is one row-pin for each column. There are also five column-pins for each column, so you never have to share a single pin between alot of buttons. I was thinking of including eight females with a short stump (1 dm?) of flat cable attached. The connectors for the analog axes are 3-pin headers like the ones on Leo's cards. To be able to use all 240 buttons, the software must be able to handle 116 buttons from a single joystick. BS can handle 128 so there is no problem there. The price is hard to estimate. It depends on how many cards that are going to be manufactured, since the PCB-manufacturing gets cheaper if you order more units. I would not order less than 10 PCB's, but I could use a few cards myself so I don't need 10 buyers to be able to pull it through. Since there are so many pins to solder it will take a while to do, and that is not something that I want to do just for the fun of it so I must use a price that will pay for all the components and the time spent. If I make 10 cards that would probably be about 800 SEK per card and 100 SEK shipping (~125 USD in total). One more thing to mention. The card uses separate power. 12 V from the computer power supply will work fine. Any other DC-source between 8-13 V will also work fine. I wouldn't want to remap regular keyboard commands. I want a joystick. I will also make a program for my joystick card that implements an IOCP-server so that the buttons can be read as with SIOC, if you want to do more advanced stuff than pushbuttons.

Yes they are good joystick cards and really cheap if you want to try and connect a few buttons. The thing that was disturbing me however was the small amount of buttons. You would need three BU0836's just to make the A-10C CDU, so the money quickly adds up. I made my 240 button board for less money than one BU0836, and it has 12-bit resolution so it should in fact be compared to BU0836A. If anyone is interested, I may sell a few of them.

Each board will show up as a joystick in the game. I have just finished the making of a joystick card that has 240 buttons and 13 analog axes. You would need seven BU0836 to get that amount of buttons. I developed this card because I want to make my own cockpit, and I like to do things myself. It works perfectly with BS.

OC are not exactly known to be good at anything.

But you said that writing LUA-code or an external program is a bad idea. When judging if a method is good or bad, you must assume that it is done right.

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.

Great find! I will save this thread.

If SIOC communicates with a LUA-script over IOCP, it doesn't generate a message about a virtual keystroke. How do you set up SIOC to talk to BS? Does IOCP sound familiar? I know that with MS Flight Simulator you can have a module in SIOC which talks to FSUIPC. In that case it isn't IOCP. However I don't know if such modules are user-creatable, so that one exists for BS. If they aren't, then BS probably takes the IOCP-way. IOCP is a very simple protocol that sends the values of the SIOC-variables whenever they change. Not even the name of the variable, only the number.

SIOC cannot generate keystrokes on another PC than the one it is running on. I am not familiar with the way SIOC interfaces with BS, but I guess it's a LUA-script that is talking to SIOC with the protocol IOCP? LUA is a powerful language. It may be possible to generate a keystroke in a LUA-script.

Absolutely no problem :) 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.

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.

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.

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).

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).