Cockpit I/O survey - what do we need?

[Alex_rcpilot]

Alex rcpilot

if need. In picture button 111 is for Teamspeak, that open mic while press.

 

Picture showed up as a little cross, what an embarrassment, I don't know if our gov had banned imageshack, or imageshack closed down its services to China mainland.:cry:

 

Anyway, as far as I know, there're two ways to emulate a keyboard:

 

First approach is pure hardware. You program the keymap into the microchip, and then it sends out keystroke same way a USB keyboard does. If the map is loaded into non-volatile memory, It doesn't require the PC to configure the microchip every time it runs the game, if it's loaded into the RAM, then something must done to initialize the board every time it's powered on.

 

The other type of emulation is done by software. The microchip transmits button press signal the way a generic USB joystick does. Then a software runing on the PC intercepts this signal, and generates a soft keystroke, which is then recognized by the game. A program has to be running while the game is on.

 

I wonder which case the BU board is.

[Sokol1_br]

Alex you know any free image host to show in China?

 

Imageshack is blocked: http://en.wikipedia.org/wiki/List_of_websites_blocked_in_the_People%27s_Republic_of_China

 

The first approach describe is like HOTAS Cougar, that store keystroke in internal memory.

 

SVMapper + BU0836 (in my example I use Mjoy16) is the second type, a software intercept buttons press and translate into keypress.

 

Sokol1

Edited August 13, 2009 by Sokol1_br

[Alex_rcpilot]

Alex you know any free image host to show in China?

 

Imageshack is blocked: http://en.wikipedia.org/wiki/List_of_websites_blocked_in_the_People%27s_Republic_of_China

 

The first approach describe is like HOTAS Cougar, that store keystroke in internal memory.

 

SVMapper + BU0836 (in my example I use Mjoy16) is the second type, a software intercept buttons press and translate into keypress.

 

Sokol1

 

Oh man...even the list itself is blocked. I hate the commies for doing this, We ain't planning to do anything against them whatsoever...:cry:

 

Anyway, photobucket works fine for me, at least up till now.

http://s923.photobucket.com

 

Thanks to your explaination, now I'm getting the picture of how these things are put together.

 

I'm looking for an optimum solution to build a DCS cockpit with least workarounds. To cut as many corners as possible, especially with cockpit information output mechanism. All the LEDs, instruments, etc. It seems to be greatly dependent on the future release of ED's third party cockpit I/O addon.

[Alex_rcpilot]

And PanelBuilder, since we can export cockpit status from the computer, is it possible to read all the switch inputs and use that to initialize all the toggle switches and dials at mission startup? Thanks!

[PanelBuilder]

And PanelBuilder, since we can export cockpit status from the computer, is it possible to read all the switch inputs and use that to initialize all the toggle switches and dials at mission startup? Thanks!

 

Yes for sure, I posted about the startup auto sync a little while ago.

 

 
if position ~= currentW4 then
LoSetCommand(850) -- jettison arm
currentW4 = position
end

 

The only command codes I haven't been able to find are for the controls that don't do anything, like the rotary switch on the lower right of the Targeting Display Control panel. But I use that one for tv scan rate.

[PanelBuilder]

Thanks dude, I see from the sample code that a TCP port is initialized, but how do you move data between TCP and serial ports?

I wrote a little windows console app that does this. I'm playing with two versions: one is synced and ensures that the lua receive function always has something, if only a line feed, to read every frame. The other is not synced and relies on the lua receive function timing out after some ms.

 

The problem is that lua socket does not apear to have any kind of data.available type function that you can test. And if you do a receive and there's nothing there, the sim will just hang (unless you set the timeout).

 

I'd be happy to share the executable but you need something attached to the serial port that you can read from or write to or both. You can test that with PuTTY.

 

One switch and one LED will do it. And trust me, once you get that first switch and first LED working, it's a sleigh ride home from there.

 

Cheers,

Colin

[sweinhart3]

Im using the Microchip PIC32MX USB controller but I have to design all my own hardware and software to make it work. Im probably about 50% done on the software side.

[Alex_rcpilot]

Yes for sure, I posted about the startup auto sync a little while ago.

 

