Updating FSX axes to match current HID values

[MarkH]

I have been working on getting FSX to stay in sync with my physical cockpit. For this I am using LINDA and the COM library's HID functions. I have been successful in reading all the button states and then setting up FSX to match my switches. The HID demo program was very helpful in this and by studying it I have taken what I had hoped was the next step, which is to successfully read all the analogue axis data. But now I am stuck.

 

I want to use the axis data to set the appropriate values in FSX to match the current settings (e.g. throttle, prop, mixture) but I am stuck because I don't see a way to identify which HID axis is mapped to which FSX function. As far as I can tell (from the demo) I will need to write data to the PFC axis offsets but to do that I need to know which is which. Is there any way to find this out? Obviously I have the Vendor/Product/Unit ids available but I'm not sure that helps. The only way I can currently see to do this is to manually determine which HID axes match which functions and then hard-code them (or more likely make a table of them in my own ini file). But that seems inelegant and not at all robust.

 

I am not wedded to any particular solution to this so if anyone understands what I'm trying to do and knows another way, please say. I had originally sort of hoped there was a software equivalent to wiggling each axis slightly, so FSX would update through the normal channels, but I think that was a bit optimistic. I would be happy to hear people's ideas on this.

[Pete Dowson]

I want to use the axis data to set the appropriate values in FSX to match the current settings (e.g. throttle, prop, mixture) but I am stuck because I don't see a way to identify which HID axis is mapped to which FSX function.

 

