data retreival question

[crashdog]

Hello,

I am trying to receive some data from leonardo's maddog for my overheadpanel. I can now set all needed switches etc with fsuipc $3110 and $3114. But I need to get info's like "apu avail light" and "apu bus on" lights. I tried to log from fsuipc when the apu started up. But no output data of that nature can be seen. Is there any way to find out how to get those infos ? I mean they must be writing somewhere in an ipc or so that their "apu is avail" or that "apu bus is on". Is there any extended logging availiable that could show ?

I tried to ask the vendor them selves, but they are ignoring my requests. Don't know whether the info is to sensitive for them to give away... or if their just ignoring by nature... So I thought I try to ask here.

Cheers,

Gery

[Pete Dowson]

I am trying to receive some data from leonardo's maddog for my overheadpanel. I can now set all needed switches etc with fsuipc $3110 and $3114. But I need to get info's like "apu avail light" and "apu bus on" lights. I tried to log from fsuipc when the apu started up. But no output data of that nature can be seen. Is there any way to find out how to get those infos ? I mean they must be writing somewhere in an ipc or so that their "apu is avail" or that "apu bus is on".

Why do you think they use any FSUIPC offsets for that? Do they use FSUIPC at all? More likely it is all internal to their code. There's no real FS simulation of the APU so why would they need anything external in any case?

Really there are very few sophisticated add-on aircraft whose systems are amenable to implementation in a hardware cockpit. This is why packages like Project Magenta, SimAvionics and FlightDeckSoftware are used in so many. They have the systems outside of FS, only using FS for visuals and flight simulation. There are a few exceptions, but not many. The Level-D aircraft have a software SDK I think.

Regards

Pete

[crashdog]

yes, ok... but fs controls are also internal and they can be set with $3110 and $3114. Also the mouse macros function can send data to maddog even though they don't use fsuipc (probably).I thought maybe there was something simmilar where fsuipc could retreive interal "output" data even if the airplane isn't using fsuipc. Offcourse you are right that they have threir own dll's with their own logic.

I can "read" the overhead panel with for example fs panel studio, it eaven shows many gauge details. That's why I thought that there is some common software interface for panels and the output action to "enlight" a lamp could be catched.

At least you give an answer. Thank you ! :-)

Gery

[Pete Dowson]

yes, ok... but fs controls are also internal and they can be set with $3110 and $3114.

Writing to 3110 merely causes FSUIPC to send a Windows message with the control number and parameter. It is those same messages FSUIPC intercepts and logs when you enable Event logging, and it is those same controls which can be assigned in FS and in FSUIPC to keypresses and buttons.

Also the mouse macros function can send data to maddog even though they don't use fsuipc (probably).

FSUIPC's "mouse" macros detect and hook into the code in gauges which are written according to Microsoft's C/C++ gauge-writing SDK. It can do this because they define mouse-sensitive spots on screen via a table of regular structures, and those structures contain the address in the Gauge code of the routine which processes a mouse click in those areas.

I thought maybe there was something simmilar where fsuipc could retreive interal "output" data even if the airplane isn't using fsuipc.

No, because there is no standard way of storing and accessing such information. Even to provide access to most of FS's own internal data values meant many thousands of hours slogging through FS code using debuggers and disassemblers. I'm not doing that for all add-ons too!

If they use name local variables then the facilities provided to read and write "L:vars" might do the job for you, but "L:vars" are more often used with XML-written gauges (not susceptible to mouse macros). You could try listing the L:vars and see -- facilities exist in FSUIPC to do this, as documented.

I can "read" the overhead panel with for example fs panel studio, it eaven shows many gauge details.

So it should tell you where to find the values you want, then?

Regards

Pete

[crashdog]

If they use name local variables then the facilities provided to read and write "L:vars" might do the job for you, but "L:vars" are more often used with XML-written gauges (not susceptible to mouse macros). You could try listing the L:vars and see -- facilities exist in FSUIPC to do this, as documented.

Thank you for that tip.

I looked at Guenter's LUA L:VAR example (and some of the other lua docu) and got a complete looking list of L:var names.

Then wrote a little lua script that shows me some details of variables that interest me.

while 1 do
      varid = ipc.getLvarId("L:ovhd_apu_bus_adv1")
      valuen = ipc.readLvar("L:ovhd_apu_bus_adv1")

      disp = "L:ovhd_apu_bus_adv1 (id) = " .. varid .. "\n"
      disp = disp .. "ovhd_apu_bus_adv1 = " .. valuen .. "\n"
      ipc.display(disp)

   ipc.sleep(5)
end

The "L:ovhd_apu_bus_adv1" id = shows me "593". The valuen is 0 when "apu avail" is off and 100 when on.

It looks like I could be a step close to my goal. That would be to enlighten an LED which is connected to a Flightdecksolutions SYS3 card.

If I now have the L:var name and the id, what is my next step ? Do I need to write it somewhere ? what can I do with it ?

