DIY decoder

Sure, but I realized I’d have to use one of those old wide-body BB Athearns to put it in…

close, :slight_smile:

If doing it for your own use and not as a product to sell to others - you can leave out what you want, and you can hard code (well, use #DEFINE in your code) the CV values and just change the settings in the micro’s programming environment and flash new code to it. All you really need is to decipher the control packets and completely ignore programming of CVs. Especially for an accessory decoder - all iut needs to do is see packets addressed to whatever address you assign it (no need t implement all program modes - just implement one if you want to program it via DCC, or hard code it in the program if not) and then look for function state messages, and then only for the functions you plan to use - say F1-F4, and ignore all the others.

–Randy

DOH. Here I am trying to figure out a way to self-calibrate an IR sensor to adjust to varying light (because I have every intention of having both day and night operations) and right there Geoff has the EASY answer - a DIFFERENTIAL IR detector. Rather than detecting absolute levels to indicate the beam is blocked or not, it compares two sensors - on exposed to ambient and one that gets blocked by the train. Simple!

–Randy

Yes, the first link leads you to instructions for a decoder that is to big for smaller scales. Not real helpful unless there is another article on how to make a smaller one.

The same code will run on any compatible Atmel microcontroller. Including nice small surface mount ones. You don’t need to use a full Arduino, although a Pro Mini or Nano is small enough to fit in a hood diesel in HO, but maybe not that AND all the parts to drive the motor. Even then, most of the size of the device is in things that aren;t needed, the second voltage regulator, all those pins in large .100 spacing, a reset pushbutton, a USB jack…

–Randy

mine is basically a copy of the MERG version 12, code is on thier page …pcb decoder

This is what I thought at the beginning. However, it would be tedious to use things without the ability to retrieve/manipulate CV values. What happens if my z21 for any reason died and I had to use different/older equipment? Besides, I was not sure which protocol my command station uses. What makes things worse, z21 has three programming menus. They do not clearly speicify POM/Programming track, or otherwise. I could not believe my eyes when I discovered for example that it sometimes uses byte 2 for light control if no speed command were sent, but switch to the F0 to control light after sending speed information. Therefore, I have to be as universal as I can (well, not exactly universal, I dropped the paging mode completely), even for my own use.

Walid

It wouldn;t matter what system you used it on. The fexied address would be the fixed address. The packet for F2 On is the same on any DCC system. What would you need to change if moving to a different DCC system? How often do you actually reprogram the regualr decoders you have now, once you get a given loco set up and working the way you want? Hard coding the config in your firmware instead of using DCC programming doesn;t restrict you to one DCC system or brand. It’s just less convenient to change on the fly, but once it’s all set up the way you want, how much changing will you do?

–Randy

It matters as long as the CV have to be manipulated.

And how would you retrieve the address? Assuming you bought a new locomotive, how to guarantee you will not give it the same address of an existing one?

VERY inconvenient

Activate/deactivate consist, for example.

And what on earth would I save by skipping the programming mode? 30, 40, or even 50 lines of code? The headache is not to type the lines as I said earlier, but to dig into the confusing NMRA standards and extract the data.

Regards

Walid

That’s exactly what I was talking about saving - all the headaches. It’s going to be a lot more than 50 lines of code to implement all 4 programming methods - though you really only need to implement one. No one does Register mode any more, you can leave that one completely out. Pick one, implement that. All systems support at least 2 of the other 3, most still support the ancient register mode just in case you have some very old decoders, but of all the ones you might NOT find on a modern system, that would be the one.

Consisting - well, I guess this is where Digitrax’s way is better. The decoder gets no changes when I consist, I just need to know the address. And it’s not likely a function decoder for controller the lights of a passenger car would be consisted with anything anyway

You were talking about making a function decoder for a apssenger car - and you’re the one programming it, so you know the address.

I still don;t understand why it would matter what system you are using. I have multiple methods of programming decoders and I can assure you that each and every decoder does not have some code in it to tell if it is getting programming commands from Digitrax or NCE or MRC or Roco or some DIY DCC system. Unless you mean support for the 4 methods, but the only thing that might not give you the option of any of them would be a homemade DCC system. Most any commercial system does at least 3 out of the 4. And it’s not like you’re giving this to other people who might have no clue - if you are building it then you know what program mode(s) you included in the code.

If you don;t allow programming and hard code the address - just keep a list, or use JMRI to keep it for you. So the next one you program, you give a different address. I keep coming back to the whole idea of, once set up and running, how often do you actually change anything? Especially the address - if you’ve addressed the loco to the cab number, why would you