Correlator Noise floor inflation by Legacy Signal Interfering with DCS

I dunno-

Your scope images show the composite track signal, I would assume (hope) that the DCS receiver/decoder has some frequency selectivity; the 455 kHz legacy signal is 4 octaves away! If the 455 kHz is getting through to the DCS decoder I can see the problem!

PLCProf posted:

I dunno-

Your scope images show the composite track signal, I would assume (hope) that the DCS receiver/decoder has some frequency selectivity; the 455 kHz legacy signal is 4 octaves away! If the 455 kHz is getting through to the DCS decoder I can see the problem!

 

When you look at the spread code MTH uses:  101100000110011010111101000110001, there's sections of 4&5 repeated symbols so you need to support bandwidth down to like 1/5 to 1/6 the bit rate to get clean eye windows, that's a pass-band starting at around 500-600 KHz. It's not a digital FIR filter so the stop-band rejection down at 450 KHz isn't going to be so great. I guess that's why it does come inside.

I wonder if a notch filter might help there, but it might need to actually be in the locomotive, probably a bit complicated.

FWIW, we've also noticed that at times the Legacy affects the DCS on the club layout.

gunrunnerjohn posted:

I wonder if a notch filter might help there, but it might need to actually be in the locomotive, probably a bit complicated.

FWIW, we've also noticed that at times the Legacy affects the DCS on the club layout.

Yup. It has to go in the engine. That's why it's hard to fix in a club with 100+ members.

I'm not sure where you'd have to put it either, a filter that handles full track power might be challenging.   Most of these have to pass the full signal, in our case that's track power.

I am think of taking the wire off the "U" terminal (I understand the signal is still there) and see if the signal degrades enough to add an MTH engine.  My biggest concern is someone turning off the Legacy signal while a Legacy engine is in operation and having that engine take off with 18 volts.

Some more quick testing to take a closer look at this. I blew the dust off the old FPGA decoder in the (old post) from last year and made the following setup:

So what we have is the FPGA decoder talking with the TIU exchanging packets and reporting the value of Cx (the packet correlation result) back to the PC. Then we have a signal generator injecting a 450 KHz tone with varying amplitude to see the correlation result Cx at different amplitude levels. Obviously doing only 1 packet is statistically meaningless so we compute the average Cx over 1000 exchanges at each voltage level. I've scaled the plot out of 16 instead of 31 (since 0 is actually 100% correlated but inverted) so the single axis can represent best to worst. This is with the actual MTH spreading code (obviously since I am talking to a real TIU)

I don't have control over the DCS excursion voltage since its set by the TIU and not adjustable but I did track it with the scope during the measurement (fixed at 6.17V in the test setup). As you can see from the above, once the injected 450 KHz tone gets to about 1.6V which is (about 25% (1.6 / 6.17) of the voltage of the DCS signal, the decoder correlation starts to drop off rapidly. I'm not sure if this scales linearly or not (like if we normalize the injection to DCS voltage will the drop at the same % each time).

It certainly doesn't fall apart gracefully, 1.2 to 1.8V (about a 0.6V change in injection) pretty much wipes out the correlator in my decoder. I'm sure the MTH one on the PS2/3 is pretty similar, at least according to their documentation.

I think the correlation confidence threshold Ct for MTH is somewhere around 13-14.

When Adrian came last night what he said is true and several other members that were their who contribute to this forum witnessed this strange event.

Any other thoughts?

Adrian, I wanted to thank you for spending the evening at the SD3R layout last night. A lot of the DCS users (me included) were going to leave the club over problems running DCS there. Finally, someone with real test equipment and an expert technical understanding DCS put the setup through a real diagnostic session.  The issues you discovered and that trick DCS panel you built gives SD3R's DCS users a light at the end of the tunnel--and I hope the light is an oncoming train...in O Gauge running DCS, that is. Thanks again!  

DJ's Trains posted:

Adrian, I wanted to thank you for spending the evening at the SD3R layout last night. A lot of the DCS users (me included) were going to leave the club over problems running DCS there. Finally, someone with real test equipment and an expert technical understanding DCS put the setup through a real diagnostic session.  The issues you discovered and that trick DCS panel you built gives SD3R's DCS users a light at the end of the tunnel--and I hope the light is an oncoming train...in O Gauge running DCS, that is. Thanks again!  

Thanks! I'm glad to help!

Immediately, I'm thinking it's probably best if you guys put in the Rev "M" TIU, get rid of the bulbs and other things that don't make sense on the track and just see how it works for a few weeks. Then I'll come back (probably mid June) and make sure the new TIU isn't degrading by repeating all the measurements we did last night. In parallel, I've got 2 or 3 ideas on new things we could build to manage the legacy interference (see above) that I'll be trying out prototypes for in our AGHR club the next few weeks or so...

After mid June I'll be a lot more free and I'm willing to come down to SD from LA as much as is needed to get your DCS running well. If there's more issues beyond what we already found, we'll figure it out together and share them with the community here!

We'll be beating on it in the coming weeks--trust me. I believe that Roger was going to install that DCS panel this or Tuesday evening.

Okay I have an interesting thought but I actually don't know that much about legacy and could use advice from someone like GRJ or someone else with legacy expertise... I actually only have DCS trains myself.

Thought Exercise:

I'm thinking the DCS packets are typically about 1.2 to 2.5ms in duration, and if a packet fails or gets a partial match, the TIU or PS2/3 will retry the exchange. If we just took a 555 timer and chopped a 6ms window into the legacy signal say every 25 ms the DCS should be able to find the holes through the retry process, and communicate in them provided they are wide enough, and frequent enough.

Something like this:

What would this do to the legacy signal?

1. Would it notice the windows (I would expect not since the current DCS packets themselves don't disrupt it).

2. I'm struggling to find good information about the Legacy signal format (modulation, duration, framing, error checking). If the command duration is longer than the window spacing (25ms) legacy will obviously fail. Is there a pulse width and duration that could satisfy both systems?

This may be a simple $4 fix...

Thoughts?

So just to be clear, nothing but MTH engines on layout with legacy active and MTH engines can not add?  Any other operator see this?  Lots of layouts run legacy and DCs so why just San Diego club.

Adrian! posted:

Immediately, I'm thinking it's probably best if you guys put in the Rev "M" TIU, get rid of the bulbs and other things that don't make sense on the track and just see how it works for a few weeks.

Rev "M" TIU?  What's that?

gunrunnerjohn posted:

Adrian! posted:

Immediately, I'm thinking it's probably best if you guys put in the Rev "M" TIU, get rid of the bulbs and other things that don't make sense on the track and just see how it works for a few weeks.

Rev "M" TIU?  What's that?

Rev "M" (with quotes) is the TIU with the 1n4148s inside and TVS. The one in my other post. I put one together for the SD3R club.

OK, that one threw me.

gunrunnerjohn posted:

OK, that one threw me.

I threw off a friend of mine using the "M" designation too on my Facebook post. 

GGG posted:

So just to be clear, nothing but MTH engines on layout with legacy active and MTH engines can not add?  Any other operator see this?  Lots of layouts run legacy and DCs so why just San Diego club.

 

I'm one of the DCS operators having to deal with this problem at SD3R.

"[N]othing but MTH engines on layout with legacy active and MTH engines can not add?"  Correct. And the same problem occurs with Legacy engines on the layout also. If no one is running Legacy the next time I'm operating trains down there, I'll do some experimenting with the issues I've been having with the Legacy transmitter base off and on.

GRJ, it sure does! Do you think any of Dale M's findings would help with this? Or is Adrian already aware of that info? I know you and PLCProf are and I know Dale was boosting the Legacy signal which seems to be somewhat opposite of this?  Just a thought here. It's all over my head...but I try to follow along anyway. 

rtr12 posted:

GRJ, it sure does! Do you think any of Dale M's findings would help with this? Or is Adrian already aware of that info? I know you and PLCProf are and I know Dale was boosting the Legacy signal which seems to be somewhat opposite of this?  Just a thought here. It's all over my head...but I try to follow along anyway. 

I think basically from the above measurements.... it's like:

IF) the Legacy signal is strong enough to run the layout at every spot on the track

AND IF) the DCS voltage at the same spot is greater than 4 times the legacy voltage,

THEN: it runs together seamlessly.

ELSE:  Trouble

Thanks, that even makes sense...used to dabble in Quick Basic many years ago.  The late Dale M did a lot of fiddling with the TMCC/Legacy stuff and I didn't know if that would help you or not. GRJ and PLCprof are much more capable of explaining Dale's research than I am, the reason I asked GRJ. Wasn't even sure it would apply?

