Reverse loop flashing on iTrain track plan when a loco runs on another section of track?

[WIMorrison]

Paul

 

I know we have been through these settings several times but here is a line by line comparison for you.

 

 

 

There are a few differences with the major one being that you are still using the old firmware though you have stated before that you have upgraded to the latest

 

I don't see the differences as major, the only real one (apart from firmware) is that you are not use Railcom Channel 2

 

 

Edited December 3, 2020 by WIMorrison

[model-trains]

I have programmed the DR5013's as follows

 

Module # - 1,2,3 and 4

 

Feedback address # - 101, 102, 103 and 104

 

Just looking at this section of your code Iain, brings me to ask a question.

 

<DCC>
    <FirstTurnoutModule>1</FirstTurnoutModule>
  </DCC>
  <RailCom>
    <ModuleNumber>6</ModuleNumber>

 

My Digikeijs modules are linked from the DR5000 in the following order...

 

DR4088LN

DR4088LN

DR5013-1

DR5013-2

 

DR5088RC

DR4088LN

DR5013-3

DR5013-4

 

Should DR5013's on the first control board be #3 and 4, not 1 or 2, or does it not matter?

 

Just looking for possibilities that could be causing my issue.

 

Paul

[model-trains]

12 minutes ago, WIMorrison said:

<RailCom>
    <ModuleNumber>6</ModuleNumber>
    <ReportDelay>500</ReportDelay>

 

Iain

 

I have 

 

 <RailCom>
    <ModuleNumber>6</ModuleNumber>
    <ReportDelay>500</ReportDelay>

 

you have 500, I have 1000

 

Should this be set to 500?

 

[WIMorrison]

the number of the DR5013 makes no difference, it is only important if you are reading and writing remotely to them using Loconet, but good practice to number them sequentially but you can have them in any order (and connected in any order)

 

Step 1 - Upgrade the firmware

Step 2 - test after updating firmware

Step 3 - change the relevant differences one by one to see if any of them clear the issue

[model-trains]

16 minutes ago, WIMorrison said:

  <ReportContainer>false</ReportContainer>
    <LogDetection>false</LogDetection>
    <UseChannel2>true</UseChannel2>
    <DetectCount>10</DetectCount>
    <PolarityCount>2</PolarityCount>
    <PolarityDelay>150</PolarityDelay>
    <MuxTime>33</MuxTime>
    <Global>

 

I have false, false, false for the first 3 lines, should my last one be 'true'?

 

Detect count, I have 15, should I change to 10

Polarity delay, I have 250, should this be 150

 

I guess the best question is, should I change everything except the module number and the feedback number to your settings?

 

[WIMorrison]

have you upgraded the firmware? absolutely no point in changing anything until you have done that.

 

 

[model-trains]

11 minutes ago, WIMorrison said:

the number of the DR5013 makes no difference, it is only important if you are reading and writing remotely to them using Loconet, but good practice to number them sequentially but you can have them in any order (and connected in any order)

 

Step 1 - Upgrade the firmware

Step 2 - test after updating firmware

Step 3 - change the relevant differences one by one to see if any of them clear the issue

 

 

I recall you saying the numbering didn't matter, so that part is fine.

 

I DID upgrade the firmware for all 4 DR5013's, before setting the data and exporting the files.

 

I can remove them and upgrade firmware on all 4 again if you think it is worth a try.

 

Although I have 4 DR5013's only 2 are added to the system, the inner loop works without issues, it is only the outer loop that is giving issues. 

 

I have just checked the exported data for DR5013-1 and 2, the data is identical in each, apart from the device number and feedback number.  This is what makes this seem so strange, the inner loop works without an issue.

 

Edited December 3, 2020 by model-trains

[model-trains]

Bottom of the exported data is the version number, I take this to be the firmware version number?

 

</ReverseLoop>

<Version>1.0.0</Version>

 

[WIMorrison]

1 minute ago, model-trains said:

 

 

...

 

I did upgrade all 4 DR5013's, before setting the data and exporting the files.

 

I can remove them and upgrade firmware on all 4 again if you think it is worth a try.

 

...

 

 

The exported data shows that you haven't upgraded it - look at the last line

 

