HDG bug Dec/Inc Fast

[jennik]

Sorry, if that issue was already discussed here, there are many similar keywords to search and i didnt found it.

I am using great USB controller MJoy by Mindaugas and there are four rotary encoders for use. But when I tried to asign them via FSUIPC, I found strange thing with HDG bug control:

There are several commands for HDG bug - the most important is HDG bug Dec/Inc and HDG bug Dec/Inc Fast, just because i am using 20-step encoders and MJoy controller is able to send diferent pushbutton outputs depending on how fast are you turning by encoder.

The first FSUIPC command HDG bug Dec/Inc works perfect, but something strange occures when HDG bug Dec/Inc Fast is used. The bug should go by 10° each step, but instead of that its only switching within two places on gauge...

The important thing is the solution, how it works with CRS bug:

There are more commands in FSUIPC for it and some of them looks like the same: VOR1 bearing Dec/Inc Fast or VOR1 bearing Fast Dec/Inc. The thrue is, that one of that two commands work perfect, and other by the same way as HDG works.

My questions:

1) I thoungh that problem is somewhere in FS or FSUIPC, not with my encoders and MJoy controller - tell me please, how to control HDG bug by this way, please. i have perfectly working CRS bug control and absolutely useless HDG (try to turn DHG by 180° by 1° step on 20steps encoder :) )

2) Another thing - is there any possibility to assign separately Batery ON/OFF of Toggle Master battery? There is only toggle function, not ON or OFF separately. The same occures with Alternator, Taxi lights etc.

Thanks for reply

Jennik

[Pete Dowson]

The first FSUIPC command HDG bug Dec/Inc works perfect, but something strange occures when HDG bug Dec/Inc Fast is used. The bug should go by 10° each step, but instead of that its only switching within two places on gauge...

Sorry, can you explain what "only switching within two places on gauge" means please?

I thoungh that problem is somewhere in FS or FSUIPC, not with my encoders and MJoy controller - tell me please, how to control HDG bug by this way, please

It sounds like an FSUIPC bug -- the "fast" controls are added by FSUIPC, they are not FS controls. I'll investigate here and get back to you.

absolutely useless HDG (try to turn DHG by 180° by 1° step on 20steps encoder :) )

Well, if you are using the normal INC/DEC controls, it is FS which accelerates them to operate in 10 degrees -- I only added the FSUIPC facilities for more precision. Have you got something else running which is defeating the acceleration perhaps? Look at your options in FSUIPC's "Technical" page.

Anyway, if it is a problem in FSUIPC, I will have it fixed within a couple of days.

2) Another thing - is there any possibility to assign separately Batery ON/OFF of Toggle Master battery? There is only toggle function, not ON or OFF separately. The same occures with Alternator, Taxi lights etc.

If I added new controls for all such things my add-on list would be veryt long indeed. I suggest you download the FSUIPC SDK and find the offsets for these things in the tables. You can make your own controls then using the "Offset ..." controls in FSUIPC. Come back after you've looked if you need more help with this.

Regards,

Pete

[Pete Dowson]

something strange occures when HDG bug Dec/Inc Fast is used. The bug should go by 10° each step, but instead of that its only switching within two places on gauge...

RightI've tested these two controls here and the ONLY oddity I've found is when incrementing through 360 (000) a rounding error occurs -- the step from 360 to 010 actally gets to 009. Otherwise it works perfectly here.

On the other points:

There are more commands in FSUIPC for it and some of them looks like the same: VOR1 bearing Dec/Inc Fast or VOR1 bearing Fast Dec/Inc.

FSUIPC added those called "VORn Obi Dec Fast" and "VORn Obi Inc Fast". The others (with the Inc/Dec at the end) are FS's and I didn't think they worked as you'd expect.

(The list of all FSUIPC added controls can be found in the Advanced User's document).

The thrue is, that one of that two commands work perfect, and other by the same way as HDG works.

Can you be clear please about exactly what you mean? I cannot make the added FSUIPC ones go wrong at all. They are much simpler than the Heading ones as the units in FS are degrees in any case -- the heading one is made complex because it uses FS's angles (360 degrees = 65536 units), which is why rounding can play a part.

So, please be rather more specific so I can help. I'll certainly try to fix the rounding (360 -> 009), but I need to understand more about what you are saying. I also need the version number of FSUIPC -- if you are not using the latest, please update it first.

Note that you can always check that it isn't something in your button hardware, or programming, by assigning keystrokes to the same controls and testing them. They use the same code in FSUIPC.

And also, if you look in the Logging section of FSUIPC, you will see that you can use button and event logging to check things even further.

Regards,

Pete

[jennik]

Thanks for so fast reply :)