Dale didn't look into the interaction between the two command types.

I was just thinking Dale may have found something in his research that could have been of interest here? Also figured if he had that you or PLCprof would have already mentioned it, but threw it out there anyway just in case. 

Adrian,

Thanks again for the DCS module!  I installed it on our layout last night (Monday night).  I didn't have a DCS engine with me to test it out last night, but I called down this morning and they said that they were able to find a DCS engine without a problem with the Legacy signal still turned on.  The difference is that they added the engine on a section of track on the main line near the back door.  The section that we were having problems with were the passing sidings on the Black Line.  We suspect that there still may be "track lamps" under that section that we couldn't get to Sunday night.  Maybe they caused enough problem in that section, combined with the Legacy signal, to block DCS in that section.

I will know more info when they finish their run today.  I'm sure there will be more posts tonight from the guys who ran.

Amazing how some details can shed light on a problem.  So with Legacy off, and MTH engines in these areas that they can not load when Legacy on, what is the Signal Strength with a TS test?  G

Roger L. posted:

Adrian,

Thanks again for the DCS module!  I installed it on our layout last night (Monday night).  I didn't have a DCS engine with me to test it out last night, but I called down this morning and they said that they were able to find a DCS engine without a problem with the Legacy signal still turned on.  The difference is that they added the engine on a section of track on the main line near the back door.  The section that we were having problems with were the passing sidings on the Black Line.  We suspect that there still may be "track lamps" under that section that we couldn't get to Sunday night.  Maybe they caused enough problem in that section, combined with the Legacy signal, to block DCS in that section.

I will know more info when they finish their run today.  I'm sure there will be more posts tonight from the guys who ran.

Hey there!

Wow you got all 4 channels hooked up already? That's pretty fast! I assume you are using the PH180 bricks as your source to the panel?

As long as you're getting rid of the lamps, do make sure you get rid of the wire and sockets that go with them. Any added capacitance to the track can hurt. I would go loop by loop and make sure literally nothing is connected to the track except the TIU. The smaller the electrical load it drives, the better the situation will be.

I'm working on other possibilities of digitally cutting some holes in the legacy signal for the DCS to talk through, but I'll need to test it in my club a bit and see if it causes undesired problems or not. As I said above I'm going to let you guys try it out a bit then come back in mid-june to remeasure everything and see the TIU "m" is holding up properly.

Once the summer starts and I'm not teaching I can come back as often as needed to get your DCS setup working perfectly.

Yes, I took your board home and spent the day (Monday) prepping some wires.  Then I went down at 5:15pm after the museum closed to install the board.  It still took me about five hours to install it because I had to connect a lot of wires.  Also, I had to mount the board with a hinge so that we could get to the electronics behind it. 

The power connected to the board is still switchable between the Z4000 and the bricks, but members of our club pretty much know to use the bricks for DCS (and TMCC).

I may not have a chance to go to the layout until Thursday to see if I can remove the "track lamps".   There is a lot of stuff in the way.

Showed up Tuesday morning (5-29) for my regular run day.  The new board was installed per above.  We cleaned track like normal and began setting up for our running.  Two members brought MTH engines.  One MTH engine has not been in command mode for over 5 years.  We set this engine up (ps2) on the top black line near the rear exit door, and with their passenger cars fully lighted (non led) they pushed the find engine button on the remote,  within 10 seconds the engine was found and loaded into the remote.  They pushed start and it started. 

The second MTH engine (ps3) was not placed on until later in the day on the lower level green line, with the same results.   Only this time a legacy engine was in operation, a conventional engine was operation and the first MTH with all those lighted cars were in operation.  We have never been able to add an MTH engine when other engines were operating.

Just for drill while the both MTH engines above were operating and the legacy engine was in operation, I got out my rail-king evo ps3 placed it on the blue track near mell's diner and got "out of range".  But the remote loaded the other two engines.  I then moved the evo to behind the roundhouse on the blue line and the evo loaded in seconds, and ran all over the layout.  I was not willing to unplug the legacy system while a legacy engine was in operation.

during the day we have removed what we believed are 100 percent of the bulbs and the bulb holders. 

The only other thing we need to do is remove the loose ground wires.

I believe we are 100 percent better with our MTH set up.

Of course we must get the members who have had issues to come and run their MTH engines and report any issues they have.

Members who have issues must report what issues they have and not just state "my engine does not work"...

We need members to report what issues they have like "out of range", "no engine on track", "engine not found" and the location that they have these issues plus any other thing the remote tells you so we can address these issues.  

We are working on a check list to report issues and hope to have this check list available soon.

bigdodgetrain posted:

Showed up Tuesday morning (5-29) for my regular run day.  The new board was installed per above.  We cleaned track like normal and began setting up for our running.  Two members brought MTH engines.  One MTH engine has not been in command mode for over 5 years.  We set this engine up (ps2) on the top black line near the rear exit door, and with their passenger cars fully lighted (non led) they pushed the find engine button on the remote,  within 10 seconds the engine was found and loaded into the remote.  They pushed start and it started. 

The second MTH engine (ps3) was not placed on until later in the day on the lower level green line, with the same results.   Only this time a legacy engine was in operation, a conventional engine was operation and the first MTH with all those lighted cars were in operation.  We have never been able to add an MTH engine when other engines were operating.

Just for drill while the both MTH engines above were operating and the legacy engine was in operation, I got out my rail-king evo ps3 placed it on the blue track near mell's diner and got "out of range".  But the remote loaded the other two engines.  I then moved the evo to behind the roundhouse on the blue line and the evo loaded in seconds, and ran all over the layout.  I was not willing to unplug the legacy system while a legacy engine was in operation.

 

during the day we have removed what we believed are 100 percent of the bulbs and the bulb holders. 

The only other thing we need to do is remove the loose ground wires.

I believe we are 100 percent better with our MTH set up.

Of course we must get the members who have had issues to come and run their MTH engines and report any issues they have.

Members who have issues must report what issues they have and not just state "my engine does not work"...

We need members to report what issues they have like "out of range", "no engine on track", "engine not found" and the location that they have these issues plus any other thing the remote tells you so we can address these issues.  

We are working on a check list to report issues and hope to have this check list available soon.

 

This is good news!

Your club already had a nice antenna in the ceiling but the connector is different (BNC) than the one on the TIU I gave you (SMA) so we couldn't hook it up yet and you're stuck with the short whip antenna I made out of a coax cable. The RF out of range will probably go away if you go back to the good antenna. I will order the SMA-to-BNC adapter and send it to you guys this week. Once you have good DCS in most places, we can use the telemetry train to look at the remaining bad spots and try to figure out why they are bad.

we have several 3 railer members running MTH today Friday June 1st.

hopefully they will give a complete report on their running, sometime in the near future.

it has been a very long time since we could lash up 3 MTH loco's

with this video it appears we have success.

bigdodgetrain posted:

it has been a very long time since we could lash up 3 MTH loco's

with this video it appears we have success.

 

Glad to see things are improving! Once you get the external antenna wired in, things should be quite responsive.

Adrian! posted:

bigdodgetrain posted:

Showed up Tuesday morning (5-29) for my regular run day.  The new board was installed per above.  We cleaned track like normal and began setting up for our running.  Two members brought MTH engines.  One MTH engine has not been in command mode for over 5 years.  We set this engine up (ps2) on the top black line near the rear exit door, and with their passenger cars fully lighted (non led) they pushed the find engine button on the remote,  within 10 seconds the engine was found and loaded into the remote.  They pushed start and it started. 

The second MTH engine (ps3) was not placed on until later in the day on the lower level green line, with the same results.   Only this time a legacy engine was in operation, a conventional engine was operation and the first MTH with all those lighted cars were in operation.  We have never been able to add an MTH engine when other engines were operating.

Just for drill while the both MTH engines above were operating and the legacy engine was in operation, I got out my rail-king evo ps3 placed it on the blue track near mell's diner and got "out of range".  But the remote loaded the other two engines.  I then moved the evo to behind the roundhouse on the blue line and the evo loaded in seconds, and ran all over the layout.  I was not willing to unplug the legacy system while a legacy engine was in operation.

 

during the day we have removed what we believed are 100 percent of the bulbs and the bulb holders. 

The only other thing we need to do is remove the loose ground wires.

I believe we are 100 percent better with our MTH set up.

