Event on Calibrated Axis Offset is Resent After ipc.control

[pilotjohn]

I disconnect a throttle (0x310A), set an event on its calibrated axis (0x3330), then in the callback function I control the throttle (65820). If the control param/value I send is not the same as the value that was provided to the callback function, the callback function is called again with the value provided to ipc.control. I'm using this setup to toggle between using the throttle axes for either forward thrust or reverse thrust based on a flag. When I'm in the toggled state, and I convert the value passed to the callback to a negative value, and then send it to ipc.control, I will get another invocation of the callback with the negative value I just sent to ipc.control. The same thing happens if I scale the forward thrust (by say 0.5). The odd thing is that this "behavior" doesn't enter a loop and only sends the "duplicate" once (that is if I get 100, send 50, I get 50, send 25, I will not get a 25.) Also, the trigger is only if the delta appears to be at least 256 (although the delta on the axis is 128). Some examples (without the delta)...

Normal:

call-back receives 100

ipc.control sends 100

call-back receives 200

ipc.control sends 100

Reverse:

call-back receives 100

ipc.control sends -100

call-back.receives -100

call-back receives 200

ipc.control send -200

call-back receives -200

Forward Scaled:

call-back receives 100

ipc.control sends 50

call-back.receives 50

call-back receives 200

ipc.control send 100

call-back receives 100

I can "filter" this out, by keeping the last ipc.control I sent, and if i receive a callback with the same value, ignore it, but I think this is likely a bug. UPDATE: on far reaches of reverse (-16383) occasionally the "phantom" event gets called with -16384 (1 off). I've only noted this at this far range. BTW, to your likely questions that -4096 is maximum reverse, the J41 actually uses -16384. -4096 only moves it "back" about 25%, even though a read from tthrottle lower limit offset says -4095 is lowest.

[Pete Dowson]

I disconnect a throttle (0x310A), set an event on its calibrated axis (0x3330), then in the callback function I control the throttle (65820). If the control param/value I send is not the same as the value that was provided to the callback function, the callback function is called again with the value provided to ipc.control. I'm using this setup to toggle between using the throttle axes for either forward thrust or reverse thrust based on a flag.

Of course, because you are sending a control which is calibrated and then intercepting the changes in the calibrated values. With the control being disconnected it shouldn't be going anywhere else in any case, so what you are trying should be completely futile.

The idea of the disconnection was to supply the already calibrated value for you to then use (or change and use) directly, not send the same control as the one originating from your joystick. The intercepting and calibrating part of FSUIPC cannot tell any difference for WM_COMMAND message arrivals containing the same control number, they all look the same!

Just drive the throttle directly via the throttle offsets. That's what the fly-bt-wire provisions were for.

BTW, to your likely questions that -4096 is maximum reverse, the J41 actually uses -16384. -4096 only moves it "back" about 25%, even though a read from tthrottle lower limit offset says -4095 is lowest.

The value is read from FS. If the throttle lower limit offset reads -4095 then the Aircraft.CFG file gives 25%. Check the value "min_throttle_limit" in the [GeneralEngineData] section. For 25% it'll be -0.25. For 100% it should be -1.00

Regards

Pete

[pilotjohn]

With the control being disconnected it shouldn't be going anywhere else in any case, so what you are trying should be completely futile.

In our last thread about the axis issue you said this should work (which appears to be the case, except for the second even trigger): http://forum.simflight.com/topic/69342-conditional-buttons-on-axis-ranges/page__view__findpost__p__431378

Just drive the throttle directly via the throttle offsets. That's what the fly-bt-wire provisions were for.

I'll double check, as this was my original plan, but writing directly to the throttle offsets does not work on the J41.

[Pete Dowson]

In our last thread about the axis issue you said this should work (which appears to be the case, except for the second even trigger)

Hmmm. Yes. I think it depends on how you assign and calibrate.

If the THROTTLEn_SET controls remain disabled for configuration in the 4-throttles calibration section of FSUIPC options (as I think they are by default), then those controls won't be subject to calibration so 3330 shouldn't change and you shouldn't then get an event.

Can you tell me how you've assigned the throttles -- where, to which controls, and which route?

Regards

Pete

[pilotjohn]

Can you tell me how you've assigned the throttles -- where, to which controls, and which route?

So the original problem is that using ipc.writeSW(0x088C, ...) does not work on the J41 (it does not move the throttles) which is why I had to resort to using ipc.control(65820, ...).

The axis is not assigned in FSX. It's assigned to send direct to FSUIPC calibraition, throttle 1.

