oorail

Here is the quick and easy fix for the capacitor, downside is the capacitor is still visible on the ends, but you can't really see it when you have the coaches coupled together. Since I have to pull two full sets apart, I think I'm going to use the time between now and December when the sets are supposed to come in to detail the interiors better and 3D print some guides to route the wiring under the floor of the coach.

@backofanenvelopeBlender is fairly easy to use once you get going. I just posted up a thread with my Blender tutorial that shows the entire workflow that I use with filament printers such as the Ender 3. You can find it here :

This tutorial shows the workflow I use to go from initial concept through the CAD process, slicing, printing and testing on the layout. All of the software used in the video is available for free. It is the workflow that I use for FDM (filament) printers like the Ender 3.

For those interested in the model, I uploaded another video this morning that has: Opening the tender and a look inside Rattling noise was the glazing that fell inside the tender Follow up on the loose screw that fell out the speaker hole An issue with the contact plate and how I fixed it New footage without music (some people asked to hear the motor) Raw test footage showing the issue with the contact plate (before it was fixed) The GT3 front bogie developed a squeak, loosening the front bogie screw a half turn fixed it I wanted to point out that I'm just a customer, thought the GT3 was worth risking the money, and I'm very happy that I took that risk. Yes I got burnt by DJ Models over the APT, out about 260 quid. I can tell you now that having put the GT3 through its paces, these guys are more like Accurascale and Rapido than DJ Models, from the quality of the model to the professionalism of the company towards their customers. Looking forward to the Fell, Iron Ore Wagons and the upcoming Leader! So far its been a fantastic model, one of the best models I've picked up in the past decade, so well done to @krmodels Here is the new video:

We've been experimenting with this for just over two years, so I thought you might be interested in what we've learnt, you can see the end result at: https://trackside3d.co.uk/ We have just over 20 FDM printers and a couple of MSLA printers. The most important thing is a 100% reproducible print, with the assumption the customer's printer is leveled and calibrated correctly. The baseline we went with was a working XYZ calibration cube and the calibration cat. If your printer will print those, all of our models should print on your printer. The second most important thing is to design the model for the 3D printer technology (Eg. FDM or MSLA). When you do this, you end up with some really good results, like this 40' container: https://trackside3d.co.uk/products/t3d-030-000-40-container The third thing we've found that was really important was the licensing and pricing. We're on the third iteration of our license, which is based on software licensing. When someone buys one of the 3D models, they aren't buying the model but buying a license to use the model. Doing it this way, we provide free updates to the model and the person can re-download the model if they need to. We allow them to make unlimited prints for their own personal use. This was based off the approach Scalescenes takes, and its proven very effective. We found that people printing models would often get confused or have problems because they were tweaking too many settings at once. So what we did was setup baseline profiles (small, medium and large objects), and slight modifications for materials. You can see this in the specifications and print settings tabs on the website. We're currently working on a secure solution to allow users to view 3D objects (like Thingiverse) and working on videos / layout photos of the current products. Right now I've got probably 100 additional designs that I need to clean up, export, package and create product entries for, in addition to updating whats on the site. Its a lot of effort, but should be good when its done. We've spent quite a bit of time perfecting 3D printable (with FDM) locos and rolling stock, and those are next. However, at this point, its going to be a matter of promoting 3D printing more via YouTube, and working on several new products each week. The reason we have 20+ FDM printers is basically for testing and design, we don't mass-produce end products, only ship the designs. We have a few printers dedicated to special materials, such as transparent PETG and PolySmooth, textured PLA, Wood-Hybrid PLA, Iron composite PLA, couple of different brands of PETG, HTPLA (high temp PLA), various different PLA brands and some special materials like TPU etc. The brands / models of printers we have are: JG Aurora z603s JG Aurora A5 / A5S JG Auora A1 / A1X Creality Ender 3 Creality Ender 3 Pro Creality Ender 5 Creality CR-10 S5 ANET A8 M3Ds AnyCubic Photons The bulk of our print-farm is Ender 5, Ender 3, CR-10s and JG Aurora A5. We do all the 3D modeling work in Blender, use Cura to slice and custom software to manage the print queues. At full capacity, we can churn out around 20-40 projects a week, depending on whats going on. We try to keep the printers going 24x7, as it leads to less problems! That sort of leads into my last point. We've found that people tend to want a steady stream of designs. We tested this out over the past 2+ years by offering a monthly subscription service that costs about $20/month, but you get a steady stream of designs, while we've limited the release of designs on the main ecommerce store. The subscription service is by far, the most popular thing that we offer. An interesting thing too about the models, we design everything for OO scale, mainly because thats what I model, and the whole project is more about getting people interested in 3D printing, however we do get a lot of people modeling O gauge and sometimes HO and N, who purchase models and then use the slicer to scale up/down. Hope that helps...