Sorry, can you explain what "only switching within two places on gauge" means please?

Oh, my poore english... I am sure, i have assigned the "Fast" functions correctly - It works with CRS bug right. the effect of HDG Fast function looks like that:

When the coder is rotating slowly, bug moves by 1°steps to the right direction. When rotating quick, and the "Fast" command is performed, bug only jump over 10° to the side, then back. When you started with HDG 15°, then rotated HDG bug by 1°steps to the right to 90° and THEN tried to use Fast function, the bug jump back to the origin location between 10-20°. Thats what i remeber when I tried it last time.

Well, if you are using the normal INC/DEC controls, it is FS which accelerates them to operate in 10 degrees -- I only added the FSUIPC facilities for more precision. Have you got something else running which is defeating the acceleration perhaps? Look at your options in FSUIPC's "Technical" page.

Ofcourse i turned it off, because of some reasons i dont remeber :) I will try that possibility.

Anyway, if it is a problem in FSUIPC, I will have it fixed within a couple of days.

Thanks very much.

If I added new controls for all such things my add-on list would be veryt long indeed. I suggest you download the FSUIPC SDK and find the offsets for these things in the tables. You can make your own controls then using the "Offset ..." controls in FSUIPC. Come back after you've looked if you need more help with this.

Thats nothnig I would like to hear :) Iam absolutely unworthy with anything which souns like scripting or programming :) but i promiss - i try it.

[jennik]

Ok, i have to review all when at home, now i cant check it. Thanks

[Pete Dowson]

Ibcidentally, the rounding problem seems intermittent -- usually 360-010 works. So it may be more of an FS quirk.

It works with CRS bug right.

Using which controls please? The "Fast Inc/Dec ones (FS's) or the Dec/Inc Fast ones (FSUIPC added)? I need to know. I cannot re-code FS but I can FSUIPC!

When rotating quick, and the "Fast" command is performed, bug only jump over 10° to the side, then back. When you started with HDG 15°, then rotated HDG bug by 1°steps to the right to 90° and THEN tried to use Fast function, the bug jump back to the origin location between 10-20°.

Hmmm .. that sounds impossible, as there is no "memory" of what it was before. Is this occurring with the default 737 (the "bug" being the numerical display on the MCP)?

Does it occur when there's a delay (pause) between the slow turning and the subsequent fast turning? what about the more usual adjustment method of fast turning followed by slow turning?

Thats nothnig I would like to hear :) Iam absolutely unworthy with anything which souns like scripting or programming :) but i promiss - i try it.

It isn't anything like scripting or programming, but you do need to understand words like "set" and "clear". For the lights you will also have to be able to work out the hexadecimal number corresponding to a bit among 16 bits, because all of the light switches are in one word at offset 0D0C.

You don't need to edit any files, it can be done in the same Button assignments screen you use for other things. It is only a matter of selecting the right control, then an offset, then a parameter (for simple on/offs this is usually 0 for off, 1 for on -- the lights are different as I say. You want Offset setbit for on, and Offset clearbit for off, with the parameter showing the needed bit for that light.

Regards,

Pete

[Pete Dowson]

When you started with HDG 15°, then rotated HDG bug by 1°steps to the right to 90° and THEN tried to use Fast function, the bug jump back to the origin location between 10-20°.

I've been trying this and I simply cannot make it go wrong. Maybe I am not able to do it fast enough? Maybe your "fast" is actually moving so fast it is going up from 90 right round to 15 again?

I've checked the code. Of course for the simple INC/DEC FSUIPC is not involved -- your request goes direct to FS. For the fast version, FSUIPC reads the value of the Bug, adjusts it by 10 degrees up or down, and sends it back to FS. If you are SEEING the value increment slowly, then that value is what FSUIPC is reading, to add or subtract 10 from it. There is no other being "held" for seconds so it can come back as you say.

I really cannot see how anything could result in what you say you are getting. Please re-check, AND use the logging provided. Log buttons and events (two checkmarks). You should also Monitor offset 07CC as type U16 (right-hand part of Logging page), checking the normal log option at the bottom.

Regards,

Pete

[jennik]

I've been trying this and I simply cannot make it go wrong. Maybe I am not able to do it fast enough? Maybe your "fast" is actually moving so fast it is going up from 90 right round to 15 again?

