Skip to main content

Replies sorted oldest to newest

Easy explanation if you understand the end to end process.

The problem with the app is- it doesn't stand up a stateful dedicated tunnel between the app and the WIU. The app spews out the network port the packets containing the commands, and you hope it makes it through the networking interface of the phone or tablet, hope it routes across the wireless network- and ends up at the IP of the WIU. Then, not only all that hoping it makes it, then the WIU converts it back to serial data, sends that to the TIU- the TIU then transmits to the engine and worse, the engine now must respond back to the TIU because DCS is 2 way communications. Then the TIU responds back to the serial interface, the WIU shoots that back out and you pray again, the app gets the response- all before a software timeout or error.

In some ways- be amazed it works at all.

Meanwhile, because the remote uses a dedicated serial data radio system between the TIU and remote, the back and forth doesn't require routing, it's not shear luck if it makes it, a much shorter path, less conversions, less chances for timeouts and errors.

Again, in the wireless app scenario- unlike some apps that purposely stand up an active tunnel connection and display and show this tunneled connection- this is a game of we hope it gets there- both directions.

One tip that does work is putting your device (tablet or phone) into airplane mode. This forces the network interface out of the wireless port rather than round robin out of potentially cellular data ports. I found this even to be valid on a tablet without any cellular modem.

Again, the net effect is lower latency and more direct routing of the app packets to the WIU.

It might sound crazy, but it does work and has made a difference for many folks.

Add Reply

Post
The DCS Forum is sponsored by
×
×
×
×
Link copied to your clipboard.
×
×