aua668

Hi, The following helped me to avoid the freeze during the last flights: If I power up CDU 1, I wait until the initialization routine of the CDU has finished. Then I switch to the CDU 2. Power up and wait again before switching back to CDU 1. In the flights before I pressed the ON button and switched to CDU 2 for doing the same. Since I wait for the init routine to run before switching it didn't freeze. Rgds Reinhard

Hi, I am using it only on the Android tablet with Chrome at the moment. Will check, if this happens on a PC too. Rgds Reinhard

Hi, Since some weeks (I can't tell the exact date when it started) I have a small problem with the aviaCDU for the Majestic Q400. I use P3D v5 with the latest HF under WIN 10. I display the CDU on an Android tablet with Chrome as the browser. The error is reproducable in every flight. During flight preparation I first turn on the CDU on the captain side, then I switch to the FO CDU by clicking on the screw on the left top corner. I turn on the FO CDU and then I switch back by to the captain side CDU clicking on the screw again. And that's the moment, where the browser window freezes. Of course the CDUs in the simulator are still working. The solution to solve the problem is easy: I just close the browser and restart it again. From that point in time I can switch between the two instances without problems without any freeze. It's only at the first switching back to the primary CDU. I also have the same behaviour with the CDU of the Aerosoft A320 Professional. Switching back to the primary CDU the first time and the application freezes in the browser. Of course this might have several reasons: A Windows update, an Android update, a Chrome update, etc. Luckily there is an easy fix to solve the problem. So I can live with it. But maybe you have other reports or any idea, what could be the reason. Rgds Reinhard

Hi, Try these things: https://www.prepar3d.com/forum/viewtopic.php?t=131642 Disabling Nvidia In-Game Overlay and Vsync helped at least in the mentioned case. Maybe also a solution for you. Rgds Reinhard

Hi, I had a similar behaviour as soon as I injected Ai planes with vPilot. My system, which ran since many months smooth and stable, dropped down to the single FPS range. The solution was hard to find: an windows update forced the audio device in P3D back to the standard window audio device. I set this value back in P3D to the audio device I use and my frames with AI planes got back. So check your audio device in P3D and set it explicitely to the device you want to use - not to Windos standard. Rgds Reinhard

Everything is better than the ugly brown haze produced by volumetric fog. I would like to have blue fog instead 🙂 Rgds Reinhard

Hi, That's he COVID19 virus which has infected the lights 😉 Do you user HDR? In that case try to reduce the Bloom factor. Rgds Reinhard

Hi, In the download section you also will find older versions too. Check for this text and click for expand. Rgds Reinhard

Hi, https://www.avsim.com/forums/topic/590049-adaptivesimgroupenable“-under-sim/ Rgds Reinhard

Hi, Hifisim is investigating already: https://forums.hifisimtech.com/threads/8005-and-volfog.14122/#post-63037 Rgds Reinhard

Hi, Aerosoft provides in the documntation folder for the A3xx a document with the title "Vol7-Thrust Lever Setup.pdf". Have you followed these instructions especially the one on page 3, where it is described, what you have to do in case you want to assign two throttle axis. Rgds Reinhard

Hi, I have it working in 5.2. Rgds Reinhard

Hi, I fly the Q400 in 5.2 without problems. I have the Pro version. Rgds Reinhard

Hi, I also did experience that - but very seldom and at different locations. I had no chance to reproduce it constantly. So hard to track down. Rgds Reinhard

Yesterday there was the final tennis match in Wimbledon and the final match of the European Soccer Championship - so no wonder, that nobody tested 😀 Rgds Reinhard

Hi, You can save a scenario with the correct window position and use this as the default startup scenario. By that you don't have to move any window (which is indeed sometimes a problem with P3D). Especially windows overlapping two monitors are sometimes a problem. I have a three monitor setup (1x 3840x1080 for the outside view and 2x 1920x1080 touch screens for the panels. I build dynamically the startup scenarion with some parameters (airport, plane, daytime,...) in a script and then just have to startup P3D and all windows are on the correct position. Even the popup panels can be positioned by this method. A commercial product is Simstarter NG, which might be a good option for you. Rgds Reinhard

The solution is also in the mentioned thread some postings below. https://www.prepar3d.com/forum/viewtopic.php?p=242281#p242281 Rgds Reinhard

Hi, Definitely an improvement. Thanks! Reinhard

Hi Mark, I had changed the broadcast address back from 127.0.0.1 to 192.168.1.255 to send the UDP packets to my LAN. And the phenomenon returned back. In the beginning the RemoteCDU did not work and suddenly after some time it started and did work until the end of the flight without any problem. During the first phase, where it was not working I did another test, which Majestic advised me to do: I checked, if the Q400 system control panel was working on a remote PC. The SCP uses also the UDP broadcast stream to get the information and I configured there on a different port the same broadcast mask. And it worked fine without any problem. So UDP stream from Majestic and my network seem to be ok. And if I only broadcast to the localhost address 127.0.0.1 it's also ok for AviaServer. So maybe you could check, if there is a difference receiving the packets via localhost IP or the IP address of the server machine. I have saved the Logfile. I sent you a PN, where you can download it. Rgds Reinhard

Hi Mark, I have posted my problem at the Majestic forum. I got some hints, how to test, if UDP is working, if the error occurs. The last flights have been without problems and therefore I could not debug. One question: Is it relevant for your application, if it receives the UDP broadcast via the localhost interface (127.0.0.1) or via the LAN IP of the system? Normally this should be no factor but in your configuration sample I see, that you use 127.0.0.1. I had configured the broadcast mask of my local LAN segment, as I plan to read the UDP stream also with some hardware of my cockpit in future. At the moment I have switched back to localhost and since then I was not able to get the error. It obviously does work in both configurations, as I have worked with the CDU in both configurations - but maybe there are minor differences showing such side effects. Just an idea... Rgds Reinhard

Hi, I did try to close and restart the server. This didn't help. I will send you the log file, if this occurs the next time. Rgds Reinhard

Hi, I was too optimistic: I had now several flights, where the connection at startup doesn't work again. Suddenly (let's say about 20 Minutes after first use) the communication gets in sync and is working until the end of the flight without any problem. I tried several variants: starting aviaServer before P3D, starting it via FSUIPC RunIf command, starting it after P3D has completely started - it makes no difference. Also a restart of the browser on my Android tablet and eslecting different browsers or using a second PC to access the CDU doesn't help. As it is a problem, which I can't reproduce permanently, it's hard to track down. Rgds Reinhard