[Pete Dowson]

If I now have the L:var name and the id, what is my next step ? Do I need to write it somewhere ? what can I do with it ?

You can see if writing to it does anything. It may not. Some add-on L:vars are simply memories of a switch setting and changing them may change the switch without activating the needed system change. But try, by all means. You could either do it in Lua, using the facility to Write to L:Vars, or create L:var macros. See the Macros chapter in the FSUIPC Advanced User's guide -- the L:Var section is actually listed in the contents page for that document.

Pete

[crashdog]

You can see if writing to it does anything. It may not.

Actually I don't need to write to these. I only need to know the variables values. The interface software to my FDS SYS3 card mainly reads fsuipc offset's and it's values or bits. I did send the value from reading "L:ovhd_apu_bus_adv1" to an fsuipc offset as ipc.writeUD(0x6d00,valuen). Obviously I am not that experianced with fsuipc and still need to read the documents more... however maybe you could tell whether there are some offset's free to use. Then I could at least map the variables needed.

I assumed I could use $6d00 onwards from the mapping list.

It would be nicer though if I didn't have to map the values at all, maybe there is some trick to get the value streigt ahead.

Gery

[Pete Dowson]

Actually I don't need to write to these. I only need to know the variables values. The interface software to my FDS SYS3 card mainly reads fsuipc offset's and it's values or bits. I did send the value from reading "L:ovhd_apu_bus_adv1" to an fsuipc offset as ipc.writeUD(0x6d00,valuen).

Why 6D00? You may clash with other uses. Please stick to the allocated User area -- 66C0 to 66FF.

It would be nicer though if I didn't have to map the values at all, maybe there is some trick to get the value streigt ahead.

Straight ahead to where? Do you know how to send data to your hardware? If it is on a COM serial port you can use Lua to write a driver for it -- the Lua implementation in the current version of FSUIPC includes a serial port library. But you will need to know all about the protocols of your hardware and drive every aspect of it.

Otherwise, if you have a driver which can read FSUIPC offsets, what is wrong with using it? What is any more "direct" without a great deal of extra work for you?

Pete

[crashdog]

Hello Pete,

I have now already used all offsets from 66c0 to 66ff. I need a lot more memory to map all variables that I need. So I'm wondering what is the best solution for that ? I read in a different post that you can allocate more memory. But are you only doing that for commercial addons ?

Since I'm not distributing anything could I also maybe just use areas like 7300 (says available for applications) assuming that I don't use what ever add-on might allocate that memory otherwise ?

Gery

[Pete Dowson]

I have now already used all offsets from 66c0 to 66ff. I need a lot more memory to map all variables that I need.

Are you being economical, like using 8 bits per byte for 8 switches, 1 byte for values up to 255, 2 for up to 65535, etc?

So I'm wondering what is the best solution for that ? I read in a different post that you can allocate more memory. But are you only doing that for commercial addons ?

No, not just commercial, but for any application, freeware or others, which will be made available to all. Private uses don't need separate areas to avoid calshes because no one else will use the software.

Since I'm not distributing anything could I also maybe just use areas like 7300 (says available for applications) assuming that I don't use what ever add-on might allocate that memory otherwise ?

No, because it may well be assigned to something which affects you one day. Best to use areas already allocated to something you are never going to use, such, for instance, those assigned explicitly to Project Magenta.

Regards

Pete

[crashdog]

Infact I checked again and realized that I mistakenly assumed that all Lvars use 4 bytes to store it's values. Checking again I could see that some actualy only use 1 byte. So I will go through all the mapped lvars and improve that.

However looking at the quite huge list of Lvars (about 400) and also that I need to map several axis (about 14X12 bits), I feel that I will run out of resources at one point. Since I'm making a MD80 sim I can surely use the 88 bytes assigned to project magenta, that will help a bit too.

But I would wish for a larger "free to use area".

Kind Regards,

Gery

[Pete Dowson]

Infact I checked again and realized that I mistakenly assumed that all Lvars use 4 bytes to store it's values. Checking again I could see that some actualy only use 1 byte.

Even those assigned 4 bytes may only take values 0 and 1 (for "off" and "on"), and you can get 8 such values in an offset byte.

However looking at the quite huge list of Lvars (about 400)

I'm sure many of those must only be on/off indications or switches. I don't know any cockpit needing that many variable displays.

... and also that I need to map several axis (about 14X12 bits), I feel that I will run out of resources at one point. Since I'm making a MD80 sim I can surely use the 88 bytes assigned to project magenta, that will help a bit too.

But I would wish for a larger "free to use area".

If you look at the Project Magenta website you'll find a comprehensive PM offset list. They have a large range -- FSUIPC and PM were developed hand-in-hand and much of what FSUIPC does was because of PM.

Incidentally, there are often other ways of doing things too. For instance using a pair of offsets to provide a "command" and "parameter" so that many of your variables can be handled through one channel.

Regards

Pete