Accessory decoder

[JudiR]

I'm very interested in your new firmware for an accessory decoder. I have in mind to use these for coach lighting and brake van lighting. An accessory decoder seems a better bet there because I can simply switch the lights on and then leave them alone without worrying about consisting with a loco or whatever. The diy version will be small enough to fit into a OO guard's van and be able to drive a smoke generator (for cold winter-time working) as well as the lamps. For this I would want to wait for your 8-way steady-state output option, since the 4-pair toggle effectively gives me only 4 outputs.

Judi

[Paul Harman]

Judi

The accessory firmware that will support 8-outputs in seperate address is a little way off yet. I am concentrating on getting it to do pulse output for solenoid motors at the moment, but once that is done I will be on the case.

In the mean time you might like to try using the function decoder firmware anyway. It uses exactly the same hardware so a firmware change to the accessory firmware is nothing more than reprogramming the PIC. The accessory firmware will work with both the 3-output and 8-output versions of the function decoder using output addressing mode so you can use either as appropriate without wasting addresses.

I would advise against using accessory decoders mobile because the accessory commands are only sent very infrequently by most command stations and could be easily missed. Accessory decoders expect to be constantly powered and will not respond as well to dirty track or power interuptions as the function decoder which has a lot of features built in to handle this such as state backup (functions will return to thier previous state after a power interruption) and support for braking modes (functions will continue to work on DC) and analogue operation.

After all, there is no need to consist if you don't want to. A rake of coaches can have its own address and 29 functions should be enough on one address to control the lighting in the whole rake. There are a lot more addresses available to the function decoder (around ten thousand with twenty nine functions on each) than the accessory decoder (just two thousand with one function on each).

[JudiR]

Paul,

Good point about the number of addresses available, I could number my brake vans from 9000 upwards to make it easier to remember which is which. I hadn't thought about a decoder missing a command - I though there was some sort of acknowledgment so it would know? It would be obvious if it had but missed then the controller would be thinking it was set and life might get confusing trying to unset and reset it?

OK, back to plan A.

Thanks,

Judi

[Paul Harman]

Judi

The accessories can have feedback via the Lenz RS bus or S88 and such if using a feedback encoder to show that the action you have performed has happened. I guess that this was expected, but they do have to be fixed and connected to the feedback bus, and not all command stations have feedback capability.

Feedback for mobile decoders should eventually be possible via Railcom, but in the meantime command stations will just continuously send commands in the hope that some will get through. Fortunately the DIY decoders are better at picking up the data than most commercial decoders so should not miss too many packets as long as they get a bit of power.

[JudiR]

On a slightly different tack, I'd like to ask how your accessory decoder interprets "start-of-day" with regard to "on/off" and "normal/reverse". I have stumbled across a problem with another decoder having a difference of opinion with my NCE Cab so I'm interested in how you have interpreted the NMRA standard (which seems vague).

For a lamp, 1 or "on" is clear and unambiguous and you would want your lamps to default to off when first powering up the layout at the start of an ops session. You then switch on the ones you want. However, for a railway operator or signal engineer, the normal default position for a signal should be "on" (at danger) and for a turnout, "normal" (straight) and this is what is required at the start-of-day-switch-on.

Without having access to the code, I believe that my NCE Cab sends an "on" data packet for "Normal" and an "off" data packet for "Reverse" but my new decoder defaults or resets to "off" when first powered up.

So how does your decoder start up? It would be really, really nice if it was configurable somehow to start up the way the user wished ...

Judi

[Paul Harman]

Good idea to make the accessory decoder configurable for start up. The NMRA specs are horribly vague, and no one seems to care about improving them and often what is there is not implemented.

The current situation is this. After a power down the last known status should be restored. After a decoder reset (command stations send this after a 'stop' condition and at power up) all outputs will be switched off, unless configured for invert when they will be switched on. No pulses will be sent to set 'Normal' or 'Reverse' unless they come specifically from the command station to the decoder's address.

When pairs of outputs are used, it has to be remembered that they are pairs of individual outputs that can be turned on and off independantly by the command station if it supports it. If a pair of outputs are configured for 'Lenz toggle' mode via CV33, turning on one output of the pair will turn off the other, but at reset both will be off initially until one has been turned on. This is of course not ideal for signals.

I think the best workaround in a situation where the DCC supply to the decoder cannot be relied upon not to power off or reset is to use the decoder to drive a relay to give an effective failsafe and to retain the 'on' indication from the signal via an auxiliary supply.

Unfortunately one of the (widely ignored) NMRA specs is that a decoder should shut down all of its outputs when it gets a decoder reset signal and wait until it is addressed with a directed packet before turning the outputs on again. It drove me round the bend for a while trying to find out why TCS decoders appeared to be working after a stop when mine shut down when the stop button was pressed and stayed off, but TCS appear to just ignore decoder reset packets and some command stations (Lenz 3.5 and earlier as an example) don't bother refreshing the current status to the decoders after resetting them.

[JudiR]

Paul,

