DCC issue with Heljan Turntable

Hi Brian

My opinion at this stage from what you have described and the YouTube video is as follows.

It is very likely that the TT bridge motor is a stepper motor and is told to step a number of times in a particular direction by the control panel.
The control panel holds the user data on where each entry/exit track position is relative to the zero datum as a number of steps.

The TT bridge PCB would have no knowledge of where the entry/exit tracks are.

I see no evidence that the TT well, pit or bridge incorporates any absolute position feedback, also it would cost too much for a £200 TT.

The only feedback that appears to be fitted is the IR emitter in the well side used to zero datum the motor controller in the TT bridge.

Every other movement is open loop and relies on the stepper motor not missing a step. For example if the bridge was to jam for a few steps it would stay out of alignment with the tracks until the the IR emitter was passed again. Small missteps would be accommodated by the chamfered track ends on the TT bridge and the entry/exit tracks.

The Tx/Rx interface between the control panel is a possibility, electrical interference, connector at the TT PCB or an interface component on the TT PCB but this would not explain how the track number on the control panel is correct without feedback from the TT PCB, which as I believe from above it cannot provide.

Given that the DCC sniffer detects no rogue commands and the track# on the control panel matches the TT position my next point of investigation would be to apply a digital scope to analyse the Tx/Rx connection between the control panel and the TT bridge and decode the communications which I would expect are simple in format.

Quite a mystery, I would be interested to know what the issue turns out to be when you solve it.

Jim

 

Hi Brian
Right, I stand, or rather, sit corrected

What is a 'chopper' in the context of this TT?
All this seems a lot of work, oh, and don't forget to enjoy your trains, I forget occasionally

Jim

 

Right Brian, as fitted to early optical computer mice.

What scale and standards are you building your garden railway to?

Jim

 

Wow, big enjoyment with all that space to play with, I'll keep an eye on that thread for sure, best of luck, Jim

 

Hi Brian,
I have the same issue with RR@co and my Walthers (Heljan) turntable (- weird random movements). I was just wondering if you ever found the cause of the problem and/or a solution?
Cheers.
Geoff

 

Dear "Brian A",

I joined this forum specifically to add to your extensive and detailed post about DCC problems with your Heljan 89121 turntable. I also have this model (in fact 2 - 1 as a spare as the first one blew up with the usual Err1 power issue), it also suddenly produces random movements and I have also gone through many of the same tests that you have. I run a Digitrax DCC setup and like you, use Railroad & Co.'s Traincontroller software (V8 Gold). I agree that these random movements at any time in an operating session ruin any chance of properly using the TT with Traincontroller, schedules, Autotrain etc. because half the time the TT is unlikely to be where TC was last told it was. As you say - "engine in pit" is the usual result!

There is one important diagnostic that you could check although I appreciate that you may no longer be using your #89121 with DCC - partly because of this seemingly intractable issue. I first read about this on an RMWEB post by "westaust55", who posted this discovery back in 2017.

Using the default base address of 57, my first DCC Track 1 address is accessed using ID=225, 'closed' or 'thrown'. My registered Track 2 address would therefore be 226, Track 3 = 227, and so on. I have 12 tracks orientated in pairs, so my twelfth and final position would be accessed using ID= 236. As for you, all this works fine with the Heljan's blue controller, calling Go/Set 1-12, or DCC "points" 225-236, or calling 225-236 'c' or 't' in TC's macros, push-button actions etc.

However, if I ADD 256 to these numbers, I get the same movements - as suggested by "westaust55". So, if I call, say, 227+256 = 483, the TT will ALSO move to Track 3. If I add another multiple of 256, so (228 (Track 4) + 2*256) = 740, the Heljan TT will move to Track 4 !! If I add 3*256 to my actual track IDs, I will get the same movements. I haven't tested it beyond ID=999, but the sequence of erroneous moves may well be infinite.

