Recovery of RMI and Stand-by

The displays of the RMI and the STBY instruments of the MIP share the same screen of the upper EICAS. The gauges are drawn by ZHSI; the quality is pretty good. The only missing feature on the RMI was the orange flag when on VORs/ADFs when there is no signal but Duncan has been very kind to implement for me.

RMI and STBY were connected to a CPFlight card that is not produced anymore and for that reason it was not possible to conncet them to the MIP board and were unusable.
The card gets the inputs of the baro knob (button and encoder), the 5 buttons of the STDBY and the 2 knobs for selecting between ADFs and VORs. The card also has the LEDs for backlit of buttons and signs.
The idea to fix is to keep the card as it is because the components are drectly mounted on it and perfectly fits with the panel. I am pretty sure that if I buy a panel the measures will be different and it will not look nice once mounted in the frame.
`
These picture shows the front and rear view CPFlight panel with the STDBY-737 card once dismounted from the MIP.



With a multimeter I looked for the connections used by buttons, encoders, switches and when found I decided to cut the connection in the STDBY737 card and connect them directly to a LeoBodnar card. You can see in the following picture the soldering with the cable to connect to the LeoBodnar card.

I could not recover the rotaries to select between ADFs and VORs of the RMI. Probably my knowledge of electronic components is too limited.
All the other components work perfectly.
At the end I decided to use the + and - buttons of the STDBY to select ADFs/VORs. Not very realistic but it works and I do not need to change the light of the STBY gauge so I am not loosing anything.
XPlane see the LeoBodnar board as a joystick. It has been very easy to associate each push button and the rotary to the proper event with the XPlane menu of the joystick,
The LeoBdnar board need to be configured to recognize the knob but it has been very easy following the documentation and immediately recognized by XP.

I have not been able to light the LEDs  because could not really understand their connection in the CPF board. I will have to get back to them sooner or later as I suspect that it s only matter to find the proper connection to have them working. Ideally, I will connect the LEDs to a power supply so that they stay ON all the time but first I have to find how to do that!

In conclusion I recovered the panel and its full functionality with some trick. In particular the selection ADSs and VORs happens with the + and - buttons of the STDBY.
Backlight still pending.

Home cockpit software integration

The software setup consists of XPlane, Zibo 737, CPFlight midwest plugin, ZHSI and a rasperry Pi4.

I personally prefer XPlane over P3D and for sure do not want to spend the huge amount of money requested by ProSim that is not justified for non-professional use IMO. XP or P3D is a personal taste of course. I think that what XP gives out of the box is much better than what P3D offers; on top of that XP has a great number of tools and sceneries provided for free by passionate users while on P3D you have to pay for everything. 

In the past XP was a difficult environment for home cockpit builders but now the situation is very good and promise for improvements in the future. XP is easy to customize, upgrading does not require full reinstallation and most of HC tools are available for free.

The integration of the CPFlight hardware has been very easy thanks to the great midwest driver that supports the Zibo 737 natively. The driver is cheap and the support is very good; the installation is easy and intuitive. My radios, MIP and CDU worked immediately once connected.

CPFlight hardware  is, as I constantly repeat, very good even if a bit expansive. IMO the time saved using this hardware its look and feel and quality really pays off. During the integration I had few problems with power supply and finding the correct way to connect the components in daisy chain problems that have been solved with CPFlight support. In this respect that documentation is not good enough and should be improved a bit.

I add a 75 inch 4K Samsung TV for the main screen and connected the monitors on the MIP and the one of the CDU to my 980Ti graphic card. It has not been easy to find the proper configuration of the monitor cables as it depends on the graphic card. It supports up to 4 mnitors but no VGA socket while MIP monitors have VGA connectors. In the market exists converters from VGA to HDMI and DVI but not all of them work well. 

My NVidia card has only 4 Gb RAM; it runs with 4k resolution and all the other monitors but need 3jFPS to keep the frame rate under control.. This is very important while flying on VATSIM because it disconnects the sim if the frame rate drops below 20/second. The reason is that when the frame rate is below 20, XP slow the simulation down and other people on VATSIM sees big liners flying as slow as a Cessna does. Perfectly fine IMO to make the simulation more close to reality.

The TV fits perfectly in the wall of the sauna. I do not foresee to install monitors for lateral views but I admit it makes a big difference so I will probably review this decision in future. For such a big screen a resolution of 4K is mandatory so I had to trick a bit the configuration of XP to get a reasonable frame rate. Now I fly at 30 or more frames per second  and 3jFPS reduces the graphic details when the frame rate drops below 30.

To improve the frame rate I connected the upper and lower EICAS to Raspberry Pi4.

737 instrumentation is displayed in the MIP monitors with ZHSI bot the in the main computer and in the RPi4. A must for home cockpit builders. The CDU screen is managed by ZCDU. The content of the FMC can also by displayed in the monitor of the CDU with xPanels but it is a bit slow.

RPi4 supports 2 4K monitors and in my case they are used for the upper and lower EICAS and the stand-by instruments whose content is displayed by ZHSI. I am satisfied of the result but note that the refresh is a bit slow. For this reason I have delegated the RPi4 to the EICAS. The slowness is due to the default graphic driver of the RPi4: I know that there is a better driver but I was not able to let it work unless together with VLC. Now there are other linux distributions for Rpi4 like ubuntu and fedora core that could help.

It is a pity that Zibo does not allow to dis-anchor and move around the display of the instruments. ZHSI and ZCDU works well and they are very well supported. However ZHSI uses jfoenix java library that seems to be unsupported so it could be a critical tool in future.