Like I said i am using MJoy16 USB device. Each rotary coder connected via that device produces 4 button presses depends on rotation speed and direction. Normal "slow" speed generates "button presses" appx 0-10 times per second. Any faster rotation generates different button presses, but it looks its no faster then appx 20times per sec. In fact, it doesnt work as precise as it sounds. When you rotate the coder fast, mainly the "fast" and sometimes the "slow" button press ocures.

I have tryed it ones more with default Boeing 737 and CRS control:

1) when VOR1 Obi Fast Inc/Dec is assigned for the "Fast pushbuttons" it works perfectly.

2) when VOR1 Obi Inc/Dec Fast is used for "Fast" presses - its useless - the bearing needle stays controlable by slow steps by 1° but anytime some "fast" buttonpress appears - it activates VOR1 Obi Inc/Dec Fast function and then the needle jumps back to ZERO.

It seems what i only need is the Heading Bug Fast Inc/Dec function instead of the only available Heading Bug Inc/Dec Fast which works the same way as desribed with VOR1 Obi...

Next time i will try to log the events and send you the report whats happened within FSUIPC and FS.

Thanks

Jennik

[jennik]

I have also trying to use that Slow/Fast feature of Mjoy for NAV Radio control. The slow steps controles -.xx part of the frequency and the fast controles whole frq. 1XX.-

It works nice :)

[Pete Dowson]

Normal "slow" speed generates "button presses" appx 0-10 times per second. Any faster rotation generates different button presses, but it looks its no faster then appx 20times per sec.

Well, FSUIPC polls by default at 40 times per second, so a 20 pulse per second rate is going to go a bit wrong. You could try adjusting this in FSUIPC (it's the "PollInterval" parameter -- see the Advanced User's documentation.

I have tryed it ones more with default Boeing 737 and CRS control:

1) when VOR1 Obi Fast Inc/Dec is assigned for the "Fast pushbuttons" it works perfectly.

2) when VOR1 Obi Inc/Dec Fast is used for "Fast" presses - its useless - the bearing needle stays controlable by slow steps by 1° but anytime some "fast" buttonpress appears - it activates VOR1 Obi Inc/Dec Fast function and then the needle jumps back to ZERO.

Well, you are saying that the simple code, adding or subtracting 10, implemented in FSUIPC, doesn't work for you. I don't know why you are getting what you are getting, and I've no way of telling as you don't show me any information.

As I said, it works fine here. It was originally tested with Goflight USB knobs with slow/fast capabilities and worked perfectly. But I've not got those devices now.

Next time i will try to log the events and send you the report whats happened within FSUIPC and FS.

Yes. There's certainly no point in continuing this exchange until some decent information is available. Please make sure you test it on a default aircraft please.

Regards,

Pete

[jennik]

Oh, I wonder about whats in that log file :)

See:

I have performed several slow turns when the HDG bug turned by 1° steps from 0 to 90. Then I turn the knob faster and the bug jumped back to 0.

Here is the expample of one of these slow steps:

HEADING_BUG_INC
  3331234 Button changed: bRef=0, Joy=1, Btn=17, Released
  3331312 Button changed: bRef=0, Joy=1, Btn=17, Pressed
  3331312 [Buttons] 26=P1,17,C65879,0
  3331312 FS Control Sent: Ctrl=65879, Param=0
  3331312 *** EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000)

But when the fast function was activated, it seems there were a lot of DEC commands was send... here is the last "slow" step and see whats happened then. I never turned the knob to the left...

HEADING_BUG_INC
  3051062 Button changed: bRef=0, Joy=1, Btn=17, Released
  3051296 Button changed: bRef=0, Joy=1, Btn=16, Pressed
  3051296 [Buttons] 10=P1,16,C65880,0
  3051296 FS Control Sent: Ctrl=65880, Param=0
  3051296 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000)
HEADING_BUG_DEC
  3051343 Button changed: bRef=0, Joy=1, Btn=16, Released
  3051343 Button changed: bRef=0, Joy=1, Btn=24, Pressed
  3051343 [Buttons] 27=P1,24,C65880,0
  3051343 FS Control Sent: Ctrl=65880, Param=0
  3051343 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000)
HEADING_BUG_DEC
  3051375 Button changed: bRef=0, Joy=1, Btn=24, Released
  3051437 Button changed: bRef=0, Joy=1, Btn=24, Pressed
  3051437 [Buttons] 27=P1,24,C65880,0
  3051437 FS Control Sent: Ctrl=65880, Param=0
  3051437 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000)
HEADING_BUG_DEC
  3051484 Button changed: bRef=0, Joy=1, Btn=24, Released
  3051687 Button changed: bRef=0, Joy=1, Btn=16, Pressed
  3051687 [Buttons] 10=P1,16,C65880,0
  3051687 FS Control Sent: Ctrl=65880, Param=0
  3051687 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000)