a) MFRC522 - you get 5 for under $13. b) You can buy RFID stickers that will fit on the underside of a loco, right down to sub-4mm diameter. Work out to be less than 20p each. This is rubbish, RFID signals cannot work through copper tape (the kind you use for RFID-proofing things), sometimes called faraday tape (google search TitanRF), its simple to constrain the reader to the track with it! Reliable read rates are easy enough to achieve, you need to make sure the RC522 maintains maximum gain, here is some sample code, just throw it in loop() and execute it every 30-40 seconds or so, you can increase or decrease the gap depending on how your RFID system performs. It'll vary based on your environment and equipment being used. Serial.print("Health Check... "); Serial.print(mfrc522.PCD_GetAntennaGain()); Serial.println(""); if ((mfrc522.PCD_GetAntennaGain()) < mfrc522.RxGain_max) { mfrc522.PCD_SetAntennaGain(mfrc522.RxGain_max); Serial.print("Reset gain... "); Serial.print(mfrc522.PCD_GetAntennaGain()); Serial.println(""); } To reliable read at high speed rates, you need to optimize the way you write and store data on the RFID stickers. The test loco that I use for the RFID system is a Hornby GWR HST (the expensive one not the railroad model), it has a rectangular RFID tag on the base of the dummy power car, each of the coaches (its configured in GWR's 'castle' formation) and the powered power car has a special RFID tag for application on metal (costs about 50p). At full speed, I can read all the RFID tags. The trick is to store the data you need in the first usable sector and one of the last sectors, I typically use the first sector and sector 14. You most likely don't need all 1K for pulling identification information, you probably only new a block or two. If you duplicate the same data on the first and a latter sector, then program the microcontroller to pull just those sectors, you can then verify the data is correct by comparing the two. If you don't want to write your own code, my code will be in the 1.1.0 release of the oorail-system, which will be released on Tuesday March 3rd 2020. You can find it at https://github.com/oorail/oorail-system just check back on the 3rd. It will be in the modules/ directory. Oddly enough that digital dc system you were ripping on for not offering any other functionality actually does this! :-D And now there is an open source project that provides this for him. What was that about looking for a problem to solve?

and there goes your credibility... Did you really just say that Wi-Fi has a lack of standards? Have you ever heard of the IEEE? Maybe 802.11? Here this may help you out: https://en.wikipedia.org/wiki/IEEE_802.11 WiFi not only has dozens of standards, its also regulated. btw. You can also use Wi-Fi and Bluetooth at the same time.

You are definitely entitled to your opinion. I'm going to let the next couple of code releases speak for themselves.

Yes but initially you have to keep things simple and build on it. This is how you build a platform that is modular and can be used by various different people for various different applications. Yes you are quite correct. Very few model railways have proper signalling either. Ah but proper signalling blocks is exactly what DDC provides. Perhaps I should have mentioned that our project has a consultant who has decades of experience with railway signaling at British Rail, Network Rail and several outside consulting firms! Give it time, it'll get there

Thanks. There has been a lot of interest in the project, I don't think it will be too long before a few places are offering pre-built systems for people who don't want to mess with the electronics. This is actually something we've already been working on. The next release will have our RFID module which enables detection and identification. If I have enough time, I'll see if I can get the IR and photo resistor modules cleaned up and API added for them.