I then disconnect throttle 1 at 0x310A with mask 0x40 every second, I intercept 0x3330 with event.offset, and send ipc.control based on my "flag" (whether it should reverse or forward thrust). ipc.writeSW works on most planes I tested, except for the J41, which requires ipc.control.

The "double-event-callback" happens when I use ipc.control and send a param that is not the same as the one provided to the callback (that is if I change the value to "reverse" or scale it any other way).

[Pete Dowson]

The axis is not assigned in FSX. It's assigned to send direct to FSUIPC calibraition, throttle 1.

Okay. Is the problem the same if you assign to AXIS_THROTTLE1_SET instead, or direct to calibration?

Can you check this question too, please, I asked before?

If the THROTTLEn_SET controls remain disabled for configuration in the 4-throttles calibration section of FSUIPC options (as I think they are by default), then those controls won't be subject to calibration so 3330 shouldn't change and you shouldn't then get an event.

So, is THROTTLEn_SET disabled in the 4 throttles calibration? (Bottom of options dialogue)? The 65820-3 are the THROTTLEn_SET controls.

I've not time to investigate this further today, but i'd like to collect all the facts beforehand.

Regards

Pete

[pilotjohn]

Okay. Is the problem the same if you assign to AXIS_THROTTLE1_SET instead, or direct to calibration?

Can you check this question too, please, I asked before?

So, is THROTTLEn_SET disabled in the 4 throttles calibration? (Bottom of options dialogue)? The 65820-3 are the THROTTLEn_SET controls.

Yes, Exclude THROTTLEn_SET is checked (on all the tests below)...

1.

"Send to FS as normal axis" "Axis Throttle1 Set"

Events triggered on 0x3330, exhibits the double event.

2.

"Send to FS as normal axis" "Throttle 1 Set"

No events triggered.

3.

"Send direct to FSUIPC Calibration" "Throttle 1"

Events triggered, exhibits the double-event (this is the original configuration)

I'm a bit confused now :). If it's set to "Send to FS as normal axis" why does it still get calibrated? What is the different between 1 and 3 above if they behave the same?

[Pete Dowson]

Yes, Exclude THROTTLEn_SET is checked (on all the tests below)...

Okay. That's a puzzle then as it should mean such events aren't processed through the calibration. I'll check that tomorrow.

"Send to FS as normal axis" "Throttle 1 Set"

No events triggered.

Ah, so it DOESN'T go through calibration normally, only when sent as an ipc.control()! Interesting!

I'm a bit confused now . If it's set to "Send to FS as normal axis" why does it still get calibrated?

FSUIPC's calibration was provided years before any FSUIPC axis assignments were ever provided. There prime function has always been to calibrate FS controls, assigned in FS. So they apply even if you assign to such controls in FSUIPC.

The "direct" option was added as a more efficient way (saves posting a control to FS for FSUIPC then to trap and calibrate) for the regular controls, and also to add new ones like the reversers, tiller, and a few others.

What is the different between 1 and 3 above if they behave the same?

As above: direct goes direct, the FS ones go via FS. Some aircraft implementations only work with the latter.

Can you paste the Axes and JoystickCalibration sections of your INI file please, those relevant to this particular aircraft?

I'll take a look at this tomorrow.

Regards

Pete

[pilotjohn]

Can you paste the Axes and JoystickCalibration sections of your INI file please, those relevant to this particular aircraft?

This "toggle" concept will be used for all aircraft, but the J41 is the only one that needs ipc.control instead of ipc.write to affect the throttle, and that's how I came across this double-event scenario. As I said, I coded around it with "filtering", but it may trip up others somewhere along the line. Ultimately though, send to FSUIPC for calibration direct is the more efficient solution, so I'll stick with that for handling the calibrated events.

[JoystickCalibration]
AllowSuppressForPFCquad=Yes
ExcludeThrottleSet=Yes
ExcludeMixtureSet=Yes
ExcludePropPitchSet=Yes
SepRevsJetsOnly=No
ApplyHeloTrim=No
UseAxisControlsForNRZ=No
FlapsSetControl=0
FlapDetents=No
MaxThrottleForReverser=256
SteeringTillerControl=0
MaxSteerSpeed=60
Aileron=-16192,0,0,16192
Elevator=-16192,0,0,16192
Rudder=-12288,0,0,12288
LeftBrake=-16192,20480
RightBrake=-16192,20480
Throttle1=-16383,0,0,16383/40
Throttle2=-16383,0,0,16383/40
Mixture1=-16192,0,0,16192/40
Mixture2=-16192,0,0,16192/40
PropPitch1=-16192,0,0,16192/40
PropPitch2=-16192,0,0,16192/40
SlopeRudder=3
SlopeRightBrake=4
SlopeLeftBrake=4
SlopeAileron=-2
SlopeElevator=-1
ReverserControl=66292
Reverser1Control=66422
Reverser2Control=66425
Reverser3Control=66428
Reverser4Control=66431
AileronTrimControl=66731
RudderTrimControl=66732
CowlFlaps1Control=66162
CowlFlaps2Control=66163
CowlFlaps3Control=66164
CowlFlaps4Control=66165

