displaying IAS/MACH using FSBUS 22

[KNI-DK]

Hi Pete

Nice meeting you at FSweekend last weekend. :D

Hope you are remembering our talk about IAS/MACH - you told me to set Fiddle IAS in the ini file - which I actually had done prior to our conversation - so I still have my problem :shock:

I am using

FSUICP 4.53

FSX sp 2

PM sw (glass, CDU, MCP and pmSys), newest releases

OCs SIOC for annunciators

FSBUS22 (the old one) for MCP/EFIS HW (from symulatory)

Let me make a introduction to my problem(s)

IAS/MACH display

1) IAS is shown and switch automatically to MACH at the set alt in the ini file, which is shown in MCP sw display (pm) and in PFD -

can I without any programming (logic) catch this display(the reading) (with an offset) to make my HW display show the same numbers (IAS or MACH)?

1a) I am of course able to read the IAS (04E0) or MACH (04E8) by using the offsets - but do "we" have an (one) offset just mirroring the numbers coming from IAS/MACH reading?

temp QNH

2) maybe you are the wrong guy to ask, but I try anyway (if so - pls. kick me to the right place if possible :) ) - when pushing STD (throughpass 49) (and logic (CCC logic in FSBUS) change writing offset from capt. QNH(0330) to Capt temp QNH (5536) the PFD shows below "STD" in white numbers the temp QNH set - so far so good - but how do I write this number as the active QNH, when pushing STD travelling through TA?

2a) Am I in first place using the right Capt. QNH offset (0330)?

BR

Kjeld

[Pete Dowson]

Hope you are remembering our talk about IAS/MACH - you told me to set Fiddle IAS in the ini file - which I actually had done prior to our conversation - so I still have my problem :shock:

You mean "FiddleMachForPM=Yes"?

Let me make a introduction to my problem(s)

IAS/MACH display

1) IAS is shown and switch automatically to MACH at the set alt in the ini file, which is shown in MCP sw display (pm) and in PFD -

can I without any programming (logic) catch this display(the reading) (with an offset) to make my HW display show the same numbers (IAS or MACH)?

1a) I am of course able to read the IAS (04E0) or MACH (04E8) by using the offsets - but do "we" have an (one) offset just mirroring the numbers coming from IAS/MACH reading?

I don't know, because I don't know FSBus and what you can do with it. IAS and Mach are formatted differently -- NNN or N.NN. How would you cope with that? Who is putting the "." in or leaving it out?

temp QNH

2) maybe you are the wrong guy to ask, but I try anyway (if so - pls. kick me to the right place if possible :) ) - when pushing STD (throughpass 49) (and logic (CCC logic in FSBUS) change writing offset from capt. QNH(0330) to Capt temp QNH (5536) the PFD shows below "STD" in white numbers the temp QNH set - so far so good - but how do I write this number as the active QNH, when pushing STD travelling through TA?

2a) Am I in first place using the right Capt. QNH offset (0330)?

Sorry, I don't really understand the question -- "how do I write this number as the active QNH, when pushing STD travelling through TA?". Do you mean when descending below the TL? The TA applies to climbing.

Project Magenta should show the QNH it will set in the subscale, below the legend "STD". That is the value in 5536. When you press STD again, it swaps the value from 5536 to 0330, which is the active FS altimeter setting. You would normally adjust the QNH value, whether active or pending, by using PM's INC/DEC facilities -- that way you'll get a nice 0.01" increment when set to inches and a 1 hPa increment when set to hPa. Any other method can get rounding differences.

Regards

Pete

[KNI-DK]

Hi Pete

You mean "FiddleMachForPM=Yes"?

YES

I don't know, because I don't know FSBus and what you can do with it. IAS and Mach are formatted differently -- NNN or N.NN. How would you cope with that? Who is putting the "." in or leaving it out?

If I for some reason in my Q made you believe the Q was about how to programme FSBUS I do hope you can accept my apology, this is not the matter of how FSBUS is programmed, but it is/was a Q to help open my eyes to which offset or offsets should be read. Will (maybe this word should be "Can") a single offset give either IAS or MACH (with the different notification (NNN or N.NN)) depending of the mode setting? Or should I keep track of which mode is in work and then read the corresponding offset?

Sorry, I don't really understand the question -- "how do I write this number as the active QNH, when pushing STD travelling through TA?". Do you mean when descending below the TL? The TA applies to climbing.

Sorry for the incorrect Q - yes I do mean the TL - and your next comment has revealed the answer to this Q

Project Magenta should show the QNH it will set in the subscale, below the legend "STD". That is the value in 5536. When you press STD again, it swaps the value from 5536 to 0330, which is the active FS altimeter setting. You would normally adjust the QNH value, whether active or pending, by using PM's INC/DEC facilities -- that way you'll get a nice 0.01" increment when set to inches and a 1 hPa increment when set to hPa. Any other method can get rounding differences.

Haven't tested it yet, but I do see the picture now - I have used the standard offset for FS to handle the input of inc/dec of QNH, which I now - of course - can see was wrong - I will reprogram with use of INC/DEC QNH for PM (just to be sure x5418 bit 18 and 19) and I will let you know when I have tested it.

Many thanks for your answers

[Pete Dowson]