Of course we must get the members who have had issues to come and run their MTH engines and report any issues they have.

Members who have issues must report what issues they have and not just state "my engine does not work"...

We need members to report what issues they have like "out of range", "no engine on track", "engine not found" and the location that they have these issues plus any other thing the remote tells you so we can address these issues.  

We are working on a check list to report issues and hope to have this check list available soon.

 

This is good news!

Your club already had a nice antenna in the ceiling but the connector is different (BNC) than the one on the TIU I gave you (SMA) so we couldn't hook it up yet and you're stuck with the short whip antenna I made out of a coax cable. The RF out of range will probably go away if you go back to the good antenna. I will order the SMA-to-BNC adapter and send it to you guys this week. Once you have good DCS in most places, we can use the telemetry train to look at the remaining bad spots and try to figure out why they are bad.

Adrian, SD3R

This is a great discussion, which I am hopping will address some of the DCS issues we are having at the NJ-Hi Railers club.  I will be at the club on Wednesday and will take track measurements of the TMCC & DCS signals and will disconnect the TMCC signal and see if it is easier to add/control a DCS engine. 

But in the mean time, I have some questions:

 Adrian –

-Can you provide some details on the DCS module which is mentioned above (is it a device that disconnects the TMCC “U” terminal from the track?). 

-You mentioned a DCS telemetry train, please tell me more about this device.        

 SD3R – Can you tell me more about your external DCS antenna system.

 Thanks,

Bob D

rad400 posted:

Adrian! posted:

bigdodgetrain posted:

Showed up Tuesday morning (5-29) for my regular run day.  The new board was installed per above.  We cleaned track like normal and began setting up for our running.  Two members brought MTH engines.  One MTH engine has not been in command mode for over 5 years.  We set this engine up (ps2) on the top black line near the rear exit door, and with their passenger cars fully lighted (non led) they pushed the find engine button on the remote,  within 10 seconds the engine was found and loaded into the remote.  They pushed start and it started. 

The second MTH engine (ps3) was not placed on until later in the day on the lower level green line, with the same results.   Only this time a legacy engine was in operation, a conventional engine was operation and the first MTH with all those lighted cars were in operation.  We have never been able to add an MTH engine when other engines were operating.

Just for drill while the both MTH engines above were operating and the legacy engine was in operation, I got out my rail-king evo ps3 placed it on the blue track near mell's diner and got "out of range".  But the remote loaded the other two engines.  I then moved the evo to behind the roundhouse on the blue line and the evo loaded in seconds, and ran all over the layout.  I was not willing to unplug the legacy system while a legacy engine was in operation.

 

during the day we have removed what we believed are 100 percent of the bulbs and the bulb holders. 

The only other thing we need to do is remove the loose ground wires.

I believe we are 100 percent better with our MTH set up.

Of course we must get the members who have had issues to come and run their MTH engines and report any issues they have.

Members who have issues must report what issues they have and not just state "my engine does not work"...

We need members to report what issues they have like "out of range", "no engine on track", "engine not found" and the location that they have these issues plus any other thing the remote tells you so we can address these issues.  

We are working on a check list to report issues and hope to have this check list available soon.

 

This is good news!

Your club already had a nice antenna in the ceiling but the connector is different (BNC) than the one on the TIU I gave you (SMA) so we couldn't hook it up yet and you're stuck with the short whip antenna I made out of a coax cable. The RF out of range will probably go away if you go back to the good antenna. I will order the SMA-to-BNC adapter and send it to you guys this week. Once you have good DCS in most places, we can use the telemetry train to look at the remaining bad spots and try to figure out why they are bad.

Adrian, SD3R

This is a great discussion, which I am hopping will address some of the DCS issues we are having at the NJ-Hi Railers club.  I will be at the club on Wednesday and will take track measurements of the TMCC & DCS signals and will disconnect the TMCC signal and see if it is easier to add/control a DCS engine. 

But in the mean time, I have some questions:

 Adrian –

-Can you provide some details on the DCS module which is mentioned above (is it a device that disconnects the TMCC “U” terminal from the track?). 

-You mentioned a DCS telemetry train, please tell me more about this device.        

    

 SD3R – Can you tell me more about your external DCS antenna system.

 Thanks,

Bob D

 

Hey there,

This lionel/DCS module is still being worked out so I haven't decided exactly how it should work yet. Part of me wants to go low tech and simple and just chop windows into the carrier for the DCS to pass through. That seems like it could come with new problems, so having it triggered is probably better. I'm thinking to use a pass transistor so it would adjust the signal voltage of the legacy signal. We could have an "1" voltage and "0" voltage for the two switch states. I think turning it all the way off (disconnecting it) is probably not necessary. I'm prototyping on my ARTY7 FPGA but still waiting on some test PCB layouts I drew up to arrive.

The DCS telemetry train is one of my older projects though it's constantly evolving. In the 5th generation we have now, I have a raspberry pi3 host bolted onto a flat car and one of those 4th order RC filters going to the pickups. I have a home-made scope (fast 12b A/D chip and a FIFO) triggering off the DCS waveforms, and then reporting the DCS excursion voltage to an LCD screen glued on top. Basically like an oscilloscope built into a train with a DCS matched filter already inside.

The SD3R basically did what our AGHR club did too. You lift the sad antenna (stick of wire) off the RF board, solder a coax to the same terminal (and solder the shield to the ground on the RF board). Then you goto a bulkhead (they use BNC we use SMA) and just buy a 900 MHz antenna on Amazon. I also did the same thing on my remote. It makes a big difference in terms of reception. Some discussion of the RF engineering basis is here. 

What kind of DCS issues are you having?

Adrian

The Lionel/DCS module you mentioned above, is that what you left behind with the SD3R club last week or was it something else?

Would you mind sharing the drawings on the DCS telemetry train.  I would like to build one for the NJ-Hi Railers.  It should make it easier to diagnose DCS signal issues on our 30'X200' layout.  Currently we are starting  to do DCS signal testing with a digital scope the club just picked up, but to have a scope on train wheels, that would make life a lot easier. 

DCS  issues:  At times, hard to load an engine into the hand held/tablet or to start up a DCS engine. We get one of those engine not found messages.  I will do a test on Wednesday to see if engines load easier when TMCC is turned off.  Last I checked the TMCC signal it was in the 5vpp range.  We also lose control of engines at various parts of the layout.

Thanks for your help!

Bob D

this is the module Adrian made for us.  The Angles gate Hi-railers use several. it is only a dcs system the legacy is connected elsewhere.

rtr12 posted:

GRJ, it sure does! Do you think any of Dale M's findings would help with this? Or is Adrian already aware of that info? I know you and PLCProf are and I know Dale was boosting the Legacy signal which seems to be somewhat opposite of this?  Just a thought here. It's all over my head...but I try to follow along anyway. 

Adrian,

just a lay person following along, but I noticed a difference in your tone generator frequency and what Dale Manquen found to be good Legacy/TMCC signal. That was 455Khz with a 5 volt excursion.

rad400 posted:

Adrian

The Lionel/DCS module you mentioned above, is that what you left behind with the SD3R club last week or was it something else?

Would you mind sharing the drawings on the DCS telemetry train.  I would like to build one for the NJ-Hi Railers.  It should make it easier to diagnose DCS signal issues on our 30'X200' layout.  Currently we are starting  to do DCS signal testing with a digital scope the club just picked up, but to have a scope on train wheels, that would make life a lot easier. 

DCS  issues:  At times, hard to load an engine into the hand held/tablet or to start up a DCS engine. We get one of those engine not found messages.  I will do a test on Wednesday to see if engines load easier when TMCC is turned off.  Last I checked the TMCC signal it was in the 5vpp range.  We also lose control of engines at various parts of the layout.

Thanks for your help!

Bob D

 

What I left in their club is a panel with the PSX breakers, chokes, and a rev "M" TIU with my diode boards inside.  The lionel/DCS switching thing isn't even finished being designed yet! (I'm thinking maybe getting into it this weekend).

I can share the telemetry train details (maybe on a separate post), but the thing is there's a lot of C++ code that drives it. I'll try to put up a thread about it this week.

Your DCS issues are typical of poor correlation (low DCS excursion or low effective SNR) similar to everyone else. A 5V carrier underneath sounds like too much based on the measurements above. I'm thinking of doing a video tutorial on some of these effects at some point...

Moonman posted:

just a lay person following along, but I noticed a difference in your tone generator frequency and what Dale Manquen found to be good Legacy/TMCC signal. That was 455Khz with a 5 volt excursion.

