Constructing Accessory Decoder

[nigelcliffe]

Slight confusion over instructions to make 8-output accessory decoders....

In the reply to Judi above, Paul said that one could just change the firmware on an existing Function Decoder, and get an Accessory Decoder.

On the website, the text says output D has moved (from pin 4) to pin 6.

Assuming the website is correct, the firmware would work on an existing function decoder, except for output D ?


Once sorted, I can see these being very useful, particularly to drive LED colour light signals.




regards

- Nigel

[Paul Harman]

Nigel

It is my intention to make it a CV option to be able to choose which 'Output D' pin is used to drive an acknowledment load in both function and accessory firmware. It should be possible to configure it as pin 6 (14-pin chips only) or pin 11 (14-pin chips)/ pin 5 (8-pin chip).

This only affects output 'D'

The reason for the move is because on a function decoder using the 8-pin processor I consider it more important to have three outputs and no acknowledgement driver by default, but on an accessory decoder it makes more sense to just have a single pair of outputs with an acknowledgement driver rather than one pair and an odd half a pair.

The acknowledgement driver is relevent to the pulse accessory decoder design that I will publish soon which is opto-isolated to prevent interference from high current pulses getting into the processor and DCC bus.

In the mean time I think the current versions of the firmware allow you to use pin 6 or pin 11 as output 'D' on 14-pin chips, and pin 5 as an output on 8-pin chips.

Paul

[nigelcliffe]

Paul,

I've hit a more fundamental problem.

I've taken my low-power 8-output board and changed the firmware on the chip. With this, I cannot get any accessory responses - turnout changes have no affect.

I have tried with the MERG toggle bits on. Tried inverting outputs. Nothing, other than a brief flicker at DCC power-on.

If I reprogram the PIC back to function-decoder, then its fine, so not a PIC or basic hardware fault.


My DIY decoder board does not have a load to generate an ACK pulse, so cannot read back values. (I can add one if its simple and fits in a very small space!)


There is probably something very simple wrong, but I'm stuck. I can read-back the PIC (and its EPROM values) if that helps.



regards

- Nigel

[Paul Harman]

Nigel

If you can read back the EEPROM, you can read the CVs. EEPROM location 0 is the page register, then EEPROM location 1 = CV1, 2=CV2 etc.

Usually this problem comes as a result of the NMRA confusion over setting the address in CV1/CV9/CV29. Usually best to set to defaults then set CV1=2, and try points 1-12 and see which address activates. CV1=2 should be points 1-4 on Lenz, 5-8 on Roco. Not sure about the others and ZTC will be something different entirely!
Paul

[nigelcliffe]

Paul,

thanks for that.
I should have remembered the +1 to accessory addresses in 80%+ of command stations ! Its one for Jeff to add to the instructions or FAQ.
( Lenz, Digitrax, Sprog all use CV1=2 corresponds to accessories 1-4).

The 8-output decoder is now working as an accessory on addresses 1-4 (CV1=2).


Moving on, with the "output address mode", only the first two outputs appear to operate. I appreciate this was put in primarily for the two-output decoder.
However, I was thinking of using the multi-output to drive LED colour light signals, and being able to move the accessory address up by one (rather than four) would be very useful. If signals around a layout have sequential addresses, and with a series of addresses on a chip, its very simple wiring to automatically display yellow/green (when the first signal is moved from "closed=red" to "thrown") on the basis of the next signal's red-state. Double yellows is not a lot more complex (my sketch circuit has a couple of extra diodes on the output to display the second yellow at the appropriate time).


regards

- Nigel

[Paul Harman]

Nigel

Output address mode should work as you expect - it did when I tested it! I will have to look again and check that no bugs have crept in.

It is a while since I did it so I cannot remember if the outputs shift up or wrap round if that makes a difference.

It follows the CV1=1 gives address 1 in both modes rules, so on your command station that does not output address 1 you should see the same addresses 1-4 being used when CV1= 2 in decoder address mode, and CV1=5 in output address mode. CV1=6 should give you addresses 2-5 in output address mode, then CV1=7 should give addresses 3-6 and so on with your command station.

Paul

[nigelcliffe]

Hi Paul,

I have just double-checked, and its as I report.

CV1=2, which corresponds to turnout addresses 1-4 on my system

Programming in "direct" mode on programming track, then swapping back to main line for running tests.
CV29=128, then its in "normal" mode, with addresses 1-4
CV29=192, only address 1 causes any change in the outputs. Other outputs remain on.
CV29=128, and back to four addresses working.

No other CV changes.

regards

- Nigel

[Paul Harman]

Nigel

CV29=192 and CV1=2 should give you address 1 on output pair 4 only since you cannot send the commands required to do the other three outputs, they would equate to points 0, -1 and -2. You could address these with a Roco system for example where you would have points 2-5.

Realisticaly with your command station you would not want to set CV1 less than 5 when CV9 is default and CV29 is 192.

To work out the new CV1 for the same four addresses in output address mode, take CV1 in decoder address mode, subtract 1, multiply by 4 then add 1. In the example above 2-1=1, 1x4=4, 4+1=5.

I will give a little bit of background to all of this. This is all in accordance with the NMRA spec as far as the statements "CV1=1 gives the same addresses in both modes" and "CV1 = 1 is first available point address". It is not in accordance with the NMRA formula which contradicts the above statements, so do not use the NMRA formula.

This all ties in nicely with CV1=1 as the default if you have a Roco command station, but not very intuative for your command station or if you have a Lenz. I do not really care what it should be, if the NMRA ever come up with a specification that actually works I will make sure that my firmware is compliant - it is just sums, but it looks like the NMRA DCC working group has stopped working so I suspect there will never be a correct specification. I have just picked what looks most sensible to me out of the mess and taken a guess at what was intended.

The other alternative would be to use the NMRA formula and have CV1=1 in decoder address mode being addresses 1-4 on your system with CV1=0 being addresses 1-4 on Roco, but that would make it impossible to have CV1=1 decoding the same addresses in both modes because you cannot set CV1 to -3 in order to work with a Roco system in output address mode, it would have to be CV1=0 giving the same addresses in both modes.

Paul

[nigelcliffe]

Paul,

thanks for the reply. I had started to think about "n-1", "n-2", etc.. as the answer, and yes that does work correctly. So my idea for sequential numbering and LED colour light signals appears to be possible. Some more bench lash-ups will get it all working.

On the numbering, its not a problem once I have a base condition to work from. It might need a bit of explanation in notes for some users, but its not impossible to follow what is happening. I'll look at producing a JMRI/DecoderPro page to help users who use that software.

The confusion over accessory addresses has been around for ages; the MERG accessory kits have both numberings in the documentation. Your design adds another option, which means another pair of possible interpretations of the NMRA documents (text or formula).
I agree that the NMRA DCC group appears to be defunct. Comments on the Zimo forum from some others suggest this quite strongly, and what developments are happening are now within a closed European manufacturers group (primarily Lenz, Zimo and ESU).


regards

- Nigel