Thanks Yeah I understand where you are coming from. This is the reason that the code releases are going hand in hand with demo videos and howto videos on the YouTube channel. I'm not expecting your average modeler to pick this up anytime soon. Its more for people who experiment with similar things to check out and for folks to provide feedback. It will appeal to different modelers at different stages. Its all about providing options. So what I meant was that "electronically" the track module is doing the same type of digital control of the motor that the DCC decoder is doing inside the locomotive. So the same "digital" control is possible, such as inertia, close control etc. The track module is just doing it via the track rather than in the locomotive. The wireless handset <-> DCC master control unit is wireless on those systems, but the DCC master control unit to the decoder is not. Yes, if you want blocks, you will need to divide your track into blocks. However you just need a track module per two blocks and the modules are wireless. So a pair of wires from the track in that block, and 12VDC to the module. Probably less wire than DCC droppers, the only difference would be the need for insulated fish plates between the blocks. We will cover doing blocks in an upcoming release and videos.

Not really. Perhaps you should look into what a block actually is.. "Signalling block systems enable the safe and efficient operation of railways by preventing collisions between trains. The basic principle is that a route is broken up into a series of blocks, only one train may occupy a block at a time,[1] and that the blocks are sized to allow a train to stop within them. This ensures that a train always has time to stop before reaching another train on the same line. A block system is referred to as the method of working in the UK, method of operation in the US and safeworking in Australia." Note "only one train may occupy a block at a time". Banking and double/multi-heading for the purposes of blocks are just one train. Station pilot operation is similar to depot and siding operations, which are special cases. Yeah this is pretty obvious? Wheels will bridge between blocks, its a pretty standard problem. You can synchronize PWM waveforms on the ESP32 using library calls. We also have a couple of neat software "techniques" that prevent problems with wheels bridging the gap. Some require the use of some sensor data, so you'll see these up in GitHub as the sensor modules are finished and made available. sounds like you This is not true at all. Even with just the track module, DDC provides: Digital speed control Profiles that enable tuning to match the loco Independent acceleration and deceleration inertia Braking Consistent illumination of lights Simple automation (show me a DC solution where you can script control with a few URLs out of the box?) Or you could fit decoders where you can update the software on the decoder, modify the software on the decoder and add sensors? (see (a)). Its no more technical complex than DCC? Yes, but you are comparing something thats brand new and under development, with something that is 30 years old? You are also missing the point that the API provides the ability for anyone to build their own throttle, whether that is company or end user. You only need the 12V and 5V power, everything else is handled by controllers. The track module is just one module, there are many many more moving their way from PoC into general availability. Again you seem to have missed the original post where this is an open source project, so the development is eh.. open? This is on the controller? These are handled "automagically" by the controller. I just finished loading esp32tools onto the controller image, so the controller can now "program" the esp32 modules via USB. So essentially, you plug an ESP32 into the USB port, select the type of module you want it to be (eg. track etc), and then it loads the software onto it. LOL. Looks like I've hit a nerve! FYI.. this is just one module, its not the entire system The mistake you are making is that the initial release isn't an end-user targeted solution. The initial release is a "hey check this out, has a lot of potential". Ultimately, the solution will be very simple to install and use. The project has a couple of different goals, one of them is to enable it to be used to teach people how to build systems. Which is why the code is being released in a certain way. For example, 1.0.0 has just L298N support, it has synchronous HTTP support, these are deliberate design decisions to make the thing "safe" for people to experiment with. The 1.1.0 release has a specific roadmap, but there is also cycles set aside for bugs or features or difficulties people have. Obviously its not too complex since we've had just over 30 people sign up for different paid subscription models to get weekly private beta access. The 1.0.1 release that comes out later today in private beta fixes some bugs, adds a lighting module and RFID module. The feedback we've got from a few people is that the controller is an item they want sooner rather than later. So for the remaining pre-1.1.0 releases, we're prioritizing the controller. The controller enables us to default asynchronous HTTP support (it requires an independent library) but we can pre-package that into the controller. So just with the second public release (1.1.0), you should be able to just download and write the image to an SD card, boot up the controller, then automatically program your ESP32 modules. We will probably try to cramp ESP8266 support into 1.1.0 if I have the time. This isn't correct (see my response to the question back up the top.. This depends on the number of blocks you decide to have, which is dependent on your layout. The PSU we recommend will power two track modules, so PSU ($20) + L298N ($2.67) + ESP32 ($6). One L298N will power two block sections. So $20 (PSU) + $5.34 (L298N x 2) + $12 (ESP32 x 2). So you are looking at $37.34 to power four track sections, or if you're not doing blocks, four loops. This is about the same cost as one analogue DC controller. Even if you have a massive layout like we have here at oorail. You are still looking at a fraction of the cost of chipping every loco with DCC. You are making an incorrect assumption here. You are looking at probably $14-$16 in off the shelf hardware modules, and $6 for an ESP32 or possibly less for an ESP8266, to support the siding software module. Not really. You don't need any software knowledge, this will become very clear once the controller is available. Again you are confusing open source project with finished product. You don't really need to be familiar with electronics hardware, you just need to be able to watch a video and follow instructions. I fully understand this isn't everyones cup of tea, however we've already had multiple inquiries just from the demo video from several companies in the UK that want to build and offer the systems. So obviously its got some peoples attention! This is temporary, once the controller is released this requirement will go away, as will the need to use the arduino IDE. Again you should re-read the original post! Wow this is pretty funny. You do realize the whole thing is modular right? You break an L298N module, you swap it out. You brick an ESP32, you swap it out. You break the software, you just reflash it. The source code is fully available. Its literately about as open and user repairable as you can get. There is also the issue tracker in github, as you can see from replies on here, we're pretty responsive! Again.. this is your opinion and again I don't care who uses it and who doesn't use it. This is about doing something different and giving people different options. There are already several layouts using this system, if you think this system is limited to the track module, you are very misguided. The track module is a very small part of it. As I've said in previous replies, the project will resonate with different people as it hits different milestones. So sit back and enjoy or go back and play with your CAN bus. Thats the nice thing about model railways, you can check out the options and pick out what works best for you!