The only command codes I haven't been able to find are for the controls that don't do anything, like the rotary switch on the lower right of the Targeting Display Control panel. But I use that one for tv scan rate.

 

I'm happy to learn about all these capabilities, even in its current status. It's also good news for Trigger, he was complaining about the initialization process.

 

The problem is that lua socket does not apear to have any kind of data.available type function that you can test. And if you do a receive and there's nothing there, the sim will just hang (unless you set the timeout).

 

I'd be happy to share the executable but you need something attached to the serial port that you can read from or write to or both. You can test that with PuTTY.

 

If we implement at timeout failsafe, how short can it be? Depending on the fact that output information is usually not very significant and doesn't need to be real-time, I think a lag of even up to 50ms won't be a big problem.

 

Don't worry about serial ports, I've got 4 of them on my PCI-E extension card. I can cross link any two of them and use a dual-port serial monitor software to transfer duplex data between the ports.

 

However, my interest actually lies in direct USB support. If there's any way to directly transfer the cockpit data as a USB HID payload, it'd be sweet. I'm still learning about WDF programing, hopefully will be able to customize my own USB driver later.

[Alex_rcpilot]

Im using the Microchip PIC32MX USB controller but I have to design all my own hardware and software to make it work. Im probably about 50% done on the software side.

 

Oh those are powerful chips. 80MHz is real fast. Full speed USB OTG interface, plus a whole bunch of different bus interfaces, DMA support, etc, neat products.

 

You guys are real fans for PIC series. Microchip has certainly won a great rep in the west. While here in China, most students start with ATMEL 8051 series, but when we get good enough, most of us do implement PIC for some projects.

 

Talking about USB, I started with Cypress CY7C68013A, which is real easy to debug. Then I moved to STM32, the powerful ARM Cortex-M3 device. Latter I started playing around with PIC18F4550, and now the bottleneck is no longer inside the chip, but on the other end of the USB cable.:doh:

[Alex_rcpilot]

SVMapper + BU0836 (in my example I use Mjoy16) is the second type, a software intercept buttons press and translate into keypress.

 

Hi Sokol, now I see the snapshot of the mapper, that's a third-party freeware right? Universal, but not enhanced for specific products. So far, it's definitely a good solution. We'll try making something better later:).

[Sokol1_br]

Alex,

 

A freeware program like SVMapper with ability to divide axis in bands, use axis as buttons... would be great.

 

Sokol1

[Alex_rcpilot]

Alex,

 

A freeware program like SVMapper with ability to divide axis in bands, use axis as buttons... would be great.

 

Sokol1

 

Yea, it's hard to imagine how to top what we've already had right now. But since we have plenty of time at hand to have fun, why not give it a shot and see what we come up with. lol.:thumbup:

[sweinhart3]

Ive been reading different forums trying to decide the best way to interface. What Im currently doing is using 1 PIC controller and trying to multiplex all the inputs/outputs onto 1 chip using address and bus line. But you guys are using several controllers? how do you interface the controllers together or are u programming then to act like (4 different keyboards)? My design is requiring a lot of wiring and extra circuitry to address each switch into a series of 16bits. From what I can i tell your guys way is simply directly plugging a switch and diode to an input until you run out and then use a different controller for the rest? For 532 inputs that would require 16 pics (assuming 32 inputs). That wouldnt even touch the outputs.

[Alex_rcpilot]

From what I can i tell your guys way is simply directly plugging a switch and diode to an input until you run out and then use a different controller for the rest? For 532 inputs that would require 16 pics (assuming 32 inputs). That wouldnt even touch the outputs.

 

Yea, they have several options to go with, but not all the options are integrated enough. Most guys here are not into EE.

[PanelBuilder]

Ive been reading different forums trying to decide the best way to interface. What Im currently doing is using 1 PIC controller and trying to multiplex all the inputs/outputs onto 1 chip using address and bus line. But you guys are using several controllers? how do you interface the controllers together or are u programming then to act like (4 different keyboards)? My design is requiring a lot of wiring and extra circuitry to address each switch into a series of 16bits. From what I can i tell your guys way is simply directly plugging a switch and diode to an input until you run out and then use a different controller for the rest? For 532 inputs that would require 16 pics (assuming 32 inputs). That wouldnt even touch the outputs.

 

