ZTC accessory operation

[philg]

I’m just starting out with some Roco “under ballast” point motors - https://www.roco.cc/en/product/220770-0-0-0-0-0-0-005002-0/products.html 

 

Their address is programmed using a capture method. With the motor in programming mode, just send an operating command

 

It works brilliantly, apart from one thing. If I program an accessory address from a ZTC 511, they will NOT respond on an NCE or JMRI system. And vice versa

 

Looks like ZTC is not programming the actual address that I think it is

 

Hope this is making sense and someone can shed light on it

 

Many thanks

[Nigelcliffe]

Its the +/- 4 problem.  

 

Try again, with an address offset by 4 in either direction. 

 

There's a hole in the DCC specification.  Some makers read a part of the spec one way, and some a different way.  Both interpretations are understandable.   Unfortunately they give different ranges of addresses for accessory decoders.  One starts counting at "0" and the other at "1".  Because accessory decoders are in groups of four, this leads to the offset of +/-4.    

 

Its one of the main reasons that accessory device makers use the "learn" approach to programming them.  You don't have to explain the multiple ways to address things in the instructions.  It works until someone moves their accessory decoders from one system to another !

 

- Nigel

 

[philg]

Interesting. I’ll also look at a +/-1 offset too. If, as you say, someone starts at 0 or 1 this may be all I need

 

A real pain I can’t query what’s exactly in the address cvs

 

I’ll report back later (and I have to admit to a memory of ZTC in the REALLY early days insisting that they knew better than most

 

Phil G

[philg]

Well, this seemed so logical, but....

 

if I program to address 1 with ZTC, it doesn’t respond on NCE to any address from 1 through 5

 

if I reprogram to 1 on NCE, ZTC doesn’t operate it on address 1 through 5

 

Now open to the next suggestion

 

I AM grateful for the thought though - shame it wasn’t the correct answer
 

[Nigelcliffe]

Try again, but program the device to 5.  Then try addresses 1 to 9.

 

[philg]

1 hour ago, Nigelcliffe said:

Try again, but program the device to 5.  Then try addresses 1 to 9.

 

Ooh. Good point. Span +/-4 from BOTH ends

 

I’ll try again this evening

[philg]

OK I couldn’t wait. Now I wish I had

 

programming to address 5 with ZTC, it doesn’t respond to ANY address from 1 to 9 on NCE or JMRI

 

Programming to address 5 with NCE, it doesn’t respond to ANY address from 1 to 9 on ZTC

 

I guess it’s not a huge issue, but as these motorised points are self-contained it would be handy if they were interchangeable without having to be reprogrammed

 

Im leaning towards ZTC being the outlier as NCE and JMRI seem to be interoperable....

[Nigelcliffe]

I'm stumped, and as you can't read back from those motors, not easy to diagnose. 

I'm assuming in each of your tests, the motors work correctly on their original system.  Thus, programmed on ZTC and works on ZTC,  programmed on NCE and works on NCE.  

 

If you want to dig further, needs an accessory decoder which can be read from programming instructions.   Or a means to "sniff" DCC packets from the track to see what's being sent (can be done with an Arduino and a few components).  

 

 

JMRI is slightly irrelevant to the question of interoperability.   

It is possible to attach ZTC to JMRI, read the JMRI website for details of what can and cannot be done with ZTC equipment. 

 

 

- Nigel

 

[philg]

Yeah, works fine ON the system it was programmed on. But not the other

 

i use JMRI with my NCE system - and it also shows what is being sent to the track

 

I did have a DCC packet sniffer that connected to the audio-in of my long-gone laptop

 

i may search around to see what (if any) sniffers are out there

 

thanks for your help though

[philg]

Well, I was sure SOMEONE would be selling a DCC Sniffer - but it seems guidance to build my own is the best I can get

 

Tricky - I’m from the BBC Micro generation, not the Arduino one

[Nigelcliffe]

47 minutes ago, philg said:

Well, I was sure SOMEONE would be selling a DCC Sniffer - but it seems guidance to build my own is the best I can get

 

Tricky - I’m from the BBC Micro generation, not the Arduino one

 

Arduino isn't that far from BBC Micro to be honest....    Programming is a fairly simple language, and you don't need to do any of that to load some code.   Hardware to add around it is hardware (transistors, resistors, etc..).     
A "teach yourself Arduino" box set from Amazon/ Ebay is around £30, hardware, software CD and enough bits and pieces to connect some circuits. 

 

I'm also from the ZX81 / BBC generation.   

 

 

Being pedantic, JMRI reports what the NCE system "says" its doing.  It may be doing something else, and what's going to the track may be different.  Hence "sniffing" the actual track output.    However, I'd not expect anything rogue in an NCE system for these sorts of accessory instructions.  

 

- Nigel 

[philg]

Cheers Nigel

 

I’m actually using the JMRI Panel application as well as the NCE system itself. Although JMRI is talking to the NCE USB interface......

 

Maybe I’ll need to go down the Arduino route 

[smokebox]

Arduino DCC monitor build - https://www.Hornby.com/uk-en/forum/post/view/topic_id/7705/?p=4

 

Earlier pages are more relevant too.

Edited November 14, 2020 by smokebox
Reasons

[philg]

Hmmmm. I think what I really need is someone who’s built a stand-alone DCC sniffer for themselves and fancies a bit extra “pocket money” by building another one

[philg]

 

I FINALLY got the old DCC Sniffer (SoftSniff) working (I had to find a Windows XP machine to run it on)

 

When I operate accessories 1 or 2 from ZTC, the sniffer confirms that I am operating accessory 1 or 2

BUT when I do the same from my ZTC 511, I see accessories 1793 and 1794 being operated

 

Some head scratching later I decided to look at those addresses in binary

1793 is 11100000001 and 1794 is 11100000010

 

Given that accessory decoder addresses are split across CV1 (6 LSB) and CV9 (3 MSB) it looks like the bits in CV9 haven't been zeroed!

 

Of course nobody would notice unless they were either porting accessories between DCC systems OR tried to use accessories in the 1793 range AND in the 1 range

 

At least I see some pattern now :) When I take accessory #3 to NCE it indeed operates as accessory #1795!!!

