UDP packet transmission for aviaCDU stops sometimes during CDU initialization

Hi,

I use the Q400 Pro version under P3D v5.1 latest HF. And I use the aviaCDU for the Q400 from aviaworx on a Samsung Galaxy Tab. I experience a problem, which is really hard to track down, as it does not pop up at every flight. I did a lot of experiments together with the developer to try to identify the root cause. The conversation could be found in that thread at the AVSIM forum:

https://avsim.com/forums/topic/585857-q400-remotecdu-startup-problems/

At some times, when I turn on the CDU via the avia CDU, the transmission from the server back to the browser on the tablet stops during the initialization phase of the CDU (self test). From that point in time, all my inputs are transmitted back to the CDU and the CDU is reacting correctly, but the display is not updating on the browser.

And around 10-20 minutes later, it continues to work correctly. And from that point in time until the end of the flight it always works. And of course there are flights, where it works from the beginning without any problem.

I sent the log file of aviaServer of my last flight, where I had this problem, to the developer. And he detected, that the UDP stream of the Q400, which he monitors, did stop. And obviously later starts again. He asked me to raise this here as a topic.

The Interface section of my INI file looks like this:

[INTERFACE]
; GENERAL SUPPORT OF THE INTERFACES
JOYSTICK_INTERFACE=1
ASN_INTERFACE=1
WXAR_INTERFACE=0
UDP_INTERFACE=1

; UDP 0 CONNECTOR FOR THE SHARED COCKPIT
[UDP_CONNECTOR_0]
UDP_ENABLED=0
SEND_RATE_DIVIDER=0; // 128 times per second
UDP_BROADCAST_ALLOWED=0
UDP_BROADCAST_MASK=0.0.0.0:49200
UDP_RECEIVE_ALLOWED=0
UDP_RECEIVE_MASK=0.0.0.0:49210
ICP_TX_FILTER=6152
ICP_RX_FILTER=6152

; UDP 1 CONNECTOR FOR THE SHARED COCKPIT OBSERVER LINK
[UDP_CONNECTOR_1]
UDP_ENABLED=0
SEND_RATE_DIVIDER=0; // 128 times per second
UDP_BROADCAST_ALLOWED=0
UDP_BROADCAST_MASK=0.0.0.0:0
UDP_RECEIVE_ALLOWED=0
UDP_RECEIVE_MASK=0.0.0.0:49200
ICP_TX_FILTER=6152
ICP_RX_FILTER=6152

; UDP 2 CONNECTOR FOR THE INSTRUCTOR STATION
[UDP_CONNECTOR_2]
UDP_ENABLED=1
SEND_RATE_DIVIDER=4; // 32 times per second
UDP_BROADCAST_ALLOWED=1
UDP_BROADCAST_MASK=192.168.1.255:49230
UDP_RECEIVE_ALLOWED=1
UDP_RECEIVE_MASK=0.0.0.0:49240

; UDP 3 CONNECTOR FOR THE 3RD PARTY
[UDP_CONNECTOR_3]
UDP_ENABLED=1
SEND_RATE_DIVIDER=8; // 16 times per second
UDP_BROADCAST_ALLOWED=1
UDP_BROADCAST_MASK=192.168.1.255:49250
UDP_RECEIVE_ALLOWED=1
UDP_RECEIVE_MASK=0.0.0.0:49260

192.168.1.x is my LAN. Both the sim PC and the tablet are in the same LAN segment. And the strange thing is, that at some flights it's working (so connectivity is ok) and sometimes the UDP stream stops, when the CDU is initializing (typically when the first or second test is running) and the stream returns later without any special action from my side. Restarting the aviaServer or the browser doesn't recover the situation, as the UDP packets are not transmitted. And the keystrokes are always transferred back and are triggering the correct function. And if transmission stops, it stops for both CDUs (L+R).

Please could you check, if there is some reason, that the UDP stream from the sim to the aviaServer in the PRO version might be blocked, when the CDU is initializing. I have checked network, firewalls, etc.

And as it does not happen every time, this is really hard to find. I will do my best to support you with tests.

Best regards
Reinhard

Comments

  • Hi Reinhard,

    I tried this device and never managed to have the trial version working (always a black screen). I tried on 2 different tablets and 3 telephones.

    I can say that Mark from Aviaworks has been very helpful and we exchanged 23 emails but finally I gave up as it could not work with my setup.

    It would be very nice if Majestic and Aviaworks could liaise to have this CDU working properly as it is a very interesting feature to have for the Q400.

    Kind regards,

    JP

  • Hi JP,

    It's definitely perfect for handling this plane, if it works. I use it also for the Aerosoft A320. One of the first things to configure is of course the INI file and the UDP interface configuration. Next is the firewall as well on the PC and on the tablet if you use one. And your network should allow UDP broadcast. If these things are enabled, it should work.

    The startup problem is a small glitch, which hopefully can be fixed. If we come here to a solution, you should give it again a trial.

    I have mounted my tablet onto my GoFlight rack, and I never have to use a mouse in my cockpit. That's really fine.

    Rgds

  • Gents,
    Thanks for the info. While doing some testing of the product before it was released I did not encounter any issues using a tablet (4th Gen iPad) or networked PC. I do have a Tab S that I use for work, so I'll see if I can get it from the office next week to see I I can replicate the issue.

    In the meantime, I'll get the Boss in on this to see if he may offer some insight.

    Cheers

  • Thank you Simeon,

    Much appreciated,

    JP

  • @aua668
    You could try running MJC84 System Panel at the same time. It also uses UDP interface from the Q400. Check the electrical page of the System Panel while your CDU does not update. See if the changes in the cockpit are reflected on the syspan electrics page. For example - switching on and off individual batteries

  • Hi Boss,

    Good to know. I will try your suggestion, at the next occurrence of this failure. The last flights have all been ok. That's the bad thing with failures, which only happen from time to time. They are hard to reproduce and therefore the nightmare for users and developers.

    Is the system panel also using UDP connector 3, which is used by 3rd party addons?

    Rgds
    Reinhard

  • Hi,

    One update for your information: I changed for testing purposes my broadcast IP to the localhost address 127.0.0.1 and I am not broadcasting by that into my LAN. Since that change I could not reproduce the error. There was one update of the AviaServer during this test period but also before this update I did not experience the problem. I will now switch back to broadcasting into my LAN to check, if the problem returns. As I plan to read values on other devices via the UDP broadcast, it's important, that this works also over the regular IP interface and not only to localhost.

    Rgds
    Reinhard

  • Hi,

    An update: I switched back from the broadcast mask 127.0.0.1 to the mask for my LAN (192.168.1.255) and the error did happen again. I had problems to recive packets with the AviaServer at the beginning of my flight, which did go away after around 20 minutes. At the same time I checked as proposed by you, if the SYSPAN was able to receive packets on another PC. And it worked perfectly. I also measured the stream with a network analyzer. While the stream for the SYSPAN was generated, the stream on the port for the AviaServer was not generated. So for me it's not the AviaServer not reacting, but the UDP interface not sending on the UDP interface 3. This fits to the observation of the developer of Aviserver, who analyzed the logfile. He told me, that nothing was sent during that phase. It's interesting, that later this starts and then continues to work until the end of the flight.

    Rgds
    Reinhard

  • Reinhard,
    Thanks for the update. We'll try to see if we can dig into this and identify the issue.

    Cheers

Sign In or Register to comment.