I have recently been bitten by the model railway bug and have purchased a small loop of track and a dummy engine to drive around. This system is a DC system, where the control box is a switch to turn on power, change the polarity of the track and a variable resistor to change how much voltage is applied across the rails. A very easy system to implement. However, it is really only designed for 1 engine, as adding a second one would need both engines to move at the same speed or they crash into each other. There is no individual engine control, just changing power to the rails which, via the wheels is fed into the motor of the engine.
This is ok for boring layouts, but I want to make something more dynamic. Looking online I found people that spent the time to cut their track into block sections so that their system can still run DC power, but after a train passes a "dead" piece of track, it is in another section so the previous section could theoretically have another train on it. This system works, but relies on the structure of the track to control everything, and now things like block section control and powering switches specially make things much more complicated. This makes the power delivery system into the control scheme, which when 2 systems are combined, there is room for error and added complexity.
Enter in DCC. DCC stands for Digital Command Control. It means that each locomotive has a special decoder within it to handle the signals sent through the tracks. The tracks, rather than running DC, run a pulse width modulated AC signal to the decoder. The decoder decodes the signal embedded in the AC, converts it to a digital instruction via a small computer, and then turns it into motor control to change the speed. This also allows for other features like lights and sounds to be controlled on the train as everything is an AC pulse width signal being sent.
This sounds great, until you see the cost. The cheapest decoder I found was 50 dollars, and that was a basic movement one, no sound, no light control, nothing. Also, there is the issue that each locomotive needs this decoder, and a special hub has to be bought to program and run them. Also, since the network is AC, it means that no regular DC train can run on it. This increases the cost as each train requires a minimum of 50 dollars on top of their already high price just to get it moving. And that is not touching the fact that DCC voltages are regularly 8 to 12 V higher than their DC counterparts. For a design from the 1970s, it does ok, but that was over 50 years ago now, certainly something better has come along, right?
No. Sure there have been a few attempts, but there has been little focus on changing the system, more on just maintaining and expanding DCC. Some have tried to hack arduinos into working, but as this is still very much an older gentleman's hobby, there has not been the pressure to update it to modern operations.
Enter Beeton Decoders. Beeton Decoders is a project I am working on to solve many of the issues I see with DCC, bring it into the 21st century, and have it be easier to implement and maintain, all for a much lower cost to enter and build upon.
The main issues I found with DCC is as follows:
1. High cost: The cost of using these components is vastly greater than they are worth. It is a specialized industry, but the actual components cost pennies, not justifying the fifty dollar plus price tag per locomotive, and minimum 80 dollar controller.
2. Constrained Operations: Due to running the rails at 20 to 24V switching repeatedly, no DC locomotives can effectively move on the track at the same time, plus there is the overvoltage issue.
3. Combined Power and Signal operation: By combining the power and the signal into one operation, there needs to be complicated hardware to both rectify and read the circuit to get the power and information required to operate the train. Combine that with signal degradation from distance travelled, and fade out is a major issue. Now is it because the signal is too weak to read, or is it due to the track not having enough power to make the locomotive motor go? I cannot tell.
4. Congestion: With any communication system, its usability is heavily dependant on how fast packets of information can be sent. By design, the frequency of the DCC system is set at 8kHz. This sounds fast, but that is actually very slow by modern communication, Wifi is in the GHz, or 1 million times faster. There is large enough models that blocking of the track has been done, controlling sections using different stations because the network gets overwhelmed.
5. Audible noise: 8 kHz is audible as an annoying squeal as well, making young kids and those whose hearing has not lost the high pitch (like myself) stuck listening to the sound it makes, similar to that of a mosquito in your ear.
Overall, it was a good system, but something with higher bandwidth, lower cost, and better interoperability needs to be made.
I plan to solve these issues with the specs for Beeton Decoders in the following way:
1. ESP32 boards: cheap, reliable full on microprocessors smaller than your thumbnail. Take almost no power to run, and have higher specifications than an arduino. Fully programmable by arduino as well.
2. Rail voltage does not matter, as there is an internal voltage regulators that step the rail voltage down to what the processor needs. Polarity does not matter either, as there is a full bridge rectifier inside. A DC system can be run AT THE SAME TIME as this, the Beeton trains will just run slower with lower voltage for the motor.
3. Split power and signal. The power is delivered through the rails still, but the signal is wireless. No contamination of the bus lines at all, and due to not switching constantly, technically achieves a higher voltage than its switching counterpart. Even when there is a polarity switch in the track, the rectifier makes it level again for the internals.
4. Congestion is significantly less due to higher frequency communication of the OpenThread network. OpenThread is a mesh network that allows for other protocols on top of it. By being a mesh network, not all packets have to connect to the central hub, but can be relayed through other nodes to the destination. This protocol is not built on WIFI either, so you don't have to worry about flooding your home network with extra IP addresses.
5. Audible noise. While not set at the time of this writing, the chip that I have chosen for the motor controller is capable of handling switching frequencies up to 200 kHz, well above the audible range of humans.
With this system, a more user friendly and moddable design can be achieved.
Comments
Log in to add a comment.