That would be before the addition of the TMCC Buffer.

gunrunnerjohn posted:

Moonman posted:

just a lay person following along, but I noticed a difference in your tone generator frequency and what Dale Manquen found to be good Legacy/TMCC signal. That was 455Khz with a 5 volt excursion.

That would be before the addition of the TMCC Buffer.

The 5vpp is a loaded reading with the buffer.  Other wise the loaded TMCC signal w/o the buffer is in the 1-2vpp range and TMCC engines runs poorly.  

Yep, with a layout like NJ-HR, there is a huge capacitive load on the buffer, and it does step on signals.  That's where the DCS signal has an edge, since at the NJ-HR, they have a ton of TIU's, and each channel is only driving a small part of the layout.

Adrian! posted:

rad400 posted:

Adrian

The Lionel/DCS module you mentioned above, is that what you left behind with the SD3R club last week or was it something else?

Would you mind sharing the drawings on the DCS telemetry train.  I would like to build one for the NJ-Hi Railers.  It should make it easier to diagnose DCS signal issues on our 30'X200' layout.  Currently we are starting  to do DCS signal testing with a digital scope the club just picked up, but to have a scope on train wheels, that would make life a lot easier. 

DCS  issues:  At times, hard to load an engine into the hand held/tablet or to start up a DCS engine. We get one of those engine not found messages.  I will do a test on Wednesday to see if engines load easier when TMCC is turned off.  Last I checked the TMCC signal it was in the 5vpp range.  We also lose control of engines at various parts of the layout.

Thanks for your help!

Bob D

 

What I left in their club is a panel with the PSX breakers, chokes, and a rev "M" TIU with my diode boards inside.  The lionel/DCS switching thing isn't even finished being designed yet! (I'm thinking maybe getting into it this weekend).

I can share the telemetry train details (maybe on a separate post), but the thing is there's a lot of C++ code that drives it. I'll try to put up a thread about it this week.

Your DCS issues are typical of poor correlation (low DCS excursion or low effective SNR) similar to everyone else. A 5V carrier underneath sounds like too much based on the measurements above. I'm thinking of doing a video tutorial on some of these effects at some point...

Adrain

I have already installed 20-PSX breakers and TVS on 10 of our Z4000/ZWL transformers.  As for the the TIU diode board upgrade, I am going to hold off for the time being.  In the 6 months that I have been monitoring the DCS output signal, I have not seen any  "0" signal outputs.  I have found some TIU DCS sig readings at 10vpp vs the 17-18vpp from a new TIU out of the box.  These are all no load voltage readings at the TIU output terminals.

Look forward to your post on the DCS telemetry car & Lionel/DCS switching.

Thanks again for all your efforts in trying to get to the bottom of the issues which many of us are having with large layouts.

Bob D 

I made a short summary video explaining the limitations of compatibility between DCS and TMCC/Legacy in terms of signal amplitude constraints. I'm 99% sure this is the issue we we're seeing in the SD3R club a few weeks ago. I also put a brief aside about why simple frequency filtering isn't an effective signal separation strategy with the DCS signal (a spread spectrum signal)

Thanks Adrian! Not sure I completely understand it all, but I do see the problem. Sure hope you can fine a solution, and thank you for all your efforts on the projects you have been tackling around here. I love following along even though I don't understand it all, it's still interesting. 

One day we will all have DCS and TMCC/Legacy systems that work even better than they were designed to work! I was always under the impression that these two systems worked well together. You have made some really interesting discoveries about all this! Please keep up you work it is much appreciated by many here, myself included!!

Again thank for the video and explanation, now a person with no electronic experience can understand what is going on.

When there are condition where a strong TMCC signal causes an issue for the DCS signal being decoded as Adrain discussed above, or any other reason where a weak DCS signal exists,  can a DCS buffer be built to increase the DCS signal?  Something similar to the TMCC buffer but at 3.75 Mhz range.

When a DCS system is in speed mode, you now have one way DCS communication between the TIU and engine.  So now you don't have to worry about the return DCS signal to the TIU.  Putting the DCS system in speed mode you loose track signal, info, and read functions, but increased DCS signal from a DCS buffer can address many poor DCS signal issues as the TMCC buffer is addressing in the TMCC world.

For those of us who play with large & extra large layouts (4,000-6,000sf range), a DCS buffer might be the answer to our DCS issues.

Thoughts, comments?

Thanks,

Bob D

There's no technical reason that a booster for TIU carrier wouldn't be possible, but I do foresee some issues.  First off, the signal is combined with the track voltage internally.  Given that fact, the only way I see it working is in passive mode where you would simply be impressing the boosted signal onto the 60hz power that is applied to the output of the booster.  It is possible to have a two-way device for the DCS signal, but I suspect the complexity would not be small.

gunrunnerjohn posted:

There's no technical reason that a booster for TIU carrier wouldn't be possible, but I do foresee some issues.  First off, the signal is combined with the track voltage internally.  Given that fact, the only way I see it working is in passive mode where you would simply be impressing the boosted signal onto the 60hz power that is applied to the output of the booster.  It is possible to have a two-way device for the DCS signal, but I suspect the complexity would not be small.

It’s not so easy. The 244 is about the only line driver with the slew rate needed and the gain is low so it won’t really amplify a weak signal.

maybe a step up transformer is the way to go since you want to deliver voltage, not power to the track 

I didn't say "easy".   You do have to deliver power as well, you'll be driving quite a bit of capacitance.

Adrian! posted:

gunrunnerjohn posted:

There's no technical reason that a booster for TIU carrier wouldn't be possible, but I do foresee some issues.  First off, the signal is combined with the track voltage internally.  Given that fact, the only way I see it working is in passive mode where you would simply be impressing the boosted signal onto the 60hz power that is applied to the output of the booster.  It is possible to have a two-way device for the DCS signal, but I suspect the complexity would not be small.

It’s not so easy. The 244 is about the only line driver with the slew rate needed and the gain is low so it won’t really amplify a weak signal.

maybe a step up transformer is the way to go since you want to deliver voltage, not power to the track 

Adrain

Would a tuned step up transformer be easier to design than the" lionel/DCS switching device" you were talking about earlier in the post.  The "lionel/DCS switching device" would address the issue when the Lionel signal was to strong for the DCS signal,  but would it address the issue of just poor DCS signal strength on a layout w/o TMCC.  

Would a step up transformer address both issues of strong Lionel signal & poor DCS signal?

Adrian! posted:

I made a short summary video explaining the limitations of compatibility between DCS and TMCC/Legacy in terms of signal amplitude constraints. 

 

Great explanation. Also, nice freehand, realtime illustration of a square wave superimposed on a sine!

Well done Adrian  Thank you.

Lou N

Former circuit designer for Right of Way and Train America Studios

rad400 posted:

Adrain

Would a tuned step up transformer be easier to design than the" lionel/DCS switching device" you were talking about earlier in the post.  The "lionel/DCS switching device" would address the issue when the Lionel signal was to strong for the DCS signal,  but would it address the issue of just poor DCS signal strength on a layout w/o TMCC.  

Would a step up transformer address both issues of strong Lionel signal & poor DCS signal?

A transformer opens a whole can of worms related to frequency response to avoid the square wave getting badly distorted. It would need to be a very broadband one. Also you have to reject the 60 Hz power so that makes everything even more complicated. The spreading code has repeats of 4, so the frequency content is down to 3.75/4M (940 KHz) and you also need up to the 3rd harmonic to keep things squareish (12.2 MHz). That's a pretty broadband transformer... over a decade of fractional BW which doesn't seem too reasonable.

As for an active amp, the ACT244 is not an amplifier it's a line driver, so the gain is low. It expects a 5V rail-to-rail square wave in on a high impedance and then it drives that square wave into a low impedance. Since they expect rail-to-rail in they can't amplify a weak signal and make it big again, they can just translate a large voltage from a high impedance to a low one, meaning you can't really use them as a down-stream amplifier.

Opamps are not anywhere near fast enough in terms of slew rate to pass a 3.75 MHz line code with the harmonics needed to keep it square-ish. Microwave amps are tuned so they won't pass all the broadband content. Limiting amps don't have the output drive strength.

For a down-stream module, you'd need to use an RC filter to loose the 60 Hz, go into a limiting amp to restore the TTL levels on a high impedance, then go back into another line driver (like another ACT244 or stack of them) to translate back to low impedance. Then you'd need to come up with some way to make that bidirectional.