HEADING_BUG_DEC
  3051718 Button changed: bRef=0, Joy=1, Btn=16, Released
  3051718 Button changed: bRef=0, Joy=1, Btn=24, Pressed
  3051718 [Buttons] 27=P1,24,C65880,0
  3051718 FS Control Sent: Ctrl=65880, Param=0
  3051718 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000) 

And, here is the example how the VOR1 Obi Fast Dec/Inc works fine:

VOR1_OBI_INC
  3899734 Button changed: bRef=0, Joy=1, Btn=19, Released
  3900515 Button changed: bRef=0, Joy=1, Btn=19, Pressed
  3900515 [Buttons] 16=P1,19,C65663,0
  3900515 FS Control Sent: Ctrl=65663, Param=0
  3900515 *** EVENT: Cntrl= 65663 (0x0001007f), Param= 0 (0x00000000)
VOR1_OBI_INC
  3900546 Button changed: bRef=0, Joy=1, Btn=19, Released
  3900546 Button changed: bRef=0, Joy=1, Btn=27, Pressed
  3900546 [Buttons] 18=P1,27,C66368,0
  3900546 FS Control Sent: Ctrl=66368, Param=0
  3900546 *** EVENT: Cntrl= 66368 (0x00010340), Param= 0 (0x00000000)
VOR1_OBI_FAST_INC
  3900640 Button changed: bRef=0, Joy=1, Btn=27, Released
  3900671 Button changed: bRef=0, Joy=1, Btn=27, Pressed
  3900671 [Buttons] 18=P1,27,C66368,0
  3900671 FS Control Sent: Ctrl=66368, Param=0
  3900671 *** EVENT: Cntrl= 66368 (0x00010340), Param= 0 (0x00000000)
VOR1_OBI_FAST_INC
  3900718 Button changed: bRef=0, Joy=1, Btn=19, Pressed
  3900718 [Buttons] 16=P1,19,C65663,0
  3900718 FS Control Sent: Ctrl=65663, Param=0
  3900718 Button changed: bRef=0, Joy=1, Btn=27, Released
  3900718 *** EVENT: Cntrl= 65663 (0x0001007f), Param= 0 (0x00000000) 

[jennik]

now its correct

[Pete Dowson]

now its correct

Erit is all pretty meaningless without knowing which button is which. Can you list your button number assignments please?

Also, Monitor the heading bug offset as I suggested. It may look meaningless to you (I will have to do calculations to convert its units to degrees), but at least it will show the results of each INC and DEC control being sent.

Pete

[jennik]

Ok, no problem, i will prepare detailed documentation for precise analyze ;)

Thanks for your time :)

[Pete Dowson]

Oh, I wonder about whats in that log file :)

The lines in the Log are wrapping, so the descriptions of the EVENT are appearing in the next line, and you are compounding this by dividing up the samples in the wrong place, in a line. Can you make the samples a little wider to avoid this please?

But when the fast function was activated, it seems there were a lot of DEC commands was send... here is the last "slow" step and see whats happened then. I never turned the knob to the left...

HEADING_BUG_INC
  3051062 Button changed: bRef=0, Joy=1, Btn=17, Released
  3051296 Button changed: bRef=0, Joy=1, Btn=16, Pressed
  3051296 [Buttons] 10=P1,16,C65880,0
  3051296 FS Control Sent: Ctrl=65880, Param=0
  3051296 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000)
HEADING_BUG_DEC

So, what is Button 16? It appears, clearly, to be programmed for a HEADING_BUG_DEC.

FSUIPC cannot influence the button numbers being reported. It looks like there is something unreliable going on with your device. The decoding of direction in many encoders is by phase differences. I have noticed that many such encoders give the odd (sinlge) spurious incorrect direction, but not usually a continuous stream like this.

Maybe there is some interaction between the pollling and the USB driver for your device? You could try fast and slower polling rates. What operating system are you using, by the way? If it is not XP SP1 or later it may be the USB drivers.

Regards,

Pete

[jennik]

Sorry, see now the words wrapping:

Another part of log file:

