MobiFlight Community Support

Welcome to the forum for MobiFlight! Feel free to reach out to the community in case you have questions, issues or just want to share great ideas or details about your latest home cockpit project.

You like MobiFlight? Donate via PayPal and support the MobiFlight development. Thanks! 

05/03/2024 - This forum is read-only

The community support for MobiFlight has moved exclusively over to our Discord server. Register for free and enjoy more interactive functions like image and video upload, voice chat. More than 7,000 registered users around the world make it a great experience!

See you on our MobiFlight Community Discord server.

A HUGE Thank You to everyone who participated in the forum, especially obviously to Pizman and Stephan who did an outstanding job over so many years providing an incredible service to the MobiFlight community.

The forum is still providing a lot of good content, hence we keep this information accessible.

Go to page 1Go to page 012Go to page 2Go to page 2
Avatar
SergeyPe
Posts: 45
Hello everyone,
I'm facing an unexpected problem with a Multi Radio module configuration. It's a quick-and-dirty but fully fuctional test bed working with Prepar3DV4 simulator and currently being tested with B737 from PMDG (however it behaves identically with default planes). The config will then be used with a nice multi-radio module from Hispapanels.

The config file and a video of a problem are here: https://yadi.sk/d/liMVtNXn_eTB0w. As you can see, it includes COM1/2, NAV1/2, ADF1 and transponder with two encoders and a separate button emulating ELNA concentric encoder. The 7-segment LED's are two MAX7219 modules. The config is straightforward with two precondition FSUIPC offsets (66C0 and 66C1) where mode selection buttons data values (1 to 6) and encoder button status value (0 or 1) are stored. Encoder button is used to emulate the 3- and 4- element ADF and transponder adjustment knobs on B737.
When COM/ NAV section of the module is used everything is working perfectly. Also if the MobiFlight Connector is started with ADF or transponder both of them are working fine. However if I move from COM/NAV to ADF/transponder the active display is frozen and to make it work for ADF or transponder I need to change the values rotating the encoder. Also the unused symbols from the previous mode (the leading "1") are visible until the appropriate digit on the display is changed by rotating the encoders. So if changing from something like "1544.2" on ADF to transponder the leading "1" will stay there as this digit is not used on transponder display. What's interesting, the standby display is never freezing.
To ruIe out the hardware problem I've tried changing the display modules and display connection pins on Mega; no result. Any suggestions will be highly appreciated.
2019-08-21 16:54
Avatar
SergeyPe
Posts: 45
One small addition: setting ADF and XPNDR values to show on standby display and the status of encoder button on an active one didn't remove the problem- the ADF and XPNDR values are not showing after COM/NAV frequencies are displayed until the encoders are turned.
2019-08-21 19:17
Avatar
SergeyPe
Posts: 45
Yet another update: removing all the COM/NAV Input and Output configs and keeping only ADF and XPDR doesn't solve the problem- when switching between them the readouts are not updated (only after turning the encoder= changing the values).
2019-08-21 21:30
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
Hi

Wrote you a long detailed awnser but Browser kill it and its lost. Now i´m to tired (4 o Clock in the morning here)
I try to reply tomorow.
Please refresh Topic if i forget cause its "readed" Status now and i maby miss.
Good Luck !
2019-08-22 03:50
Avatar
SergeyPe
Posts: 45
Thanks, I'll be waiting!:)
2019-08-22 06:24
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
OK
Second try B)

First Problem is a wrong Diggit Setting :