Ironically this makes absolutely no sense at all..

Not available to the public, there is part of the problem right there. Arduino is ok, but IoT platforms like ESP32 are much better controllers. I see why you're aggressively "critiquing" this now, you worried it'll obsolete the efforts of merg. People will choose what they want to use. Ultimately things that are built in hardware get replaced with software defined solutions. Look at networking, it used to be dominated by FPGA/ASICs, now everything is moving towards SDN. I don't need to justify anything. I'll let GitHub do the talking release after release!

Thats odd since I've got a prototype sitting in a Class 66 that cost under $20 to put together!

Obviously its a bit above your head. Go check out Adaptive Radio Management, its been around for over a decade!

Not really. Having a fully programmable (actually programmable, not setting fields like DCC does with CVs) decoder on the locomotive opens up a slew of possibilities, aside from stuff DCC is capable of like independent control of lights and the motor. You can also do some pretty slick stuff with sensors and get advanced telemetry from the loco. This is just one application. This is actually not true. The PWM on the ESP32 supports three modes 7-bit, 10-bit and 15-bit if my memory serves me correctly. We've done extensive testing with dozens of locos from different manufacturers, you can see some very basic results of this in the manufacturer profiles that we added to the track module in 1.0.0. It is early days yet, but basically you will be able to tune both the resolution and frequency, along with the speed-step range within that configuration for optimal control of the loco. This maybe using the resolution for inertia or directly through speed steps. Ultimately though we will be able to use this along with data from the real prototypes, to simulate the running characteristics of the real thing. WiFi brings a lot more that higher data transfer. WiFi is being used to connect the module to the controller, so the API you see with the track module will ultimately be consumed by the controller, which the user will either interact with or configure for automated operation. The controller uses WiFi to exchange state and health information on the module, and gather other information. so what? DCC is definitely *not* cheap. Sure you can get $10 decoders, they also seem to lose their settings and go POP quite often. I think you are missing the point about the reliability of using the data single over the power signal over metal track as being a reliable communications means. You just have to pickup something like a Bachmann Dynamis which is a reasonable OK DCC controller and the latency issues with DCC are pretty apparent? If you say otherwise, you just in denial! Again why does this matter? This system is just another option. No harm in having alternatives are there? This is completely wrong. You would be a complete nut job to expose your model railway at an exhibition by attaching the modules to public WiFi. The system ultimately uses a controller (should be available in the March release 1.1.0) which has the option to act as a secure WiFi access point, or you can use any off-the-shelf access point. The DHCP server on the controller takes care of IP handling, manages the WiFi network and won't have any issues with channel contention. You guys seriously have WiFi knowledge that is about a decade out of date! The ESP32 is a widely used IoT platform, it is the successor to the popular ESP8266 platform, which is also still widely available. Short of a massive coronvirus outbreak, which to be fair is quite possible, you should be able to source these for years to come without any issues. This is a bit like asking what if OLED displays become unavailable. We are adding support for other IoT hardware platforms including Particle, and of course we will be adding support for the Arduino with both WiFi and Ethernet support. Most likely going to see support for ESP32, then ESP8266, Particle, Raspberry Pi Zero and then other IoT platforms. This is the dumbest thing I've read all day. You do realize that HTTP based APIs are the foundation for high performance / highly scalable distributed cloud applications and microservices right? Obviously not by your comment. Security is managed through the controller, the controller sets up the private network, so the connections between the controller, the modules and between the modules is all done under encrypted WiFi using things like WPA2. Since the data is being exchanged internally, this is very similar to the data being exchanged on the backend of enterprise cloud computing deployments, where you use HTTPS on the frontend and HTTP on the backend as the backend is usually a private network. Access control is handled by the controller. As mentioned in the original post, the 1.0.0 release is about making the technology available for people to play around with and get familiar with, provide feedback. All of those buses you mention are CAN based. There is a massive difference between a CAN bus and an advanced REST/Web based API!