Will (maybe this word should be "Can") a single offset give either IAS or MACH (with the different notification (NNN or N.NN)) depending of the mode setting?

You could write a little Lua plug-in to do that, yes. It would have to test the mode and copy the relevant value into one of the user-free offsets at 66C0-66FF.

Or should I keep track of which mode is in work and then read the corresponding offset?

That's the same. If you are writing your own driver, that's the place to do it. If you only have an interface program which can read one stated offset, then use the Lua program. But my question about arranging for the decimal point still applies. Of course your Lua program or driver could format the result into character format, if that's what your display can handle.

Haven't tested it yet, but I do see the picture now - I have used the standard offset for FS to handle the input of inc/dec of QNH, which I now - of course - can see was wrong - I will reprogram with use of INC/DEC QNH for PM (just to be sure x5418 bit 18 and 19) and I will let you know when I have tested it.

Yes, those are what I use.

Regards

Pete

[KNI-DK]

You could write a little Lua plug-in to do that, yes. It would have to test the mode and copy the relevant value into one of the user-free offsets at 66C0-66FF.

Last night I was doing some initial studies at Lua - will go for it in the weekend to assess wether I will do it inside the FSBUS22(CCC logic programming) or go for Lua

Thanks

Kjeld

[Pete Dowson]

You could write a little Lua plug-in to do that, yes. It would have to test the mode and copy the relevant value into one of the user-free offsets at 66C0-66FF.

Last night I was doing some initial studies at Lua - will go for it in the weekend to assess wether I will do it inside the FSBUS22(CCC logic programming) or go for Lua

Okay. If you go for Lua and get stuck, get back to me.

Regards

Pete

[KNI-DK]

Hi Pete

Got the flu right after the last post and been busy afterwoods regaining the lost time. Haven't tested the LUA yet.

But the time doing nothing made me re-consider my approach - and I decided, as you actually advise me at FSweekend, to make a direct wiring from the encoders to FSUICP (bypassing the FSBUS2.2) - which now have been done. BUT now I have another problem (and based on my search at www I am not the only one) using the std. FSUICP assignment "PM MCP HDG INC 1" and "PM MCP HDG DEC 1" (goes as well for SPD, ALT etc) the speed of the bug movement is slow and it takes ageds to dial 180 deg, or go from 6000 ft to FL390.

I do not have a dual encoder (could be the case later) and will not use x10 FSUICP inputs (PM MCP HDG INC 10 etc), but as far as I have read it should be possible to let the PM read fast dial as fast and the inc the numbers, but will that require another input (offset)?

I have also used both "push" and "release" programming, but for some reason it reads that as 2 "click" even I only feel one at the encoders.

Thx

BR / Kjeld

[Pete Dowson]

I do not have a dual encoder (could be the case later) and will not use x10 FSUICP inputs (PM MCP HDG INC 10 etc), but as far as I have read it should be possible to let the PM read fast dial as fast and the inc the numbers, but will that require another input (offset)?

Sorry, I don't understand. Where do offsets come into it? How will you signal the fast or slow modes? What's "fast dial"?

Are you sure this isn't a question for PM support? I do not control their offsets nor do I know anything about FSBUS.

I have also used both "push" and "release" programming, but for some reason it reads that as 2 "click" even I only feel one at the encoders.

Possibly. I think there are several makes of encoder. Yous seem to give one complete pulse per clcik whereas the GoFlight and others I've used go on and off alternately, a click for each. Presumably yours stay off except when being turned?

Pete

[KNI-DK]

Sorry, I don't understand. Where do offsets come into it? How will you signal the fast or slow modes? What's "fast dial"?

Let us say we are going from 3000ft to FL390, if using the FSUICP input "PM MCP Alt Inc 100", one have to turn the knob many many times and keep it running beacause only a few detents are "stored"! (Encoder wired using BU0836x to FSUICP as button assignment)

Besides using the "PM MCP Alt Inc 1000" can one do anything to make "PM MCP" or "FSX" or "FSUICP" understand that fast dial or many detents will result in faster increasement of ALT?

BR / Kjeld

[Pete Dowson]

Sorry, I don't understand. Where do offsets come into it? How will you signal the fast or slow modes? What's "fast dial"?

Let us say we are going from 3000ft to FL390, if using the FSUICP input "PM MCP Alt Inc 100", one have to turn the knob many many times and keep it running beacause only a few detents are "stored"! (Encoder wired using BU0836x to FSUICP as button assignment)

Besides using the "PM MCP Alt Inc 1000" can one do anything to make "PM MCP" or "FSX" or "FSUICP" understand that fast dial or many detents will result in faster increasement of ALT?

If you cannot program it in FSBUS or whatever, you would need to use another program, possibly a Lua plugin. You'd need to get the knob incrementing or toggling a user offset (e.g. one in the range 66C0-66FF, available to users for any use) for each "click", and detect the changes in Lua, checking the time between each change -- do one increment anyway, but if another change comes within, say, 100 mSecs, doing the remainder of the increment (say 999 from 1) and thence stay in fast mode till you detect a gap longer thanm, what, 500 mSecs perhaps?

There must be many ways of doing this with different times. You can adjust it to suit your needs.

Regards

Pete