Mobiflight Logic for ALL Outputs is always the same..... A Config Controll a Output aslong its activated..... if you Disable a Config via Precondition THEN it no longer controll this Output.... BUT That not means the Output get in OFF Status (Like a LED that simply get dark) .... The Output stay in the last setting ( that was send by the config before deactivation).
In your example i´m pretty sure you use 4 Diggits for the ADF but you use 5 Digits for the NAV1 ( On same Display) ..... The ONE Digit you not use twice is the most Left Diggit ( Where the Leading "1" is shown in the Nav Config.

Result: When your MultiPos Switch is turned then the Precondition "Stop" the Nav Config ..... And it start now the ADF Config.
In that situation the ADF Config will controll the 4 digits to the right .... But NOT the left diggit.... So This diggit will simply show the last information it was set before Nav Config was disabled.... And thats logical "1" .

To Solve this simply use 5 Digits also for the ADF Config ( The same 5 Digits as in other Config)
You can use the "Left Padding - Space" System to have a "clean" result !

*************
The Second Issue i think is a PMDG Problem. PMDG use for ADF and Transponder a internal Logic. So you can not use the EventID from PMDG here cause those change the StBY Value that is just a internal Variable we not be able to readout.

You can use Search Function and google to see some examples how you can rebuild this.

The problem is with only MF you have a improvisional solution. For a Real 1:1 System you pretty sure need to write a little Lua Script here.
Good Luck !
2019-08-22 19:58
Avatar
SergeyPe
Posts: 45
Hi,
Thanks a lot! Actually the first issue is exactly what I suspected- that the config switched off doesn't "blank" the unused digit. The only issue with the transponder is that the "Left padding- Space" option will blank the leftmost digit (or digits) if it's (or they are) zero- but I'll play a bit with the workaround.
As for the second one- I think it's not a PMDG, but rather a FSUIPC problem, as I'm using Peter Dawson's offsets from FSUIPC documentation both for ADF and XPDR; PMDG doesn't provide secial offsets for these variables. Which means that the situation is exactly the same with all the default planes- I've checked it. It looks like for some reason these variables do not "initialize" the readout as the other variables do immediately after the config is switched on- only when the values start changing. It also means that even if I force a "blank" for the leading digit of a transponder, the "1" from COM/NAV readouts will stay there until I start changing the XPDR code. It's clearly not a problem if ADF and XPDR use separate displays, but on a combined display it is.
Anyway thanks for the info; and your project is absolutely amazing- please keep up a great work!
2019-08-22 20:23
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
Please Confirm you use UptoDate Version 7.5.3 (Update 2 weeks ago)

This "Bug" is a problem we observe in the Past. That time this was not reproduceable on every System. ( For example Sebastian himself NOT be able to reproduce)
After 7.5.2 and also 7.5.3 the problem was gone also on my testing board ( before 7.5.1 i could reproduce it).

Basicly we find out there was 2 Problems ( One is STILL existing) .

The first occures in Errors we could never find the reason ( as i said it was also solved with 7.5.2 / 7.5.3 in my system)
The second is a problem if you use multiple configs on a Display and also Multiple Diggit Settings.

So its recommend that ALL Configs that use a Display "shared" use ALWAYS the Same Diggits.

To explane this......
If your Nav Config get disabled ( but the "1" is still standing) then it could happen that Mobiflight write also the other 4 Diggits for one Loop to the Display.
So your initial call of ADF Config will be overwritten by the (basicly) not longer active Nav Config temporary..... Then only a Change of Value occure in a new "update" of the Display.
If i understand correct ( and my testings confirm that) a use of exaclty same Digit setting simply solve this problem.

Please try out !
Also check if you have maby another config ( Like Blank in case of battery switch ) that also controll those diggits in a special precondition.
Thats the same Problem.... If you blank the whole 8 Digits by this config.... But your Nav Config use only 5 diggits this occure in the same issue.

Report Experience. If problem is not solved completly please send my your MCC File ( If possible only including the problematic part or with a short note "where" the problem is)
Email: pizman@freenet.de
Good Luck !
2019-08-22 21:29
Avatar
SergeyPe
Posts: 45
1. Yes, I'm using the latest 7.5.3.
2. My .mcc file is in the folder that I've provided a link to in my first post- the video and pictures are there as well. Are you able to access it? It's a Russian cloud storage and I'm not sure if there are any issues in accessing it from Germany. I'll also send it (a simplified version with, say, COM1, ADF and XPDR) to your mail address if your suggestion about using exactly the same number of digits in a config doesn't work.
3. There are no "blanking" configs and anyway the NAV/COM configs are OK.
So thanks again, the instructions are clear- I'll go experimenting))).
2019-08-22 21:53
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
Thanks for fast reply.
Must work on weekend.... But pretty sure find a hour in the night. Will Ckeck it and report.
Please also report if you find a solution meanwhile.
Good Luck !
2019-08-22 22:29
Avatar
SergeyPe
Posts: 45
OK, you were absolutely right. Adding a fifth leading digit to transponder makes switching between it and COM/NAV absolutely smooth and correct. So if any digit used in the previous config is not used in a current one, then MobiFlight doesn't refresh the whole display before the values are changed. As I said, the issue is that I cannot use "Left padding- Space" option as the "real" XPNDR leading zeroes will not show. I wonder if there is a Compare or a Precondition way to have an additional display config that would blank just this extra fifth zero without influencing the other digits, but also using the same 5 digits on a display...
As for ADF- it's more tricky, as I'm using the advice of one of the forum members (he made a C172 radio stack); there are two configs for the same precondition (mode button) reading different offsets- the inner three digits and the outer two separately. They are deliberately using only these display digits each (3 and 2) to be projected onto the same display simultaneously, so your suggestion won't work in this case.
I'm sending a COM1/ ADF/ XPDR part of the config to your mail address- for sure you have way better understanding of MobiFlight internal logic to consider any possible workarounds...
Thanks in advance.
[Last edited by SergeyPe, 2019-08-22 22:49]
2019-08-22 22:36
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
I realy need to test this.
Will do next possible spot.

About the Left Padding.

For ADF this should be no Problem i think..... I know this "strange" System from the other user cause i designed it myself that time.
If he use "my" logic then Offset 0284 2 Byte BCD is shown in the middle part ( A ) and Offset 0286 2 Byte BCD is shown Left and Right part ( B ) like BAAA.B
The second Offset pretty sure use Transform or Compare " IF Value bigger as >100 THEN $-90 ELSE $" .... this result in a Value 00-19 .
And here ( In THAT second Config) a Left Padding Space should exactly do what it should do.


Your right. This Idea sounds fine with Frequencys but sure.... In a transponder this is problematic cause a Code like 1234 is working but a code like 0123 would resuilt in 123 in case this Zero also get terminated ( Whatever we need it)

Solution:
In Case the other user and nobody else report a problem i think the key is using the same diggits in all situation. But it sounds like its no Problem if Diggits controlled via multiple configs in ONE Situation.
Situation 1: Config A use 5 Diggits like AAAAA .... Config B use 4 Diggits like _BBBB .... This occure in a Error.
Situation 2 Config A use 5 Diggits like AAAAA .... Config B use 4 Diggits and a additional Config C use 1 Diggit like CBBBB

If my idea is correct then system work also in Situation 2.... Cause there is Config A Active OR Config B and Config C together.
So here we also got 5 (the same) 5 Diggits active in both precondition situations. (Whatever they get controlled now by 2 configs simmular)

To build this.... Make another Config that use only the LEFT Diggit single.... Offset is not important .... use 0000 e.g.
Make Compare..... If Value = 1 THEN "Space" ELSE "Space" ( Space means 1 time Space button). So this config simply Blank that Diggit .
Finaly use same Precondtion like in the XPDR Config cause this should work only in this mode.
And get sure you reset the XPDR Config to old settings with 4 Digits only and no Left Padding.


I Hope this work already. Please report again experience. If all is not help i will check it myself !
Good Luck !
2019-08-23 01:38
Avatar
SergeyPe
Posts: 45
Thanks; I've already tried exactly this solution before with XPDR. Unfortunately it doesn't work- otherwise switching between ADF and COM/NAV would be working fine as in its two configs/ one situation all five digits are used. No, it's behaving differently- it's any single config in the situation that matters, not the whole situation. To get more details I've tried changing COM1 display to use the 3 inner digits- then you can switch between COM1 and "main" 3 digits of ADF. Then changing COM1 to use the 2 outer digits works with ADF outer digits. Using all 5 COM digits blocks the display change to/ from ADF as I described. So it's a single config-to-config match that matters when changing situations.
The same with XPDR- as none of the two new configs matches the number of digits exactly (1 and 4 agains 5) neither a blank nor the XPDR values are showing.
It looks like you need to test it yourself, although I would be surprised if you get different results.
2019-08-23 09:41
Avatar
pizman82
Moderator
From: ETSI, Germany
Posts: 6010
Supporter
Come still from work now..... Must start verry early tomorow..... so This night is not possible :sleep:

But i have another simple idea to solve this improvisional before we can test this perfectly.....

The follow logic should work for the XPDR .....

Read the XPDR ( That Result in a 4 Diggit Value like "1234" )
In Compare Tab your say IF Value = 1 ( Not important what you use here we just need to open the compare )
In THEN Filed you say ' '+$ ( The ' Symbol is above the # sign on german keyboard ..... Use ' SPACE '+$ So between the TWO '' there must be ONE Space.
in ELSE Field you sue the SAME entry.... ' '+$
Result: Mobiflight write a Space and behind it write the Value of "$" that represent XPDR . This should solve the first Problem

For ADF its more difficult. To Solve this we need to build maby the SAME Situation.....
In ADF there is ONE Config on Digit 1 and 5 and a OTHER Config on digit 234 .
Maby its possible to build this also for COM..... So Config 1 show 1_ _ _ x and Config 2 show _yyy_
Config 2 is no problem..... Simply read the Com Offset and use just 3 Digits instead of 5.... It should now show just the 3 needed Characters.
For Config 1 its more advanced..... We need a MODULO to make "1234" into "4" and instead a +10 to build the leading 1
Try tansform "$%10+10" .... If i´m right then a 12345 (Value 2345 should result after Modulo in 5 and after +10 its "15"

Not try out but technical it shpould work.....
And if theory is correct then problem also should be gone cause in BOTH Situations a Config Controll Digit 1,5 or 234 withaout a mixing !

********************
Please try out if you find time.... BUT finaly we must check this to maby rebuild the logic internal. THIS is a bad situation and should be controlled more easy in the future,
Good Luck !
2019-08-24 00:09
Avatar
SergeyPe
Posts: 45
Was quite busy for some days, so it was just recently that I was able to try your suggestion. Unfortunately it didn't work. Of course switching between COM and XPDR is OK, as both configs now use the same digits. Also the three lower digits are OK. However when the leading digit is set to zero, MobiFlight stops cosidering it a value and puts a "space" there, while the leftmost digit shows zero, as the left padding zero is switched on. The same happens if the next digit is set to zero- the "space" moves right and another zero is at the left.
Haven't tried ADF yet; maybe tomorrow...
2019-08-27 20:09
Go to page 1Go to page 012Go to page 2Go to page 2