DCS Premium App "Read" Delay

Adrian,

Are the WIUs in MTH or Home mode?

If in Home mode, your club's WiFi network could be contributing to the problem. I suggest that you configure one WIU in MTH mode and then the others in Home mode, with the first WIU acting as the router.

Then, see if the timeouts are as prevalent.

Hey, I just tried the other mode (MTH) mode as suggested. The delay spread is pretty-much identical when I use one WIU's internal access point as when I had all WIUs 5 on the external router.  Read is still fast with 1 WIU/TIU, getting slower with 2,3 and timeouts start appearing at 4 and become common at 5 WIU/TIUs. It appears to be similar statistics to the above though I have not plotted them.

 We don't have anything on our network except the 5 WIUs (no one streaming videos or anything) and my smartphone that runs the app. Network wise things look reliable... both network configuration (ext router) and (WIU-as-access point) look good in terms of network quality. Here's just the ICMP report (they both look identical).

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.2: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.2: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.2: bytes=32 time=<1ms TTL=64

Pinging 192.168.1.3 with 32 bytes of data:
Reply from 192.168.1.3: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.3: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.3: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.3: bytes=32 time=<1ms TTL=64

Pinging 192.168.1.4 with 32 bytes of data:
Reply from 192.168.1.4: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.4: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.4: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.4: bytes=32 time=<1ms TTL=64

Pinging 192.168.1.5 with 32 bytes of data:
Reply from 192.168.1.5: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=<1ms TTL=64

Pinging 192.168.1.6 with 32 bytes of data:
Reply from 192.168.1.6: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.6: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.6: bytes=32 time=<1ms TTL=64
Reply from 192.168.1.6: bytes=32 time=<1ms TTL=64

Adrian,

I suggest that you use the app's buil-in trouble reporting to file a problem report:

More.../App Settings/App Support/DCS App Contact Report.

Hey Barry, I know that you and the beta testers did a phenomenal job prior to the release of the app. Were there any beta testers who had more than one or two TIU's while conducting their tests? Did MTH conduct any tests for multiple TIU's?

I tested pretty extensively with 3 TIUs in Super TIU Mode. I will admit that I turned up a number of bugs in Super TIU Mode on the iOS platform, some of which have not yet been corrected.

In some early betas I did receive timeouts. However, they rarely occurred in the final beta or production releases, unless I was connected in Home mode, where I suspect that the train room's weakish network signal might have played a part.

I had 2 TIUs and 2 WIUs, android, and did not experience that problem.

Barry Broskowitz posted:

I tested pretty extensively with 3 TIUs in Super TIU Mode. I will admit that I turned up a number of bugs in Super TIU Mode on the iOS platform, some of which have not yet been corrected.

In some early betas I did receive timeouts. However, they rarely occurred in the final beta or production releases, unless I was connected in Home mode, where I suspect that the train room's weakish network signal might have played a part.

Barry, Adrian,

As additional information to the topic, we had our first "open house/doors" at our club yesterday since we installed WIUs.

Our exact setup is : 4xWIU/TIU, Home-Mode via WiFi-Router, TIU DCS 6.0, WIU F/W v1.1,  Premium Android/IOS App V2.0.0, Remote Handhelds and Android/IOS Apps in Super-TIU mode for all 4xWIU/TIU.

We did experience errors with all IOS devices yesterday (iPhones and iPads at IOS 10.3.3), but none (to my knowledge) with the Android devices.  As it was a busy day with visitors, we did not have a chance to troubleshoot the situation, nor take details of the errors.

Here is one scenario that occurred consistently:  The function "Add Engine"+"Add MTH Engine" was working on Android devices (slower than usual, apparently), but it was failing consistently on IOS devices (iPhones and iPads) with an error message.  We had about 4 to 5 engines on the layout while doing this scenario, and about the same number of users with either IOS, Android or DCS Remote Handheld devices being used simultaneously.

Something seems to be related to a difference between Android and IOS.

Daniel

Daniel,

Something seems to be related to a difference between Android and IOS.

There are several differences between the iOS and Android versions of the app. Some differences are how certain features are implemented and some differences are in the bugs each has.  

Barry, was there any testing with multiple users? It seems that there are also conflicts when more than one person is trying to execute commands.

Jeff in LA

