Alex_rcpilot

Dude! welcome back.... Ready to move on with the prj? lol.

(off topic, sorry) seriously man, you've got some REAL COOL business running there. :D Speaking of sim pits, iBoard functionality looks cool to me. No comment on the price though. You might wanna sketch a couple of diagrams to determine what topology you need with the boards, which form of programing is preferable...etc.

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!

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

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

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:

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

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

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:

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

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:

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

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!

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.

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.

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? Understood. It's way simpler in the firmware than I've thought.:thumbup:

Thanks, does SVmapper program the BU0836 cards as keyboard emulators? I can imagine how painstaking it would be when you get started with it. But the good thing is you'd only have to do it once. Anyway, a file is opened? What is it? The SVmapper settings profile?

Wow! Nice to have you here buddy. So does the console application run on a secondary TCP device, or does it run on the gaming PC and "intercept" TCP packets, then bridge it with the extended serial port? Is there anything in the cockpit that can't be accessed through this approach? I'd presume you have a microcontroller behind your panel that interprets the incoming serial data into status information. And then the 7-segment displays and LED indicators work offline according to your inputs and patterns depicted in the firmware to synchronize with the virtual cockpit? Sounds like a huge project.

oops! My bad, you got me. It's not a brilliant idea to save a port with this sortta compromise.:doh:

oops, That sounds weird to me. Like I said, the USB protocol should be independent from operating systems. Since it's a standard released by the USB organization, any operating system utilizing USB interface should comply to this standard. But I may speculate. The issues with old BU boards might attribute to one or multiple causes listed below: A - BU firmware not fully compliant with USB_HID1.11 standard; B - Windows XP not fully compliant with USB_HID1.11 standard; C - Windows Vista/7 not fully compliant with USB_HID1.11 standard; D - USB.org has released a new USB_HID standard after Windows XP, which has been implemented in Windows Vista and later versions. I don't see how D is possible, because I've just downloaded the exact HID spec and HID Usage page tables a couple of weeks ago, and it says 1.11 on them. Any ideas?:music_whistling:

Thanks, that makes me wonder why it fails. I don't have any problem with my own I/O card, which has been tested with XP 32 bit and Vista 64 bit. Straight and smooth.

Hi Feuerfalke, Since the BU0836 homepage is currently closed, I have to ask those who have this board, is BU0836 shipped with a driver or does it use the standard USB driver from the system? To my understanding, when it comes to driver issues, I/O card developers have two options to with: A - Building a card that's fully compliant with the minimum requirement according to default HID standard. This kind of devices are shipped hardware only, they're plug-n'-play, no driver is required whatsoever. B - For various purposes, customized drivers are required to extend the device capabilities. These drivers are usually OS specific, and are generally to be blamed when compatibility problems arise. So by this statement: Were you hinting that all those incompatibility issues fall into the second catagory, or did I get it wrong?:music_whistling:

hi londo, since you've been into I.T industry before I was born, I'd presume that you might have good knowledge regarding WDM and WDF. But if you're not from the R&D dept. and not interested in programing, please just ingnore what I'm about to write below. Thank you anyway:). Here's the thing I don't understand - by default, DirectInput supports up to 32 buttons, 8 axisies, and 1 hat switch on each LOGICAL HID device. Any device with less than that amount of inputs can simply borrow the default driver coming with Windows. The buttons, axisies and hat switch are described within USB ReportDescriptor as 'Usage' items. Each Usage is declared according to the USB HID standard. That means, what used to be - for example - Axis_Z in Win XP, actually has no direct correlation with XP, but is coherent with the HID standard v1.11. Win XP sees it that way just because Win XP utilizes HID standard 1.11. Then if Win 7 also implements the same standard, the same button should also appear exactly as Axis_Z in Win 7. So is it with all other inputs. That's the way it should be. But some folks here find things different, I'm curious about what's behind those issues. Is there something common with those hardware problems?

Dude, that really sucks. I'm wondering what the device property sheets look like in XP and Win 7. Could you take a snapshot with each one of them?

Couldn't wait to see you finish this part. Let's talk after you come back. lol:)