Oh I understand what you are saying. I'm not confusing anything. What I'm saying is that there are "ways" to "guide" unmanaged access points so they don't interfere with your network. There are a wide range of techniques you can use to do this. Think of it as "herding" the other unmanaged wifi access points / routers to go where you want them to go, often this is done by creating conditions that trigger features that cause the neighboring access points to react a certain way. Exhibitions are a very small subset of model railways compared to layouts at home, where you won't really have this density issue, and if you do, you've got other problems! For exhibitions though, there are other things you can do to limit the impact of neighboring wifi, even outside of software. It really is a non-issue.

Cool, the more folks developing on esp32 the better. Do you have your code up on GitHub somewhere? What kind of things do you like to develop? Yes, that is also one of the goals with this solution. I currently have a prototype board stuff into a Hornby Class 66 that allows you to control the loco that way, and it also works with the track control. Once I have modules that have tested safely for a few weeks, and I have the time to document it up, I'll push the code and the documentation / video for it. Extra processing steps.. This is a very simplistic way of looking at hardware architecture. There is a lot more to it than that, you should know that as well being a developer? Do you have a link to the spec sheets for these 4 core decoders. Soundtraxx have a couple of 32-bit decoders but there is no indication on their site as to the specifications, they also run US$188 compared to $5 for an ESP32/32S. That isn't a problem. I've already got this working in proof of concept. Even if you crank up the density of the block sections (for example if you want to build dynamic blocks). Its handled by code in the microcontroller with the control plane done via WiFi. This really isn't that hard, I have over two decades of experience writing code for high-end enterprise networking devices (eg. firmware) across layer 2-7. Its not hard to do if you apply the right techniques. For example, I saw someone post a few months back that it was impossible to do something via RFID, however I was able to do it by increasing the output of the RFID emitter and optimizing how the data was written to the RFID sticker. I'm very familiar with CAN. You still have to run the two wires, you don't need to do that with WiFi, and WiFi doesn't suffer from the node limitations of CAN. CAN can only support up to 64 nodes. Do you have a link? There seem to be a lot of people very afraid of this system why is that? Again, this is just another option. Its something I developed for my layout because there wasn't anything on the market that let me do what I wanted to do. Looking at the tone and the number of posts you've made, you seem to be afraid of this system for some reason. Why are you worried if it replaces DC or DCC or both? Yeah I did come across some folks that ran into that problem. It looks like it may have been a bug in the ESPNOW stack, I have tested several MESH configurations with it, and haven't run into the RTT problem. Its also possible that the guy who was complaining about it had a mistake in his test code. The original problem was reported some 11 months ago, no longer seems to be an issue. ESPNOW has some potential but WiFi + IP can be optimized so easily, I am not sure for model railways you would need more than that.