the other 2 aspects to check are, if you disconnect the track connection from the dr5013 does the unit still flash occupancy? If not then the track connection is at fault (A), if it does then you are a DR5013 issue.(B)

 

(A) - reconnect the wiring bit by bit and see when it starts flashing, that is where the fault lies.

(B) - swap the unit out for a spare

 

 

 

[model-trains]

23 minutes ago, WIMorrison said:

The exported data shows that you haven't upgraded it - look at the last line

 

the other 2 aspects to check are, if you disconnect the track connection from the dr5013 does the unit still flash occupancy? If not then the track connection is at fault (A), if it does then you are a DR5013 issue.(B)

 

(A) - reconnect the wiring bit by bit and see when it starts flashing, that is where the fault lies.

(B) - swap the unit out for a spare

 

 

What is the latest firmware version?

 

Regarding your second comment, this is a good check. I disconnected the outer loop track connection of the reverse loop with the issue, I them ran all three locos, one at a time, that had interference flashing when running, there were no issues, so it is back to item A.

 

Edited December 3, 2020 by model-trains

[WIMorrison]

Paul

 

The latest version of the firmware is 1.1.0 as shown in the last line of my XML sheet - your XML shows 1.0.0

 

Version 1.1.0 was issues at the end of October 2019

[model-trains]

5 minutes ago, WIMorrison said:

Paul

 

The latest version of the firmware is 1.1.0 as shown in the last line of my XML sheet - your XML shows 1.0.0

 

Version 1.1.0 was issues at the end of October 2019

 

 

That makes sense then, the date I exported the data following the upgrade and set up was 12 August 2019.

 

Paul

[model-trains]

I have updated the firmware to 1.1.0    

 