I started this enquiry as a thread on another forum and it has led to a journey of discovery. I've been wanting to emulate the analogy of a manual signal box ... as a life-long railway engineer, that has to be right for me to feel happy with my model railway. Not necessarily doing the right thing but doing things right.

I'm driving the decoder with my NCE cab and it gives the option of "Normal (On)" or "Reverse (Off)", which is standard terminology for a railway engineer for both signals and turnouts. Using the analogy of a manual signal box, the signalman will pull a lever towards himself to pull a signal "off" or to "reverse" a turnout.

What it comes down to is that, when I switch on at the start of an ops session, I want to have my turnouts and signals to be set to "normal" which is, in big railway parlance, "on". Unfortunately, my NCE Cab interprets the initial state as "off" and, perversely, "reverse". The first time I call up an accessory, the button for R(off) elicits no response but the button for N(on) does.

Inverting outputs will not resolve this contradiction, I need to have the decoder to reset or initialise "on" so that, when I push the R(off) button on my Cab, the turnout will reverse or the signal will pull off. It seems that that is exactly what the NMRA recommended practice says should not happen!

The alternative would be to reconfigure the legend on my NCE Cab but the guys at NCE don't understand the problem and just told me to swap the point motor wires over!

Maybe the answer to this little problem is the same as your answer to the first question I asked on this thread on 1st August ... to use a loco function-only decoder which I can configure to behave exactly as I want.

Judi

[Paul Harman]

Judi

As long as your NCE will send the commands when you press the buttons regardless of the current state it thinks is present it should be possible to make the accessory decoder's default behaviour configureable to suit, either NMRA standard, last know condition or predefined condition.

I believe that NCE has support for feedback now, so presumably the command station would query the state at power on if you have feedback encoders connected to the outputs of the accessory decoders (or to other proving circuits) which might get round the NCE default problem. Probably not a cheap solution - but if you make your own accessory decoders you could save a few quid anyway to buy the feedback encoders. Proving circuits are quite easy to add to live frog points by connecting an optoisolator between the frog and one of the running rails with a series resistor, and to LED signals by connecting an opto isolator in series with the red LED (and adjusting the resistor).

The biggest problem now with making the default behavior adjustable is deciding which CV to use!

[Paul Harman]

Judi

It has been a little delayed, but I have produced a new version (V0.05 currently) of the accessory decoder firmware now. All the pulse modes as per NMRA spec is working and I have added a new CV37 to set a default value at power up. CV37=85 will set all the outputs to be normal at power up, and CV37=170 will set them all to reverse. You can play about with the values if you do not want all the outputs to be set, pulse outputs especially probably don't want to be enabled because the pulse might be a bit long.

The new firmware will be on the website soon, but let me know if you want it sooner.

[phillby]

Hi Fellow Railroaders. I have my main line track laid and it is N-Gauge
possibly way to small to conider DIY in the Rolling Stock. I am however interested in the accessory decoders for at this stage points. I am in a remoteish location in Australia two hours from a DIY electronics chain who have limited products. I know there is the internet but would like to play first to figure out exactly what I need and how many. My observation is that although the circuit and operation is similar on both decoders Q9, R15 and R17 are not listed in the parts lists as they do not exist on the Function Decoder. I will only be able to obtain a 12f675 which is an option. As I am new to this Microcontroller world, to use the firmware do I just recompile changing the header to a 12f675 and it will compile correctly or do i have to do more serious modification of the code. You mention a new version of the code in 2010 is that what is posted now.
I appreciate your work on thes projects and look forward to the answers.
Thanks
Brian

[Paul Harman]

Brian

Q9, R16 and R17 are only required if you want to read back CVs from the decoder. Q9 is a BC182L or similar, R17 is 4K7 and R16 is 220R if you want to add them.

There is no need to change anything in the source before recompiling, the target hex code is fine in all of the supported processors. If you want to take it as it is just use the .HEX file.

There has not been any recent changes to the firmware.

[Paul Harman]

Here is the current V0.06 version of the accessory firmware.

Attachments:

[phillby]

Thanks Paul that's very helpful.
I travelled to Canberra and got a fist full of components to try a few electronic projects. The Accessory decoder will be one.
Cheers
Brian

[phillby]

Hi again,

I have been checking things to order some parts from O.S. and see that the component list in the Decoder Manual lists R15 as a 47R 2 watt resistor and the parts list in the function decoder Zip file lists R15 as a 4R7 2 watt resistor. Could you please clarify which is correct.

I have transfered the circuit for the accessory decoder (12F629) for controling a pair of points solenoids to a printed circuit board design. It is considerably larger than the stripboard version 130mm x 55mm. Should I post it when it has been constructed and checked.

I have used a simple method of producing printed circuit board for awhile now and could also detail the process.

Cheers,
Brian

[Paul Harman]

47R is the correct value and the solenoid decoder does not need a 2W resistor, you can use a 0.25W version instead.

Please post your PCB when done, I am sure that other people will be interested in it.

There is a 4-way version available too that will complement your 1-way version if you look in the "PCB for solenoid accessory decoder" thread.