Hi nice to see you here,

 

In my case I use 1 PIC per control panel and they all talk and listen on the same UART serial line. I'm using PIC16F688 (14 pin) PIC16F690 (20 pin) and PIC16F886 (28 pin).

 

Cheers,

Colin

[PanelBuilder]

However, my interest actually lies in direct USB support. If there's any way to directly transfer the cockpit data as a USB HID payload, it'd be sweet. I'm still learning about WDF programing, hopefully will be able to customize my own USB driver later.

Funny you should say that. For the interface I'm actually using Microchip's Low Pin Count USB Development board.

 

I originally got because I thought I'd configure it as a USB keyboard to send keystrokes in, and maybe as a printer or something to send data out.

 

Turns out we don't need to sent keystrokes, so I have it configured as a USB to serial inteface to handle the traffic both ways.

 

Cheers,

Colin

[Alex_rcpilot]

Funny you should say that. For the interface I'm actually using Microchip's Low Pin Count USB Development board.

 

I originally got because I thought I'd configure it as a USB keyboard to send keystrokes in, and maybe as a printer or something to send data out.

 

Turns out we don't need to sent keystrokes, so I have it configured as a USB to serial inteface to handle the traffic both ways.

 

Cheers,

Colin

 

Sorry for the confusion dude. I think you found it funny because I didn't explain my system topology.

 

Yea, for the time being, the USB-serial system is the best solution I've ever seen. But since I have the experience with USB firmware development, I've actually pictured an I/O card with both input and output functions integrated on one end of the same USB cable. input works as ordinary I/O cards with a bunch of customization capabilities, and output fully complies with DCS interface standards or whatever that requires minimum operation from the users.:D

[sweinhart3]

Sorry for the confusion dude. I think you found it funny because I didn't explain my system topology.

 

Yea, for the time being, the USB-serial system is the best solution I've ever seen. But since I have the experience with USB firmware development, I've actually pictured an I/O card with both input and output functions integrated on one end of the same USB cable. input works as ordinary I/O cards with a bunch of customization capabilities, and output fully complies with DCS interface standards or whatever that requires minimum operation from the users.:D

 

Hi. This is actually what Ive been attempting but with limited success. Right now Im writing the PC side of the software in C++. I have successfully got 2-way communications to work but not completely in the way I want. My pc sees my device as a single generic HID device which is fine except that buttons dont register in the game controllers. It seems that game controllers have to be 1-way device or windows wont comunicate with it as a game device. I thought if I could recompile the controller as a HID composite device (game controller and output device) this could be a work around but I havent been successful creating a composite device.

 

Im thinking that maybe I could create something like most of you using 8bit PICs for each panel and then interfacing them all together into my PIC32 which could be a cross between what u guys do and what I was thinking of. If I can think up the design of course it would significantly cut down on the wiring and logic but still all interface to the PC as 1 device. Good thinking guys.

[PanelBuilder]

Sorry for the confusion dude. I think you found it funny because I didn't explain my system topology.

I didn't find if funny; I found it very interesting. "Funny you should say that" is just an expression :-)

 

Cheers mate,

Colin

[Alex_rcpilot]

It seems that game controllers have to be 1-way device or windows wont comunicate with it as a game device. I thought if I could recompile the controller as a HID composite device (game controller and output device) this could be a work around but I havent been successful creating a composite device.

 

Congratulations, you're ahead of the game!:thumbup:

 

Yes that can be a little set back in the process. Do you still have the DirectInput joystick property sheet for your HID when you implement duplex transmission with it?

 

I think you're gonna need a composite device sooner or later, a DirectInput and a keyboard emulator would make a perfect combination. Try to export cockpit information through the keyboard element.

 

Here's a question from me, what happens to the 8th byte of HID_Descriptor(SIZE_OF_REPORT_DESC) when the byte count of Report_Descriptor exceeds 0xFF?:music_whistling:

 

Please keep us updated, I'm new to Visual C++ and WDF programming, hopefully will catch up in a while?:doh:

[Alex_rcpilot]

I didn't find if funny; I found it very interesting. "Funny you should say that" is just an expression :-)

 

Cheers mate,

Colin

 

oops, looked it up and found what it really means. I think I need to spend more time talking here, rather than chit-chatting in domestic forums.:doh:

 

I'll see how things turn out in a fortnight, I'm expecting the second phase of interview at Microchip. First round worked out pretty well last thursday. If I make my way in, I'll get to travel around U.S a lot.:D

Edited August 16, 2009 by Alex_rcpilot

[sweinhart3]

Congratulations, you're ahead of the game!:thumbup:

 

Yes that can be a little set back in the process. Do you still have the DirectInput joystick property sheet for your HID when you implement duplex transmission with it?

 

I think you're gonna need a composite device sooner or later, a DirectInput and a keyboard emulator would make a perfect combination. Try to export cockpit information through the keyboard element.

 

Here's a question from me, what happens to the 8th byte of HID_Descriptor(SIZE_OF_REPORT_DESC) when the byte count of Report_Descriptor exceeds 0xFF?:music_whistling:

 

Please keep us updated, I'm new to Visual C++ and WDF programming, hopefully will catch up in a while?:doh:

 

My PC side software will be taking the PIC input and outputting a keyboard combination. Im not sure how to program around the LUA files yet. I still gotta do research on that. The direct input is what i cant get to work. It will enumerate as a game device but since the programming is 2-way coms windows doesnt recognize buttons being pushed. Ive never dealt with the HID descriptor being longer than 128bytes. Since data (at least mine) is transmitted in sets of 3bytes, (descriptor, data, data) the rest would be waisted bandwidth as the rest of the 125bytes would be 0xFF, the only advantage Im aware of using more than that is for cable transmission since apparently a logic high is less suseptible to noise than logic low.

[Alex_rcpilot]

My PC side software will be taking the PIC input and outputting a keyboard combination. Im not sure how to program around the LUA files yet. I still gotta do research on that. The direct input is what i cant get to work. It will enumerate as a game device but since the programming is 2-way coms windows doesnt recognize buttons being pushed.

 

I see we're using different approaches. I'm splitting my composite device into 2 modules. A - From the device manager list, a pure DirectInput joystick; B - An individual keyboard that directly feeds USB keystrokes to the PC, without any help from the PC. I know this could be less flexible, but I have my reasons.

 

Then the game won't get confused of the "standalone" joystick because this part utilizes 1-way communication.

 

Ive never dealt with the HID descriptor being longer than 128bytes. Since data (at least mine) is transmitted in sets of 3bytes, (descriptor, data, data) the rest would be waisted bandwidth as the rest of the 125bytes would be 0xFF, the only advantage Im aware of using more than that is for cable transmission since apparently a logic high is less suseptible to noise than logic low.

 

Sounds like you were talking about a payload of more than 128 bytes. While I was actually referring to the Report_Descriptor itself, which is only transmitted once upon USB enumeration. Anyway, my bad!! I was so careless reading the HID specification that I actually thought the wDescriptorLength within the HID Descriptor had only 1 byte in it. I just reread the spec and found out I'd asked a really stupid question.:music_whistling:

Edited August 16, 2009 by Alex_rcpilot

[sweinhart3]

Well if you have any insight on making a composite device lemme know. I attached a very rough drawing of my design. I previously had several ICs in place of every PLD but 1 PLD could save a lot of wiring and headache and could be good for 8 inputs or outputs each and they only cost $1.50 each. Downside is i have to get a programmer and they run $250-$600+.

Edited August 16, 2009 by sweinhart3

[Alex_rcpilot]

Well if you have any insight on making a composite device lemme know. I attached a very rough drawing of my design. I previously had several ICs in place of every PLD but 1 PLD could save a lot of wiring and headache and could be good for 8 inputs or outputs each and they only cost $1.50 each. Downside is i have to get a programmer and they run $250-$600+.

 

Personally I'd prefer the more flexible approach, a programmer will turn out handy in future. :)

 

Make sure you read this thread regarding composite devices. I'm still testing mine. Good luck!