I have been working on and off on a project to build my own decoder -- hardware and software. While it is not complete, it is far enough along I have decided to share it with the world. https://github.com/bicknell/DCC-Mobile-Decoder If you are interested in electronics, writing software for micro-controllers, or just wanted to know how the innards of these things work please take a look. I am hoping to find a couple of other people who would like to help advance this project forward. The eventual goal is to make a mobile decoder that could go in a scale engine and work just like any commercial decoder -- except you have the source code!
I just committed support for Address, Direct, Register, and Paged programming in Service Mode! I also added a resistor to the hardware design so that the board can do CV read back without having to have a real motor attached.
https://github.com/bicknell/DCC-Mobile-Decoder/tree/main/hardware/reference/Manual-1 is how to build the circuit by hand on a bread board, and includes a picture of the bread board next to me right now. https://github.com/bicknell/DCC-Mobile-Decoder/tree/main/hardware/reference/Breadboard-1 includes a computer generated rendering of the "reference hardware" designed to make developing and debugging the software easy. I haven't actually had any of these produced yet, but that's going to be a step soon. https://github.com/bicknell/DCC-Mobile-Decoder/tree/main/hardware/decoders/Wired-N-1A-6-1 includes a computer generated rendering of a N scale, 6 function, wired decoder, 6mm x 25mm. This is also an untested draft, but it should run the same software as both of the designs above yet be a real, functional N scale decoder. My hope is that eventually more decoder designs would be added, for instance drop in decoders for popular locomotives.
Véry interesting indeed! Can you provide a schematic in pdf please? I am willing to make the complete pcb in Eagle, ready for production.
i looked around as well .. a little short on stock most places, but only 2-3 bucks for small quantities ... but nothing other than DIL shown as a direct replacement .. might make a pretty big decoder, lol
Schematic link is on the page at https://github.com/bicknell/DCC-Mobile-Decoder/tree/main/hardware/reference/Breadboard-1, but also in that directory is the full KiCad schematic and PCB design. No need to replicate in Eagle, it's already a production ready design. If you're trying to source a DIL/DIP package to build this on the bread board, any of these work: PIC18F16Q40-I/P = DIL/DIP package for a bread board. Mouser shows 20 available, Digikey shows 506. This is a 64K part. PIC18F06Q40-I/P = Same part, but with 32k of ram. Right now everything fits (with full debugging) in 32k, but we may exceed that later. PIC18F16Q41-I/P = Same part, but with one additional OpAmp on board we don't use, would work just fine. Also 64K. PIC18F06Q41-I/P = Same part, extra OpAmp we don't use, but only 32k of RAM. Now, replace all the "I/P" with "E/P". Same chip, rated for "extended temperatures" (up to 125c, rather than 100c). So there's four more options. There are also 16k options, they will run the code but have no room to enable much debugging. They would work great for "production" runs to save some bucks. Any of those 8 would work fine on a bread board. After downloading the code the chip type would have to be set in MPLab, and if you get the "41" part with the extra OpAmp MCC would have to be run again to generate updated files. For more about the chips in general, see https://github.com/bicknell/DCC-Mobile-Decoder/blob/main/hardware/conventions/CHIP-SELECTION.md I picked these chips because there is a VQFN package, 3mm x 3mm. Why this one? Well I found it inspecting 4 different commercial decoders. That's right, your favorite decoder vendors seem to all be using this chip. But also, it fits the needs nicely. Available in a small package, relatively cheap, way more power than necessary to do the job, lots of EEPROM. Digikey has the PIC18F16Q40-I/REB (3x3mm VQFN) in small quantities in stock if your crazy and wanted to hand-solder something that small. I've inquired with two Chinese fabs, and they assure me they can get them even though DigiKey and Mouser in the US both show low/no stock.
Since I've found some people on here who seem to know a thing or two about hardware, I'd like to make a specific request. https://github.com/bicknell/DCC-Mob...rdware/reference/Breadboard-1/CALCULATIONS.md details the calculations for the components involved. So far what is there is my first draft. It's entirely possible there are better component choices for some of these items, my calculations are wrong, etc. Any feedback on the components, calculation, or design would be much appreciated.
For the H-bridge, why not use SOT23 packaged N- and P-channel paired mosfets AO3400A and AO3401A: Rds (on) is about 25mOhm, yours come at about 100mOhm. Datasheet attached. For the size you do not need to worry: only six pins to solder, your IC needs 8 pins to solder. EDIT: For the cost no need to worry either: on AliExpress a few $$ per hundred.
The manufacturers I've looked at seem to be using an MSOP 3mm x 3mm form factor part that are a bit hard to find. Not really necessary for the "Breadboard" version, but would be important for the N Scale and Z Scale real decoders. This is one of the few that seems available: https://datasheet.lcsc.com/lcsc/1808281700_Infineon-Technologies-IRF7509TRPBF_C148280.pdf $0.40 each makes them a bit expensive, so maybe the Breadboard-1 design with more space will use something cheaper. But I think moving the N scale decoder design to a part like this is a good way to save space. That's a bummer on availability in Europe. Can you get the I/P version (DIP-20) for a breadboard? What about the I/SS version which is what I use on the Breadboard-1 board?
They would absolutely work for the Breadboard version. 4xSOT-23 is a bit large for an N/Z real decoder. FWIW, Mouser does not stock them, and Digikey does but has them flagged as not recommended for new designs. LCSC has them and several Chinese knock-offs at good prices. It's an interesting set of competing priorities, and I'm still looking at parts as a result: I'd like the parts to be generally available in the US, Europe, and China as that would expand the reach of the project. I'd like the parts to generally be usable in N/Z decoders, where practical, because that generally means the same part (rational, specs, and code to it) can be used in larger scales. The H-Bridge is one place this rule may not be practical, it may require 1 part for Z/N/HO and 1 part for O/G. I'd like the part to have multiple pin-compatible & spec-compatible suppliers as this both tends to drive the cost down but also increases the chance someone will be able to build one of these a year or 5 down the road with the same parts. The passives (resistors, capacitors) are not really a problem, all standard values with hundreds of compatible options. I think I've done decent on the processors; there are a lot of other choices though and I would like to make a PIC16 rather PIC18 version at some point. It's the MOSFETs for both the functions and the H-Bridge that are a bit more tricky to source and meet all those criteria. The one thing I'm not concerned about is the ability to hand-solder. It's just not going to ever be easy with Z/N, and probably even many HO decoders. Could the Breadboard-1 be made with all hand-solderable components? Sure, but it's not practical for people to go buy quantity 1 worth of parts. If this is successful I'll order 100 or 500 assembled by pick and place and wave soldering from a fab and then sell them out at cost to people who want to help develop the software and further the project. I should be able to make them for ~$5 a board in quantity, or less, so sell them for $10 shipping included to someone who wants one. That's going to be cheaper than them buying all the parts themselves. I have also considered if it is worth using a "motor driver" IC. They integrate the H-Bridge, overload logic, often current sense. The package is overall smaller than individual components, which matters a lot for small N/Z decoders. The cost is generally a smidge more. The one interesting thing is I've never seen a commercial decoder that uses them. Do they know something I do not? Are they just stuck in the old-school built-it-yourself mentality? I don't know. I hope I don't come across as not valuing your input. You are correct the ones on the BOM today are not optimal. And I need feedback from different people -- maybe I'm wrong and people really want to hand solder these things for some reason. So please, keep the feedback coming as it is valuable.
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. I'm hoping this might make it easier for people to get started with development, and more developers == faster progress! 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.
The resistors are sized to limit the LEDs to approximately 5ma at 5v. [off your github] shouldn't the LED resistors be passing -roughly- three volts ?? not five ??
Humm, I have stated that poorly in the README.md file, I need to use better language. The CALCULATIONS.md file has the detailed calculation. Vf of these white LEDs is 2.9v, micro-processor drives at 5v, so it's actually 2.1 volts across the resistor. Which also makes me realize my CALCULATIONS is littered with 0402 components and in my update they are all 0805, I have some more updates to do.