Jeff,

I had 2 or 3 iOS devices going simultaneously without any issues at all.

The Refresh command can take a long time, particularly if there are a lot of DCS engines in the app.

However, even with 90+ DCS engines in the app, the refresh time was significantly shorter than a Read using a remote with the same number of engines.

Thanks Barry. You are a welcome source of knowledgeable information.

Jeff

Interesting update....

I hard-wired our 5 TIU setup with Ethernet cable (to remove the wireless from the equation) into a 100Mbps router. Now it reads lightening fast, until you put more than one engine onto the layout. Then it reads slow again. My app only has the 3 engines I was testing out added. It's always the same, very fast with no engine or 1 engine, and then slow with more than one. It definitely seems worse if the different engines are on different TIU sections. I can take statistics again if anyone is interested.

I've had some thoughts earlier..... When the engines aren't there the ASCII string back to the app is really short, like about 50 characters. With one engine it's about 200, and with 2 engines it's about double (which makes sense).  So I was thinking that maybe like multiple TIUs are replying with long strings at the same time so there's collision and they they all keep retrying and continuing to collide until eventually everything is received by statistics. 

The Ethernet setup seems to rule this out... since with each Ethernet cable going from each WIU to a different port on the router there will be no traffic collisions (the 802.3 router will buffer the downstream traffic from each port received in parallel, and pass it to the destination host sequentially).

I want to keep looking into this.... I still have lots of open questions though:

1. Has anyone explored the app connection yet (Like what kind of connection the app and the WIU are making)? I was hoping it would be like a simple TCP or UDP connection so I could just open a telnet or something and talk ASCII to the TIU (since San Diego Mark already has the underlying MTH ASCII protocol)... but it seems more complicated. I did a TCP/UDP port scan on the WIU and nothing seems open. Also I tried pcap but nothing *train instruction* related seemed to be going by for UDP/TCP. More investigation is needed here.

2. How does the app know which IP addresses are WIUs and which aren't? I don't think it broadcasts since I put my PC on the same network as the app and WIU and it didn't receive any packets from either the app or WIU except a discovery packet/DHCP stuff when the WIU was turned on.

Will keep working on it between space missions....

~Adrian

I can comment on the packets between the Remote and TIU. This might be useful when looking at the WIU comm.

Case 1: no engines on track (total time about 80 seconds)

• Remote displays "Looking for Engine..."
• Remote sends I0 command (8 ASCII bytes)
• TIU responds with 19 ASCII bytes - a 99 bit bit-mapping showing which engines numbers are on the track. In this case, the bit mapping is all zero.
• Comm port goes quiet for 75 seconds, "Looking for Engine..." continues to display on Remote
• Remote displays "No Engine to Add"

Case 2: Add engine on track but not in remote (total time about 3-4 seconds)

• Remote displays "Looking for Engine..."
• Remote sends I0 command (8 ASCII bytes)
• TIU responds with 19 ASCII bytes - a 99 bit bit-mapping showing which engines numbers are on the track. In this case, one bit is '1' indicating the engine number.
• Remote sends IXX command (XX is the found engine number) 9 ASCII bytes
• TIU responds with 86 bytes (includes engine name and soft keys)
• above 2 steps are repeated 2 more times.
• Remote shows the added engine.

Case 3: Add engine on track and already in remote (total time about 60 seconds)

• Remote displays "Looking for Engine..."
• Remote sends I0 command (8 ASCII bytes)
• TIU responds with 19 ASCII bytes - a 99 bit bit-mapping showing which engines numbers are on the track. In this case, one bit is '1' indicating the engine number.
• Remote sends IXX command (XX is the found engine number) 9 ASCII bytes
• TIU responds with 86 bytes (includes engine name and soft keys)
• above 2 steps are repeated 2 more times.
• Comm port goes quiet for 50 seconds, "Looking for Engine..." continues to display on Remote. During this time, a couple of garbled packets went over the radio - this consistently was reproducible over several runs of this test.
• then messages "Out of RF Range" and "Engine in Remote" (it was)

I can see that even with the Remote, adding a new engine is fairly fast. Adding with no engine or adding an engine that is already in the remote is much slower.

I've only tried a few tests with multiple TIU but I can see cases where a TIU with no engines will retry up to 10 times before going on to the next TIU. With multiple TIU, adding an engine could be very slow.