You could test this theory of adding one or more multiples of 256 to your range of TT DCC track position addresses and see if you get the same movements. To my mind this explains the seemingly random and uncalled-for Turntable movements. In my case, my actual points number 1 to 124, my TT should be restricted to the low 200's - where absolutely nothing else is used, but above about 400, I have several Digitrax SE8c boards which are switching signals. So, the switch of some signal on the other side of the layout from amber to green may call ID 742, and that will ALSO cause the Heljan #89121 to move to Track 5 - and so on. There is no range of accessible Heljan Turntable base addresses that, when multiples of 256 are added, do not result in conflict with signal boards etc. on my layout.

So, your observation that the DCC sniffer showed no untoward calls in the desired TT address range is correct - I found the same thing. In your conversation, the suggestion that one might use an Arduino interface to limit/filter the addresses that the TT controller sees is an excellent one, but is also a bit above my skill level. You use a Lenz DCC system, I'm using Digitrax, and 'Westaust55' was using NCE, so this is nothing to do with Command Station models or manufacturers.

It is quite simply, a big bug in the address handling firmware in the Heljan blue control box. When contacted by both you and Westaust55, they seemed to prevaricate or blame other vendors' equipment. I have now written to them too and even sent them the pictures they requested etc. If you can reproduce this specific behaviour of wrongly also interpreting/acting upon your correct addresses + multiples of 256, then the bug will be very well confirmed.

I hope that this has been interesting or helpful for you - please let me know what you think.

Martin Reed

 

Dear Brian (and your Pet-sitting mate!),

Your confirmation is excellent news and really explains not only what the Heljan blue control box is doing, but also what they need to do to fix this bug. I agree that there may be higher addresses (i.e. above the last Heljan registered track DCC ID) that are being called or switched that I'm not aware of. On my system, all the Digitrax boards also support "Routes" which may well involve these higher IDs. I never use these Digitrax routes and leave all of that to TC, but that doesn't mean that some of these IDs aren't being changed/called as points or signals are switched.

I too can do some more tests and 'sniffing', and am happy to report back on this forum. However, I feel that with your detailed contribution, Heljan now have plenty to work with - basically if they read the whole address in binary, rather than just the first 8 digits, the problem should go away and the resultant turntable action would be restricted to only exactly the registered addresses desired and called.

Thank you for your contribution to this. Heljan haven't got back to me with a course of action yet, but I can send them a synopsis of this confirmation too.

Cheers
Martin

 

Dear Brian (again),

I briefly tested the theory that other 'significant' binary numbers could also cause extraneous movements, but I only get the unwanted turntable moves with multiples of 256 added. Here are my quick results, as far as they go (using Base Address = 57 as before) :-

Correct/desired address Track 03 Track 04 Action
227 228 Turntable moves Trk 3 <-> 4 desired movement
add 256 to these No. 483 484 Turntable moves Trk 3 <-> 4 unwanted movement.
add 128 to these No. 355 356 No movement
add 64 to these No. 291 292 No movement
add 256 + 32 to these No. 515 516 No movement
add 256 + 128 to these 616 612 No movement
add 256 + 256 to these 739 740 Turntable moves Trk 3 <-> 4 unwanted movement.

Like you, I'll still try and understand exactly what is calling or changing these higher IDs on my layout - i.e. (in my case) Digitrax's unused "Routes" or something else.

Cheers
Martin

 