I have changed the settings in the module that gave issues, (#2 -102) to your settings.

The one I cannot find, I am not sure which setting it is in the module options.

 

In <LocoNet>

You -  <SenseReport>1</SenseReport>

Me  - <SenseReport>0</SenseReport>

 

[WIMorrison]

are you comparing with your 10/19 export made with V1.0.0 of the software or a new export made with v1.1.0? you cannot compare to a v1.0.0. config if you have upgraded. 

 

amend the XML to your values and read it back in to get the same config.

[melmerby]

Blimey.

I didn't know setting up a reverse loop could be so complicated.

 

[model-trains]

1 hour ago, WIMorrison said:

are you comparing with your 10/19 export made with V1.0.0 of the software or a new export made with v1.1.0? you cannot compare to a v1.0.0. config if you have upgraded. 

 

No, I was making the changes in the module to match your settings.

 

1 hour ago, WIMorrison said:

amend the XML to your values and read it back in to get the same config.

 

That makes more sense!

 

Thanks

 

[model-trains]

1 hour ago, melmerby said:

Blimey.

I didn't know setting up a reverse loop could be so complicated.

 

 

Hi @melberby,

 

The reverse loops are themselves working, the issue was interference, causing flashing when a loco is else where on the layout.

[model-trains]

UPDATE

 

All 4 DR5013 have been removed, each one has been factory default set, then upgrade firmware again to get a clean start.

 

Taking the forth module the data is now...

 

<?xml version="1.0"?>

-<DR5013 xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

-<LocoNet>

<Purge_Time>0</Purge_Time>

<FastClock_Rate>0</FastClock_Rate>

<FRED_Timing>false</FRED_Timing>

<Baudrate_Tuning>110</Baudrate_Tuning>

<Comparator_Tuning>1.8046875</Comparator_Tuning>

<LN_ReportAfterPowerOn>false</LN_ReportAfterPowerOn>

<SenseReport>1</SenseReport>

<RailComReport>2</RailComReport>

</LocoNet>

-<DCC>

<FirstTurnoutModule>1</FirstTurnoutModule>

</DCC>

-<RailCom>

<ModuleNumber>4</ModuleNumber>

<ReportDelay>500</ReportDelay>

<ReportAfterPowerOn>true</ReportAfterPowerOn>

<Report7D>false</Report7D>

<ReportRX8>false</ReportRX8>

<ReportSpeed>false</ReportSpeed>

<SpeedDelta>3</SpeedDelta>

<ReportQoS>false</ReportQoS>

<QoSDelta>5</QoSDelta>

<QoSSuppress>10</QoSSuppress>

<ReportContainer>false</ReportContainer>

<LogDetection>false</LogDetection>

<UseChannel2>true</UseChannel2>

<DetectCount>10</DetectCount>

<PolarityCount>2</PolarityCount>

<PolarityDelay>150</PolarityDelay>

<MuxTime>33</MuxTime>

-<Global>

<FeedBackAddress>104</FeedBackAddress>

<FeedBackEnabled>true</FeedBackEnabled>

<FeedBackTimeout>500</FeedBackTimeout>

<BlockAddress>104</BlockAddress>

<BlockEnabled>true</BlockEnabled>

<DirectionInvert>false</DirectionInvert>

</Global>

</RailCom>

-<ReverseLoop>

<StartUpDelay>450</StartUpDelay>

<OffDelay>150</OffDelay>

<TurnoutMode>0</TurnoutMode>

<TurnoutState>1</TurnoutState>

<TurnoutAddress>0</TurnoutAddress>

<s0Address>0</s0Address>

<s1Address>0</s1Address>

<s2Address>0</s2Address>

<s3Address>0</s3Address>

<TrackAddress>104</TrackAddress>

<ShortDelay>75</ShortDelay>

<ShortReport>0</ShortReport>

<RetryDelay>500</RetryDelay>

<AutoRetry>true</AutoRetry>

</ReverseLoop>

<Version>1.1.0</Version>

</DR5013>

 

Do I leave FirstTurnOutModule 1 for all 4 modules?

 

-<DCC>

<FirstTurnoutModule>1</FirstTurnoutModule>

</DCC>

-<RailCom>

<ModuleNumber>4</ModuleNumber>

 

Modules 1 and 2 have been fitted back to the layout, module #1, feedback #101, module #2, feedback #2

 

I have done this so as to try another angle to the issue checking, I have added them back the opposite way. #102 was connected to the outer track and is now connected to the inner track, and visa versa.

 

My theory here is, if there was a wiring issue, I would expect the outer track still to show an error, that is if the firmware and changes to the module do not solve the issue. 

 

Having now tested it I can only confirm that the error is still evident, but it is now the inner track that has the frequency flashing issue???

 

I am now thinking that maybe the best thing to try next, is to change the #102 DR5013 and add in its place #103 or #104 module which I have for the other end of the layout, then test for the fault again. Maybe it is module 2 #102 that is causing the issue, I welcome all comments.

 

I am finished for tonight so will check here tomorrow before doing anything else.

 

Thanks to all for your help.

 

Paul

[melmerby]

4 hours ago, model-trains said:

 

 

Hi @melberby,

 

The reverse loops are themselves working, the issue was interference, causing flashing when a loco is else where on the layout.

OK

I'll rephrase it

 

Blimey.

I didn't know setting up an occupancy module could be so complicated.

 

Seriously, I can understand the frustration these sorts of things cause.

I just spent 3-4 hours trying find a "semi-short" on my layout. (Fortunately I have heavy duty, 30A,  screw connectors every so often so can isolated sections easily.)

There was just enough current flowing to trip the breaker at 3A, it wasn't instant it took noticable time (up to a second) to go.

I traced it to a push on connector on a Tortoise point motor.

There is lateral play in the commonly supplied one which over time can move sideways slightly with the vibration of trains passing over it and start to short adjacent PCB tracks.

I have replaced a few of them them with soldered joints over the years.

[Michael Hodgson]

19 hours ago, WIMorrison said:

The current draw needed to make a DR50xx device show occupancy is much higher which means that there are significantly less sensitive and to date I haven’t heard of false signals on a DR5013 or DR5088RC.

 

 

Probably not relevant to the OP's problem, but doesn't this mean a resistive axle that works OK on a 4088xx might fail to trigger a railcom detector?  If so, you presumably need to use lower resistor values for reliable operation if you have any 50xx devices

[KingEdwardII]

13 hours ago, melmerby said:

Blimey.

I didn't know setting up a reverse loop could be so complicated.

 

 

I said right at the start that the DR5013 is a complex beastie ;-)

 

The manual shows 6 different configurations - and those are just the simple cases!

 

Digikeijs also under-explain the setup and programming.

 

