whartsell

Lemme know what you think if you give it a try. I'm working on getting basic output functionality (annunciation lights) working and hope to have that ready by the end of the weekend

Current Features in Hogkeys 1.2.0 Support for Pokeys 56U Digital Inputs Analog Inputs Digital Outputs Planned Features for 2.0 (release early-mid Q2 2013) New UI. The UI needed to be completely re-written to decouple it from the hardware. Im open to suggestions if anybody has any opinions on layout. Right now its based on what my needs are. This is taking the most time as all the "backend" functionality is basically unchanged (I built it right from the start). UI is not my forte. support for Arduino based hardware (currently the poc is working and fully integrated) implementing framework to support a plugin based driver/hardware model. This will make adding new hardware very easy. implementing framework to support different simulators. Just like the hardware plugin model this will allow HogKeys to work with different simulators. e.g FSX,X-plane,etc Servo support is coming (it may not make it into 2.0 but will definitely be in 2.1. Once 2.0 is done it will be trivial to add servo support. More info on HogKeys 2.0 Version 1.2.0 is out and adds support for analog inputs In the long quest for my A-10 cockpit I have evaluated a bunch of different options all the way from openCockpits cards to rolling my own with ATMega chips and came across Pokeys a while back. I was very impressed with the cost (about 50 euro 60 USD), flexability (analogue in/out encoder support,pwm etc), and how developer friendly they are. The biggest drawback is the crappy macro support (doesnt know about Left vs right Shift,CTL etc. So i struck out to build my own integration software. I created a simple utility that currently allows you to map simple switches to DCS commands and send them via udp. In the near future i will expand this to support lights/servos via pwm,encoders as well as analog input/outputs. I am working on this utility for mainly my own purposes but figured i would share it with anyone who is interested. There is a wiki going over all the details but it still is being updated It is located at https://code.google.com/p/hogkeys/

this went to an A-10 pit builder ... Me :)

i usually get my stuff from digikey

almost forgot: http://www.poscope.com/pokeys-io-devices.html

I have tried opencockpits poKeys and even built my own with microcontrollers...so far the easiest and most flexible are the poKeys. pokeys has many inputs/outputs and is very expandable. you can start with simple keystroke emulation and grow into more complicated software if needed..their api is well documented and you can code it in almost whatever you want. pokey cons: if you want to use any of the outputs you will need to write your own code opencockpits cards work well when you get them working. My problems with them are : cards are too specialized. you need a card for displays,encoders,etc SIOC work great when you figure it out but is a pain in the ass to use and poorly documented. with opencockpits you will also still need to write custom lua just to get the inputs into the sim. there are some available on the forums here sorry to ramble but on my lunch break

A pot is really the best solution for the yaw trim. Unlike radio knobs you really want the absolute position of the knob. You can't do that with simple encoders. Your best and easiest solution is to pick up a pot between 10k and 100k and plus it directly into the iocards USB expander. If memory recalls there are 3 headers for pots If you use an encoder you will get into situations where the trim is out of sync with the knob

When you built your ACEsII what did you use to attach the seatback to the seat base. It looks like bolts in your pics. Is that right?

hows the stick force? is the return spring working ok?

Servos are easier to get a hold of locally and have all the position sensing built in but are limited to less than 360 deg rotation usually less than about 270 deg. Stepper motors require you to do a little more electronic work like build your own "park" position sensing but can be used throughout multiple revolutions. For example a servo would be simpler for gauges like vsi or temp gauges that are limited in rotation. A stepper would be easier for gauges like an altimeter or a generic heading gauge that doesn't have a limit in its rotation. Hope that helps

thanks

damn i diddnt look for that

rotary thumb switches for IFF and TISL Just picked up these thumb switches. should be a good fit for the IFF and TISL panels for only 20 bucks including shipping i figured i couldnt go wrong http://www.ebay.com/itm/230736246843?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1423.l2648#ht_539wt_1326

Maybe she is trying to get me out of the house...She has also given me permission to start building a RV-10 next year

awesome...thanks

I was shocked when my wife said i could put the pit in the game room. I was planning on keeping it in my office

i love your warthog center stick solution. If you get a chance can you give me the measurements for the extension

i fixed the offending link and added more pics.

very nice. looks like im about 2 weeks behind you as im using dimebugs plans as well. I wish my woodworking skills were as good as yours. After seeing how helios looks in the cockpit im really torn now between just getting another monitor to get up and running quickly with helios or waiting and taking the time to build out the mechanical instruments. I guess i could do both ;)

