Building your own decoder.

[peteski]

Are accessory decoders programmed on a programming track normally?  I don’t have a lot of experience with them, but that seems weird. Im not sure how most are programmed though.

Seems that wvgca and I are talking about different decoders.

Accessory decoders are stationary and used for things like turnout control or activating trackside signals. I'm not familiar with programming them.  I think those are POM.

Function-only  decoders (the ones I'm talking about) are mobile. They are installed in push-pull train cab cars (dummies with no motor), passenger cars for lighting control, etc. Those can be POM, and also in service mode, but they will not acknowledge the programming packes and cannot provide CV readback.

Think about function-only decoders as regular mobile decoders with the motor control part removed or disabled.  Since they cannot control a motor, so since they do not provide enough of a load on the programming track (the LEDs used on function outputs do not create high enough of a load).  Why is there need to read CVs from those decoders. Well, one would be just to find out their address, but also to get the configuration of the lighting effects.

[bicknell]

Ah, got it.

Accessory decoders that I've used have all been loconet devices, not programmed over the rails.  I guess there are some that just take rail power, I never really thought about how they might be programmed.

Function only decoders are just a mobile decoder with the motor output unused or omitted.  If unused, a resistor across the output would likely cause read back to work just fine.  The read back is a 60ma pulse, and most decoders pulse at "full throttle".  So consider 13v track, 60ma would require about a 200 Ohm resistor.  As it is a momentary pulse I don't think the wattage rating of the resistor matters much.  If it didn't have a motor output then it's much harder.  It might still be possible, LEDs typically draw 10-20ma, and so if all 6 functions were used that could be 60-120ma of total lighting that could be flickered.

The other option is RailCOM, which is bidirectional communication over the main line operations mode signal.

[C855B]

Accessory decoders that I've used have all been loconet devices, not programmed over the rails.  I guess there are some that just take rail power, I never really thought about how they might be programmed.

Those I have used either have a jumper to enable programming (or at least setting the address) or have function buttons (turnout controls) enabling a programming sequence.

[peteski]

Function only decoders are just a mobile decoder with the motor output unused or omitted.  If unused, a resistor across the output would likely cause read back to work just fine.  The read back is a 60ma pulse, and most decoders pulse at "full throttle".  So consider 13v track, 60ma would require about a 200 Ohm resistor.  As it is a momentary pulse I don't think the wattage rating of the resistor matters much.  If it didn't have a motor output then it's much harder.  It might still be possible, LEDs typically draw 10-20ma, and so if all 6 functions were used that could be 60-120ma of total lighting that could be flickered.

Not that simple.  While some are actual mobile decoder with the H-Bridge and associated circuity components not populated, many other  function-only decoders are designed without the motor driver circuitry.   In either case it is not feasible to temporarily or permanently connect a load resistor.

Even if that was feasible. the decoder is often at the same address as the mobile decoder in the loco of that train, so it would respond to the speed-step packets and the resistor would get hot during operation.

As for the LED loads, most LEDs are very efficient and/or too bright at 10-20mA each. Also many small SMD LEDs have recommend operating current of 5mA.  My headlight LEDs often don't use more than couple of milli-Amps each. Plus often only 2 or 3 functions are utilized. So the  total load is nowhere near 60mA.

That is what I would lobby for a dedicated load resistor connected to a internal-use function output, with the firmware only using it for the acknowledge pulse.  Since the pulses are short duration, a low power resistor (physically small) could be safely used., not taking up much space on the decoder.

Seems to me that you as a decoder designer don't have too much experience in how decoders are used.  When designing something it is really beneficial to actually understand the device's real-life applications.

[bicknell]

At work we talk about crawl/walk/run behaviors as a project matures, using the analogy of a child growing up.  My project is absolutely in the crawl stage.  While there are a number of accessory decoder designs out on the internet I'm only aware of one mobile decoder design with full schematics, and it's designed for large scale operation.  As a result my focus is 100% on a mobile decoder, for an engine, with the basic functions people expect in that package.  That is, I'd really like to have some "drop in" designs available that someone might choose over a Digitrax/Lenz/Zimo for their engine conversion.  I feel like this is the market segment likely to touch the most modelers.

I am aware that function only decoders exist and some but probably not all of the applications.  For instance I know some people use them in passenger trains to be able to control the lights on a car by car basis, or use them in cabooses with marker lights that need to be controlled.  I have no problem with including such designs in the project, but I'm going to probably put them in the run category as they are used by a smaller percentage of DCC users.  As such I just really haven't spent much time thinking about them.

The great thing about the project though is it's open source.  If someone wanted to make a function only design and write software for it, they could do so and then send me a pull request to merge it back in!

[peteski]

At work we talk about crawl/walk/run behaviors as a project matures, using the analogy of a child growing up.  My project is absolutely in the crawl stage.  While there are a number of accessory decoder designs out on the internet I'm only aware of one mobile decoder design with full schematics, and it's designed for large scale operation.  As a result my focus is 100% on a mobile decoder, for an engine, with the basic functions people expect in that package.  That is, I'd really like to have some "drop in" designs available that someone might choose over a Digitrax/Lenz/Zimo for their engine conversion.  I feel like this is the market segment likely to touch the most modelers.

I see your point.  I had unreasonable expectations.  I expected you to be model railroader very familiar with both, model trains in general, and the existing DCC systems and decoders.  But from what you state, you seem to be more of a computer programmer/hardware-engineer who is just taking bunch of DCC specs and designing a decoder which will operated on DCC systems.

While in many cases it is a pipe dream, I think the best designs are produced by people who are intimately familiar with the real world applications of the device they are designing.

I'll be watching this thread to see how you the the rest of the open source "crowd" deal with the whole motor control design (BEMF, and a wide range of motors, including coreless ones).

[bicknell]

Model railroaders come in all shapes and sizes, scales and practices.  I am an avid N-Scaler, who does N-Trak.  98% of my DCC experience is with Digitrax systems as that is what most N-Scale clubs run.  My goals are no doubt partially formed by that experience and environment.  For instance, we don't get any working smoke in N scale so I've never thought about a decoder might drive a smoke generator in HO or O.  I've talked up many people at my own club and various other clubs at shows, as well as talked to vendors who sell some of the existing commercial products.

Because this project is still trying to get off the ground I'm concentrating on fundamentals (e.g. meeting all of the relevant NMRA specs) on the products I think will be most popular (drop in decoders in N and HO).  Based on the conversations I've had with vendors, drop in decoders in N and HO is > 75% of their sales.  Sales decoders have also been dropping as more and more vendors move to offering DCC only versions now that analog mode is relatively standard and more and more people want DCC.

You point out one of the interesting difficulties.  Driving a motor when there are many different motors out there.  No doubt Digitrax/Lenz/Zimo have spent lots of RnD dollars optimizing for the standard Atlas/Kato/Bachman motors.  To get the project on-par is going to require a lot of time testing and tuning.

All I can say to you or anyone else is please come on the  journey with me.  The more people working on it, contributing hardware designs or software code the faster it will become good.  The more perspectives, the better the final product.  You've already got me thinking about tossing a function only design to see what sort of traction it gets.  That's actually pretty easy once I have the various light control routines written.

[peteski]

I'm glad I sparked an new idea in your head.  Carry on!  Like I mentioned, this looks like an interesting project.

I'm also in N scale and NTRAK, have been for many years.  I just assumed that since you were not familiar with function-only mobile decoders (which I do use), you were more into programming than modeling.  And we all know what "assume" really stands for.    The written word often leaves a lot to be desired compared to a real-time face-to-face conversation.

[bicknell]

No worries.  There are 150 things I'd like to add to the project, but I feel like if the project is always just me it will always be too slow.  So I'm trying to reach out and find 2-5 other people who are interested in contributing right now.  If I can get that, we can really motor on some features and functionality.

I attempted a revision of my design that I think might be a bit more clear to new people, but also uses more commonly available components that should be cheaper and easier to find, as well as all components it's possible to hand solder.

New: https://github.com/bicknell/DCC-Mobile-Decoder/tree/sot23-refactor/hardware/reference/Breadboard-1
Old: https://github.com/bicknell/DCC-Mobile-Decoder/tree/main/hardware/reference/Breadboard-1

Any thoughts are welcome.

[wvgca]

did you ever get around to doing a decoder pcb that would actually fit inside a n scale loco ??

[bicknell]

Yes and no.

I have made significant progress on the software.  It pretty much decodes all the DCC commands correctly now, and can do things like consisting and such.  There are really two things left to have a working decoder, 1) Motor Control -- I have the basics but I suspect some tuning and tweaking is required with real motors 2) Lighting effects -- Right now it can only turn functions on or off, I need to add at least some basic blinking functions.

On the hardware side I have a couple of draft designs which include at least one design that could fit in an N scale locomotive.  I have not yet had any PCB's made or tried to actually operate one inside of a locomotive yet.

I'm continuing to work on it as time allows.

[wvgca]

if you want a -possible- different direction, look at my home made decoder on modeltrainforum.com ...it's based on the merg offierng, complete with four functions, bemf, a 'stealth' mode, and a ready made [can even be pre ordered] pcb layout under an older version of eagle .. the decoder is used as an avatar on that site ..