Hi, The last update of the server app might have eliminated the problem. At the moment I have not experienced it again. I will let you know, if it should happen again. Thanks for taking care. Btw: An implementation for the RXP GTN 750 would be a great addition to your product... Rgds Reinhard

Hi, I use the remoteCDU for the Q400 (Pro version, P3Dv5). At some flights I have a strange problem. If I power up the plane and the FMC, I see the startup screen appearing ("UNS" at the top) but then the display is not further updating, although in the simulator it's running normally continuing. And this is the same for both CDUs (left and right). All the keys on the FMC are working and produce the correct reactions on the FMC - but the display is not further updating. I tried in that state to restart the server, restart the browser on the Samsung Tab (with Chrome as the browser), choose different browsers, access the server from another laptop, and a lot more things. Nothing changes. The keys are working but the display is frozen at the startup screen. If I continue with my procedures in the simulator to come from the cold & dark state to ready for flight, suddenly after 5-10 minutes everything works normally on the remoteCDU and this stays until the end of the flight stable. I can then operate the FMC as intended and the display is always updated. So it looks for me, that suddenly the remoteCDU catches the output stream produced by the server without any special action from my side. And this doesn't happen at every flight (sometimes it works from the beginning) but quite often it does nort. I know, that this is very difficult to reproduce. Is there any debugging option, which I can enable, to find out, why the display is not updated in the beginning? Rgds Reinhard

Hi, First of all: No questions in this forum. To generate out of the question a trick: Check FSUIPC and these controls: 66508 PANEL_ID_CLOSE 66507 PANEL_ID_OPEN 66506 PANEL_ID_TOGGLE Calling these controls via FSUIPC with the panel id from the panel.cfg file as a parameter will open the pop-up 2D panel. Rgds Reinhard