I'm guessing from your tone the existence of this has sort of upset you. No worries, you don't have to use it! What you said above here is pure nonsense, the power has to flow through the track-wheel whether you are using DC or DCC. We've tested the DDC system for a very long time, there is no impact on lighting using the system because of the way PWM works. Perhaps you should go read up on it? Actually thats not true at all, the hardware architecture and performance of the microcontroller play an important role in what can be done. DCC is a signalling protocol thats piggybacked over your power source. Its not the most ideal of communication methods. You don't know too much about WiFi do you. What you've written here is complete nonsense. 2.4GHz is the frequency spectrum, 802.11n runs off both 2.4Ghz and 5GHz, and the frequency spectrum is channelized. Modern wifi systems adjust the power output of the radio and perform analysis on the channels to avoid collections. What you've basically said above is the equivalent of saying if you have two mobile phones in the same room they won't work. Complete nonsense. Not really. You are missing the point. You can assemble this system by buying 2-3 items off Amazon, plug together and off you go. You can't do that with DCC. Also if these kits are so available how about some links? Dozens? Hundreds? So far you've provided two? Eh, this code hasn't been touched in about 6-7 years, and one of the outstanding issues from 2013 is that it doesn't output properly?? Again, this is all about providing options. You guys seem really adverse to having options, why is that? That is the case, either you have no idea how to navigate GitHub or you are just knocking it for the sake of knocking it? The code is in the modules directory. That is one way to do it. However if you are a little smarter about it, you don't need one controller per section. If you check out the PSU video, you'll see you can control two modules with one PSU, and each module controls two track sections. So you can effectively power four block sections very cheaply.

Thanks for taking the time to comment. First off, I'm really confused why people think this is some kind of business venture, this is an open source project. Its the sort of thing as you have pointed out that would get a bit of a grilling through something like Dragon's Den, not because of the system, but more those type of investors look for big money returns. As an open source project though, it is highly disruptive for a variety of reasons. Practically, are you ever going to have more than one train per block except for maybe in a siding or depot? If you have a main or branch line, you'll never have more than one train in a block anyway? If you have more than one train running in a block, your blocks are probably too big. You sort of touched on one of the things you can do with this, which is slicker changing between blocks. With a little more effort, you will also be able to use this to build dynamic blocks, which you can change via software! Also the way this system is designed, it supports running a type of Digital DC decoder, so you can drive the track or if you want to drive the train by adding the decoder. You can also to a host of other really cool things in terms of telemetry by sticking a programmable system on a chip in the loco. The trick with getting people on board is making them want it badly enough, like I said in previous posts, there are milestones where people go, oh I want that, they look to see whats involved and they either go there or not. This is an open source project to build something better, push the envelope a bit and obviously its going to upset a few DCC purists who feel a little threatened by it.

There is no such thing as a WiFi domain. WiFi operates on different frequency bands, and each band is split into channels. There are a wide range of techniques you can use from adaptive radio management (adjusting the channel / power levels of the radios) to maintain appropriate levels of SNR. There are things you can do at a packet level (802.11) that will discourage other access points from selecting certain channels. A layout, especially at an exhibition is a pretty finite space, it would not be a challenge to establish a very workable WiFi network even when you are dealing with hundreds of conflicting access points. There are a number of vendors - Aruba, Ruckus, Ubiquiti, Cisco etc, that have done this at trade shows for well over a decade. Its a non-issue if you know what you are doing

I've got several years experience developing code for Enterprise grade WiFi solutions for companies like Aruba Networks. Exhibition hall wifi-problems are poor deployment and bad management vs a technology problem.