rad400 posted:

Adrain

Would a tuned step up transformer be easier to design than the" lionel/DCS switching device" you were talking about earlier in the post.  The "lionel/DCS switching device" would address the issue when the Lionel signal was to strong for the DCS signal,  but would it address the issue of just poor DCS signal strength on a layout w/o TMCC.  

Would a step up transformer address both issues of strong Lionel signal & poor DCS signal?

This is correct. Making the DCS signal voltage excursion larger solves the a weak DCS signal and overcomes a tmcc signal inflating the correlator floor. The switching device I'm working on just stops the tmcc signal from being involved. However making the DCS signal larger would be really complicated.

Adrian,

We have a DCS on/off switch for each of our four separate tracks at theSD3R layout.  I am not sure of the effectiveness of this switch since we installed the "rev M" board.  But I was thinking: what if I used this switch to block the TMCC signal for a particular track.  Granted that the TMCC signal "wafts" itself over multiple tracks, but if I block the direct feed to a particular track it may be enough to allow the DCS signal to prevail for that particular track.  Granted that I may have to make some changes in the "common ground" in our layout, but I think this is problematic in several ways anyway.

Roger L. posted:

Adrian,

We have a DCS on/off switch for each of our four separate tracks at theSD3R layout.  I am not sure of the effectiveness of this switch since we installed the "rev M" board.  But I was thinking: what if I used this switch to block the TMCC signal for a particular track.  Granted that the TMCC signal "wafts" itself over multiple tracks, but if I block the direct feed to a particular track it may be enough to allow the DCS signal to prevail for that particular track.  Granted that I may have to make some changes in the "common ground" in our layout, but I think this is problematic in several ways anyway.

This could work!

If you wanted to make it even more effective to stop the track-to-track coupling, you can change to a SPDT switch and have the track on the common post toggle between the TMCC feed and earth ground on the two switch poles. If the outer rails are earth grounded the TMCC shouldn't be able to couple in a meaningful way.

Adrian! posted:

rad400 posted:

Adrain

Would a tuned step up transformer be easier to design than the" lionel/DCS switching device" you were talking about earlier in the post.  The "lionel/DCS switching device" would address the issue when the Lionel signal was to strong for the DCS signal,  but would it address the issue of just poor DCS signal strength on a layout w/o TMCC.  

Would a step up transformer address both issues of strong Lionel signal & poor DCS signal?

This is correct. Making the DCS signal voltage excursion larger solves the a weak DCS signal and overcomes a tmcc signal inflating the correlator floor. The switching device I'm working on just stops the tmcc signal from being involved. However making the DCS signal larger would be really complicated.

Tell me more about this switching device?  One of the principal benefits of the current structure is the ability to run TMCC/Legacy and DCS at the same time on the same tracks.  Are you maintaining this capability with your switching device?

Adrian! posted:

rad400 posted:

Adrain

Would a tuned step up transformer be easier to design than the" lionel/DCS switching device" you were talking about earlier in the post.  The "lionel/DCS switching device" would address the issue when the Lionel signal was to strong for the DCS signal,  but would it address the issue of just poor DCS signal strength on a layout w/o TMCC.  

Would a step up transformer address both issues of strong Lionel signal & poor DCS signal?

This is correct. Making the DCS signal voltage excursion larger solves the a weak DCS signal and overcomes a tmcc signal inflating the correlator floor. The switching device I'm working on just stops the tmcc signal from being involved. However making the DCS signal larger would be really complicated.

Adrain

Thanks for all your efforts in trying to address these DCS issues.  The four threads you are currently running on DCS are great and helps many of us to better understand the technical portion of DCS.  I am very interested to learn more about the DCS/Lionel switching device and try it out at NJ-HI Railers.  

rad400 posted:

Adrain

Thanks for all your efforts in trying to address these DCS issues.  The four threads you are currently running on DCS are great and helps many of us to better understand the technical portion of DCS.  I am very interested to learn more about the DCS/Lionel switching device and try it out at NJ-HI Railers.  

Hey,

Here's the idea of the switching device I'm working on...

The basic idea is to detect the very first instant when a DCS packet appears and turns on a switch that blocks the TMCC/Legacy signal, but only for the very short (millisecond time) while the DCS packet is going through. The TMCC/Legacy system won't notice the short delay since it's like 0.001 seconds per second or so, and the DCS system won't feel the effects of the legacy signal since it isn't present during the packet.

The hard part is detecting the packet quickly enough to turn on the switch. The DCS bit period is about 260ns (3.75 MHz), so you'd want to do the detection and turn on in like a 10th of that time... 26 ns. The only thing that can run that fast is an FPGA which is what I'm using.

Here's a doodle of what I've been testing so far:

How are you detecting the DCS signal in 26ns?  Are you just looking for a fast edge from the track?  Given the fact that you could have multiple TIU channels and multiple TIU's, would you have to do this detection for each output?

BTW, you keep saying 3.75mhz for the DCS signal, but all the stuff I've read on DCS says 3.27mhz.  Where exactly are you getting the 3.75mhz figure?  Just curious what the base carrier frequency actually is.

gunrunnerjohn posted:

How are you detecting the DCS signal in 26ns?  Are you just looking for a fast edge from the track?  Given the fact that you could have multiple TIU channels and multiple TIU's, would you have to do this detection for each output?

BTW, you keep saying 3.75mhz for the DCS signal, but all the stuff I've read on DCS says 3.27mhz.  Where exactly are you getting the 3.75mhz figure?  Just curious what the base carrier frequency actually is.

I'm luckly the SD3R club  I'm working on this for only has 1 TIU so I only need a 4 channel ADC. You're right, I'm triggering off the first rising edge. If I was doing this for my own club it would be epically complicated as I would have to coordinate 20 triggers!

I dunno, in the old post with my FPGA decoder I found 7.50 MHz works best which seems to imply a symbol rate of 3.75 MS/s. I'm sure I didn't read anything, I probably just measured it and copied it.

It looks like you're shorting the TMCC signal directly to earth ground.  That may not be good for the drivers in the TMCC command base, and I'm pretty sure my upcoming TMCC buffer won't be happy that's happening either.  Might I suggest you open the signal at the command base (or buffer output) and short the outside track to earth ground, it'll be less traumatic for the TMCC/Legacy base or buffer.

gunrunnerjohn posted:

It looks like you're shorting the TMCC signal directly to earth ground.  That may not be good for the drivers in the TMCC command base, and I'm pretty sure my upcoming TMCC buffer won't be happy that's happening either.  Might I suggest you open the signal at the command base (or buffer output) and short the outside track to earth ground, it'll be less traumatic for the TMCC/Legacy base or buffer.

You're probably right. The left pull down device can go away I guess. The FETs come in packs of 2 so I was trying to be sophisticated

I think abusive is the better term, at least in terms of the poor TMCC signal.

The key with this unit is probably putting it really close to the command base so that you don't get any radiated track signal as that actually can affect things.  However, with the outside track returned to earth ground, that should deal with most of that kind of issue.

I tried to cheap out and go microcontroller instead of FPGA. Forget it. Not even close to fast enough to catch the DCS signal.This is an atmega 328p overclocked to 30 MHz:

Direct polling:

Interrupt based:

I'll get xilinx vivado fired up now.

gunrunnerjohn posted:

How are you detecting the DCS signal in 26ns?  Are you just looking for a fast edge from the track?  Given the fact that you could have multiple TIU channels and multiple TIU's, would you have to do this detection for each output?

BTW, you keep saying 3.75mhz for the DCS signal, but all the stuff I've read on DCS says 3.27mhz.  Where exactly are you getting the 3.75mhz figure?  Just curious what the base carrier frequency actually is.

Okay folks.... While conceptually cute this idea is not going to work because of basic referencing. I got 1/3 of the way done before catching this.

The digital waveform on the TIU is referenced to the Layout ground, but the TMCC signal is referenced to the earth ground. So if you build a digital circuit (microcontroller/FPGA) referenced to the layout ground to grab the TIU waveform, then you won't be able to control a transistor because your DCS bottom is the legacy's top and you can't establish cutoff potential on the switching device.

If you sense the DCS with reference to earth ground that has to consider the 3.75 MHz signal flowing through the single legacy base wire, the base itself and the building wiring, so it really doesn't look like anything.

It's time to start looking for fast opto-couplers but 26ns propagation delay seems ridiculous.

I don't find any opto couplers with that speed, that's pretty fast.  Here's one that looks possible...

