Jump to content

Recommended Posts

  • Replies 680
  • Created
  • Last Reply

Top Posters In This Topic

Posted (edited)

Any reply on this or is it dead? if it is i am working on the same thing now

I recently e-mailed a local air museum with an A-10, and asked them the part numbers of various instruments. They replied, and said they would have the information within a week.
Edited by Deadman

https://forum.dcs.world/topic/133818-deadmans-cockpit-base-plans/#comment-133824

CNCs and Laser engravers are great but they can't do squat with out a precise set of plans.

Posted

On the cards i am not sure yet I have heard there are limits to what yu can do with open cockpits and the same for The PIC HomeCockpit Controller (PHCC). Beta Innovations was the most developed system but as far as i know it is no longer in production. EPIC is just way to expensive and the programing is a pain in the but. I have not seen the card your talking about.

https://forum.dcs.world/topic/133818-deadmans-cockpit-base-plans/#comment-133824

CNCs and Laser engravers are great but they can't do squat with out a precise set of plans.

Posted

Is the key map complete? I don't think so. I know this is only Beta. There's a lot of generic stuff, please some keys for the HOTAS. But how are we going to control the hundreds of switches on the panels? Are more keyboard commands going to be assigned to these switches? Or are they going to be controlled only through the mouse? if only the latter then there is no point building our cockpits if the switches are not going to be controlled through keyboard commands.

 

Not sure if it's even possible to find enough combinations to assign key commands to all the switches in the A10-C!

Posted
Any reply on this or is it dead? if it is i am working on the same thing now

 

They replied and invited me to come visit the museum, they didn't offer any information in the e-mail. The info I requested from the National Air and Space Museum may not come for a while either.

I only respond to that little mechanical voice that says "Terrain! Terrain! Pull Up! Pull Up!"

 

Who can say what is impossible, for the dream of yesterday is the hope of today and the reality of tomorrow.

-Robert Goddard

 

"A hybrid. A car for enthusiasts of armpit hair and brown rice." -Jeremy Clarkson

 

"I swear by my pretty floral bonet, I will end you." -Mal from Firefly

Posted
it will be fine, there won't be key commands for all cockpit switches but they can all be controlled from lua script.

 

Are you saying it'd be something FSUIPC where there's a list of code internally assigned to each switch function, so we send those codes when a switch is flicked and it'd be like onscreen mouse click? Is this list of code already in lua or you make it up yourself? Sorry I don't know much about lua script.

Posted

It's just like that, yes. It's a "back door" provided by the developers for interfacing with the sim. I can't imagine it will be much different for A-10C than how it already works in Black Shark, if you're curious about the details, there's a lot of information in the forums about it.

Posted

Thanks for your input.

 

I guess that's how the BS builders like Oakes, Bad CrC and Gillesdrone etc. did the interfacing. I know most people use OC, so they talk about SOIC, but I haven't given much thought about lua. I kept thinking lua is for very customized thing that the pit builder is trying to do. Now it seems like a broad necessity to use lua for many of the functions that are not provided as key commands.

 

So much to read, the A10C manual, SOIC, lua etc. Now I need to search this forum for examples of how lua was implemented in BS.

Posted