I assume you have no trouble identifying which parts of the HID input relate to which physical axes? (The way I've always done it by logging the input and seeing which axis elements change when moving each in turn). So what is then the problem in sending that value on as that axis control?

 As far as I can tell (from the demo) I will need to write data to the PFC axis offsets but to do that I need to know which is which. Is there any way to find this out?

 

 

Why do you need to? If you want that to be your normal method of axis input, you will find the PFC axis offsets mapped to joysticks 16-18, so you just assign them as you wish in FSUIPC's axis assignments dialogue. They aren't fixed -- the labelling in the offset list is for the automatic assignment made by the PFCFSX.DLL driver for the serial port PFC devices.

 

I don't really understand your last paragraph.

 

Pete

[MarkH]

I assume you have no trouble identifying which parts of the HID input relate to which physical axes? (The way I've always done it by logging the input and seeing which axis elements change when moving each in turn). So what is then the problem in sending that value on as that axis control?

 

Yes, I think that's the sort of thing I had in mind when I talked about doing it 'manually'. I suppose I could write a separate Lua program that does this in the background and arrange for it to run at startup. It could record its mappings in an ini file and it could stop monitoring (and terminate) when it has identified every slider.

 

I don't really understand your last paragraph.

 

Well I'll try to say it clearer (and hope it doesn't just come out as longer and less clear!)

 

My joysticks are built around physical sliders and FSX maintains axis data that the positions of those sliders are mapped to. In between is a chain of software that I don't know much about. FSUIPC is somewhere in this chain, and further out are a HID driver and probably other things I cannot name. Knowing what I do about how these things work, that chain is an intricate mechanism of polling loops, timers and interrupts that links the joysticks to FSX in a way that makes the data shadow their movements - almost.

 

That they can get out of step tells me that somewhere along the chain there is at least one link that pushes data to FSX, rather than sending it on demand. If I physically wiggle a joystick, that link notifies FSX and the axis data gets updated. In principle there is a way (perhaps several ways) to poke around in the mechanism and make that push happen without actually wiggling the joystick. Whether there is a practical way to do it is the real question. I had assumed the 'delta' setting on your axis assignment dialog meant that FSUIPC uses a push model to send axis updates to FSX. It would be nice to be able to say 'push now' to FSUIPC.

[Pete Dowson]

Yes, I think that's the sort of thing I had in mind when I talked about doing it 'manually'. I suppose I could write a separate Lua program that does this in the background and arrange for it to run at startup. It could record its mappings in an ini file and it could stop monitoring (and terminate) when it has identified every slider.

 

Er, why do you need to do it more than once? Are you reassigning all your axes regularly? What is going to change that demands re-investigation on every startup?

 

I'm obviously not understanding anything of what you are trying to do!

 

Knowing what I do about how these things work, that chain is an intricate mechanism of polling loops, timers and interrupts that links the joysticks to FSX in a way that makes the data shadow their movements - almost.

 

That they can get out of step tells me that somewhere along the chain there is at least one link that pushes data to FSX, rather than sending it on demand. If I physically wiggle a joystick, that link notifies FSX and the axis data gets updated.

 

I think you misunderstand something. FSUIPC polls the data -- i.e. it reads the settings at regular intervals. It ignores readings which are the same the the previous reading (within a certain adjustable range, called the Delta). Until it sees a change on an axis it ignores it.

 

I think FS operates in the same sort of way.

 

 In principle there is a way (perhaps several ways) to poke around in the mechanism and make that push happen without actually wiggling the joystick. Whether there is a practical way to do it is the real question

 

There's a question which comes before that: WHY would you want to in any case? What is the purpose, the point?

 

It would be nice to be able to say 'push now' to FSUIPC.

 

Why would sending the same value as before be of any use? Maybe when you first load up the simulator you want all of FS's settings to match the axis positions? (though personally I find my cockpit performs far more predictably and reliably if when starting up I make sure every axis is moved up and down its full range fore doing much else -- part of the initial checks. I do this with the Boeing surface positions display on the EICAS screen).

 

If all you want to do is match things up initially you need to send a change which is bigger than the delta, that's all. i.e send x+delta then send x.

 

Pete

[MarkH]

What is the purpose, the point?...Maybe when you first load up the simulator you want all of FS's settings to match the axis positions?

 

Yes, that's exactly it. If I load a situation I want FSX to set its switches and axes to match the positions of the real ones in my cockpit. (And no, I shouldn't need to do the axis mapping more than once but I would prefer a generic solution that wouldn't care if I did change something.)

 

If all you want to do is match things up initially you need to send a change which is bigger than the delta, that's all. i.e send x+delta then send x.

 

Sorry, I don't understand this - send where? Do you mean to write to the FSUIPC offset for the axis? And what is x - what I find at that offset in the first place or what I read from the HID?

Edited July 5, 2015 by MarkH

[Pete Dowson]

Sorry, I don't understand this - send where? Do you mean to write to the FSUIPC offset for the axis? And what is x - what I find at that offset in the first place or what I read from the HID?

 

Yes, the offset for the axis -- you said you were writing to the PFC offsets, didn't you?

 

If you are assigning "direct" in FSUIPC then you need to use those PFC offsets. If you are assigning to FS controls then you merely need to send the actual controls with the input value. Either way they'll get passed through FSUIPC's calibration.

 

Yes, of course, x = value you want to "push"! We do seem to have a communication problem here, don't we? ;-)

 

I still don't see the point of all this worry. Yes, for toggle switches, that's a good idea. but axes should be checked (effectively cleaned) before each flight.

 

Pete

[MarkH]

If you are assigning to FS controls then you merely need to send the actual controls with the input value

I still don't see the point of all this worry. Yes, for toggle switches, that's a good idea. but axes should be checked (effectively cleaned) before each flight.

 

Yes, in the interim I've tried reading and writing the axis controls using the offsets and that works as expected. (I only mentioned the PFC offsets as from the HID demo I thought maybe it had to be done that way.) As for why do this in the first place? Well, because I think it's better - and it's how it behaves in real life! For example, if I start up my Twin Otter with the fuel lever in the ON position I should get an engine fire. Currently I can get away with that if I am lax with the checklist. (Which I am.)

 

Anyway, it's just an experiment. It seems worth doing at the moment but once I get it working it may turn out to be less useful than I expect.

 

We do seem to have a communication problem here, don't we? ;-)

 

That seems to be how it works! As a deeper thinker than I am once said,

 

'We never say all that we expect to be heard as having said, and we often say something quite different from what we intend to be heard as having said. That is, we expect the hearer to do what is technically referred to as “conversational implicature”; to “add” the implicated meanings and respond to them. In this way we are able to use jargon, idioms, figures of speech, and the like.'

 

(I have often wondered if the clumsy phrasing was a deliberate irony :huh:)

 

Thanks for the help.