How about Barry White - My First, My Last, My Everything (or something close to it).
I will stay out of the DCS discussion, just trying for the gold star. 
rtr12 posted:How about Barry White - My First, My Last, My Everything (or something close to it).
I will stay out of the DCS discussion, just trying for the gold star.
Bingo.
Attachments
Images (1)
Barry,
If you're not going to take the youtube video at face value, so be it. It was just a quick experiment - take it or leave it. Next you'll want to know what remote version, what TIU hardware revision, what voltage, was it star-wiring, what camera and video software, what I had for breakfast, etc. As suggested, I give up.
You're right, I'm wrong. You win! 
FWIW, and not intending to get involved in this kerfuffle, there are occasions when the fiber pin doesn't completely insulate signals. When I only had one WIU, connected to one of my 2 TIUs, when reading locos it would occasionally pick up locos served by the other TIU. Also, I on occasion get a double response to a softkey, which does not happen if I turn off the other TIU. I have been unable to discover any electrical connection between the center rails controlled by TIU#1 and those controlled by TIU#2; their areas of the layout meet in only one spot. Perhaps some ghost of the signal passes along the outer rails (which are not and cannot be separated, or perhaps some of the signal goes back through the transformers to the other TIU (I tried putting chokes and capacitors on TIU inputs, to no avail.), or perhaps two wires are close enough to have inductance.
stan2004 posted:rtr12 posted:How about Barry White - My First, My Last, My Everything (or something close to it).
I will stay out of the DCS discussion, just trying for the gold star.
Bingo.
Finally! 
I will put it with my lump of coal.
I will keep trying for the gold star in electronics, but I think that one is way down the road. 
Today, I conducted an experiment designed to determine what effect, if any, ProtoCast has on the functionality of other engines being operated simultaneously with the engine playing music via ProtoCast.
My setup was as follows:
- Three Rev. L TIUs running DCS 5.0 under Super TIU mode. However, only one TIU was used in the experiment
- Two DCS Remotes running DCS 5.0
- One DCS Remote Commander connected in Passive mode to Fixed Channel #1
- Three WIUs with version 1.1 firmware, one of which was connected to the Rev. L TIU used in the following test cases. All WIUs were connected in HOME network mode
- Four DCS engines:
- RK Imperial FEF PS3
- Premier AEM7 PS2
- RK RS-1 PS2
- RK SD 9 PS2
- iPad Mini running iOS9 playing “The Best of the Allan Parsons Project”
- iPhone 6 running iOS9 and the DCS WiFi App, Standard version, release 1.1.
For test cases #1 - #4, the FEF was started up and playing music using ProtoCast, via the TIU’s ProtoCast port.
Test Case #1
When the FEF was started up and ProtoCast was initiated via the DCS Remote, the FEF’s normal idle and engine sounds turned off, and music played very nicely. It was clear and static-free.
Using a second remote, I then started up a second engine, the RS-1, on a different TIU channel. I was able to execute all commands without the slightest issue. Everything responded quickly and without any “latency” or other delay. The FEF continued to play music as clearly and static-free as before.
Test Case #2
Again, using a second remote, I started up a third engine, the AEM7, on the same TIU channel as the FEF that was playing music. Again, I was able to execute all commands, to both the RS-1 and the AEM7, without the slightest issue. Everything responded quickly and without any “latency” or other delay. Again, the FEF continued to play music as clearly and static-free as before.
Test Case #3
I now started up and exercised the SD9 using the DCS Remote Commander, on the same TIU channel as the FEF, while continuing to play music via the FEF, and also continuing to exercise the AEM7 and RS1. The exercise continued to be problem-free.
Test Case #4
I shut down the SD9 using the DCS Remote Commander and then added the SD9 to the DCS App in the iPhone. This is where I encountered a new (to me, at least) bug in the DCS WiFi App. Any time I executed a command using the DCS WiFi App, the FEF stopped playing music and went back to making its normal engine and idle sounds. The FEF’s DCS Remote still displayed the “C”, however, ProtoCast had ceased playing through the engine. The iPad, off course, still was playing music. (It's worth noting that the DCS App's active engine list contained the FEF.)
I could restore ProtoCast by turning it off and then on again from the DCS Remote, however, every subsequent command issued by the DCS WiFi App turned ProtoCast off again.
For test case #5, the I moved the iPad Mini’s headphone out cable from the TIU’s ProtoCast port to it’s ProtoDispatch port.
Test Case #5
The FEF’s normal idle and engine sounds remained on while music played, poorly, over the normal engine sounds. It was not particularly satisfying..
I then attempted to use the second remote to start up a second engine, the RS-1, on a different TIU channel. I was completely unable to execute any commands, including Startup. The FEF continued to play music as poorly as since the start of this test case.
Conclusions
- Since there is a long-standing “feature” in ProtoDispatch that locks out all DCS command operation when ProtoDispatch is active, whether via a DCS Remote’s mic or an external mic plugged into the TIU’s ProtoDispatch port, the results of test case #5 came as no surprise.
- It appears, from the results of test cases 1-4, that there is no latency or other degradation of DCS command packets due to “flooding” a layout with DCS packets via ProtoCast, which is arguably the most packet-intensive of all of the DCS operational commands. While things like software updates, sound file transfers, and backup/restore of DCS Remotes are, I believe, more packet-intensive than ProtoCast, they are intended to be used outside of normal DCS operations.
- It looks as if I may have stumbled across a bug in the DCS WiFi App, which I shall shortly be reporting to MTH R&D.
I would be happy to discuss the above further on this thread, should anyone so desire.
All,
From my previous post above:
I shut down the SD9 using the DCS Remote Commander and then added the SD9 to the DCS App in the iPhone. This is where I encountered a new (to me, at least) bug in the DCS WiFi App. Any time I executed a command using the DCS WiFi App, the FEF stopped playing music and went back to making its normal engine and idle sounds. The FEF’s DCS Remote still displayed the “C”, however, ProtoCast had ceased playing through the engine. The iPad, off course, still was playing music. (It's worth noting that the DCS App's active engine list contained the FEF.)
I could restore ProtoCast by turning it off and then on again from the DCS Remote, however, every subsequent command issued by the DCS WiFi App turned ProtoCast off again.
It looks as if I may have stumbled across a bug in the DCS WiFi App, which I shall shortly be reporting to MTH R&D.
I received notification from MTH that the above bug in the DCS WiFi App has been placed on the development list for correction in a future app release.