[Axes]
0=0Z,128,D,9,0,0,0
1=0U,128,D,10,0,0,0

[Pete Dowson]

This "toggle" concept will be used for all aircraft, but the J41 is the only one that needs ipc.control instead of ipc.write to affect the throttle, and that's how I came across this double-event scenario.

I notice from these:

Throttle1=-16383,0,0,16383/40

Throttle2=-16383,0,0,16383/40

Mixture1=-16192,0,0,16192/40

Mixture2=-16192,0,0,16192/40

PropPitch1=-16192,0,0,16192/40

PropPitch2=-16192,0,0,16192/40

that you have FSUIPC's Filtering checked. Why is this? Are you joysticks very jittery?

By some coincidence you might see from another thread near here (here)that some problems have been discovered with filtering, and I'm now wondering if this double event is another side effect of this. So, could you try with the filtering off on all those 6 axes, please (I say all because there's a good chance of them cross-interfering as I discovered today).

Please let me know. If that helps you might want to try 4.729 which I supplied today in that other thread, because that should have the filtering bug fixed: http://fsuipc.simfli.../FSUIPC4729.zip

The other odd thing about those "calibrations" is that they seem too 'perfect' to be true calibrations! Surely you should allow some dead zone at either extremes, otherwise you cannot guarantee to reach a stable idle nor max thrust! In fact with min and max set at -16383 and +16383 the calibration is doing nothing at all, there's little point in using it!

Meanwhile, tomorrow I'll see if I can reproduce this double event -- but I shall be using 4.729.

Regards

Pete

[pilotjohn]

that you have FSUIPC's Filtering checked. Why is this? Are you joysticks very jittery?

I installed 4.729 and disabled filtering, but double-events persist. I also moved the min/max.

However, I noticed a side-effect of disabling filtering: If I move the throttle levers too fast, the idle position event may not get triggered. Interestingly, with filtering on, this was never a problem.

I posted the script I use for the forward/reverse toggle: http://forum.simflight.com/topic/69388-throttle-manager-to-allow-axis-forwardreverse-toggle/

And, on a separate thread hijacking note, the sound position parameter in sound.play seems to have no affect: 90, or 270 all play seem to play in center.

[Pete Dowson]

I installed 4.729 and disabled filtering, but double-events persist.

Okay. checking today ...

I also moved the min/max.

However, I noticed a side-effect of disabling filtering: If I move the throttle levers too fast, the idle position event may not get triggered. Interestingly, with filtering on, this was never a problem.

It sounds like you've not moved the min-max enough, then ... Filtering will slow the changes considerably, and allow a calibrated 0 to be seen, but evidently your calibrated "idle" zone is not large enough to guarantee a stable enough idle.

And, on a separate thread hijacking note, the sound position parameter in sound.play seems to have no affect: 90, or 270 all play seem to play in center.

I think that might be because of the specific sound device configuration. Try 5.1 surround or similar. I use it here and get sound positioned well.

[LATER]

I just re-tested the sound with 4.729, and it certainly positions correctly here. The speakers used depend on the sound device configuration. For example with "Stereo" selected it'll be using front speakers only -- left-centre-right, with 5.1 it will use rear speakers too, to get 360 positioning.

Regards

Pete

[Pete Dowson]

And, on a separate thread hijacking note, the sound position parameter in sound.play seems to have no affect: 90, or 270 all play seem to play in center.

I checked this again.

There are two ways of positioning sound:

SETPAN for non-3D capable setups, using just left/right speakers, and

SETPOSITION for 3D/surround capable setups, using any number of speakers up to 7.1

It seems that some sound cards support only one or the other. In my test case I have 5.1 speakers plugged in and normally the card is set to "5.1". Then the positioning from FSUIPC is perfect. But if i select Stereo mode in the Windows properties for the sound, I get the sound on all three front speakers no matter what position is set. It should let me use "SETPAN", as on a stereo card, but it doesn't, and the SetPosition seems to be, er, ignored.