Gentlemen, this is very interesting to me. I had given up on using my Heljan TT dcc control but your posts have encouraged me to do some experimentation. I have a #81921 HO 90' turntable. My Command station is a Digitrax DCS100, I have a number of BDL168 occupancy detectors, DS64 accessory decoders, a DT402 controller and some arduino based accessory decoders and occupancy detectors. I also run Train Controller v8 Gold.
My TT is programmed with the default address of 57 and has 26 track positions. The address range is therefore 225 to 250. I have wired the blue box controller in accordance with the instruction manual in that a track feed supplies terminals 3 & 4, bridged to terminals 1 & 2. Using the blue box controller, everything works perfectly. Issuing switch commands from the DT402 or from Train Controller in the range 225 to 250 works perfectly. I tested your idea that issuing a switch command which is the address + 256 or 512 would activate the turntable and found that I could replicate your results exactly. I also tested switch addresses from 1 to 224 and 251 to 480 and found that there was only one anomaly, which I will come back to. From 481 onwards of course, I was back to the accessory address + 256 problem so I went no further. I can confirm that accessory addresses higher than 999 continue to cause the +256 problem as all of my signals have addresses starting at 1000.
Now to the anomaly. I found that issuing switch command 17 (My turnouts are in the range 1 to 40) sent the TT to position TR8. This doesn't fit into the binary number solution at all. TR8 has the address 232 which is 11101000 and 17 is 00010001 (Assuming my decimal to binary calculation is correct!!!). Perhaps someone can try and replicate this to check if the same thing happens?
I also experimented by changing the connections to the blue box. I left 1&2 connected to the dcc track supply and connected 3&4 to an independent 15v ac supply. The +256 issue remained, however the switch 17 anomaly disappeared. Again, perhaps someone might care to replicate that.
I made one final observation and that was when the track power is switched on, either using the DT402 or by starting Train Controller, the TT moved to TR25. This happened regardless of whether the power supply came from the DCC bus or the independent supply.
OK, so in reality, all that I have done is verified the results of others and posed a couple of extra questions. There is no doubt that there is a problem with the decoder on the TT and Heljan need to sort out the hardware or the firmware. In the meantime, my TT is set up as a test rig so I am happy to run tests if anyone wishes, the more information that we have, the better, I guess.
George

 

Evening All, I've been doing a bit more playing around with this with the following, disturbing observations. First of all, going back to my previous post, the anomaly that I had with switch 17 causing the TT to move to track 8 was being caused in Train controller. I have a signal with dcc address 1000 which was conditional on the position of turnout 17. Track 8 has address 232, when T17 changed position, the signal changed aspect. Address 1000 is 232 + 256 + 256 + 256 so that is why the turntable moved to track 8. Although that question now seemed to be resolved, a new problem arose. Issuing the switch command 17 now moved the turntable to Track 25 most times but not every time. I did some more investigating and this is what I found, I would be interested to find out whether other members can replicate this.
Brian mentions in Post #33 that he gets random movements with addresses below the range used by his TT and this fits in with what I have found.

I only had my DCS100 and DT402 throttle connected for this experiment (i.e. no other accessory decoders and no Train controller running)

I found that 1 or any multiple of 4 plus 1 moved the TT to track 25 (e.g. 1,5,9,13,17....101,201,401 etc)
I also found that 2 or any multiple of 4 plus 2 moved the TT to track 26 (e.g. 2,6,10,14...202 etc)

Sometimes this involves sending the same command twice, say Sw 001 c followed by Sw 001 c. In normal practise, it would be unusual to do this but it can happen which adds to the impression of random behaviour from the TT.

You might be wondering why I have programmed 26 tracks, it does seem a lot but in actual fact there are only 13 real tracks, the other 13 are simply the same positions with the bridge at 180 degrees. This allows me to program Train controller to not only move the bridge to the correct track but to keep the engine orientation how I want it to be.

So what happens if I just remove 1 track and therefore have 24 positions (12 tracks)? Well, this particular problem goes away although the +256 bug remains. The TT which moved to TR25 when track power was switched on has also disappeared.

If I shift the base address down from 057 to 056 and re-instate tracks 25 and 26, the problem doesn't manifest itself, suggesting that the problem lies with addresses 249 and 250 (Tracks 25 & 26 with a base address of 057)

If I then shift the base address to 058, all of the issues listed above return except that instead of tracks 25 and 26, the TT moves to tracks 21 and 22.

What are my conclusions from all of this?
1. The +256 bug is real and can be reproduced by anyone.
2. There is something special about addresses 249 and 250.
3. The Heljan decoder is fatally flawed and needs to be corrected.
4. In the event that Heljan do not rectify the decoder problem, it may be possible to programme other accessory decoders to avoid the addresses within the range used by the TT plus multiples of 256.
5. If there are other "special" addresses other than 249 and 250, the previous conclusion will be become more difficult to achieve!

Like others, I too have emailed Heljan but as yet have had no reply, if and when I do get one, I will post back here.

In the meantime, as I said in my previous post, I am very happy to conduct experiments with my turntable here.

All the best,

George