https://www.mouser.com/Product...qLppiUeN9C2DwQ%3d%3d

gunrunnerjohn posted:

I don't find any opto couplers with that speed, that's pretty fast.  Here's one that looks possible...

https://www.mouser.com/Product...qLppiUeN9C2DwQ%3d%3d

Okay a new plan has been formulated:

It's going to be the 3 pole RC filter to trigger a resettable monostable multivibrator using a 74HCT123. to trigger the DCS waveform off each TIU output. Then a galvanic isolator to leave the detector part that is referenced to the layout ground and enter the control side referenced to earth ground. So it'll need two isolated 5V supplies, one for each side (5Va and 5Vb).

I still need to think about the switching element. I'm on the fence between a simple jfet, and those TI analog mux products. Either way there needs to be bias under the TMCC signal to get the transistor to the operating point. Probably just (R+R)||C.

It's 25ns on the one-shot chip and 15ns on the coupler so we're about 15-20% into the period of the first bit already (266ns). Parts are ordered so I guess I'll breadboard it next week.

Is that the fastest one-shot you can find?  How much delay in the filter?

gunrunnerjohn posted:

Is that the fastest one-shot you can find?  How much delay in the filter?

The filter is negligible, like 2-3ns. That one-shot is DIP so it's good for prototyping!

I look forward to the results.  I doubt the brief interruption of the TMCC signal should affect TMCC/Legacy, they send multiple copies of commands.

gunrunnerjohn posted:

I look forward to the results.  I doubt the brief interruption of the TMCC signal should affect TMCC/Legacy, they send multiple copies of commands.

Some slow progress and updates on this. Here's the CMOS variant of that one-shot (CD74HCT123E) chip triggering off a DCS waveform through that RC filter. Good clean edges around the packet and no misfires in the middle. Blue is the output, yellow is input DCS. The initial delay is like 8.5ns end to end, but I still need to propagate this through the idolator and into the switch (about 18ns of margin remaining). I used Cx=10n, Rx = 10K, so that's nominally a 50us box per trigger received.

Overall shape:

Leading edge behavior:

Trailing edge behavior:

Packet procession behavior:

This detector is the hardest part (I think). The next is to transfer the reference from the layout ground (for DCS) to the earth ground for TMCC using a galvanic isolator, and then developing a graceful switching circuit that doesn't short out the TMCC base. It's going to look weird because it needs two 5V supplies referenced to the different grounds.

So for everyone else following this the idea who may be a little lost....the concept is we're building something that detects when DCS (the yellow waveform) is communicating between the TIU and train, and generating the blue box which will eventually inhibit the TMCC signal. Since the DCS packet is only about 1/500th of a second long the TMCC shouldn't notice the short time it's being inhibited. At the same time the DCS decoder performance improves because there isn't a 450 KHz TMCC signal inflating the apparent noise floor.

This looks like something that could be incorporated into my upcoming TMCC buffer, kill two birds with one stone.

Speaking of the TMCC Buffer, I was thinking about this issue and the increased amplitude signal from the TMCC buffer. 

The basic idea behind the TMCC Buffer is to provide a lower impedance drive to drive the capacitance of a large layout.  It increases the TMCC signal amplitude and uses a lower impedance driver to accomplish that goal.  Adding this circuitry would allow us to simply cutoff the TMCC signal from the buffer during the DCS packet interval.

gunrunnerjohn posted:

This looks like something that could be incorporated into my upcoming TMCC buffer, kill two birds with one stone.

Speaking of the TMCC Buffer, I was thinking about this issue and the increased amplitude signal from the TMCC buffer. 

The basic idea behind the TMCC Buffer is to provide a lower impedance drive to drive the capacitance of a large layout.  It increases the TMCC signal amplitude and uses a lower impedance driver to accomplish that goal.  Adding this circuitry would allow us to simply cutoff the TMCC signal from the buffer during the DCS packet interval.

So how about this...

1. When I do my board I'll put terminals with the Earth-referenced TTL out.

2. Then on your booster you can have a TTL in port that inhibits the driver.

That way we'll be compatible-ish.

Of course this clever trick will only work with 1 TIU. I think in our club the physical delay (speed of light) between the 5 TIUs is already way more than 25ns.

Hmm...  The whole point of this is mostly for large layouts, that's the only place that the TMCC Buffer makes sense. 

I haven't researched this, but if you have multiple TIU's, don't all the commands go out on all channels?  The TIU doesn't know which segment that the locomotive is, and it could have transitioned to a different place.  I suppose there's enough time for the signal to have skew based on each TIU has to process the incoming remote command individually.

I did have another thought.

The TMCC buffer increases the signal amplitude in an effort to combat the increased capacitance of a large layout.  The output buffer is capable of driving about a .1uf capacitance of the outside track to earth ground.  One of the issues is the amplitude, the buffer has a 3:1 gain.  I wonder if dropping the gain to unity and adding a larger isolation capacitor would allow it to drive the same capacitance but have less effect on the DCS signal?  This TMCC Buffer Schematic.pdf is what we have now.

gunrunnerjohn posted:

Hmm...  The whole point of this is mostly for large layouts, that's the only place that the TMCC Buffer makes sense. 

I haven't researched this, but if you have multiple TIU's, don't all the commands go out on all channels?  The TIU doesn't know which segment that the locomotive is, and it could have transitioned to a different place.  I suppose there's enough time for the signal to have skew based on each TIU has to process the incoming remote command individually.

I did have another thought.

The TMCC buffer increases the signal amplitude in an effort to combat the increased capacitance of a large layout.  The output buffer is capable of driving about a .1uf capacitance of the outside track to earth ground.  One of the issues is the amplitude, the buffer has a 3:1 gain.  I wonder if dropping the gain to unity and adding a larger isolation capacitor would allow it to drive the same capacitance but have less effect on the DCS signal?  This TMCC Buffer Schematic.pdf is what we have now.

Inside the TIU there's a mux (U502) which steers the FPGA to each of the each of the 4 channels one by one. Although everything happens together, if you look close you can see different channels (VARx, FIXEDx, ..) are on different time slices.

You could try to do a blanket window over all of them, but now your talking 0.2 seconds and TMCC/Legacy might start to take notice. Also physically... if you have two TIUs and either of them is more than 20 ft away from the TMCC input, that's already a good 23ns of delay right there.

Both DCS and Legacy are voltage-mode receivers so you don't want to lower the gain of that driver or you're directly dropping your SNR on TMCC.

