Wow!!! Very, VERY cool!
I've seen several pics of guys that have built the shell but they leave alot of the panels "drawn in". To see one this complete and functional, is a real treat!



Wait a minute!.....Michi???
Are you the same programmer that created FAST? (The Falcon-SIOC bridge.)
If so, I kneel before you, humbled by your greatness. Your name has been mentioned, as just the guy we need to talk to....

By "we", I mean the small group of rotor-head pit builders, that are designing pits around EECH. (My Comanche pit is posted above.)
I don't know if you follow EECH's development but one of our devs (Retro) created a shared memory/data export utility called CommServer. It's currently being used for exporting the data to UDPSpeed gauge sets. (See DickDastardly's post above.) However, it should be able to work well with SIOC, too....if someone could figure out how to make the bridge. Unfortunately, my/our skills lie in fabrication, not programming. And most of our devs are not pit builders, so their interests are on other things.

We could REALLY use your help with it. I, for one, would love to be able to have my upper panel's warning lights and stealth indicator responding correctly.
Is there any chance that FAST could be modified, to work with EECH? (EEST maybe??? Enemy-Engaged-Sioc-Transfer.)
There was even talk of collectively paying someone to do it, so if money is a motivator.... I'm not above begging, bribing, or blo....uhhhhh,... well, at least begging or bribing.

Grizz

I MIGHT be able to help here... I've just finished a VB6 exe that connects to the EECH CommServer and grabs the values out for an Altimeter on another PC.


Simpit flickr set

Send me a PM with what kit the warning lights are connected to please. I'll have a look when I have finished work.

Edit: Mmmm might take me a while to wrap my head round SIOC sorry Griz - I will download Michi's FAST and see if that gives me any clues...

Cheers

That would be great! (I didn't know you were a programmer, too.)


Yeah...That's the rub, isn't it? Retro knows how to work with EECH, FuFunka knows how to work with SIOC, and Michi probably knows how to connect them together. (Me?... I barely understand any of it. ) If we could just get the three of them together!!!

As far as the "kit", there isn't anything yet. Not until I know it can work.
The idea is to have a networked 2nd PC (using mue's MFD hack) to run MaxiVista without the UPDSpeed overlays and put the MFDs on small LCDs. Then, (using Commserver and EEST?) control an OpenCockpits Master Board off that same 2nd PC (Or a 3rd PC if needed), to properly trigger it's inputs, through SIOC.

ahem, *cough* *cough*, humm.. yes, that would be me..

you may rise now, unworthy! :-D

I read the whole CommServer thread with great interest, also your's, Kimchock's and Dick's cockpit progress reports. Actually, I'm in planning stage for a multifunction heli pit and will borrow quite some of your ideas ;-)

Absolutely... I remember, that some time ago someone of the team contacted me - but I don't remember, if I really sent the sourcecode as promised *g*.
FAST is really, really simple. I haven't checked EEComm's protocol, but there should only small modifications be necessary to work with EEC.

@GlynD: The sourcecode is not available (yet) for download. Please send me an email to fast AT f16simulator.net and I'll send you the code, so you can have a look at it.

As written above, it should only be necessary to modify the data extraction function and define the Vars to use in SIOC.

I haven't had a look at the code for some monthes now, and there definitely are some bugs, but I think we should be able to work them out.

greetings
michi

I love this place. A place where we can come together, share ideas and learn from each other. Thanks guys!

YES!!!!!
OMG! You just made my year!
I'm so friggin' happy I could...............oops, I think I just did.

Grizz - I do stuff for work in VB6 (not C or C++ unfortunately)...

Michi what is the code written in please, as if its C/C++ or .Net I probably wont be able understand it?

Cheers

WOW

that's all I can say

I think you will like it - it's VB6

greetings
michi

Michi - dropped you an email for the source code please?

There is a small fly in the ointment with CommServer however. Retro very kindly supplied me with a list of IDs that the CommServer uses for the various helos - problem is each helo has it's own set and there are major differences between the helos!

For instance if you are in the Havoc and ask the CommServer for the value of the "R/502" variable you will get the "Weapons Management Left hand outer pylon green" status back. Whereas in the Comanche this is returning info on the "Left engine Ignition", for the Hokum it will return the value for the "Left engine fire" and the Apache is set to the same as the Comanche but apparently not all values are being exported...

The problem will be when you want to fly in different helos and have a generic pit wired up to "EEST" (nice one Grizz ). Every time you jump in a different helo you will have to let the software know which helo you are in, otherwise incorrect lights will be coming on or wrong data will be returned.

I imagine it would be a major job to standardise the data coming into/out of the CommServer! It will probably be easier to have a "helo switch", this would allow EEST to adjust to what values it is expecting, if you swap helos...

Cheers

Couldn't that already be handled, just by using different .ssi files, in SIOC?

Done (spamfilter caught your mail, sorry)


Sounds like a possible solution to me.
Kind of that is already implemented in FAST, where you can choose between AF and BMS - this just would have to be extended to HAVOC/APACHE/whatever and the appropriate part in the code adapted.
Nevertheless, the user would have to jump out of the sim, change the datamodel in the GUI and hop back in.


Yes, this could be the other approach.
EEST would just do a 1-to-1 transfer of the data, with a fixed mapping of CommserverVAR <-> SiocVAR without any "processing".
You could have a rotary switch in your pit, connected to IOCard's inputs, where you select the actual airframe, and in SIOC process the incoming data dependend on this switch's position.

Sounds even better to me, than my older approach...

greetings
michi

Thanks for the code Michi - fab stuff! I understood most of it - I've only just got into using the Winsock controller for my gauge project.

The F4Lib module and SimData class I will need to see working to better get my head around...

Sometime after Christmas, I think I will order the Master card from OpenCockpits and give this a go. Do you know if the Master card has the same "3 switches on" limit as Leo Bodnars USB controller please?

Cheers

Great to hear, that my code is readable to others, too ;-)