Its not actually a proposed system, you can download the code and run it now Also this isn't the entire system, its just the track module. The DDC solution uses a mesh of "track modules" which consist of the microcontroller (ESP32 currently, but ESP8266 / Arduino and even Raspberry Pi support is coming) and a motor driver module. The ESP32 provides a HTTP API interface into the module for control and collecting data via WiFi. The DDC mesh can work with just one module or dozens of modules. The decoder on the locomotive isn't necessary, its optional. So if you decide you want to control on-board lights or have the loco provide you with telemetry, then you can optionally put the decoder into the locomotive. The decoder in the locomotive uses WiFi to communicate with the track module, and adjusts the power going to the locomotive based on whats incoming from the track. To answer your question on how its different see below, you also have to factor in that the software is a HUGE difference between DCC and DDC. Decoder is optional (mainly for lights and telemetry) Decoder can provide advanced telemetry back to the system, again is optional DCC has to convert the AC signal to DC and decode the DCC signal for instructions (processing) DDC already has the controlled signal (eg. what you'd normally get out of the decoder to the motor in DCC) going straight to the motor DCC uses the track as a control plane (means of getting control signals to the locomotive) DDC uses WiFi so the performance, bandwidth and exchange of data is orders of magnitude faster The WiFi modules are cheaper than DCC decoders, the cheapest DCC decoder I could find on-line here in the states was discounted from $23 to $18.50. The cheapest WiFi module that you can buy is under $5. The decoder is 3x the cost. In fact, the decoder costs more than the ESP32 module plus the L298N motor board. Two decoders, and you've got the cost of the track module and a decent din-rail mounted PSU. Its already an advantageous price for users - low cost hardware and FREE software? Again, this is an open source project, the size of the market doesn't matter? Its about giving people a choice and building something better. If you want to use it great, if you don't use it, I couldn't care less The system isn't just the track module, so if you have a DCC layout, you can indeed benefit from the solution while retaining your DCC control. Supporting DCC isn't a top priority at the moment because the Digital DC development is where the focus is being placed. You have to realize that what I've done is looked at analogue DC, the same way the people who invented DCC did 30 years or so ago, looked at what DCC does today, and asked myself, how would I implement this today using today's technology. When DCC was invented there was no-WiFi, dial-up Internet was just starting to become a thing and 486 computers were state of the art. Electronics were huge, go compare a 486 motherboard to your phone! The problem is that no manufacturer is going to toss DCC out the window, they've got too much invested in decoder designs and controllers. DCC involves pushing a data connection over track, so its not as straight forward as grabbing an ESP32 module from Amazon. They have zero motivation to innovate there, they want to keep pushing DCC, its profitable. However they still make DCC-ready locomotives? Why? Lots of people are still on DC, have no interest in moving to DCC and DCC pushes the price up because DCC is specific to model railways, no other industry to share the costs involved. If you look at new releases, DCC factory fitted is still in the minority of options, most DCC fitted options are companies like Hattons and Rails doing it for you before they ship out your loco to you. So if I'm on DC, and now I can go to Digital DC, what is the motivation to go to DCC? It costs way more. Makes my locomotives more expensive. The only difference now is that I can turn the lights on and off, and raise a panto (on a couple of models). What about sound? Well with Digital DC, if you know where the locomotive is, you can software control the sound through a 5.1 surround sound system using the same techniques that are used in video games. You can pickup a decent 5.1 Logitech surround system, add a sound module to the software and tada.. you have far superior sound to a speaker you can toss into your locomotive. DCC has a lot of barriers to entry normally for a lot of people. Its also quite interesting to look at the problems people have with DCC - blown decoders, decoders losing settings, decoders not responding properly etc. These are all symptoms of the design of DCC, the track as a digital communication medium its pretty innovative in 1990, but in 2020, its a bit daft when you have WiFi, BLE, ESPNOW etc. Whats interesting is people seem to "quietly fix" their problems with DCC, I don't know if its buyers remorse, they just live with it, have spent so much on the system and don't have any other options. Once I get DDC where it needs to be in terms of modules, code etc, I will turn focus to adding track support for DCC, the reason for that is there are a lot of DCC users out there, and by doing so, it offers an upgrade or at least an integration path with their existing investment. Its quite possible, you'll see people in the future using DDC alongside DCC, the same way people use DCC alongside DC as they migrate or run both systems.

The technology advantages aren't claims, they've already been demonstrated. You just have to look at the specs of an ESP32 and compare it to the performance of a DCC signal over track to a decoder? Its like comparing a toddlers tricycle to an Aston Martin! Thats not exactly true. Yes, DCC is an open standard but the decoder designs are indeed proprietary. DCC is also specific to model railways, the electronics aren't being used elsewhere, so the market is relatively tiny compared to the electronics used for DC applications used in everything from IoT to appliances to industrial applications. So it does indeed need "special components", your DCC decoder and DCC controller are both special components. There are things like DCC++ which makes some code available, but a lot of the code in that project hasn't been touched in many years.