If its useful, I can assemble a test layout with 3 TIU and run some more tests.

SanDiegoMark posted:

I can comment on the packets between the Remote and TIU. This might be useful when looking at the WIU comm.

Case 1: no engines on track (total time about 80 seconds)

• Remote displays "Looking for Engine..."
• Remote sends I0 command (8 ASCII bytes)
• TIU responds with 19 ASCII bytes - a 99 bit bit-mapping showing which engines numbers are on the track. In this case, the bit mapping is all zero.
• Comm port goes quiet for 75 seconds, "Looking for Engine..." continues to display on Remote
• Remote displays "No Engine to Add"

 

Case 2: Add engine on track but not in remote (total time about 3-4 seconds)

 

• Remote displays "Looking for Engine..."
• Remote sends I0 command (8 ASCII bytes)
• TIU responds with 19 ASCII bytes - a 99 bit bit-mapping showing which engines numbers are on the track. In this case, one bit is '1' indicating the engine number.
• Remote sends IXX command (XX is the found engine number) 9 ASCII bytes
• TIU responds with 86 bytes (includes engine name and soft keys)
• above 2 steps are repeated 2 more times.
• Remote shows the added engine.

 

Case 3: Add engine on track and already in remote (total time about 60 seconds)

 

• Remote displays "Looking for Engine..."
• Remote sends I0 command (8 ASCII bytes)
• TIU responds with 19 ASCII bytes - a 99 bit bit-mapping showing which engines numbers are on the track. In this case, one bit is '1' indicating the engine number.
• Remote sends IXX command (XX is the found engine number) 9 ASCII bytes
• TIU responds with 86 bytes (includes engine name and soft keys)
• above 2 steps are repeated 2 more times.
• Comm port goes quiet for 50 seconds, "Looking for Engine..." continues to display on Remote. During this time, a couple of garbled packets went over the radio - this consistently was reproducible over several runs of this test.
• then messages "Out of RF Range" and "Engine in Remote" (it was)

 

I can see that even with the Remote, adding a new engine is fairly fast. Adding with no engine or adding an engine that is already in the remote is much slower.

I've only tried a few tests with multiple TIU but I can see cases where a TIU with no engines will retry up to 10 times before going on to the next TIU. With multiple TIU, adding an engine could be very slow.

If its useful, I can assemble a test layout with 3 TIU and run some more tests.

Hi Mark,

More tests today...

First I have to say I'm not clear on yet is what the "read" function is really doing on the app. Anytime you put the phone in your pocket or take a phone call you need to "read" (the little circle arrow up in the corner) in order to regain control of your trains. If you try to send the trains commands after the phone has sat idle for a few min, it doesn't work until you run the "read" command again.  I'm fairly sure it's a different function than adding an engine because the ASCII exchange is always short and identical when you monitor the TIU-WIU communications.

The part that's so mysterious to me is the timing and delay:

We have a 5 TIU system, and if you clip onto the RS232-WIU connection of any of the 5 TIU-WIU interfaces and watch the ASCII exchange when you read it, the discussion looks exactly like this at every TIU:

00:00:02.125 [from APP]: 78 0D 0A 49 30 0D 0A

00:00:02.156 [from TIU]: 78 30 30 0D 0A 2D 3E 49 30 3A 43 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 32 2C 30 38 20 6F 6B 61 79 0D 0A 2D 3E

This ASCII reply comes in about 0.2 seconds or less - from the time you push the button until the time you see the exchange at the TIU-WIU interface (regardless of which TIU 1-5 you are monitoring). However the app still says "reading" and waits for a long long time (60-80 seconds) even though the exchanges are all complete after the first 0.2 seconds or so. If only 1 TIU is on (and the 4 others are off)  the read time is much quicker, only 1-2 seconds, however the length and time of the ASCII exchange seems about the same.

At this point the only suspicion I have is that maybe when all the strings (TIU1-5) arrive at the app at nearly the same time,  some additional software delay is needed for parsing to sort out what string came from what TIU or something similar.

Thanks for your input! Much appreciated as always

~Adrian

The commands used for "Add MTH Engine" and "Read" are the same ones.  Notice that in my case 1 and case 3, there are long delays after all commands are complete before the Remote finally acknowledges the engine.