to give you a little insight into how my solution will work (I'm using Arduino cards for my pit) here are some of the components I'm working on:

 

* defining a protocol for communication between the various tiers. I chose to use a very basic ASCII NVP (name-value pair) format.

 

* generic firmware to parse and handle incoming messages, and send control event messages, acts as a TCP client that connects itself to the server

 

* simulator interfacing (or what I'm calling "agent") to provide the connection to simulator software. So in the case of DCS this is a Lua script, for FSX this is a SimConnect program, probably in .dll form, or FSUIPC for older versions, etc. etc. This is also a TCP client that connects itself to the server, but identified itself differently than the firmware client.

 

* TCP Server to accept client connections, contains configuration for the pit, runs all "custom" pit logic with embedded Javascript engine (Google's V8 ) and handles all communication between sim clients and microcontroller clients.

 

A diagram would really explain all this better, but that's for another time.

 

There will also be some one-off solutions, like the A-10's CDU, that don't use the generic firmware but instead use specialized firmware, but still interface with the TCP server using the same protocol.

 

This whole system is essentially the same thing that OC / IOCP / SIOC is, except it's geared around the Arduino / ATMega family of microcontrollers.

For my solution NVP protocol takes the place of IOCP, and Javascript replaces SIOC. Already, this is a huge improvement. I encourage others to follow this path which I believe is superior and much more "future proof" than the OC solution. Also cheaper. I know it's a tough sell until people see it in action as a proven solution, all I can say to that is I have already proven the concept through isolated tests, and I'm getting close to releasing the complete solution for all to see and use.

Posted

Besides the need of a proven solution, another issue would be support. For OC there are many 'veterans' would can lend support in the forums. For your proposed solution you'd have to show how/why it's superior to OC to convince people, and also provide support, which can be overwhelming as people can have all kinds of hardware/software related issues. I think providing support is a bigger challenge than proving it as a viable solution.

 

I've heard of Arduino but you lost me when you talked about the other stuff.

 

Also you'd need lots of documentation to educate users how to set it up, else they won't know how to begin. Tons and tons of examples for all kinds of switches and input/output setup would help.

Posted

Sorry if I lost you, but you're absolutely right, documentation and examples/tutorials are a must. I'll put that stuff up onto the project website.

 

As far as support goes, it would be an open source solution so the community at large would be responsible for supporting each other, no different than OC or others of its kind. I would fully expect early on to answer questions on the forums and clear up any gray areas in the documentation, but after some time the community should be able to pick up from there, even if it's only a few people. I would see my ongoing role as maintaining the code base, implementing bug fixes and suggestions/requests from the community, and putting out new releases.

 

That all being said, I don't think support will be much of a problem, the Arduino community is large and active, much larger than the OC community, and growing all the time. I'm sure this is because it's not so focused on one thing, more of a general prototyping board. This is actually very advantageous to pit builders because we can benefit from the work of hundreds of people that have no interest in building pits, but whose work is useful to us. From the perspective of any 'veteran' on the Arduino, the firmware I create will be nothing more than "just another library," something very familiar to them. Depending on your programming level you would either use it out of the box, no coding (or very very little coding) required, or if you want to get more advanced you can extend it, modify it, or do just about anything with it. In fact the firmware is written with the intention to be extensible, so the community can create and post code for new electronics that they may want to use.

 

I know right now it's all talk until you guys see something concrete. I haven't even really announced it yet, except for this post. I fully intend it to be a turn key solution, complete with a visual development program for configuring your pit controls.

Posted

I searched the forums about lua. so far mostly random questions about it. Can someone show me where to start? find the lua file in the A10C folders and then edit it? If I have a very simple I/O card right now, eg. the BU0836, not OC/SOIC stuff, where do I begin to control simple things like toggles in fuel system control panel?

Posted

y2kiah - the solution you're planning sounds very promising and the Arduino card looks like it can do a lot for pit builders. I'll be watching for updates from you on this. Thanks!

Posted
Two questions to pit builders.

1. In Hispapanels.com the parts sold look similar to OC so I thought they are related. even the pictures of the components look like OC's! But then at the simcard section the motherboard and daughter boards look completely different than OC's selections. If the two sites are related, does it mean OC has come up with new sim cards? I know OC cards are widely used with good reputation. Just wondering if anyone has tried these new looking red simcards. If this site is not related to OC then they are on their own, with no forum to provide support? I read the manual of one of the card, looks good. The only problem I have with OC is that some of the manuals and forum posts are in spanish, with no english translations. and the card design look a bit dated with those DB connectors, but hugely popular.

 

2. How are you guys connecting the individual panels to your I/O solution? What kind of wires and connectors? DB25/15/9 combination with ribbon cables? cat5/6 cables? then extending these wires to the I/O's mastercard? Or bringing the mastercard(s) to the panels, ie. short connection to the panels, but long extension from mastercards to the USB card and PC? I know all combinations are possible. Just wondering what's popular or proven methods. I was toying with a series of RJ45 connectors compared to DB connectors. What do you guys suggest? Any pictures to help illustrate your work?

 

I personally am making varying lengths of wire for the switches to reach the location of my input breakout boards. The DB25/ribbon cables just hook up the boards to each other. Connection to the PC is USB.

Intel i7 990X, 6GB DDR3, Nvidia GTX 470 x2 SLI, Win 7 x64

http://picasaweb.google.com/sweinhart

Posted

cool I'll keep you updated.

Your BU0836 card works a bit differently since it is a USB HID device, when you plug it into the PC, Windows recognizes it as a game controller. With that card, you would be limited to the normal key mappings available in the sim, and not use Lua at all. If you purchase a card with an RS232, Serial-to-USB, or ethernet connection, it's a lot easier to talk with from the lua script.

Posted

I wrote a sample program that will talk with a usb generic HID device (not game controller as it is very restrictive). Problem is that getting into USB is quite a bit more advanced. I had to read a book about it but essentially it would do the same thing OC does but with my own software interface interface which likely is not as advanced as what other more experienced people could come up with. Plus programming the firmware just to get it to properly enumerate in windows was a challenge by itself.

Intel i7 990X, 6GB DDR3, Nvidia GTX 470 x2 SLI, Win 7 x64

http://picasaweb.google.com/sweinhart

Posted

Thanks guys for your input. So if USB devices are too complicated, say I use other solutions like OC or whatever with ethernet connection that produces the keyboard emulation, my questions is still where do I begin for lua? There are several lua files in the DCS installation folder. How do I know which ones to work on? And given the functions of many panel switches are not assigned to key commands, where do I find the list of these functions/code and what do I do with it?

 

The best way for us lua newbies to start is to have someone to show us a very simple example, say any of the toggles in the top left Fuel System control panel. They are not assigned key commands. If I have an I/O card and if I know the assigned key command by DCS then I'd just assign it to the toggle. But there are no key commands in this case for these toggles. So how do I find the functions or codes for this panel, these toggles? Then after I find them how do I make the lua talk to my I/O card to control the function of the toggle? I think this example doesn't get simpler than that. Once I know how to do this one simple example I can figure it out for other panels, other switch type like push buttons, pots, encoders etc. I just need one simple example! I'm sure other newbies would appreciate this too.

Posted

ok, in clickabledata.lua I found this

 

-- Fuel System Control Panel

elements["PTR-FSCP-EXT-TANKS-WING"] = {class = {class_type.TUMB,class_type.TUMB}, hint = "Extenal Tanks Wing" , device = devices.FUEL_SYSTEM, action = {device_commands.Button_1 ,device_commands.Button_1}, arg = {106,106}, arg_value = {1,-1}, arg_lim = {{0,1},{0,1}}}

 

This is the left side fuel system top left most toggle. say I want to control this via a physical switch. how do I use the lua stuff above to interface with say BU0836 or SOIC?

Posted

Do you need to work with LUA-scripts to make this switch work?

As it is implemented in A-10C, the switch-positions have keys assigned. So you can simply use tools like HIDMacro or SVMapper and map the according buttons to your switches.

 

The later also ID's any devices listed. In theory, you can link up 20 keyboards or so and assign the same key on each keyboard with a different function or macro. I used this for programming my BU0836, as well as for modifying a standard external keypad to a WASD-Gaming pad.

 

SVMapper also allows press and release configuration, so it should be very easy to make up makros and map buttons directly instead of working via lua. Well at least IMHO.

MSI X670E Gaming Plus | AMD Ryzen 7 7800X3D | 64 GB DDR4 | AMD RX 6900 XT | LG 55" @ 4K | Cougar 1000 W | CreativeX G6 | TIR5 | CH HOTAS (with BU0836X-12 Bit) + Crosswind Pedals | Win11 64 HP | StreamDeck XL | 3x TM MFD

Posted

sounds like there have been some improvements in A-10C in this area. Should make it easier for builders that don't want to mess with lua!

Posted
Do you need to work with LUA-scripts to make this switch work?

As it is implemented in A-10C, the switch-positions have keys assigned. So you can simply use tools like HIDMacro or SVMapper and map the according buttons to your switches.

 

I looked at the key commands list. Most switches on the panels are not key assigned. I only found them in the clickabledata.lua file. The keys assigned so far are view, hotas, systems etc. Very few of the switches on the right and left consoles have been assigned. If they are, I'd know what to do as I have used I/O cards before and SVMapper. Right now I dont know what key commands are assigned for these switches, so I can't do the key press recording. Maybe I'm not getting what you are saying. Please elaborate.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...