FULL ACK ;-). Even I have to rethink it, when I haven't worke some time on the code *g*

I'll give you a short overview, maybe this can clear thinks up a bit:

SimData is easy ;-): The main variable is
It's simply an array of LongInteger numbers, that represent the SIOC vars 1-500.
So, i.e. siocIndex(23) will hold the value of SIOC's VAR0023.

It's quite hard to remember, which index in the array represents which data from Falcon ;-)
That's, when F4Lib.bas comes into play *g*:

just maps a meaningful name to the appropriate number, ie.

That would be the place for you, if you want to change the names to the data that you get out of EHComms.
The rest of the enums and Data Models is Falcon specific and usually you should not need to keep it anyway.

The most important changes would be in SimData.
FillFlightData holds the code that puts the data from Falcon into the different indizes of siocIndex[]. I think, one example should explain the rest (I commented each line)

In your code, you would substitue .ShipDown with the needed value from EHComm.
I don't know EHC's data structure, but I if it's data is also ordered in arrays, it would even be easier to just say

as discussed some posts earlier. So you wouldn't even need the "Enum SIOC_Index" part, just send EHCs data to SIOC in a 1:1 mapping.
If you don't mind, I'll have a look at EHCs data structure, maybe I will find some "quick and dirty" solution ;-)

AFAIK, no (I don't use IOCards for inputs, just for outputs). And IIRC, there shouldn't be a problem on Leo's parts with diodes in the matrix.

HTH and greetings
michi

Well, that's the only part that I fully understood but it looks like we're making progress!!!

As always....Thanks a million!

NP...
I tried to contact Retro through PM but I'm not sure, if he got it.
If you are able to communicate with him - maybe he could contact me through email:
fast AT f16simulator.net

I'd have some questions about his datastructure.

greetings
michi

Sorry for the delay my main PC has hard drive problems - retro gave me a couple of links to stuff in this thread

http://www.simhq.com/forum/ubbthreads.php?ubb=showflat&Number=2136680&fpart=18

(third post down)...

Does this help?

Cheers

Oh yes!! That's exactly, what I was looking for!

Thx a lot!

Now that I see the IDs of the values, the solution of 1:1 mapping of EECHServer : SIOC variables looks even more advanced to me. This way, no changes to the code of the transfer utility would have to be made, if anything inside EECHServer changes.

GlynD, could we do some code sharing? Could you send me your code, which you use to get the data from EECHServer?

greetings
michi

Emailing it to you now chap.

It's not quite as advanced as yours...

Cheers

Is that F-16 pit made out of wood or metal?

Where did you get the switches at?