So, please check your windows settings.

Incidentally, your Left and Right sounds are much more precisely positioned if you use 45 for right and 315 for left -- then they are precisely on the right and left speakers. with 90 and 270 the 3D effect tries to set them direct right and direct left using rear speakers as well, which make the sound rather more "amorphous".

I'm still trying to work out a way of correcting the double event. I can see what it is doing, but fixing it without messing other things up isn't so easy ...

Regards

Pete

[pilotjohn]

Filtering will slow the changes considerably, and allow a calibrated 0 to be seen, but evidently your calibrated "idle" zone is not large enough to guarantee a stable enough idle.

I hope filtering is not going away then, as I like this feature. It makes the throttle movements much smoother with a guaranteed idle, despite a slight (nearly imperceptible) lag.

It seems that some sound cards support only one or the other. In my test case I have 5.1 speakers plugged in and normally the card is set to "5.1". Then the positioning from FSUIPC is perfect. But if i select Stereo mode in the Windows properties for the sound, I get the sound on all three front speakers no matter what position is set. It should let me use "SETPAN", as on a stereo card, but it doesn't, and the SetPosition seems to be, er, ignored.

I'm using a headset, and I'm sure it's set to stereo. I'll check with a forced 5.1 setup.

I'm still trying to work out a way of correcting the double event. I can see what it is doing, but fixing it without messing other things up isn't so easy ...

Glad I can throw you another something to tinker with. :) As I said, I worked around it, so I'm sure others can as well, but if you're like me, it's probably the principle of the thing to get it fixed.

[pilotjohn]

I'm using a headset, and I'm sure it's set to stereo. I'll check with a forced 5.1 setup.

I'm using the on-board Realtek audio, which does not let me force 5.1 mode on the headphones. Is it possible to expand the sound code to have it check whether it's in stereo or surround mode and use the appropriate calls?

[Pete Dowson]

I hope filtering is not going away then, as I like this feature. It makes the throttle movements much smoother with a guaranteed idle, despite a slight (nearly imperceptible) lag.

No, I'm not removing filtering, though I don't like it myself. It should only make things smoother on a rather unsmooth input, so it's very dependent on the hardware and its connection.

I'm using a headset, and I'm sure it's set to stereo. I'll check with a forced 5.1 setup.

Yes, but as I found, switching the card to stereo mode seems to destroy any ability to choose a position, which seems totally daft to me. I can only find two ways to position as I said, and neither work in stereo mode. Everything's fine in 5.1 and other surround modes. There must be a way, of course, but it defeats me at present. I'll research it further when I have a bit more time. Not now. Sorry.

Set 5.1 or another 3D mode and change the angles to 45 and 315 and it will go to the correct side of your head.

Glad I can throw you another something to tinker with. :) As I said, I worked around it, so I'm sure others can as well, but if you're like me, it's probably the principle of the thing to get it fixed.

I've fixed the double event problem. Once I could clearly map the routes things were taking it was easy enough to put the right check in.

Please download FSUIPC 4.731

Regards

Pete

[Pete Dowson]

I'm using the on-board Realtek audio, which does not let me force 5.1 mode on the headphones. Is it possible to expand the sound code to have it check whether it's in stereo or surround mode and use the appropriate calls?

I'm actually also using on-board hardware -- not sure if it's Realtek or not, but that's most likely. The facilities for modes are in the "Sound" control panel applet, "Playback device" tab, "configure" button. This is Windows 7 with its own installed drivers.

Is it possible to expand the sound code to have it check whether it's in stereo or surround mode and use the appropriate calls?

The code already does that of course. It tests the capabilities of the sound device and uses Panning or Positioning as appropriate. I traced through the running code and the card never says it has panning, no matter what mode i set it into. I also tried sending only the stereo panning, irrespective of the capabilities, and that didn't work either.

I'll investigate further when I have a little more time.

[pilotjohn]

I'm actually also using on-board hardware -- not sure if it's Realtek or not, but that's most likely. The facilities for modes are in the "Sound" control panel applet, "Playback device" tab, "configure" button. This is Windows 7 with its own installed drivers.

Yes, unfortunately the "Configure" button is disabled on my headset. I'm using the official Realtek drivers, but I'll try to revert to the default Windows ones.

I've fixed the double event problem. Once I could clearly map the routes things were taking it was easy enough to put the right check in.

Great, thanks! I'm sure you can now sleep better at night. :)