MobiFlight Community Support

Hi,

I would like to know how to split a value between 2 daisy chained MAX7219 drivers. I have SPD on digits 1,2,3 on display module 1, HDG on 4,5,6 of module 1, and want to have the left 2 digits of ALT displayed on 7,8 of display module 1, and then display the right 3 digits of ALT on digits 1,2,3 of display module 2, but I can't figure out how to do it. Any help would be awesome.

Thanks,
Buddy

I awnser in the other topic already.... THIS is not recommend. Simply use a new Max for it.

If you like to try out you have to find a Math Calculation for that....
For example a Value like 23500 ft must be split in a 23 and a 500 Block..... So you have to find a Math logic to split it....
i Never try out.... Mab its possible.... Maby not.

Thanks for the reply and the help. Is there a way to do left/mid/right string functions on the value of $ ??

Not shure what you mean here....

Maby you mean a "splitting logic" .... NO that not exist.... BUT in one Side you already got it.....

If you for example have a value like "123456" and you show it on a 2 Diggit Display then it show "12" .... a 4 Diggit Display show "1234"
So the Numbers behind the existing Diggits are simply cut out.

Problem here is if you get below the Number Of diggits.... For Example in Altitude a Value like 12500 wil be shown on a 2 Diggit Display correct 12 ( The rest is Cut out)
BUT if you have a Altitude below 10.000 ft .... For example 8500 ft then the first 2 Diggits will show "85" now but you need "08" in that situation.

Again: With lots of IF Conditions this can be done maby.... But thats realy not useable....
I recommend to plan your project with More Max7219 Chips and individual Displays ( NOT use the 8 Diggid Premade Tubes for that)

My first attempt at COM / NAV panels was with combined displays:

COM1STBY1 display 1 digits ------ XX transformation ($ + 10000) / 1000
COM1STBY2 display2 digits X, XX ----- transformation $% 1000
NAV1ACT1 display 2 digits ----- XXX, transformation ($ + 10000) / 100
NAV1ACT2 display 3 digits XX ------ transformation $% 100.

It worked perfectly. Let's see if it can help ...

regards

Hello, Buddym ...

I think if you try like that, you'll make a mess ...
Why do not you try it with SPD in digits 1,2,3, digit 4 free, HDG digits 5,6,7, digit 8 free of display 1
ALT digits 1,2,3,4,5 of display 2?

You will use two displays, but it makes things easier.

My first attempt at COM / NAV panels was with combined displays:

COM1STBY1 display 1 digits ------ XX transformation ($ + 10000) / 1000
COM1STBY2 display2 digits X, XX ----- transformation $% 1000
NAV1ACT1 display 2 digits ----- XXX, transformation ($ + 10000) / 100
NAV1ACT2 display 3 digits XX ------ transformation $% 100.

It worked perfectly. Let's see if it can help ...

regards

WOW !!!

I´m sorry i not think ablut %Modulo% until now....
YES.... THAT can be the solution for that problem !

For the first part.....

Here we get lucky that in Mobiflight a Display NOT will show decimal Values.... For example a Value like 12345 / 1000 result in 12,345 BUT Mobiflight/Display will only see 12 and ignore the decimal ,345.
Additional we are lucky that Sebastian never implement the "AUTO ROUNDING" function in Mobiflight.
In the past he plan for it... Then for example a Value like 12789 divide through 1000 will result in 12,789 and Mobiflight then had see it as 13 (roundet) .
So summary YES !!! Thats a good idea for our current technical situation!
((And with a correct LEFT PADDING Logic we can also protect issues for the wrong position of Number problem !! ))


For the second Part......
Here MODULO% looks like the perfect solution ( again sorry i not think about )

Thank you for that Input.... I will use it in the future !

****
But last word....
Whatever this is now possible.... I Already recommend to use Single Displays instead of this trash 8 Diggit hardfixed 2x4 Blocks ..... And i already recommend to work with more Maxtubes if possible.... Complete Logic is much more easy and tidy (wire system and Device Names for example) when you work with policy.... "ONE Display for ONE Function with ONE MaxChip" .... BUT Thats only my personal opinion !

Yes, even though the expression engine docs don't mention modulo, my friend and i tried it anyway and it does work!

Thanks!

My first attempt at COM / NAV panels was with combined displays:

COM1STBY1 display 1 digits ------ XX transformation ($ + 10000) / 1000
COM1STBY2 display2 digits X, XX ----- transformation $% 1000
NAV1ACT1 display 2 digits ----- XXX, transformation ($ + 10000) / 100
NAV1ACT2 display 3 digits XX ------ transformation $% 100.

It worked perfectly. Let's see if it can help ...

regards

yes, thanks for the help. A friend had already come up with modulo for me and it works perfectly! thank you very much anyway though!

My first attempt at COM / NAV panels was with combined displays:

COM1STBY1 display 1 digits ------ XX transformation ($ + 10000) / 1000
COM1STBY2 display2 digits X, XX ----- transformation $% 1000
NAV1ACT1 display 2 digits ----- XXX, transformation ($ + 10000) / 100
NAV1ACT2 display 3 digits XX ------ transformation $% 100.

It worked perfectly. Let's see if it can help ...

regards

WOW !!!

I´m sorry i not think ablut %Modulo% until now....
YES.... THAT can be the solution for that problem !

For the first part.....

Here we get lucky that in Mobiflight a Display NOT will show decimal Values.... For example a Value like 12345 / 1000 result in 12,345 BUT Mobiflight/Display will only see 12 and ignore the decimal ,345.
Additional we are lucky that Sebastian never implement the "AUTO ROUNDING" function in Mobiflight.
In the past he plan for it... Then for example a Value like 12789 divide through 1000 will result in 12,789 and Mobiflight then had see it as 13 (roundet) .
So summary YES !!! Thats a good idea for our current technical situation!
((And with a correct LEFT PADDING Logic we can also protect issues for the wrong position of Number problem !! ))