You are seeing the same commands over the RS232 and I see over the radio just in a slightly different format.

00:00:02.125 [from APP]: 78 0D 0A 49 30 0D 0A

is two commands:

• the "x" command ("78" is ASCII 'x') followed by a CR/LF
• the "I0" Command ("49" "30" are ASCII "I0") followed by a CR/LF

00:00:02.156 [from TIU]: 78 30 30 0D 0A 2D 3E 49 30 3A 43 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 32 2C 30 38 20 6F 6B 61 79 0D 0A 2D 3E

is two responses:

• response to the 'x' command - the number of AIU attached - "30" or 0/none followed by CR/LF
• response to the 'I0' command - bit mapped 99 bit string that indicates which of the 99 engines are present in the TIU.

 2D 3E 49 30 3A 43 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 32 2C 30 38 20 6F 6B 61 79 0D 0A 2D 3E
  -  >  I  0  :  C  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  2  ,  0  8     o  k  a  y CR LF  -  >

I think I counted my bits correctly to say this indicates engines #3 and #9 in the TIU.

After determining which engines are in the TIU, the Remote sends "Innn" commands to the TIU, where "nnn" is the engine number from "001" to "099". The response to this command is the long 86 byte return which includes the engine name and softkeys available.

Here is an example of the TIU to WIU comm. Its all ASCII.

    TIU V5.00: MTH Electric Trains, copyright(c) 2002, patent pending
    TIU board address: 00
    AIUs connected: 1
    ->m4PC connection not available
    ->H5 80918028 okay
    ->H6F02EA5F3 okay
    ->y13 okay
    ->u4 okay

    ->X0 okay
    ->IOIO:40,00,00,00,00,00,00,00,00,00,00,00,10 okay
    ->y5 okay
    ->m4 okay
    ->s0000 okay
    ->v0000 okay
    ->aa0 okay
    ->Q100 okay

SanDiegoMark posted:

The commands used for "Add MTH Engine" and "Read" are the same ones.  Notice that in my case 1 and case 3, there are long delays after all commands are complete before the Remote finally acknowledges the engine.

You are seeing the same commands over the RS232 and I see over the radio just in a slightly different format.

00:00:02.125 [from APP]: 78 0D 0A 49 30 0D 0A

is two commands:

• the "x" command ("78" is ASCII 'x') followed by a CR/LF
• the "I0" Command ("49" "30" are ASCII "I0") followed by a CR/LF

 

00:00:02.156 [from TIU]: 78 30 30 0D 0A 2D 3E 49 30 3A 43 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 32 2C 30 38 20 6F 6B 61 79 0D 0A 2D 3E

is two responses:

• response to the 'x' command - the number of AIU attached - "30" or 0/none followed by CR/LF
• response to the 'I0' command - bit mapped 99 bit string that indicates which of the 99 engines are present in the TIU.

 2D 3E 49 30 3A 43 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 30 2C 30 32 2C 30 38 20 6F 6B 61 79 0D 0A 2D 3E
  -  >  I  0  :  C  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  0  ,  0  2  ,  0  8     o  k  a  y CR LF  -  >

 

I think I counted my bits correctly to say this indicates engines #3 and #9 in the TIU.

After determining which engines are in the TIU, the Remote sends "Innn" commands to the TIU, where "nnn" is the engine number from "001" to "099". The response to this command is the long 86 byte return which includes the engine name and softkeys available.

Here is an example of the TIU to WIU comm. Its all ASCII.

    TIU V5.00: MTH Electric Trains, copyright(c) 2002, patent pending
    TIU board address: 00
    AIUs connected: 1
    ->m4PC connection not available
    ->H5 80918028 okay
    ->H6F02EA5F3 okay
    ->y13 okay
    ->u4 okay

    ->X0 okay
    ->IOIO:40,00,00,00,00,00,00,00,00,00,00,00,10 okay
    ->y5 okay
    ->m4 okay
    ->s0000 okay
    ->v0000 okay
    ->aa0 okay
    ->Q100 okay

 

Got it. Thanks for clarifying that... So then the last question to answer is what is the long delay after all the exchanges? I guess that's hard to figure out since it's operations within the app software itself. I also don't understand why you need to do this each time the app losses connection while being idle.