A last one we could also think about (but it's really hard compared to the the switching idea) is to induce a copy of the TMCC signal on the center rail that closely mirrors the one induced on the ground. Nominally the TIU and Transformers are in common mode to the injected legacy signal meaning both + and - outputs of the TIU/transformer are going up and down at 450 KHz wrt the Earth ground and with the same phase and amplitude on center and running rails. Of course practically this is not the case since the capacitance of each side (center and running rails) to Earth ground is a little different and the circuitry inside the transformers and TIU aren't perfectly symmetric. Also it can be different at different locations along the layout due to series R and L of the track and wiring.

If the Legacy signal is very well balanced on both rails, the DCS decoder which senses things differentially should not see it, as it's on both ground and power rails. That's the operating principle of DCS when legacy is present.

So could we build a small circuit/board/module that senses the differential 450 KHz at some points along the track and copies the TMCC onto the center rail with just enough amplitude to balance them.

This would probably be feedback based...

-Have a diff amp across the rails with a high-Q 450 KHz filter in front

-Have some type of envelope detector on the filter to get a DC-ish value from the legacy tone

-Use that envelope DC to control a variable gain stage like your booster connected to the center rail and make them balanced.

This is probably an even better idea than what I'm doing, but it's pretty hard.

Here's a doodle of how that might look:

Adrian! posted:

Here's a doodle of how that might look:

Also you're pretty-much relying on the BPF to keep the DCS transients out of the loop. I doubt it'll be so good when the the inputs are being yanked +/-7V with ns rise and fall times. We could make the loop time constant really really really long (like seconds) so the DCS timescales don't affect where it settles.

Also^2 unlike the outside rail, the center rail is in blocks, so you're going to need a lot of these for a big layout.

One wonders if there's not an easier method.  How about a low-pass filter that simply couples the outside and center track together.  Obviously, it would have to pass the 455khz TMCC signal and block the DCS signal lowest frequency component, that's around 1mhz, right?  With that approach, you could do each DCS block.

gunrunnerjohn posted:

One wonders if there's not an easier method.  How about a low-pass filter that simply couples the outside and center track together.  Obviously, it would have to pass the 455khz TMCC signal and block the DCS signal lowest frequency component, that's around 1mhz, right?  With that approach, you could do each DCS block.

Need to block the 60Hz too....

Also it needs to be really low impedance to force the rails together. I looked at ceramic filters but they are all 3dB insertion loss meaning they don’t impose voltage well, plus they need the earth ground to be routed to them... not so easy 

Well, I don't know that we have to block the 60hz, a popular method of insuring that S-gauge has good TMCC reception is to tie the rails together with capacitors to couple the signal, they don't do anything to block the 60hz.

Trying to think outside the box here, since having the capability on every TIU channel to interrupt the TMCC signal seems to be a rather giant task for large layouts.

I'm not so sure that we need the amplitude from the TMCC buffer if we make the signal low enough impedance.  After all the command base manages to work with many pretty large layouts with it's wimpy output circuit.  One of the limitations of how much capacitance the buffer can drive is the 15V PP signal amplitude, it takes a bit of power to push that out.  Cutting that in half would allow a lower impedance drive of the TMCC signal.  Obviously, I haven't tested this, just tossing out ideas.

In thinking about this issue, I'm wondering why the Legacy signal has such a strong effect on the DCS signal.  After all, the Legacy signal is referenced to earth ground.  I'm wondering how the Legacy signal gets the drive to affect the DCS in the fashion illustrated.  Did you do any checking to see if there's something odd about that particular layout configuration?

John,

I'm wondering why the Legacy signal has such a strong effect on the DCS signal.

Good question. I'm wondering if it actually has any real effect at all.

In the past, any time there's been a perceived negative effect of the Legacy signal on the DCS signal, it's typically turned out to be due to one of the following:

• Faulty earth ground.
• Faulty command base power supply or AC power strip.
• Faulty command base.
• Legacy engines themselves (arguably the most prevalent reason).
• The problem wasn't due to Legacy at all.

 That is what I implied a while ago.  Layout construction and where the weak signal occurred.  Again, another one off type situation where we jump to technical conclusion.  G

Adrian! posted:

 

 

A lot of it is balance since it's two voltage sources stacked on top of each other.

The Legacy 455 KHz is from Earth ground to layout ground and then the DCS voltage is stacked on top from layout ground to layout center. They really rely on the 450 KHz potential being at the same at both outer and center rails, and not any type of frequency selectivity. If both rails are moving up and down together you can reject a good 1-2V, but if not of course the decoder performance falls off.

If you look at the data from before (above), you can consider the amplitude "differential voltage" or imbalance. I'm going to redo this test in balanced mode too so we have data.

I look forward to more data Adrian, I got to thinking about this issue and I was having some difficulty seeing the amount of interference based on the two signal sources.

Barry, that's precisely what I'd like to find out.  By understanding what Adrian was seeing at the test layout, we may be able to understand why it was happening.  At this point, I'm not saying there is or isn't a problem, only that more than one person has reported similar issues. 

I know even at our club, we've had on and off issues where disconnecting the Legacy would help the DCS, so I think it's important to understand the whys and wherefores.

I would say the SD3R club I'm helping is a special situation. They are a museum open 6 days a week so they can't just tear their layout down and rewire it from the ground. Ideally it would be best to go in and balance the legacy signal to be the same at the ground and center rail at every spot on the layout so it stops inflating the noise floor on the DCS, but it's not going to happen with their operational constraints. So I'm working out this switch board, which is probably overkill for most cases, but suits theirs well.

I'm posting because the forum is for discussing special cases.  We have your book for the usual stuff!

I find these posts interesting but not directly applicable to my layout as I've never had the issues described. I also did not throw away my tiu or legacy bases after reading them. 

Upon reading and following this post I was and still am under the impression that there is a problem with Legacy and DCS. After following for a long time I finally came to the conclusion that 1. There is a problem with a particular clubs layout and that layout only. 2. This issue had scared the igee begees out of me till I realized this is seems to be a electronic techo's in depth view into a problem that I now am thinking it is no where near the size he has made it. 3. Your advice is taken. DONE READING! I do thank you for your RESEARCH but now have concluded it did nothing but scare me. As a NEW Legacy and a 3 yr old on DCS I feel others in my area would feel the same way. The Title in all caps meant to me "Hey here is an important problem so beware and look out for it." Please understand I am not intending in any way to put you down or discredit you. I do agree with Barry that this is more a research issue than a problem for the masses. Thank you for your willingness to pursue the issue for this club and I wish you a speedy repair to the problem as I feel that is the issue, fixing the problem.

Respectively

Curtis

This is not totally "nonsense" as I've seen this very issue at two locations.  While it's generally not a problem, it is a potential problem for some, and a real one for others.  What I'd like to understand in more detail is how this effect is manifested in a real layout.  While injecting the signal on the bench is a very worthwhile exercise, and also a repeatable scenario, I'd like to understand the depth of the issue on real layouts.

As I have stated, I've actually seen this on our club layout, it's not just one layout.  I won't dispute that ours is "poorly wired" as it was initially wired for TMCC/Legacy only, so that could be a significant part of the issue.  What interests me is knowing enough to find out what the root of the problem is.

I find this information all very interesting, even though it's mostly over my head. I do like to learn about these things and other things electronic. It doesn't scare me or make me want to start re-doing my layout, as it all still runs just fine together here. I wired it specifically for DCS per Barry's book which has worked great since the beginning a few years ago. I added Legacy later on and it has worked flawlessly since as well. 

My layout is nowhere near the size of a club layout or many other's layouts that I have seen around here. That could and probably does make a big difference. However, if I ever do have problems this work by the more knowledgeable (than I am) folks here may very well help me (or others) solve that problem someday. Knowledge is a wonderful thing, and so is learning about things, IMO. 

There is no question that Barry is one of the pioneers in DCS. His DCS companion sits prominently on our table at the AGHR club layout. I have met Barry several times and he has been an incredible source of reference and information. His insight into DCS has helped many of us.

About a year ago, Adrian Tang joined our AGHR club. Adrian, a PhD, NASA and JPL engineer brings the under the hood understanding to DCS. We went through 10 TIU's in less than a year. Adrian discovered a flaw in the REVL. Working  in conjunction with Jason at MTH, they found the fix. New REV L's have the fix. We have had flawless operation and no TIU replacement since November.

These two gentleman are priceless for our hobby. Let's take advantage of them and not get into a pi...ng contest.

Jeff

Okay so let’s revisit the discussion and establish the facts:

1. Two large layouts (SD3R and AGHR) near me, and apparently two near GRJ experience a situation where disconnecting the legacy base significantly improves DCS performance (responsiveness, delay when adding engines, track signal test numbers). Others may have this too, but we only know of these four right this moment.
2. DCS is a CDMA packet with a bipolar line code which typically exhibits 13-14V pkpk excursion when everything is working well. This is confirmed to be the case in the two layouts near me, both have >13V of DCS excursion.
3. Legacy is a continuous wave carrier at 455 KHz and is applied between the layout ground and the earth ground.
4. The TIU output circuitry (red and black terminals) are after an internal transformer so they are only referenced to each-other, not earth ground. The TIU output network has a low output impedance meaning the Legacy carrier applied to the ground is copied onto the center rail as the TIU output transformer winding is floating with respect to earth ground.
5. Bench experiments show that the correlator in the DCS decoder architecture can only tolerate about 1.5V of this 455 KHz carrier at the input before the error rate becomes high. This effect is known in communication literature as “correlator noise floor inflation”. The presence of the carrier, in effect, lowers the average number of correlated bits per CDMA packet.
6. A DCS engine on the layout has no connection to, or knowledge of earth ground, only layout ground and layout positive (the TIU red and black terminals). That means that it can only see the voltage difference between the center and outside rails. Therefore the 455 KHz carrier must be appearing across the center and outside rails, not just between the 3 rails and earth ground, and it must be appearing on the order of 1-2V of amplitude in order to have any effect on the DCS system (based on the bench tests).
7. The only possible signal voltage scenario that explains this is that the legacy carrier at 455 KHz is not equal on the center and outside rail. This can occur in two possible ways: (iA). There is a path to earth ground at 455 KHz of modest impedance in the layout from either the center rail or outer rails, but not both. In this case the superposition onto the floating TIU is not balanced. (iB). The capacitance to earth ground from the center and capacitance from earth ground to the outside rails differ significantly.
8. Since the TIU is isolated by the output transformer the only explanation for case (i.a) is through the power source. Both layouts investigated use the PH180s which are isolated transformers so this seems unlikely. Also both layouts investigated have chokes between the track and PH180, so the impedance at 450 KHz must be pretty high. (i.b) Seems more likely and makes sense that it would be exacerbated in a large layout. A small layout will have a small difference in node capacitances, while a large layout will have a larger difference. A large difference in capacitance will create an amplitude difference between the center and outside rails, across the DCS decoder, and inflate the noise floor of the decoder.

Illustrations of nominal, case i.a and i.b voltage behavior:

To correct the i.a scenario the only option is to change the power source and ensure it's isolated. The chokes seem to do this automatically, but I've confirmed that the PH180 is an isolated power supply. With a multi-meter there is no voltage from either terminal to earth ground. I'm sure others here can confirm this also.

Then the possible solutions to correct a capacitive imbalance between center and outer rails (scenario i.b) are:

1. Rewire the entire layout making sure the wire load on TIU +/- are coupled tightly and well balanced. Probably the best option for small home layouts, not possible with large museum or club layouts that need continuous operation and that took 10+ years to build in the first place.
2. Temporarily inhibit the legacy carrier while the DCS packet is present, preventing it from inflating the noise floor in the decoder. This is the design I am working on. This will work well for large layouts with not a lot of TIUs (maybe 1 or 2). This is the SD3R case. The AGHR case is 5 TIUs so it's not a good solution for them becasue as you increase to 4-5 TIUs you have to monitor a lot of channels (20 for 5 TIUs). Further, those TIUs are probably not physically close to each other and still have to coordinate with an inhibiter of some form at the one legacy base meaning a lot of added wiring. The delay is also an issue because you have to inhibit the legacy quickly when the DCS appears. To respond after the first bit the design can tolerate only on the order of 25-50 ns delay.
3. The last option is to build some type of active circuit to ensure that the 455 KHz carrier is the same voltage for (earth ground to outside rail) and (earth ground to center rail) making it truly invisible to the DCS decoder. Using two of GRJ’s boosters in parallel with some type of feedback connected to control the gain stage may be able to accomplish this.

So unless anyone here has specific objections to anything stated here (and if you do please identify them specifically and lets discuss them... that's what the forum is for!), I suggest we continue with the design work and post the results to inform the rest of the community about the outcomes of the possible solutions above.

~Adrian

Adriani,

1. Rewire the entire layout making sure the wire load on TIU +/- are coupled tightly and well balanced. Probably the best option for small home layouts, not possible with large museum or club layouts that need continuous operation and that took 10+ years to build in the first place.

You proved my point. The culprit is the wiring. That's the root cause of the problem.

The fact that turning off the Legacy command base improves things is not the same as proving that the command base causes the problem. Rather, it's the wiring that causes the problem.

Wouldn't you agree?

OK....because of the many alerts we have gotten to the recent bantering on this thread, I spent valuable time reading every one of the posts.  I have deleted and edited those that seemed to me to push other people's buttons.  I will not do this again folks because I simply don't have the time so take heed....NO MORE PERSONAL REMARKS. 

Barry Broskowitz posted:

Adriani,

1. Rewire the entire layout making sure the wire load on TIU +/- are coupled tightly and well balanced. Probably the best option for small home layouts, not possible with large museum or club layouts that need continuous operation and that took 10+ years to build in the first place.

You proved my point. The culprit is the wiring. That's the root cause of the problem.

The fact that turning off the Legacy command base improves things is not the same as proving that the command base causes the problem. Rather, it's the wiring that causes the problem.

Wouldn't you agree?

Well I think this is perspective. From a user perspective (someone who only has the DCS/Legacy hardware they have and cannot change it) I would  agree with you, the layout wiring is not tightly enough and therefore not meeting the criteria for coexistence of the two signalling methods (SNR, balance, relative amplitudes) required.

From the designer's perspective (someone who is free to change the hardware to whatever) I would say the current principle of operation for TIU and Legacy to co-exist well makes a lot of assumptions  (SNR, balance, relative amplitudes) and those assumptions impose layout constraints that are too tight for the real-world layouts encountered.

I can't speak to the SD3R club, but the AGHR club re-wired the layout over the last 2 years with your book in hand, and it's a pretty good result. The wires are kept to length, tapped correctly, and run in tight pairs in all places, yet these effects are still there. I think in this case especially, the user has done what can be reasonably expected of them, and it's time to look at the design assumptions.

The imbalance is expected to scale with layout size....if you think about it physically, the 3 rail track has 1 center rail and 2 outside rails, so the design assumption that both capacitances are identical is already not a great one to make since there's literally twice the surface area on one node relative to the other. So the difference in cap developed will be like K(2Crail - Crail) where Crail is the capacitance of one rail, and K is some layout scaling factor. Second, the outside rails are one node and the center rail is another so the fringing effect will lead to the capacitance favored on the outer rails, especially where the track passes things connected to earth ground. From a design perspective I would say these layouts are exceeding the design envelope of the TMCC/Legacy compatibly principle. That is why we are here talking about design solutions.

Please, let's listen to Alan and simply discuss the issue rationally.  There's room for dissenting opinions, nobody here knows it all.

I don't think there's a lot of disagreement that the specific wiring of a layout quite possibly had a significant effect on this problem.  Our mission, if we choose to accept it, is to figure out how to solve this with a minimum of impact to the overall wiring.  I can tell you for sure that the larger layouts i see are not going to do a massive rewiring job, so that option isn't really on the table.  Only by really understanding why the interference exists can we hope to create a way to minimize it.

Adriani,

Let me share something with that, while not exactly on point, may provide some food for thought.

A few months ago, I installed a DCS Explorer on my son's and granddaughters' small 4X8 layout. It's 2 loops of RealTrax, with 4 RealTrax switches that provide a pair of crossovers between the loops. The switches use track power. Each has a lantern and a lighted controller. The layout is powered by a Z500 brick into the DCS Explorer, and then on to the tracks via a pair of lockons.

At all times, there are two trains sitting on the tracks, a Rail King diesel with 3 postwar Lionel illuminated passenger cars and a Rail King steamer with a lighted caboose. In addition, there's an illuminated accessory that works off track power that turns on with the layout.

The Lionel passenger cars are a new arrival and their addition seems to have caused the situation that I'm about to describe. I worked the following over the phone (Allan and the girls are 1,100 miles away).

My son and his two little girls use the DCS App on his iPhone and their Kindle Fire tablets. For some reason, my son recently reset the DCS App on all 3 devices, causing the two engines to be deleted from the app. When he attempted to re-add the engines, the following scenario evolved:

• The DCS Explorer was powered up in MTH mode and the DCS App connected to the network generated by the DCS Explorer.
• The DCS App was launched and a Refresh command was issued. The DCS App reported "No DCS Explorers found", although, as expected, track power was turned on and a watchdog signal was broadcast. Both engines remained dark and silent.
• My son shut down the DCS Explorer, reset the DCS App, reset the explorer and toggled the Home/MTH mode switch a few times. We then reattempted to get things to work.
• We were able to then get the DCS App to recognize and connect to the DCS Explorer about 90% of the time. However, when it did, it still reported "No engines to add".

What finally worked was the following:

• We physically disconnected the tracks from the DCS Explorer.
• We restarted the DCS Explorer and connected to its MTH mode WiFi network.
• We launched the DCS App and issued a Refresh command, The DCS App found the DCS Explorer.
• We reconnected the track and the layout powered up. Since the DCS Explorer only issues a watchdog signal at the time of the initial Refresh command, as expected both engines came up in conventional mode, bright and noisy.
• We added both to the DCS App without any issues whatsoever.

This workaround was 100% successfully repeatable. The permanent solution will be to replace the Z500 with a Z1000 for track power, and use the Z1000's accessory power for switch tracks and accessories.

I spoke with an EE friend (and well-known forum member) who is arguably the most knowledgeable person around as regards DCS hardware and protocols. I asked if an overcurrent demand could cause the DCS Explorer to behave in the described manner and allow the workaround solution that we implemented. He agreed that the overcurrent demand was more than likely the culprit.

While the layout at the club is in no way similar to my son's layout, perhaps you may see some small aspect of the issue that relates to your current (pun intended) club layout's issue.

As an aside, I've had my son install his old DCS Remote Commander receiver in passive mode to generate a watchdog signal whenever track power is removed and restored, along with an inline track power switch.