I have been lurking on these forums for over a year now and seeing all the great work people have accomplished so i decided to get my feet wet and start on my own build. My goals are to make it as realistic as practical. For the cockpit i decided on dimebugs excellent plans since my wood fabrication experience is limited to Jr. High woodshop. The area i hope to really focus on is the avionics since i worked in that field in the AirForce for 7 years. Below is what I have accomplished so far. I did not cut out the instrument holes for the MIP as im still deciding on what instruments will be mechanical and which will be virtual. Also the top of the glareshield is not installed so i can get in and out of that space for wiring etc. Next up is assembly of the side panels this weekend (if the wife approves) and then the acesII seat to go along with it. After all that is done i will be installing a set of modified RCS with cubpilots hall effect mod (and anxiously waiting for the toe break mod to be released) as well as my warthog HOTAS. I also took pictures to document what how i handled the build

Im interested as well

Remends me of when i used to fly ultralights in California when i was younger. We would take off on a cross country at dawn then by the time we got back the Santa Ana winds would be blowing and you had to hover off the rwy at 50' and wait for people to come out and "catch" you then wing walk you back to your parking spot. You never stopped flying till you were tied down in your spot

Overview: how to get data from the Sim to the uC this is basically the opposite of the uC to sim overview except the data flow is reversed: Sim>>Computer>>uC From the Sim to the Computer: Once again this is the part most people are familiar with. I will not go into details on configuring the export.lua as that is well documented. In my example case i am exporting the Tacan displays from the sim to the computer. The export.lua sends this data via UDP (im using the default helios export) to a udp listener on the computer. In my case im using python. The python script once again listens for data via udp with an address that it cares about. From the Computer to the uC: The listener program above does the opposite of what it did when receiving data from the uC. It takes the message from the sim and converts it to a message the uC will understand. In my example the data format for LCDs is the high nibble is the address of the display and the low nibble is the value to be displayed. The udp script then sends out this byte to the uC on the appropriate port. The uC is listening for messages on the port and when one is received it sets the appropriate display to the appropriate value. About the uC: in the case of the 7 segment displays the uC firmware has an array of 10 bytes that correspond to lighting 0-9 on the display. the value received can be 0-16 as we are using 4 bits (but currently only implements 10). Since the array holding the display patterns is indexed 0-9 its just a matter of setting the segment pins of the display to the appropriate value. once that is done the display is quickly turned on ...then turned off. then the steps are repeated for each display. This is an example of miltiplexing the displays as each uses the same segments but are turned on and off at different intervals ( so fast you cant see it). this is suitable for this poc but in future iterations I will use hardware based multiplexing to reduce pin counts and control current draw from the displays

just say the word and ill be down for it

That is why im on the fence with either doing dedicated "plug and play" devices for each panel or just doing what OC did and have generic cards. With the generic cards you can get a much higher density since they only do one thing. Also on the board of todo's is the 32u4 which has built in USB for pwr management i plan on using a seperate bus for power. In my example since im running only two and the duty cycle is so low they only consume 4ma which is below the 40ma limit for the pin. Also plan on having back lighting on a separate bus as well already working on serial/parallel shift registers and some interrupt enabled expanders i plan on using 74HC595s for multiplexing leds. Should be able to get 4-5 7segments on each one of those and use another 595 for multiplexing the commons but im still investigating that. If that works well i should be able to drive 8 seven seg displays easily with 3 74hc595s and only using aprox 6 pins. I will look into the MCPs as they could be more appropriate than the ones i currently have With regards to surface mount im not too afraid of that...used to do it when i was an avionics tech in the military I would love to check it out and am open to any collaboration. I also noticed that Helios was opened up a but and was thinking of speaking with you about using it as the integration point. No sense reinventing the wheel. one more thing...its ugly but a pc can accommodate 25 virtual com ports (I have no plans to go that route though)