For the second Part......
Here MODULO% looks like the perfect solution ( again sorry i not think about )

Thank you for that Input.... I will use it in the future !

****
But last word....
Whatever this is now possible.... I Already recommend to use Single Displays instead of this trash 8 Diggit hardfixed 2x4 Blocks ..... And i already recommend to work with more Maxtubes if possible.... Complete Logic is much more easy and tidy (wire system and Device Names for example) when you work with policy.... "ONE Display for ONE Function with ONE MaxChip" .... BUT Thats only my personal opinion !

Hello, Pizman82

That is also my opinion, but I had to go through the previous one to realize that it is easier to implement as you say.

Another thing: Is there any way to pass an EventId as a parameter in calculations?

Greetings.

Another thing: Is there any way to pass an EventId as a parameter in calculations?

Not shure what you mean with "pass" ....

1. Do you mean you like to execute a EventID in case of a readed indicator ??
For Example: You like to execute the Event "Gear UP" automaticly always when Readout of Altitude is bigger then 2000ft.
Thats NOT Possible..... Cause a INPUT (EventID in that case) can only execute after a phisical Input by the USER ... Like a Button Push or a Encoder Turn.
We experimental for that... But at the moment (and in the next future) THIS is not implemented.

2. Do you mean you like to use the EventID itself as a indicator (parameter) for a calculation.
For Example: You like to say in a transform IF Value of EventID xxxx is 1 THEN Do" A" ELSE Do "B" . (Like we make with "$" at the moment )
Thats also NOT Possible.... Not now and not in the future cause this is basicly not allowed from FSX/P3D.
A EventID have no own value... So We can´t use it for a calculation.
With EventID you only can SET something or use Mouseparameters.... But you can´t say $+1 simply cause $ not exist !

NOTE: Thats how i learnd it..... If i´m wrong please somebody correct me !

Hello, pizman82

I refer specifically to:

ADF FRACT DEC CARRY (66461)
ADF FRACT INC CARRY (66462)

If they could be used in any way, we could solve the difference in the funding between the physical encoders and those of the simulator to adjust the value presented by the ADF ...

Ah... That is what you mean here.....

I try to explane how i understand it....
My last comment is already correct i think.... WE are not be able to readout a value of a EventID (cause it simply not exist) ....
BUT the event ITSELF pretty shure got a value internal !!!
For example the event "Increase Altitude" pretty shure read the current altitude and say something simular like "$+xxx" BUt we can´t read it cause the event not have the value it just start a internal process in FSX/P3D .... these process is Hardcoded.... the Events are not made by Mobiflight... THIS events are set by Microsoft in a fixed kind over 20 years ago !

***
So... I not try out the "CARRY" commands till now , but i looking forward to do this on next "mobiflight Evening" maby middle of next week. THEN i can give you more information.
I prommise that this is verry easy maby.....
The normal INC command just add the specific Number by 1 without a overrun to next number.... Like 17,18,19, 10,11,12,and so on.
The "Carry INC" will "carry" the overrun to next number like 17,18,19,20,21,22 and so on.....
BUT I don´t know.... I Have to try out !

***
If Possible please make your own testings and report experience to prevent me of doing this.... If not i will report my results as soon as possible !

Hi, pizman!

I have noticed that all offsets with display output (COM, NAV, ...) have their own CARRY as offset.

If you run the simulator, you can see that CARRY is using all the diaplays ... But I do not know how they use it ... I can not find a way because I do not know enough about the simulator or the FSUIPC ... I'm sorry. But I continue testing.

Hi Again....

i Think i got time tomorow... ( I hope )

But basicly i not understand the problematic.....

Simply use the Carry event instead of the Standard Event..... And Check what happens if you turn the encoder....
EventID you still now.... Parameter is same like in all other standard events ( 0 if i rember right) .

Set it... Test it. And report result !

Hi Again....

Today i try out the Carry Events ! They work like every other EVENT ID Input.

Result: Its like i said in previous post !

For example Com 1 :

Code:

COM RADIO FRACT DEC CARRY 66434
COM RADIO FRACT DEC 65638
COM RADIO FRACT INC CARRY 66435
COM RADIO FRACT INC 65639

Here the Standard Events 65639 and 65638 are inc/dec the Devimal part of Com1 without "carry" the full numbers to the next position....
For Example 121.95 - 121.97 - 121.00 - 121.02 and so on.
If you use the "Carry" Events then the full numbers interact with the overrun of the decimal
For Example 121.95 - 121.97 - 122.00 - 122.02

I only test it on COM1.... But System should work simmular on COM1/2 NAV1/2 ADF1/2 and "XPDNR Complete "


EDIT: But let me say again....THIS is not usefull and not realistic i think.... Whatever Microsoft use it in Stock FSX.... Thats sucks !

For example you like to turn in a frequency of 121,10 .....
At first you turn the 121 with the Increase Whole encoder.... Then You use the second Encoder ( Dual shaft for example or by switching) to set the decimal part.
If your decimal is at the moment at xxx.85 and you turn it clockwise you go from .85 to .10 BUT with your logic now the Full number increase by 1 to 122.10
The already correct 121 change into 122 so..... And that we dont want.

If you make it in other direction and you turn FIRST the Decimal and then the WHOLE number then the problem is not exist... BUT Then it make absolutly no sence if you "carry" the number or if not cause you will set the WHOLE Number AFTER the Decimal !

Summary.... For "ME" that function is wrong.... whatever it is used in FSX !