Hi,Today I have released FSCONV version 2.11I have resolved some bugs in the AFDS (MCP) part and I have added some flags that were not present in the basic SDK but are derived by me, such as FanInop, PackOff, ApuFault, UtilBusOff, ValveOff, FwdPumpPress, and so on...Nicowww.nicokaan.nl

You are excellent man!! Will start Wiring my MCP!!!Roberto

Hi NikoWhat more can I say....and you are probably sick of hearing it....but...MANY THANKS for all your work and generosity in sharing with us!

Hi,I'm happy to announce that version 2.20 of FSCONV is available for download.On special request I have add AP selected Altitude, Hdg, Vspeed and IAS/MACH to the AFDS_READ section of my program.I have also add some (proven) non-Level-D-SDK functionality: * Support for SquawkBox3: an ATC activity flag ('hit by radar') and (specific) Textmessage (for you) filtering; * Support for the Level-D COMM1 VFR radio: with a dynamic standby window and a frequency select transfer switch.The FSCONV for Programmers manual has been updated and restyled.I don't expect any more new developments. This is it, until Level-D adds more functionality to their SDK in a future release. I'll only fix bugs and definition oversights ( ;-) )from now on.Best Regards,Nicowww.nicokaan.nl

So, realistically speaking, how much is still impossible to do in a home cockpit for LDS? Or is it pretty much complete? Meaning, is LDS SDK the cheap home cockpit builders dream everyone expected it to be, or is the SDK missing some important stuff?If you had a plan to do a full cockpit, would it work?//Tuomas

>So, realistically speaking, how much is still impossible to>do in a home cockpit for LDS? Or is it pretty much complete?>Meaning, is LDS SDK the cheap home cockpit builders dream>everyone expected it to be, or is the SDK missing some>important stuff?It's pretty much complete. Don't forget that the Level-D also offers Custom Controls via key(-combinations) for a lot of functions. That together with the SDK makes gives you a lot of hooks so to speak. The major instruments of the aircraft are covered, such as all the navigational and communication radio's, full AFDS/MCP, complete FMC and lots of systems of the Overhead panel. Ofcourse there are still functions to be wished, like EXEC and MSG signals for the FMC, the ability to control all the lights, the Warning signal, more signals that indicate the state of systems, like FAN Inop, or Press warnings for Fuel Switches (now I compute these signals myself in FSCONV in the DERIVED section, but it would be easier and more reliable if these signals were in the SDK as well)The implementation of your cockpit could also be more reliable if the SDK would also support writable variables for controlling the buttons and switches that are now controlled via key(-combinations). >>If you had a plan to do a full cockpit, would it work?Well I know that Ian Cameron from Tasmania is building a full cockpit based on this. If you have a look at his shell you will be impressed. Don't take my desk cockpit ('knutsel' in Dutch) as an example. ;-) But on the other hand, do note that all the buttons and leds in my desk cockpit work. I have a 5 inch B/W TV for the CDU, two LCDs, 45 7-segment digits and about 74 leds working.... I can bring my 767-300 to a full operational state starting from a dark and cold cockpit without having to use keyboard or mouse. Nicowww.nicokaan.nl

Hi Nico,I am in the process of building an overhead panel for the LDS 767.I am using your wonderful program to read the states of the lights, etcI am using phidget boards to light the LED,s.If I understand correctly, the overhead panel MUST be sent keystrokes to activate the switches (i.e. no offsets available in FSUIPC,etc)From your web site you mention using a KE72 for your FMC, but I am not sure how you are getting keystrokes for the overhead from your IOboards into FS.Is this using FSUIPC or KE72, or some other method?I am looking at phidgets, and thinking that I may have to write a program that takes a switch or toggle and converts it to a set of keyboard presses. The only problem I see with this is that the phidgets would have to be connected directly to the FS system, and that it always has application focus. There must be a better way. Any ideas?Thanks

Hi,>If I understand correctly, the overhead panel MUST be sent>keystrokes to activate the switches (i.e. no offsets available>in FSUIPC,etc)That's right. There are no commands in the SDK for that. So we still have to generate key-strokes.>From your web site you mention using a KE72 for your FMC, but>I am not sure how you are getting keystrokes for the overhead>from your IOboards into FS.>>Is this using FSUIPC or KE72, or some other method?I use the expansion ports of the Aerosoft MCP for that. See page MCP. I have made three BO72 break out boxes, each with 72 inputs. The MCP is capable of sending the right key strokes to the Level-D directly via the COM port. >I am looking at phidgets, and thinking that I may have to>write a program that takes a switch or toggle and converts it>to a set of keyboard presses. The only problem I see with>this is that the phidgets would have to be connected directly>to the FS system, and that it always has application focus. >There must be a better way. Any ideas?I don't know phidgets technology, sorry. But you may also consider using a KE72... It's mature (proven) technology and very flexible in programming capabilities. You may connect it to PS2 or USB, and it has 72 inputs, sufficient for the Overhead Panel. You don't have to write software then.Regards,Nico

Hi Nico,Well the I started using Phidgets (0x16x16) with FS2Phidgets to try and send switch signals, but of course, not supported in LDS. So I have now opted for betainnovations GammRay V2 - with 256 inputs. Hopefully that will be able to send all my overhead keystokes to Level-D.Now, I am still having trouble with my Phidget LED64. I can get it to light most signals really well (awesome with my cool Korry Style switches I have spent the past 2 months moulding in rubber and casting in plastic). Ths issue I have is that the FS2Phidget program can only respond to 8 bits (0-7) and not the 16 or so that some of the panels have (i.e. Fuel) - so this means that after bit 7 I cannot light the LED.I am extremely new to this type of programming so I hope I am not missing anything.I have looked around for the 2**n type of statement you mention in the programmers manual, but cannot find anything that would help (i.e changing the bit value to A, etc)I am not sure where to proceed with this. Any help / ideas would be greatly appreciated.Still think you have done a fantastic job.CheersChris

Hi Chris,Thank you for your kind words. I have read in the Level-D Forum that there will be an enhanced SDK in SP2, so there is still a lot more to come!!!>I have looked around for the 2**n type of statement you>mention in the programmers manualWith 2**n I mean '2 to the powerof n'>the FS2Phidget program can only respond to 8 bits (0-7) and>not the 16 or so that some of the panels have (i.e. Fuel) - so>this means that after bit 7 I cannot light the LED.Well there is a simple work around. Suppose you want to test bit 8 (B8 left_fuel_switch) of the Fuel Panel (note that bit numbering starts at 0, so actually this is the 9th bit...)Instead of masking the Fuel panel word, starting at 0x04F6, with 256 (= 2 to the power 8)You just take the byte at the next address, 0x04F7, and test B0 by masking with 1 (= 2 to the power of 0)Here you are!Cheers,Nicowww.nicokaan.nl