kiek

Good to see it's solved. Enjoy your LeveldD767 MCP! Nico

Hello Chakko, I'm sorry, but I'm not familiar with Pokeys, Arduino and your advanced use of FSUIPC (wrt rotary encoders)... I only know Opencockpits hard- and software very well ;-) But it is unlikely that there is something wrong with lekseecon_f. Regards, Nico Kaan

It looks like you forgot to add /NODEFAULTLIB:LIBC.lib to the Command Line options of the Linker in the Configuration Properties of your project... I don't think you need to compile a new .lib, at least I did not.

Hi Lasse, I can see that you are not a SIOC programmer yet ;-) Here example SIOC code to display the GS needle and Localiser needle values -if alive- at four digit displays (most left digit blank or minus and then 3 digit value): You have to update the digit numbers to your hardware. Have not tested it but this is how you should do it in SIOC. Var 1 name gs_alive Link FSUIPC_IN Offset $0C4C Length 1 { CALL &OUTGS } Var 2 name gs Link FSUIPC_IN Offset $0C49 Length 1 { CALL &OUTGS } Var 3 name OUTGS LINK SUBRUTINE { IF &gs_alive = 1 { &D_gs = &gs IF &gs < 0 { D_gss = -999998 // minus sign } ELSE { D_gss = -999999 // blank } } ELSE { &D_gs = -999999 // blank &D_gss = -999999 // blank } } Var 4 name D_gs Link IOCARD_DISPLAY Digit 1 Numbers 3 Var 5 name D_gss Link IOCARD_DISPLAY Digit 4 Numbers 1 Var 10 name loc_tuned Link FSUIPC_IN Offset $0C4A Length 1 { &loc_tuned_in = TESTBIT &loc_tuned 1 } Var 11 name loc_tuned_in { CALL &OUTLOC } Var 12 name loc Link FSUIPC_IN Offset $0C48 Length 1 { CALL &OUTLOC } Var 13 name OUTLOC LINK SUBRUTINE { IF &loc_tuned_in = 1 { &D_LOC = &loc IF &loc < 0 { D_locs = -999998 // minus sign } ELSE { D_locs = -999999 // blank } } ELSE { &D_loc = -999999 // blank &D_locs = -999999 // blank } } Var 14 name D_loc Link IOCARD_DISPLAY Digit 5 Numbers 3 Var 15 name D_locs Link IOCARD_DISPLAY Digit 8 Numbers 1 [/CODE] regards, Nico

That your radio receives a Glideslope signal. You need that because from the needle values you cannot exactly tell, 127 can be the value at 100 km from the airport (GS not alive), but also when the GS is alive but you are way below the glide. In my sim the GS offsets work well ... Same principle as for "Localiser tuned in".

Hi Lasse, You can do it even better: Take 0C4C for GS alive and 0C49 for GS needle Take bit 1 ( Localiser Tuned in) from 0C4A and 0C48 for LOC needle.

Afirm. Use lekseecon_f.exe from the 8.3 version: all FMC keys and info about EXEC and MSG lights are available via FSUIPC offsets.

I don't think so Roar. The best way forward for SIOC users would be a lekseecon like solution, meaning a direct connection between the SIOC Server and the SDK. No involvement of FSUIPC. With the lekseecon solution the user only has to deal with SIOC variables, not with FSUIPC offsets and not with lua scripts.

You are right Pete. I've seen that poor man on television, arriving at Heathrow airport, leaving his wife behind... I hope these lawyers understand what FSUIPC is all about, it's rather technical stuff ... ;-)

Pete, I guess that they have to consult their lawyers. This may take weeks ;-)

Hi Dario, I know nothing of lua (not using it), but let me tell you (just for information) how my lekseecon (a C++ program) reads data from the NGX SDK via SimConnect. The simconnect interface is abstracted by a SimConnectClient object.That object takes care of opening and closing the connection to FSX, initialisation, and mapping the needed client events to simobjects (however, that part is out of scope her, I only detail reading now). Five times per second an object abstracting the SDK, calls a read on the SimconnectClient object. That object calls the simconnect callback procedure and it checks whether the NGX datastructure has changed. If so, it copies the whole structure to the same strucure into my lekseecon C++ program. Also 5 times per second a check operation on objects representing annunciators, values (like heading, altitude, course) in the end-user application is called. Every object has a 'const reference' (set at compile time) to that part in the NGX datastructure, within lekseecon, to which it needs to be checked. If there is a change in value it will send the new value to the end users application via an object abstracting the SIOC interface or an object abstracting the FSUIPC interface. In my lekseecon program for the Level-D 767 I do exactly the same (with the Level-D SDK). I have about 400 objects that poll the datastructure (within lekseecon!) 5 times per sond, but with the powerful cpu's we have these days that is no problem at all. Lekseecon is always below 0,00 % in the Task Manager.

Negative... lekseecon is also able to make the NGX SDK available in FSUIPC offsets. It already does so for the Level-D 767. See http://www.lekseecon.nl/lekseecon.html But same problem here. The EULA is bothering me...

Sure it can. Every SIOC variable is 32 bit, so there is really no problem to send that value to a 4 byte FSUIPC offset.... And again, are you sure your Aircraft add-on in MFS 'supports' the FSUIPC offset? Seeing (with FS Interrogate) the value arrive at FSUIPC, proves nothing ...

My lekseecon program http://www.lekseecon.nl/lekseecon.html. provides almost every control and state of the Level-D 767 via FSUIPC offsets (and, although out of scope here, SIOC variables). Use lekseecon_f.exe. The leksecon variables for controlling the Left and Right Fuel Switches (as ON/OFF switches) are 505 and 506, provided via FSUIPC offsets $91F9 and $91FA (1 byte each).

Hi Gibbon , Here some tutorials how to read, write and read/write from/to FSUIPC offsets from SIOC: http://www.lekseecon...html#readFSUIPC http://www.lekseecon...tml#writeFSUIPC http://www.lekseecon...readwriteFSUIPC And study the list of FSUIPC offsets (inthe FSUIPC SDK) carefully... And do note that you cannot be sure that an aircraft add-on supports the published FSUIPC offsets.

Hi Pete/Rob, Here are the definitions of the lekseecon read/write variables for the Level-D MCP. These variables are available at the 4 bytes offsets posted before. Note that these variables are not only used to send rotarie values to the Level-D but they also receive information from the Level-D, for instance in case you change a heading or altitude with the mouse in the panel, or to give the Speed a value when a speed window "opens" or the VS a value when the VS window "opens" (with opens I mean that it goes from blank to a value). So these variables can also be used to drive 7-segment displays in an MCP. 296 Vrw MCP IAS/Mach, range 100 to 950 Note: Mach values are given x 1000, so .802=802 297 Vrw MCP Heading in degrees, range 0 to 359 298 Vrw MCP VS, range -9900 to 9900 299 Vrw MCP Altitude in feet x100, range 0 to 640 Using word controls in stead of dword controls might work for ALT, HDG and SPD. Maybe you have to make sure that the upper 16 bit of the offsets are 0 by changing these values in the panel with your mouse, before you start using your rotaries, then lekseecon will initialize these values. For VS it will not work i'm afraid. Lekseecon treats the 32 bit value as signed, not the 16 bit lower part. regards, Nico

Hi Pete, I see, that's indeed the way forward, not via FSConfig, but with your powerful FSUIPC Offset controls. The lekseecon offsets can be found in the Lekseecon Manual, 0x8b18 for the IAS, 0x8b1c for the Hdg, 0x8b20 for the VS, and 0x8b24 for the Alt, all 4 bytes. (and do not forget to 'activate' lekseecon variables 296, 297, 298 and 299 in the CONFIG_FILE for lekseecon in FSUIPC Mode)

Hi Pete (and Rob), Rob has to check the Manual of the GoFlights FSConfig software to find out how he can assign FSUIPC offsets to his rotaries. I do not know the RP48 but I doubt it will be possible to let the rotaries generate values between 0 and 359 for the MCP HDG offset. That's what my leksecon FSUIPC offset for MCP HDG requires... best regards, Nico Kaan

Hi Fouad, Good to read lekseecon 8.0 is useful. I know nothing of lua but i'd assume that it also has a clear byte command, or a setbyte to value 0? so you do not have to use clearbits. And also setting the value 1 in a byte should be possible with a command other than setting bit 1.. ipc.setByte(0x905f, 1) ? regards, Nico Kaan

Hi, no not in the standard FS2004 offsets of FSUIPC, I think. Nico Kaan

Hi, FYI, from one of the developers in the Level-D FSX Forum (only for licenced members): "The 767 for FSX has been reprogrammed to take advantage of the new SimConnect features. FSUIPC is now only used for the advanced fuel logic (fuel dump, scavenger pumps, apu fuel flow). It is likely that this logic will be also converted to SimConnect in our future products. In the meantime, if you want to desinstall FSUIPC you will only loose what is mentionned above."

But surely it's a scenery enhancer. How is it going to enhance scenery from a different PC? I really don't know how it can be used with WideFS -- if you know more please let me know. Indeed. It does so via shared directories over the LAN directly, and not via WideFS ...

No, that depends on the aircraft. For the Level-D 767 there are on/off commands for the Fuel Pumps as offstes in FSUIPC (at 0x8B22). They are provided by the Level-D SDK and my FSCONV program (for free).

Yes! These offsets are FSCONV offsets. They represent hardware switches. Note I'm only using your offsets as mailboxes, they are not 'real FSUIPC offsets' in the sense that they represent something in FS9. So what you're saying about differences in processing needed to obtain values is not relevant here. Much appreciated, but I want to be as precise as possible. We are both talking within our own 'mind sets'.

Hi Pete, Thanks. Splitting up Reads is no option. I only read once and process (16 times a second). So I understand that calling after every 60 msec FSUIPC_Read(dwoffset, 128, pDest, &Res); FSUIPC_Process(); is not faster then calling every 60 msec: FSUIPC_Read(dwoffset, 121, pDest, &Res); FSUIPC_Process(); So it makes no sense enlarging my blocksize with dummies from 121 to 128.