cefs

You could use a typedefed struct and cast a pointer of that type to your buffer, easiest way as long as the structure of your data does not change. Could also use an id, value pair, where the id of the value is used in a switch statement, I have used this before and it works ok, like below- BYTE *b; // pointer to buffer short id; // id of value short numVals; // the number of id, value pairs in buffer, first item in buffer int iVal; // integer value - maybe a frequency short sVal; // short value - maybe airspeed etc b = buffer; // buffer received from sim numVals = (short*)b; // get the number of id, value pairs to process b += sizeof(short); // increment buffer pointer to start of data for( int i = 0; i < numVals; i++) { id = (short*)buffer; b += sizeof(short); // increment buffer pointer to value switch(id){ case 1: // int - maybe a frequency ival = (int*)b; // do something with iVal b += sizeof(int); // increment buffer pointer to next id break; case 2: // short - something like airspeed sval = (short*)b; // do something with sVal b += sizeof(short); break; case 3: ... } }

Check out the 74xx138/238. You could still possibly use multiple slaves with the same address, they would all have to send their acknowledgements together, not sure if that would cause a problem, if using an arduino then it could be a problem as you would be using their library code and you would most probably want to alter the interrupt service routine. As the bus is pulled high, are you going to be able to use logic gates. EDIT: Was thinking a little last night, (it hurts, this thinking lark) and as long as your slaves are not responding to write requests, only reading data from the master then you should be ok to use the same address for multiple slaves, may want to enable clock stretching though.

Hi, I2C is a multi drop bus, just 2 lines are used to connect to multiple devices, works like a lan. SPI is a little different with data in, data out, clock and chip select lines, you do not have to use both data lines if you only want to transmit or receive. You can connect the data out and clock lines to multiple devices on a shared bus (like !2C), and drive multiple devices with those two lines and then maybe use something like a 3 to 8 address decoder, 3 lines in which select one of 8 lines out, which would connect to the slave devices chip select pin, so you could drive eight slave devices from 5 pins of your micro controller, each one selectable. One thing you have to take note of though is that both I2C and SPI use pullups on their lines, this is something like a 10K resistor connected to the line from the power rail, with arduino that would be 5 volts I think, (I dont use arduino so you need to check) and both devices should be running at the same voltage level. I have used the MAX 7219 before so have some 'C' code to drive it, it is not difficult, the code may be compatible with arduino as I think its 'C' based, but again you would need to check.

I did start working on a generic usb interface to DCS a while ago and should still have the code somewhere. It was implemented as a dll which was loaded from a dofile() call from a script with a set of functions that wrote data to a buffer and then sent the buffer to your hid device. Maximum buffer size was 64 bytes, thats the max for a vendor defined hid device. I'll dig out the code, if anyones interested, and try and get a basic implementation up and running. At the time I did not have a dev board to test the code so the project died, but I have a pic based board I can test with now.

Someone made an app for Android and exported the gauges for the Huey, think it was free also, why not start there.

That sounds like a bug in your code. Maybe have a return statement rather than a break in the path your code takes when the altimeter is moving fast. Just a guess of course, but would be worth following the different paths the code can take and check the values of controlling variables etc. Very impressive so far, inspiring me to get on with my pit.

Sounds like all the analogue axis, so could be a ground problem. Don't have this stick so not sure how its wired, but could be something like a bit of metal making contact with a part of the pcb and creating a short. Had a similar issue once and was solved by using a fiber washer between a screw and a pcb. So check connections are right way round and things like screws that mount pcb's are isolated.

That thread looks like a good place to start, it will give you a good idea of what needs to be done and the hardware/software needed.

First of all have a look at some of these products already available, http://www.opencockpits.com/catalog/modules-plugplay-boeing-c-22_61.html maybe they could be modified to suit your needs. If you already have panels what are the dimensions of the cut outs for the displays, what sort of display will fit, if seven segment leds then how many will fit and how many digits are needed and what colour. It is best to plan all of this and then use a single board (like an arduino) to drive all the displays.

There are a few variables that you need to consider, mainly the display type, the size and colour required. For radios you could use seven segment displays, but now there are a few small oled displays available that could work well, the only problem is their size. You may be able to get away with small single line character lcd's for instance. I have used seven segment led's before, and currently checking out small oled panels which are easier to work with as they can be connected straight to a microcontroller without having to use a separate driver as with led's. I can give you some help if you or anybody else wants it.