[Nigelcliffe]

Well done in solving it.  

Good old ZTC.  Solid metalwork, and not sure about the insides.   I wonder if anyone else has been there before, because it implies that manually programming accessories via CV changes would also fail (failing to set CV9 to the "ZTC 1792 offset"). 

 

- Nigel

[philg]

On 18/11/2020 at 20:44, philg said:

 

I FINALLY got the old DCC Sniffer (SoftSniff) working (I had to find a Windows XP machine to run it on)

 

When I operate accessories 1 or 2 from ZTC, the sniffer confirms that I am operating accessory 1 or 2

BUT when I do the same from my ZTC 511, I see accessories 1793 and 1794 being operated

 

Some head scratching later I decided to look at those addresses in binary

1793 is 11100000001 and 1794 is 11100000010

 

Given that accessory decoder addresses are split across CV1 (6 LSB) and CV9 (3 MSB) it looks like the bits in CV9 haven't been zeroed!

 

Of course nobody would notice unless they were either porting accessories between DCC systems OR tried to use accessories in the 1793 range AND in the 1 range

 

At least I see some pattern now When I take accessory #3 to NCE it indeed operates as accessory #1795!!!

It may be more subtle than I suspected initially. According to the NMRA specs, the three msb of the accessory address must be INVERTED. So if they are zero, they should be sent as 1s. Because ZTC sends them as zeros, the decoder THINKS they should actually be 1s!  Sure enough, if I program one to address 1793 on ZTC, NCE does recognise it as address 1

 

Pretty sure this is as clear as mud

 

Im going to chat to ZTC next week. I may also have an obsolete firmware version......

[philg]

Well, seems that “this is what happens when you mix DCC systems”

 

Not that this us the best answer, but at least it’s AN answer, and I now understand why you need to be careful programming accessories on one system and using them on another. Glad this doesn’t happen with mobile decoders!

[Nigelcliffe]

5 minutes ago, philg said:

Well, seems that “this is what happens when you mix DCC systems”

 

Not that this us the best answer, but at least it’s AN answer, and I now understand why you need to be careful programming accessories on one system and using them on another. Glad this doesn’t happen with mobile decoders!

 

I think it looks like ZTC found a unique way to implement the accessory protocol.   I think that would fail NMRA-DCC compliance testing.  

 

 

- Nigel

 

 

[Combe Martin]

Considering that the software in the ZTC controller has been completely re-written in a different language for the 611, I wonder if this has been 'fixed/changed' in the 611.

 

Is there anyone out there with a 611 who used to have a 511 and who has ZTC 304 accessory decoders or the ZTC DCC point motor that were originally programed on the 511.   Did they need re-programming ?   

[philg]

23 minutes ago, Combe Martin said:

Considering that the software in the ZTC controller has been completely re-written in a different language for the 611, I wonder if this has been 'fixed/changed' in the 611.

 

Is there anyone out there with a 611 who used to have a 511 and who has ZTC 304 accessory decoders or the ZTC DCC point motor that were originally programed on the 511.   Did they need re-programming ?   

When I tried to talk to ZTC about this, they strongly suggested it was my “fault” for mixing DCC systems. So I suspect nothing will have changed. And they are right, to a point. But failing to invert the bits in the accessory address (as per the NMRA spec) does introduce challenges

 

if memory serves, this May date back to the very beginnings of ZTC. And the feeling that to “put it right” would inconvenience a lot of blissfully happy ZTC-only customers

[Combe Martin]

The reason I 'wondered' was because I understood that one of the problems with the old (511) software was that it was in a language that was no longer used, so finding a programmer that could decipher it was difficult.

 

So, unless the new ZTC owners had a detailed 511 software spec (in english) to give to the programmer of the new 611 software then he would have to be working from the 511 manual for some things, so it might have been fixed by accident.