DCS Remote vs. App on issue with adding MTH engines

That video is not length edited so those are the real wait times when you have 5 TIUs!!!  WIU1 to WIU5 are all wired with ethernet in our setup.... so as I understand it... that's as fast as it can possibly go.

By the time the read is over.... the senior members have fallen asleep, and the junior members have lost interest and wandered off....

My setup is similar and I have no issues whatsoever adding engines to either the remote or the app:

• 3 Rev. L TIUs in Super TIU mode.
• Each WIU is connected via an Ethernet cable to a switch. The switch is connected to an AirPost Express access point which communicates with the AirPort Extreme router downstairs.
• Each WIU is assigned a static IP address (10.0.1.96 - 10.0.1.98) based on its MAC address.
• WIU #1 is connected to TIU #1 via a USB cable. However, WIU #2 and WIU #3 are connected to their respective TIU's serial ports (see below for the reason) via a USB to Serial cable.

The reason I use a USB to Serial cable for two of the WIU/TIU combinations is the following.

I have always had a long (40') serial ribbon cable that goes from the PC in the train room work area, around the layout to where the TIUs are located. When it's DCS upgrade time, I connect the serial cable from the train room to the serial port jumper cable connected to the TIU. I also have extension cables to jumper together the ProtoCast and ProtoDispatch ports. Then I can upgrade the TIUs in place.

When I first began using the app, I connected the USB ports of each TIU to its respective WIU. However, I encountered a situation where when certain commands were issued to an engine on TIU #2 or TIU#3, the WIU would "go out to lunch" for up to 30 seconds or so. TIU #1 didn't have this problem and the remotes worked fine.

After eliminating everything else, to my surprise I found that the problem was finally resolved by removing the long serial extension cable  from TIU #2 and TIU #3 serial ports, even though this cable was absolutely a straight-through, 9-pin cable with nothing attached to its other end.

TIU #1 was unaffected, seemingly because it connected to a Legacy command base using an MTH #50-1032 cable.

I now have TIU's #2 and #3 connected to their respective WIUs using a USB to Serial cable with a 2-port splitter for connecting the long serial ribbon cable when its upgrade time.

If you have anything dangling from the serial ports of your TIUs perhaps removing it would help to resolve the problem.

Interesting that you bring up the serial port cable problem. For years I've always had a cable connected between a TIU and PC serial port...mainly for loading soundfiles.

Lately I've completely reconfigured my layouts and PC as the serial port card is gone.

I've noticed that the DCS signal on my RevL fixed 1 out now remains strong...hmmm....coincidence? 

Barry Broskowitz posted:

If you have anything dangling from the serial ports of your TIUs perhaps removing it would help to resolve the problem.

Yeap. I leave my TIU connected to my old computer most of the time after upgrades. However this usually just happens to be my TIU #1. So I believe I've avoided this issue?

I will test it anyways.

Barry Broskowitz posted:

My setup is similar and I have no issues whatsoever adding engines to either the remote or the app:

• 3 Rev. L TIUs in Super TIU mode.
• Each WIU is connected via an Ethernet cable to a switch. The switch is connected to an AirPost Express access point which communicates with the AirPort Extreme router downstairs.
• Each WIU is assigned a static IP address (10.0.1.96 - 10.0.1.98) based on its MAC address.
• WIU #1 is connected to TIU #1 via a USB cable. However, WIU #2 and WIU #3 are connected to their respective TIU's serial ports (see below for the reason) via a USB to Serial cable.

The reason I use a USB to Serial cable for two of the WIU/TIU combinations is the following.

I have always had a long (40') serial ribbon cable that goes from the PC in the train room work area, around the layout to where the TIUs are located. When it's DCS upgrade time, I connect the serial cable from the train room to the serial port jumper cable connected to the TIU. I also have extension cables to jumper together the ProtoCast and ProtoDispatch ports. Then I can upgrade the TIUs in place.

When I first began using the app, I connected the USB ports of each TIU to its respective WIU. However, I encountered a situation where when certain commands were issued to an engine on TIU #2 or TIU#3, the WIU would "go out to lunch" for up to 30 seconds or so. TIU #1 didn't have this problem and the remotes worked fine.

After eliminating everything else, to my surprise I found that the problem was finally resolved by removing the long serial extension cable  from TIU #2 and TIU #3 serial ports, even though this cable was absolutely a straight-through, 9-pin cable with nothing attached to its other end.

TIU #1 was unaffected, seemingly because it connected to a Legacy command base using an MTH #50-1032 cable.

I now have TIU's #2 and #3 connected to their respective WIUs using a USB to Serial cable with a 2-port splitter for connecting the long serial ribbon cable when its upgrade time.

If you have anything dangling from the serial ports of your TIUs perhaps removing it would help to resolve the problem.

Hey, all 5 TIU Serial ports are totally bare here.

I don't have a static IP, its setup by DHCP, but I guess that's something to try quickly.

The really sad part for us is if you power down the TIU4 & TIU5 and their WIUs, that crazy long delay for each read becomes a lot more reasonable (down to 5-10 seconds), so it seems like it's intrinsic to having the 5 TIU system. Why the delay of (5 TIUs) is averaging 6-12X the delay of (3 TIUs) is something I don't understand. You'd expect it to go up by 5/3 in terms of packet traffic volume, right???  The only way to explain it is when  you go from 3 to 5 the probability of packet collision goes up super exponentially, but that doesn't make sense because each TIU is on a different router port, and routers unlike dumb ethernet hubs, only route corresponding traffic to each port (so 5 nodes on 5 ports shouldn't have any ethernet collisions).

The impact for us is kinda serious:

Sometimes when you put the phone in your pocket, or switch away from DCS to browse (in our case turning off wifi since our club doesn't have an internet connection)  you need to do a read again when you come back before you regain control.With the long 1min delay you can't quickly react to a developing problem situation if you don't already have the app open and you usually get a train wreck while waiting for the read to finish.

all 5 TIU Serial ports are totally bare here.

Them why not try a "Hail Mary" - replace the USB cables between the TIUs and WIUs with USB to Serial cables. It should make no difference, however, you never know...  

Joe,

However this usually just happens to be my TIU #1. So I believe I've avoided this issue?

That most likely acts just like my Legacy Command Base connected to my TIU #! and makes things "right".

If you ever leave that cable connected at the TIU but disconnect it from the PC, and bad things happen with the app, you'll know for sure!  

I forget the exact details of this but here goes.

I kept having troubles adding a used engine that I bought to my outdoor layout. I believe that I had renumbered or swapped around my TIUs outside. So at this time I had 2 issues I remember. The battery on the new engine had died and was not charging. I swapped to a BCR and for some reason the board didn't like that either.

But I had tried to delete and re-add a good engine and that did not work either.

 The second issue was that the TIUs were numbered 2 and 3 if I remember? A new DCS release at that time had some issue when there was no number 1 TIU available to add a new engine to. So any message or issue adding an engine took what seemed like 5 minutes to get a response from the remote on.

 Barry suggested that I renumber the TIUs and have a #1. I think the remote also had another TIU listed that it could not find (in the house unpowered).

So between these 2 issues, the system would just lock up for so long that I couldn't stand it. After talking with Barry by email, I deleted some TIUs from the remote and renumber the other. The system came alive. Of course that problem engine had to be fixed as well.

Barry maybe able to clarify some of this as it was maybe 2 years back? It had something to do with the #1 TIU slot. Bug or not?

Joe,

The second issue was that the TIUs were numbered 2 and 3 if I remember? A new DCS release at that time had some issue when there was no number 1 TIU available to add a new engine to. So any message or issue adding an engine took what seemed like 5 minutes to get a response from the remote on.

This was not a bug at all. It's just the way DCS works. Whenever DCS looks for an engine to add, it looks at all of the TIUs of which it's aware, i.e., the list of TIUs in the remote doing the add.

If this remote has a TIU in its list that isn't available, i.e., not powered up in range of the remote, and if the remote looks for that TIU prior to fining an engine that it can add, it can spend a loooong time looking for that TIU.

 Barry suggested that I renumber the TIUs and have a #1.

Doing so eliminated the remote searching for a TIU that wasn't there, and also eliminated the long delay.

Hi Adrian: I watched your real time video, this was very helpful. Yesterday I programed a new RailKing Locomotive to my layout. I noticed you have the handheld controller setting next to your Wi-Fi device.  Maybe there is some kind of interference going on. I am going to show my steps for Adding a MTH Engine to an iPhone. (I programed the handheld controller first, No Chaos).

Gary

Thanks Barry! Yes, I might have just deleted #1 and any other that wasn't getting power outside then.

I guess I should clarify that this was posted for others that may have issues with timely adding in general!

Gary,

If your post was intended to instruct Adrian regarding the "right way" top add an engine using the DCS App, rest assured that Adrian isn't doing anything wrong from a process perspective.

Although the steps to add an engine are very simple and straightforward, you may not understand that there's a lot that happens "under the hood" every time one attempts to add an engine. 

Although, in my experience, the app performs very well, be aware that the software is in its infancy and has not been "in the wild" long enough to become rock-solid. There are still known issues and unknown issues that can cause problems. MTH is aware of, and is working to correct, known issues. However, I am confident that there will be more "opportunities for improvement" that will present themselves as time goes on.

Barry Broskowitz posted:

all 5 TIU Serial ports are totally bare here.

Them why not try a "Hail Mary" - replace the USB cables between the TIUs and WIUs with USB to Serial cables. It should make no difference, however, you never know...  

Hi Barry, I own a lot of USB to serial converters now but I'm still stuck in the same place on the app.

However your mention of the static IP is interesting and I made an interesting discovery.... in the 5 TIU system the read is much faster if the TIUs 1-5 have static IPs in accending order. They don't need to be consecutive x.x.x.1 x.x.x.2 and so on..... just monotonically increasing. In this config the read is down to 10 seconds from over a minute. I changed it back and forth 5-6 times to be sure it wasn't coincidence..... the ip order definitely had a big effect.

I still get the timeout, but it comes much faster now so that's a start I guess. I'll keep poking it this week. 

Adrian

Adrian,

What happens if you have less than 5 TIUs/WIUs powered up? Can you then add engines.?

Hey Barry,

It adds engines totally fine with 3 TIUs. Totally solid. With 4 it works but intermittently. With 5 it just doesn't happen.... It always times out. As a work around I've been powering down two TIUs to add the engines then put them back after. Once the engine is actually on the engine list you can move it between inactive and active without a problem, it's just getting it added that's the issue.

On a quiet day when it's just me, powering down 2 TIUs will work, but when the club has lots of people running trains, that's not really going to be an answer.

Cheers!

~Adrian

Adrian,

It really is starting to sound like a bug. I can’t attempt to replicate it since I only own 4 WIUs. 

I strongly urge you to use More.../App Settings/ Contact Support to file a bug report.

Hi Adrian:  (1) Why do you have the handheld controller next to your Wi-Fi device during the Add Engine to your Wi-Fi device?   (2) There are 202 model railroader showing how to use and or programing the Wi-Fi on YouTube.

YouTube is the worlds second largest search engine, I was unable to find anyone on YT using your process, but I have not watched them all.

I am only programing one TIU, but I turnoff the handheld controller during, the ADD Engine Process with my iPhone.  This means that only my iPhone is talking to the TIU.  This is just a guess but maybe the handheld controller is the issue. Turn off the handheld controller & than do the ADD Engine.  MTH is always telling us that we no longer need the handheld controller.

Hope this helps, there is a large learning curve for MTH DCS Wi-Fi, I have been keeping a note book on all these issues that pop up on the OGR Forum, starting back to April of 2017.

Gary: Look forward to seeing how this issue is resolved.

Gary,

I am only programing one TIU, but I turnoff the handheld controller during, the ADD Engine Process with my iPhone.  This means that only my iPhone is talking to the TIU.

That's completely and totally unnecessary for two reasons:

• First, neither device initiates a conversation with the TIU on its own. In order to "talk" to the TIU on either device, it's necessary to enter a command on that device. Further, the TIU itself is incapable of initiating a conversation at all.
• Second, the DCS App cannot talk directly to the TIU. It can only communicate with the TIU via the WIU's 2.4 GHz radio. The TIU only has a 900 MHz radio and the smart device does not have a 900 MHz radio.

This is just a guess but maybe the handheld controller is the issue. Turn off the handheld controller & than do the ADD Engine.

It's an erroneous guess. The remote being on has absolutely no effect on anything that the DCS App is doing.

MTH is always telling us that we no longer need the handheld controller.

Really? MTH is staying no such thing.

Barry Broskowitz posted:

Adrian,

It really is starting to sound like a bug. I can’t attempt to replicate it since I only own 4 WIUs. 

I strongly urge you to use More.../App Settings/ Contact Support to file a bug report.

Just did that! We'll see if they can find it in a new release....

As always thanks for your thoughts!

Adrian

Barry Broskowitz posted:

Gary,

I am only programing one TIU, but I turnoff the handheld controller during, the ADD Engine Process with my iPhone.  This means that only my iPhone is talking to the TIU.

That's completely and totally unnecessary for two reasons:

• First, neither device initiates a conversation with the TIU on its own. In order to "talk" to the TIU on either device, it's necessary to enter a command on that device. Further, the TIU itself is incapable of initiating a conversation at all.
• Second, the DCS App cannot talk directly to the TIU. It can only communicate with the TIU via the WIU's 2.4 GHz radio. The TIU only has a 900 MHz radio and the smart device does not have a 900 MHz radio.

 

This is just a guess but maybe the handheld controller is the issue. Turn off the handheld controller & than do the ADD Engine.

It's an erroneous guess. The remote being on has absolutely no effect on anything that the DCS App is doing.

MTH is always telling us that we no longer need the handheld controller.

Really? MTH is staying no such thing.

 

Hi Barry: You are putting out erroneous information. 

The MTH Catalog: 2018 Volume One, Page 8.  Shows that the advanced user needs a Smart Device, DCS Interface Unit (WIU) 50-1034 and the DCS Track Interface Unit (TIU) 50-1003.  No mention of having to have a MTH Handheld Controller. I run my layout with smart device, (iPhone) just like they show on page 8. No handheld controller needed.

Yes: MTH is saying: 

In there own words: MTH Executives: Mike Wolf: CEO  /  Andy Edelman: V.P. of Marketing /  Rich Foster V.P. of Sales  / on the main layout.

“You don’t have to buy different remotes” • “It all work seamlessly together”

The company needs to clear up this issue.  Does the end user need a MTH DCS Handheld Controller? and if we do, what for?  

Gary

Gary,

You are putting out erroneous information. 

Really? Give me a break. Are you being deliberately obtuse or are you just ignorant of how DCS communicates?

You made two statements. The first was:

This is just a guess but maybe the handheld controller is the issue. Turn off the handheld controller & than do the ADD Engine.

That is completely wrong. The DCS Remote and the DCS App do not interact in any way. They talk to different devices (TIU vs. WIU) and on different radio frequencies (900 MHz vs. 2.4 GHz).

Your second statement was:

MTH is always telling us that we no longer need the handheld controller.

If that was really true, then why did MTH just manufacture a whole bunch of TIU and Remote sets, as well as separate-sale packages of both?

Further, on the video, Rich Foster does, indeed, state:

“You don’t have to buy different remotes” • “It all work seamlessly together”

However, you took his statement out of context. He was meaning that one could operate DCS engines and other engines with the app and that one did not have to buy different remotes to run those different engines. Its also worth pointing out that this is old news. One could make exactly the same statements regarding the DCS Remote.

The TIU/WIU/DCS App is but one of two ways to operate full-featured DCS. The other way continues to be the TIU/DCS Remote combination.

Also of note is thither are a few DCS features that one has when using the DCS Remote that are not present in the app, and vice-versa.

Barry Broskowitz posted:

My setup is similar and I have no issues whatsoever adding engines to either the remote or the app:

• 3 Rev. L TIUs in Super TIU mode.
• Each WIU is connected via an Ethernet cable to a switch. The switch is connected to an AirPost Express access point which communicates with the AirPort Extreme router downstairs.
• Each WIU is assigned a static IP address (10.0.1.96 - 10.0.1.98) based on its MAC address.
• WIU #1 is connected to TIU #1 via a USB cable. However, WIU #2 and WIU #3 are connected to their respective TIU's serial ports (see below for the reason) via a USB to Serial cable.

The reason I use a USB to Serial cable for two of the WIU/TIU combinations is the following.

I have always had a long (40') serial ribbon cable that goes from the PC in the train room work area, around the layout to where the TIUs are located. When it's DCS upgrade time, I connect the serial cable from the train room to the serial port jumper cable connected to the TIU. I also have extension cables to jumper together the ProtoCast and ProtoDispatch ports. Then I can upgrade the TIUs in place.

When I first began using the app, I connected the USB ports of each TIU to its respective WIU. However, I encountered a situation where when certain commands were issued to an engine on TIU #2 or TIU#3, the WIU would "go out to lunch" for up to 30 seconds or so. TIU #1 didn't have this problem and the remotes worked fine.

After eliminating everything else, to my surprise I found that the problem was finally resolved by removing the long serial extension cable  from TIU #2 and TIU #3 serial ports, even though this cable was absolutely a straight-through, 9-pin cable with nothing attached to its other end.

TIU #1 was unaffected, seemingly because it connected to a Legacy command base using an MTH #50-1032 cable.

I now have TIU's #2 and #3 connected to their respective WIUs using a USB to Serial cable with a 2-port splitter for connecting the long serial ribbon cable when its upgrade time.

If you have anything dangling from the serial ports of your TIUs perhaps removing it would help to resolve the problem.

Hi Barry,

I investigated your 40' cable story on the bench and have figured out what's going on so you can spread the word. As you are probably super well aware already the DB9 port on the TIU is serial (RS232) and has two pins of importance (TXD and RXD) as well as some control pins (CTS DTR,...).

Even when nothing is plugged into the TIU DB9 port, the TX pin on the TIU is still spitting stuff out to nowhere. While a short cable doesn't do much, the long cables (I found more than 15ft is where it starts) allow the TXD conductor's signal to nowhere to capacitively couple onto the essentially floating RXD conductor. The TIU starts thinking it's receiving ASCII and gets confused. It's like the un-terminated transmission line problem except instead of worrying about signals bouncing back, the problem is coupling from one line to another parallel line.

If you put a pull down resistor of a few Kohm to -10VDC (you'd have to get this somewhere?) the problem is solved as that establishes the voltage on the RXD line (-10V indicates idle is RS232), eliminates the floating condition and stops the parasitic coupling.

Cheers!

~Adrian

Adrian,

I had pretty much detrnmeined that it was a capacitance issue. Anything longer than about 12" hanging off the serial port causes the problem to occur.

I took the easy way out and simply shared the serial port with a Y splitter. It's still necessary to disconnect the WIU when upgrading the TIU since when the WIU is connected to the serial port ti disrupts the data stream during the TIU's software upgrade.

Thanks for taking the time to look into this!

Adrian! posted:

Barry Broskowitz posted:

all 5 TIU Serial ports are totally bare here.

Them why not try a "Hail Mary" - replace the USB cables between the TIUs and WIUs with USB to Serial cables. It should make no difference, however, you never know...  

Hi Barry, I own a lot of USB to serial converters now but I'm still stuck in the same place on the app.

However your mention of the static IP is interesting and I made an interesting discovery.... in the 5 TIU system the read is much faster if the TIUs 1-5 have static IPs in accending order. They don't need to be consecutive x.x.x.1 x.x.x.2 and so on..... just monotonically increasing. In this config the read is down to 10 seconds from over a minute. I changed it back and forth 5-6 times to be sure it wasn't coincidence..... the ip order definitely had a big effect.

I still get the timeout, but it comes much faster now so that's a start I guess. I'll keep poking it this week. 

 

Adrian

  

 

 

Adrian,

I might be a little late here with a response, but wanted to add to your comment.

Our club layout has 5 TIU/WIU's which are statically assigned an IP address in ascending order. This was done by pure coincidence, and when I was recently onsite, I tested your idea about reversing the order of the assigned IP's. I can confirm your results. I'm glad my OCD about not using DHCP and assigning things in order has paid off! Even phones and tablets are statistically assigned to the network with a dedicated IP address.

I went a step further.

I plugged all of the WIU's into an old school network HUB (not a switch), and plugged in a PC running wire-shark to capture all of the network data flowing to each WIU and the wireless router.  The apps will scan pretty much every available IP address in the subnet to discover all WIU's. This didn't take very long.  I then shut down two of the WIU's (selectively random 2 & 5) and the traffic was interesting. The DCS app was aware that a WIU should be at these two IP addresses and continuously tried to communicate with them which resulted in a long wait time on the app side up to the time out.

It appears the app retains information about where each WIU is on the network. When we humans take that away the app doesn't rescan the network to determine which WIU are now offline. It appears that this "scan" only happens when we hit the "run trains" button on the first screen.

When I get back there, I am going to do some more testing and tinkering.

H1000,

It appears that this "scan" only happens when we hit the "run trains" button on the first screen.

TIUs also get reacquainted with the app every time a Refresh command is issued.

This and a whole lot more about DCS WiFi is all in MTH’s “The DCS WiFi Companion 1st Edition!" This book is available from many fine OGR advertisers and forum sponsors, or as an eBook or a printed book at MTH's web store! Get the free TMCC & Legacy Addendum here!

The app needs an advanced settings panel where you can plug in IPs for each TIU and skip all the searching. I think that would make it much more robust to use....

Adrian! posted:

The app needs an advanced settings panel where you can plug in IPs for each TIU and skip all the searching. I think that would make it much more robust to use....

I agree, and recommended for advanced users only with networking knowledge.
"look at these IP addresses and don't look at anything else" Because that is the exact way I configured my (WIU) network. 

The next thing I want to try is to change the Subent mask to shrink the number IPs that need to be scanned.  Thinking about trying a /28 subnet to limit the max number of IP addresses to 15 (vs. the 255 used in the default /24 subnet) to see if that will reduce the discovery time.

Barry Broskowitz posted:

H1000,

It appears that this "scan" only happens when we hit the "run trains" button on the first screen.

TIUs also get reacquainted with the app every time a Refresh command is issued.

---

This and a whole lot more about DCS WiFi is all in MTH’s “The DCS WiFi Companion 1st Edition!" This book is available from many fine OGR advertisers and forum sponsors, or as an eBook or a printed book at MTH's web store! Get the free TMCC & Legacy Addendum here!

Barry,

Does the TIU really communicate directly with the App? The way I picture it is the WIU acts as a middle man between the App and the TIU, just as the TIU acts as a middle man for the DCS remote and the DCS engine on the track.

Another one of my many side projects has been picking apart the data packets the app sends to the WIU to see if something other than the App can be used to communicate with the WIU. (Similar to what San Diego Mark did with his RTC program)  I have been able to send a few simple commands to the TIU (via the WIU) by using some packet mirroring and trick the WIU into doing what I want from a PC. While the App issue the commands based on the information plugged into it, the WIU is really the "puppet master" of the TIU. The TIU is only aware of the WIU and the WIU is aware of both the App and TIU.

There are some other things I have done with the WIU that lead me to the above conclusion that I would rather not discuss on a public forum without permission from MTH first.

H1000 posted:

Barry Broskowitz posted:

H1000,

It appears that this "scan" only happens when we hit the "run trains" button on the first screen.

TIUs also get reacquainted with the app every time a Refresh command is issued.

---

This and a whole lot more about DCS WiFi is all in MTH’s “The DCS WiFi Companion 1st Edition!" This book is available from many fine OGR advertisers and forum sponsors, or as an eBook or a printed book at MTH's web store! Get the free TMCC & Legacy Addendum here!

Barry,

Does the TIU really communicate directly with the App? The way I picture it is the WIU acts as a middle man between the App and the TIU, just as the TIU acts as a middle man for the DCS remote and the DCS engine on the track.

Another one of my many side projects has been picking apart the data packets the app sends to the WIU to see if something other than the App can be used to communicate with the WIU. (Similar to what San Diego Mark did with his RTC program)  I have been able to send a few simple commands to the TIU (via the WIU) by using some packet mirroring and trick the WIU into doing what I want from a PC. While the App issue the commands based on the information plugged into it, the WIU is really the "puppet master" of the TIU. The TIU is only aware of the WIU and the WIU is aware of both the App and TIU.

There are some other things I have done with the WIU that lead me to the above conclusion that I would rather not discuss on a public forum without permission from MTH first.

My picture is like this:

The TIU came before the WIU in terms of design so I don't think the TIU can even know what's going on with the wifi.

If you examine the TIU hardware, ... the TIU has always accepted ascii commands (Which San Diego Mark's program has mapped out cleanly) on a serial interface at the FPGA inside the TIU (which is connected to the DB9 at the bottom of the box). The USB port MTH added in the later revs just goes to an FTDI chip (one of those virtual com port RS232 converter chips) which then goes to the same serial port on the xilinx FPGA. The WIU just translates the network packets into the existing ASCII language that the TIU already uses. Since the serial ports are ganged together inside.... if you connect the WIU to the USB port on the TIU and monitor the DB9 port on the TIU with a serial cable and terminal on a PC, you can see the entire WIU-TIU conversation on the ASCii side of the translation, which is exactly the command protocol SanDiegoMark's notes describe.

The interesting part to me would be looking at the network side protocol and see if the content matches the ASCii side, or if the command set is different. I haven't even figured out what type of network packets it is yet. I didn't see any TCP or UDP going by on my packet captures... All I saw was the ARP discovery so far.

Adrian,

If I recall correctly, it may be possible to use LuCI to set a static IP address for a WIU. I'm not able to look into LuCI at this time, however, on page 11of the full WIU Manual there's a setting for "Network Configuration" and the associated "Protocol" that may allow setting a static IP address.

Regardless, it makes more sense to me to have my router serve static IP addresses to the WIUs, based on their MAC addresses. This way, the WIUs stay in factory setting mode.

H1000,

Does the TIU really communicate directly with the App? The way I picture it is the WIU acts as a middle man between the App and the TIU, just as the TIU acts as a middle man for the DCS remote and the DCS engine on the track.

Yes, you are correct. Whenever a Refresh command is issued, the app polls the WIUs for connected TIUs. That's how the app gets "reacquainted" with the TIUs.

Barry Broskowitz posted:

Adrian,

The app needs an advanced settings panel where you can plug in IPs for each TIU and skip all the searching. I think that would make it much more robust to use....

If I recall correctly, it may be possible to use LuCI to set a static IP address for a WIU. I'm not able to look into LuCI at this time, however, on page 11of the full WIU Manual there's a setting for "Network Configuration" and the associated "Protocol" that may allow setting a static IP address.

Hi Barry,

I meant a setting so the app itself would have knowledge of the WIUs. I have static IPs on the WIUs already, but the app still has to search the entire subnet for them when I hit read. If the app itself had a setting to plug these in and knew exactly which 5 IPs to talk to instead of searching it should be much faster....

Barry, I thought about what you originally said and realized after the fact that you were thinking bigger picture and I was drilling more into the processes & devices involved.

Regardless, it makes more sense to me to have my router serve static IP addresses to the WIUs, based on their MAC addresses. This way, the WIUs stay in factory setting mode.

I see where Barry is coming from here. However, there is a small advantage to Static IP's assigned on the WIU. There is no wait time for the DHCP process to occur between the WIU and your router.  Also when you turn on your layout, 5 WIU's are no longer hammering the router for an IP address, it's already configured right out of the gate and decreases the boot up time of the WIU slightly.

I haven't even figured out what type of network packets it is yet. I didn't see any TCP or UDP going by on my packet captures... All I saw was the ARP discovery so far.

Adrian, I had a similar problem until I switched to a (really old) network hub I had laying around. I'm not sure how you were trying to capture the packet data, I've always done this via ethernet and not with wireless.

I didn't get too far into this yet, I've just been grabbing packets and resending them using a pc to repeat commands sent from the App.

H1000 posted:

I haven't even figured out what type of network packets it is yet. I didn't see any TCP or UDP going by on my packet captures... All I saw was the ARP discovery so far.

Adrian, I had a similar problem until I switched to a (really old) network hub I had laying around. I'm not sure how you were trying to capture the packet data, I've always done this via ethernet and not with wireless.

I didn't get too far into this yet, I've just been grabbing packets and resending them using a pc to repeat commands sent from the App.

Also when you port-scan the WIUs, the only shown open port is the HTTP connection for the LuCI interface.

So that's interesting too.

Adrian,

While working on something else with the DCS app I manage to take a peek at a data export file from one of my android devices.  At the very end of the file I noticed something. The app associates each TIU by identify them with the last four digits of the WIU's MAC address. Also every engine is stored in the file with the original WIU identifier that the app added that engine with. I'm at home now and my personal layout only has one WIU, so obviously these identifiers are all the same. 

The other thing. The Export file contained a string "network_address" which was the IP address of the WIU I have on my layout.  It appears the App is recording where each WIU is located in the network map.  Lastly, it identified the IP port that the app is using, (drum-roll) the port identified on my export file is 40588 which is open to TCP connections.

If family lets me, I will play with this more today.

Have a nice Thanksgiving!