5657203 *** EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC
  5657250 Button changed: bRef=0, Joy=1, Btn=17, Released
  5657609 Button changed: bRef=0, Joy=1, Btn=17, Pressed
  5657609 [Buttons] 26=P1,17,C65879,0
  5657609 FS Control Sent: Ctrl=65879, Param=0
  5657609 Button changed: bRef=0, Joy=1, Btn=25, Pressed
  5657609 [Buttons] 28=P1,25,C1025,0
  5657609 FSUIPC Control Action: Ctrl=1025, Param=0
  5657609 *** EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC
  5657656 Button changed: bRef=0, Joy=1, Btn=17, Released
  5657656 Button changed: bRef=0, Joy=1, Btn=25, Released
  5657687 Button changed: bRef=0, Joy=1, Btn=25, Pressed
  5657687 [Buttons] 28=P1,25,C1025,0
  5657687 FSUIPC Control Action: Ctrl=1025, Param=0
  5657734 Button changed: bRef=0, Joy=1, Btn=25, Released
  5657781 Button changed: bRef=0, Joy=1, Btn=17, Pressed
  5657781 [Buttons] 26=P1,17,C65879,0
  5657781 FS Control Sent: Ctrl=65879, Param=0
  5657781 *** EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC
  5657812 Button changed: bRef=0, Joy=1, Btn=17, Released
  5658218 Button changed: bRef=0, Joy=1, Btn=17, Pressed
  5658218 [Buttons] 26=P1,17,C65879,0
  5658218 FS Control Sent: Ctrl=65879, Param=0
  5658218 *** EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC
  5658265 Button changed: bRef=0, Joy=1, Btn=17, Released
  5658296 Button changed: bRef=0, Joy=1, Btn=25, Pressed
  5658296 [Buttons] 28=P1,25,C1025,0
  5658296 FSUIPC Control Action: Ctrl=1025, Param=0
  5658343 Button changed: bRef=0, Joy=1, Btn=25, Released
  5658390 Button changed: bRef=0, Joy=1, Btn=25, Pressed
  5658390 [Buttons] 28=P1,25,C1025,0
  5658390 FSUIPC Control Action: Ctrl=1025, Param=0
  5658437 Button changed: bRef=0, Joy=1, Btn=25, Released
  5658468 Button changed: bRef=0, Joy=1, Btn=17, Pressed
  5658468 [Buttons] 26=P1,17,C65879,0
  5658468 FS Control Sent: Ctrl=65879, Param=0
  5658468 *** EVENT: Cntrl= 65879 (0x00010157), Param= 0 (0x00000000) HEADING_BUG_INC
  5658515 Button changed: bRef=0, Joy=1, Btn=17, Released
  5659046 Button changed: bRef=0, Joy=1, Btn=16, Pressed
  5659046 [Buttons] 10=P1,16,C65880,0
  5659046 FS Control Sent: Ctrl=65880, Param=0
  5659046 *** EVENT: Cntrl= 65880 (0x00010158), Param= 0 (0x00000000) HEADING_BUG_DEC
  5659078 Button changed: bRef=0, Joy=1, Btn=16, Released
  5659125 Button changed: bRef=0, Joy=1, Btn=16, Pressed
  5659125 [Buttons] 10=P1,16,C65880,0
  5659125 FS Control Sent: Ctrl=65880, Param=0

This is the part of log, when the "jumping back to ZERO" is happened.

I have to say another thing - sometimes the movement of the rotary coder is not translated correctly and reports "fast" button press instead of "slow". Rarely the oposite direction button press is generated too. So i should to expect the HDG bug can step sometimes back a little bit. But why directly back to zero?...

How. It is late today, i have to go sleep now, tired after the hard week. I would like to read your documentation more precise and then I could post soem more usefull information.

Thanks

jennik

[jennik]

Sorry - the buttons are:

No. 16 - turning slowly to the left - Heading Bug Dec assigned

No. 24 - turning fast to the left - Heading Bug Dec Fast assigned

No. 17 - turning slowly to the right - Heading Bug Inc assigned

No. 25 - turning fast to the right - Heading Bug Inc Fast assigned

[Pete Dowson]

So i should to expect the HDG bug can step sometimes back a little bit. But why directly back to zero?...

No idea. That's why I asked for the heading value to be monitored too. Once that is included in the Log maybe we can see the whole picture.

Regards,

Pete

[jennik]

Dear Pete,

I have to apologize... I have upgraded to newest FSUIPC version and everything works fine now...

Sorry for wasting your time :)

Jennik

[Pete Dowson]

I have to apologize... I have upgraded to newest FSUIPC version and everything works fine now...

Sorry for wasting your time :)

Ah. Uh, ok. Thanks. Shame on me for not asking the version right at the start, though I must admit not remembering problems such as those you described in older versions. I guess I just assumed you were on the latest, as I don't support older versions.

You may be interested to know that 3.553 is available in the Interim Version announcements above. I'm planning on a full new User Release, which won't be substantially different to that, by mid-April.

Regards,

Pete