Given that the fault moves with a particular DR5013 unit, then it seems most likely to me that this particular unit is faulty or is misconfigured.  Since you have other DR5013 units to swap it with, Paul, I would start with that and consider returning the unit that is causing the trouble for a replacement. Digikeijs might like to fathom the nature of this failure to ensure that it does not recur on other units.

 

My own preference for the DR5013 setup is to use the configurations with sensing track sections and avoid the idea of ever having a short which must be detected in order to flip the track polarity (i.e. one of configurations 3 - 6 in the manual). But that is clearly more complex in wiring and configuration...

 

Mike.

[WIMorrison]

6 hours ago, Michael Hodgson said:

 

Probably not relevant to the OP's problem, but doesn't this mean a resistive axle that works OK on a 4088xx might fail to trigger a railcom detector?  If so, you presumably need to use lower resistor values for reliable operation if you have any 50xx devices

Absolutely correct. A resistive axle resistor for a DR5088RC should be drawing 15-20mA whereas for the DR4088xx needs to be 1-5mA. 
 

other aspects that’s affect the value are the track voltage because with a 12v track voltage the resistor is on 2/3 of the value needed for 18v.

 

the same applies to the shunt resistance used on the DR4088xx to resolve false signals, the track voltage needs to be considered. 

[Nigelcliffe]

9 hours ago, melmerby said:

.....

There was just enough current flowing to trip the breaker at 3A, it wasn't instant it took noticable time (up to a second) to go.

I traced it to a push on connector on a Tortoise point motor.

There is lateral play in the commonly supplied one which over time can move sideways slightly with the vibration of trains passing over it and start to short adjacent PCB tracks.

I have replaced a few of them them with soldered joints over the years.

 

Can be fixed by gluing a piece of square section plasticard at each end of the inside of the connector.   There seems to be a mis-match between the PCB on the Tortoise and the commonly available edge connectors.  

 

- Nigel

 

[Andymsa]

3 minutes ago, Nigelcliffe said:

 

Can be fixed by gluing a piece of square section plasticard at each end of the inside of the connector.   There seems to be a mis-match between the PCB on the Tortoise and the commonly available edge connectors.  

 

- Nigel

 

I don’t use edge connectors for this very reason on tortoises, see how I do it in general modelling questions and tips.

[model-trains]

4 hours ago, KingEdwardII said:

Given that the fault moves with a particular DR5013 unit, then it seems most likely to me that this particular unit is faulty or is misconfigured.  Since you have other DR5013 units to swap it with, Paul, I would start with that and consider returning the unit that is causing the trouble for a replacement. Digikeijs might like to fathom the nature of this failure to ensure that it does not recur on other units.

 

That was where I ended last night Mike, but I wanted to see what you guys suggested overnight.

 

After months of wire tracking, convinced it had wiring part incorrectly, then taking time off to do speed measurement and controlled stopping, I came back to wire checking again, literally not getting anywhere. Sometimes I find it worth leaving an issue and coming back to it later, but in this case that didn't work either. 

 

Issues as they have unfolded...

 

I made mistake number one, due to not having any real track to test on, I used one loco only, the rest were still in their boxes, had I used more than one at that time I would have realised the issue was not with every loco, easy said afterwards but when a problem persists it is easy to zoom down into it and be blinkered of the logic of trying another item (For me anyway)

 

Doing the speed measurement and controlled stopping highlighted this issue, so one by one, I was then able to work out which loco caused the issue, directly or indirectly, and which didn't. 

 

So with the help from you guys, we have been squeezing out possibilities. After changing DR5013-101 and 102 and seeing the issue followed the DR5013-102 it seemed it had to be this module. This morning after reading all the replies, it made sense, as you suggest, to remove DR5013-102 and replace it with one I have for the other end, so I used DR5013-104. I then ran all 4 locos on the speed measurement track, this and other parts of the track outside the reverse loop blocks had previously shown the interference flashing in the reverse loop, the locos which had previously shown the issue were Royal Signals P6, Class 37 and Class 66040 and 66111. Brilliant this time there were no issues at all. I haven't tried the reverse loop as board-1&2 are upright at present ready for point motors, but I have no concerns here as they worked previously. I have 17-18 Cobalt slow action point motors to setup and add to these boards, once this is done I can test all track, blocks and reverse loops fully, then join them and move forwards. 2021 should at last see some positive progress, I look forward to this and 'Playing Trains'.

 

Paul