Jump to content
 

Digital DC (DDC) - Open Source Project


oorail
 Share

Recommended Posts

Good evening... 

 

I recently started an open source project called Digital DC (DDC) which is a modular system for computerized train control using a web based API (HTTP).

 

The project is functional enough that I released a copy under GPLv3 as Open Source, you can find it over at GitHub at https://github.com/oorail/oorail-system

 

There is an article detailing the system a little more at https://oorail.co.uk/digital-dc/ and you can watch a demo of the system over at YouTube:

 

 

Let me know what you think, its early days yet, so a few things to keep in mind:

 

1. This works but its a 1.0 release

2. The HTTP interface for the track module is *NOT* the end user interface

3. There is an open source app under development that will interact with the HTTP API

4. This is for people to have a look at, get involved if they are interested etc.

 

There will be a month main release on the first Tuesday of every month.

 

Thanks

  • Like 1
  • Craftsmanship/clever 1
Link to post
Share on other sites

This may be interesting but having read quickly through the OORail web page I'm still not clear what a railway modeller would need to do to use your system and what exactly it is currently capable of. It is not the first time I have come across an introductory website that has lots of praise for itself but little concrete information. (By the way the video stopped working a short distance in and I could not get it going again - that could be the fault of my slow internet connection)

 

I think (and correct me if I am wrong) that you are using an ESP32 WiFi module to receive instructions from a phone or tablet and via an L298 H-bridge it controls the DC power in the track so that normal DC locomotives can use it. And I believe your system does not have any microchip in the locomotive.

 

I am a little surprised that you have combined a very modern WiFi chip with such an old-tech motor driver - there is such a thing as taking cheapness too far. IMHO a driver that can comfortably deal with short circuits is a must.

 

I have built a system for wireless hand-controllers for a club DC layout using nRF24L01+ wireless transceivers and it has been well received so I can see that users could be interested in your system.

 

On the other hand, I have also been building an Arduino based system for turnout control and, because there has been no interest among club members to learn Arduino programming we have concluded that the future of the layout will be more secure if it is based on a commerical system - in this case Megapoints. In retrospect the lack of interest in Arduinos is understandable - it's a model railway club and not a computer club. I suspect you may face the same problem. It seems to me most railway modellers have more money to spend than I have and just want to see their latest Bachmann, or Hornby or ... running as soon as possible.

 

...R

Link to post
Share on other sites

Thanks for your feedback Robin. You seem to have missed the instructions that are listed on the oorail site:

 

https://github.com/oorail/oorail-system/blob/master/README.md

 

You can find the current capabilities in the release notes:

 

https://github.com/oorail/oorail-system/blob/master/docs/release-notes/2020/Release-Notes-1.0.0.md

 

The code on the track module (which you can check out on GitHub) provides a web API that allows you to interact with the software to control and obtain information from the module.

This is not intended to be the end-user interface but an API for other software / modules (that are in progress) to interact with, that will provide the end-user interface.

 

Yes, you are quite correct the L298 H-bridge is an older type module, you are also correct in that its very cheap. Worse case scenario in a short-circuit situation, you may end up damaging the L298N board. However, last month for example, we had several modules running for about 9-10 hours continuously a night with a variety of different locomotives, without any issues. The L298N is a good starter module for people to learn on, should they want to. In terms of supporting other modules, I am currently cleaning up the code for L293D modules, so support for these will end up in 1.1.0 on March 3rd. Currently testing proof of concept code with DRV8833 and L9110S modules. I also have a couple of other more specialized modules from a few "drone" part suppliers coming in this month, so I'll be testing those out in terms of viability. The goal with the track module is to support as many different options as possible. If you check out the code you will see there is initial support for optional features:

 

/*

#define OORAIL_FEATURE_WIFI_LED 1

#define OORAIL_FEATURE_ASYNC_WEB 1

*/

 

You would uncomment the features you want to enable. The reason this support is in there is to make the ESP32 (which like most system on a chip solutions has limited resources) as feature-rich as possible while protecting the resources. So for example, you most likely wouldn't drive L298N and L293D modules off the same ESP32, so when there are multiple modules supported, you will enable/disable the ones you need in the code. I will probably leave them all enabled until the ESP32 starts to get close to running out of resources.

 

Another thing you'll notice is that the initial release doesn't have asynchronous web support, this was done on purpose so users can learn about the system without running into issues sending conflicting commands to the module. The next release will add support for asynchronous web support, and some improved reporting.

 

I definitely agree that there will be some individuals who would prefer to spend more money to install and go without putting any real effort in. I think this goes for a lot of different aspects of model railways though, you have individuals who prefer to spend rather than learn modeling skills, and thats totally their choice. The nice thing about model railways as a hobby is there are always new ways and new options, for example a lot of people don't like woodworking or are just bad at it, which is where there is increasing demand for laser cut baseboards. You just have to look at the folks buying z21 and ECoS systems, sometimes both. You also have to factor in though that not everyone has such deep pockets, and many are more than happy to learn when shown. 

 

Which is one of the reasons I started the project (aside from needing the code for my own layout), the project isn't just about making the software available each month, its also about the videos on the YouTube channel that will be pushed out as I release code. Its probably not going to be picked up by someone who just wants to buy, drop and go, but there are a lot of people out there who would like to learn this stuff, and this is a means for them to do so.

 

The nice thing about this project is that its licensed under GPLv3, and the project is setup so that commercial dual-licensing is also a possibility. I have over two decades of professional programming experience incorporating open source solutions, so I definitely know there is market there for taking a project such as this, adding your own parts to it and making it available as a more expensive drop in solution to cater for those who want that option.

 

You also have to factor in that this is an early stage project, I understand that many people will most likely opt to buy a HM 6000 and be quite happy with it. However, I also know that there are individuals who will look at this project as it progresses, we will hit different milestones that will interest different people. The first stage of the project is functionality, that is where we are now, adding modules, extending support, adding more modules, getting feedback from people as they watch demo videos each month. As that is built up, adding support to make the system less of a computer project and more of an end-user solution will get added. 

 

To give you an idea, this weekend aside from messing with L293D module support, I grabbed the latest version of Raspbian Lite, which is the Linux platform for the Raspberry Pi. The reason I did this, was to start the packaging and release work for the layout controller. The layout controller is the computer system that will ultimately interact with things like the track module via the API.

 

User (tablet/phone/computer/digital knob) -> layout controller <-> various modules on your layout

 

The layout controller is really important because it makes the whole system easier to build, for example, you just need to plug together a raspberry pi, download the pre-built image (that I'm currently working on) to an SD card, plug the SD card into the raspberry pi and point your browser/phone/mobile device at it. The controller also enables us to do things like over the air updates to the ESP32 modules, and probably automated deployment of module sketches to the ESP32 modules.

 

We are also not limiting the project to ESP32, we have prototype code for adding support for ESP8266 and Arduino. 

 

Unlike something like the Hornby HM 6000/6010 or Megapoints products that are developed behind the scenes, this is being developed as an open source project, you can follow along with the progress, provide input if you'd like and jump in when the project hits a milestone where you go, wow I really like that I want to give it a try. For some people that was last week with 1.0.0, others it might be 3, 6 or 12 months from now, for others its probably never. However for that last group, the way the project is licensed, opens up possibilities for model shops, on-line retailers or even manufacturers to commercially license the solution and offer it. 

 

Another interesting thing to consider is that we'll be offering downloadable STL files for printing enclosures etc, so ultimately if you watch the videos that are coming, follow the project, you'll be able to build your own commercial-quality system in a few months. It'll be interesting to see how many younger people this might bring into model railways as a hobby coming from the computer side of things. 

 

Anyway I've rambled enough, this is another option thats there for people to take if they so wish.. so enjoy! :)

 

btw. I get the impression you might be more of the target audience for the initial release :)

 

 

 

 

  • Like 1
Link to post
Share on other sites

  • RMweb Premium

Various Merg members have been working on digitally controlled analogue controllers using cheaply available ready-built modules. They use the same throttle bus protocol as the Merg CANCMD DCC Command Station, each analogue output being assigned one DCC address. Using the Merg CBUS as a common throttle bus allows the analogue controllers to be used with the Merg CANCAB hand held thottles. It also means that using the Merg CANUSB module to connect the CBUS to a PC or Raspberry Pi, JMRI or RocRail (both of which already support Merg CBUS) can be used to provide software throttles, or via their WiFi services, Engine Driver, WiThrottle or DigiTrains mobile phone/tablet Apps can be used to control analogue trains. Just select the DCC address allocated to the analogue output and then control the train on the analogue track. There is also the possiblity of then using JMRI or RocRail to partially or fully automate an analogue layout.

 

Here is my test prototype for a cheap 2-channel controller I call the CANCMDDC Duette.

 

CANCMDDC_Duette_prototype.jpg.2c44c0d2bc9e1bfe1682c1d84da7bc7b.jpg

  • Like 1
Link to post
Share on other sites

2 hours ago, oorail said:

Thanks for your feedback Robin. You seem to have missed the instructions that are listed on the oorail site:

 

https://github.com/oorail/oorail-system/blob/master/README.md

 

You can find the current capabilities in the release notes:

 

https://github.com/oorail/oorail-system/blob/master/docs/release-notes/2020/Release-Notes-1.0.0.md

 

 

You are quite correct. I did not look at the Github pages.  Github is for programmers. I was trying to look at your stuff through the eyes of a railway modeller. 

 

IMHO you need to consider carefully who your target "market" is. On the one hand it might be programmers who could be tempted to try model railways. On the other hand it might be model railway folks who could be tempted to try programming.

 

Also (IMHO) the subset which is already both competent with programming and interested in model railways (like me) is {A} a very small proportion of railway modellers and {B} unlikely to need your product.

 

Breaking a new market is not easy. Look how long it took DCC to get where it is. And I suspect the largest part of its current attraction is sound. I am a firm believer in the Open Source ethos but the evidence all around us is that most people feel more comfortable with commercial products. I know it seems like heresy but I suspect you might actually get more market penetration if you commercialized your product - similar to Megapoints. Of course that does require the time and commitment to make a commercial product work.

 

My own interest is in battery powered radio control for my trains. The number of railway modellers interested in that is also tiny. And the most frequent objection to it is the demand for sound - which does not interest me at all.

 

In case it is of any interest I am using Infineon TLE5206 h-bridge chips in the wireless DC system I am building for a club layout. They have a capacity of 5 amps with short circuit protection and error feedback.

 

...R

Edited by Robin2
Link to post
Share on other sites

20 hours ago, Robin2 said:

You are quite correct. I did not look at the Github pages.  Github is for programmers. I was trying to look at your stuff through the eyes of a railway modeller. 

 

IMHO you need to consider carefully who your target "market" is. On the one hand it might be programmers who could be tempted to try model railways. On the other hand it might be model railway folks who could be tempted to try programming.

 

Also (IMHO) the subset which is already both competent with programming and interested in model railways (like me) is {A} a very small proportion of railway modellers and {B} unlikely to need your product.

 

Breaking a new market is not easy. Look how long it took DCC to get where it is. And I suspect the largest part of its current attraction is sound. I am a firm believer in the Open Source ethos but the evidence all around us is that most people feel more comfortable with commercial products. I know it seems like heresy but I suspect you might actually get more market penetration if you commercialized your product - similar to Megapoints. Of course that does require the time and commitment to make a commercial product work.

 

My own interest is in battery powered radio control for my trains. The number of railway modellers interested in that is also tiny. And the most frequent objection to it is the demand for sound - which does not interest me at all.

 

In case it is of any interest I am using Infineon TLE5206 h-bridge chips in the wireless DC system I am building for a club layout. They have a capacity of 5 amps with short circuit protection and error feedback.

 

...R

 

As I mentioned in my previous comment, as the project hits different milestones, it will interest different groups of people. GitHub isn't just for programmers, it provides access to things like issue tracking, release builds (so you can download the zip vs having to use git) and so on. Looking at the number of tracked issues in JMRI, I'm going with railway modellers don't seem to have a problem using it.

 

Ah so I think you are confusing open source, programming and commercial products? This is an open source project, which means the code is available to you if you want it under an open source license, it this case GPLv3. However you don't need any programming skills to use it. Give it a couple of releases and you won't even need to use the Arduino IDE to load the code onto the modules. To use this project you have to be able to:

 

  1.  Operate a screwdriver
  2.  Operate wire strippers
  3.  Capable of putting a wire into the hole in a breadboard
  4.  Matching numbers/letters
  5.  Downloading files from the Internet
  6.  Editing a file to type in your WiFi user/pass info
  7.  Clicking some buttons
  8.  Following instructions
  9.  Use a web browser

 

You don't even need any soldering skills. So I think most people can pull off the above. You definitely don't need any competency with programming. In fact the point of the project is that you gain from my pretty decent competency with programming.. :)

 

I'm not concerned about target markets and this isn't a product, its an open source project. I think you'll find that people will look for functionality and cost. If they can follow some instructions, buy some stuff of Amazon and save a few hundred pounds, they will go for it if that few hundred pounds is valuable to them. You also have to factor in the "cool" factor, when people see a feature or module that is available and their existing system can't do that, thats a milestone when they gain interest. This is more about meeting a demand (what I need for the two layouts I have) that isn't there on the market today and me just being nice and sharing it :)

 

You gave a pretty good example with Megapoints, plus Ian above gave a similar example with his CAN interface / bus. CAN is primarily used in automotive applications, so your car has one or more CAN buses. For model railways though its completely unnecessary, adds a ton of wiring and pretty much obsoleted by leveraging WiFi or WiFi-Mesh / IP / TCP or UDP stacks on top of IoT type solutions such as the ESP32. Not only that, everything moves from hardware to software, so updates are easier and the capabilities of the system are much more advanced that traditional solutions. It is a bit like DCC, it was a good option at the time, but that time was a couple of decades ago now, and things have moved on. 

 

I've also discovered over the past 8 or so years of running a model railway youtube channel that free information (youtube) and free  / low cost options tend to be a very strong motivator for people to learn! :)

 

Battery powered radio control is interesting, you might want to check out the smaller ESP32 modules like (I think its WEMO). I looked into a number of battery options when developing the PoC for a Digital DC decoder. I actually managed to stuff a WEMO ESP32 module, LiPo battery and a charging circuit into a Hornby Class 66, and charge it from the track. Its totally impractical though, but an interesting project. I ultimately came up with a better solution that does the "radio" control, well assuming you could WiFi as "radio" without needing the battery. 

 

FYI. I think the TLE5206 is being end-of-lifed by Infineon have a look at https://www.mouser.com/PCN/Infineon_cPD_231_19_update.pdf

 

 

 

 

 

 

 

 

Edited by oorail
Link to post
Share on other sites

47 minutes ago, oorail said:

Battery powered radio control is interesting, you might want to check out the smaller ESP32 modules like (I think its WEMO).

 

I did consider the ESP8266 - it can be built into a small package but it consumes too much energy and I want it always on. The Wemos boards would be far too big. 

 

Quote

FYI. I think the TLE5206 is being end-of-lifed by Infineon

 

That seems to be the story of my life.

 

...R

Link to post
Share on other sites

Sorry about the repeated Posts - the original seemed to get lost and I don't know why there are now so many. I can't see an option to delete the excess.

 

...R

EDIT - I have now hidden the duplicates as suggested by @dhjgreen (thanks for the tip)

Edited by Robin2
Link to post
Share on other sites

  • RMweb Premium
25 minutes ago, Robin2 said:

Sorry about the repeated Posts - the original seemed to get lost and I don't know why there are now so many. I can't see an option to delete the excess.

 

...R

Option, hide in each post.

  • Informative/Useful 1
Link to post
Share on other sites

Interesting idea, but I can't help but think some of the claims of this vs. DCC are a bit far fetched?

 

eg. How can a track-connected controller give better speed control than a DCC decoder directly in a loco with no extraneous connections between that and the motor?

 

And far sillier, the claimed advantages technology-wise or cost-wise of this over DCC.

DCC is an open standard, not proprietary. It does not need any "special components".

There are many examples of software, source code and command station / decoder hardware designs freely available.

 

 

In your proposed system:

You have a microprocessor controlled unit that applied PWM power to a track.

You also have a microprocessor based unit that plugs in to a loco DCC socket to provide direct control rather than whole-track control.

 

How are those two any different, other than software / firmware, from a DCC command unit and loco decoder?

The parts cost cannot be different purely due to different programming requirements - in fact using non-wifi modules, as that is not needed for DCC, would be cheaper still!

 

If you can make them at such an advantageous price for end users, why not make them DCC compatible so you have a much wider market?

 

 

Link to post
Share on other sites

6 hours ago, Robin2 said:

I did consider the ESP8266 - it can be built into a small package but it consumes too much energy and I want it always on. The Wemos boards would be far too big. 

 

...R

 

There are a couple of boards available now that are smaller than the Wemos D1 (ESP8266), there used to be a company in the Netherlands that made a module smaller than a DCC decoder. 

 

Not sure about Amazon UK, but they do show up from time to time on Amazon (US). You can also check Alibaba Express, but you might want to hold off on that until the whole coronavirus thing calms down.

 

The ESP8266 does have a low power mode, but you are correct the energy consumption for a battery will make even a good quality LiPo battery last only a couple of hours. 

Link to post
Share on other sites

5 hours ago, RobjUK said:

Interesting idea, but I can't help but think some of the claims of this vs. DCC are a bit far fetched?

 

eg. How can a track-connected controller give better speed control than a DCC decoder directly in a loco with no extraneous connections between that and the motor?

 

 

 

Obviously someone didn't look at the code! :)

 

The track module is more like a "track connected decoder", the controller part is handled via the API. The track module is basically a much more powerful and programmable decoder (try comparing specs on the ESP32 to a DCC decoder). 

 

The track module is taking pure 12VDC and controlling it via PWM, the resolution on controlling that signal is 10-bit, so you can literately go between 0-1023, tuning that along with the frequency to the specific motor for improved speed control. This isn't even the full capability of the ESP32, we could crank the resolution up to 15-bit that would enable even finer control of the PWM. This will only be further improved with support of better motor drivers too. The processing capabilities of the ESP32 are far superior to a DCC coder. With DDC you are controlling the speed before power hits the track. With DCC you are converting an AC-like signal and doing the PWM control of the motor on the DCC chip in the loco. 

 

With DDC its literately custom PWM (speed supply) -> track -> motor.

With DCC its AC-signal -> track -> DCC decoder -> process DCC signal -> convert AC-DC -> motor.

 

There are no extra connections with DDC, its power -> track -> motor. The difference is merely the DDC control is already done when the power hits the track, rather than it needing to be converted in the loco.

 

With DDC, you have a constant 12VDC supplied to the track, its just manipulated via PWM. Unlike existing PWM controllers, the frequency isn't fixed, so you can tune the frequency and resolution, as well as the start/stop/speed-steps via profile, to optimize it for specific locomotives. This is similar to using CVs for DCC, but more advanced as its in a nice data structure and not limited in length! :)

 

So if you look at this block:

 

 

struct oorail_pwm_t

{

unsigned int ENA; /* enable pin */

unsigned int IN1; /* input 1 or 3 */

unsigned int IN2; /* input 2 or 4 */

unsigned int mfreq; /* pwm frequency suggested 28kHz which is 28000 */

unsigned int mres; /* bit resolution */

unsigned int mchan; /* pwm channel */

};

 

This is the data structure for controlling the PWM with the L298N board, so a couple of things to factor in, the L298N board is an older module, you can get much better response out of some of the more modern motor driver ICs (chips). Support for those is coming up in the next few releases. This initial release was more to get people started with the idea.

 

The above structure has two values which are important, the mfreq, which is the PWM frequency, and mres which is the resolution of the PWM. It is the resolution that enables you to have finer control over the motor. 

Link to post
Share on other sites

5 hours ago, RobjUK said:

And far sillier, the claimed advantages technology-wise or cost-wise of this over DCC.

DCC is an open standard, not proprietary. It does not need any "special components".

There are many examples of software, source code and command station / decoder hardware designs freely available.

 

 

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. 

Link to post
Share on other sites

5 hours ago, RobjUK said:

In your proposed system:

You have a microprocessor controlled unit that applied PWM power to a track.

You also have a microprocessor based unit that plugs in to a loco DCC socket to provide direct control rather than whole-track control.

 

How are those two any different, other than software / firmware, from a DCC command unit and loco decoder?

The parts cost cannot be different purely due to different programming requirements - in fact using non-wifi modules, as that is not needed for DCC, would be cheaper still!

 

If you can make them at such an advantageous price for end users, why not make them DCC compatible so you have a much wider market?

 

 

 

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. 

 

 

 

 

 

Link to post
Share on other sites

You should be careful in considering that the UK predilection to using DC is representative of anywhere except the UK, and that resistance to DCC is universal. The UK is significantly behind the European market in the adoption, use of DCC and the availability of control devices and programs. My limited experience of the US suggests that DCC is the control system adopted by the majority over there also. 

Link to post
Share on other sites

As a person that develops for esp32 there’s a lot of hyperbole around 

 

the big advantage of dcc is the ability to drive trains wherever you like without section switching

 

 

as for conversion from AC to dc to ac for dcc , so what 

 

esp32 is a dual core processor , many sound decoders in dcc are now high performance 4 core 

 

dcc does  sound dc doesn’t without lots of additional kit 

 

note of you deploy lots of pwm  bassed dc controllers along adjacent track sections , you better have synchronised pwm or you’ll short the H bridge . It will be amusing to see how that’s done over Wi-Fi 

 

lastly as a builder of a layout with 70 CBUS modules all Can bus nodes I run two wires and power between each board and you clearly have zero idea about the uses for a bi directional layout control bus 

 

lastly Merg members have already designed a superior system to yours. Open source for Merg members, why invent the wheel 

 

by all means talk up your scheme , but it’s not new , and it will not displace conventional Dc or DCC 

 

oh and be aware that experiences in large model railway exhibition means that Wi-Fi is not reliable to the point of near un-usability  

 

 

Ps ESPNOW round trip time to ACK packet is truly awful , it’s a very slow protocol 

 

 

 

Edited by Junctionmad
Link to post
Share on other sites

26 minutes ago, Junctionmad said:

 

oh and be aware that experiences in large model railway exhibition means that Wi-Fi is not reliable to the point of near un-usability  

 

 

 

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. :)

Link to post
Share on other sites

Note also 

 

ultimately putting a Wi-Fi decoder in the loco is .... reinventing DCC  because the technology doesn’t deliver any real advantages 

 

10 bit speed is useless on most model railways, the typical model  motor can hardly resolve 128 steps ( a real GM engine has actually only 8 speed notched ! ) 

 

wifi brings higher data transfer , for what exactly 

 

dcc is a widespread cheap system , you can get $10 decoders and MERGs DCC system is about £60 

 

Railcom provides two way transmission 

 

DC users typically stay away from “ tech “ they won’t adopt this system either 

 

Wi-Fi brings issues in exhibitions , including IP handling and channel contention 

 

the esp32 is a single source proprietary Wi-Fi controller what happens if it’s unavailable 

 

using http is very inefficient and what security have to to prevent unauthorised access 

 

today for layout control there are several layout busses schemes including openlcb , Merg CBUS , loconet. Adding another is hardly Innovative 

 

Edited by Junctionmad
  • Agree 1
Link to post
Share on other sites

5 minutes ago, oorail said:

 

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. :)

Nope the problem is every layout is a separate Wi-Fi domain and the lack of channel space means there is poor connectivity 

 

this means that Wi-Fi can’t get a clear Chanel because there’s isn’t an enterprise wide system in place rather large numbers of individual access points 

 

it has already caused significant issues at large exhibitions , it’s not an issue of enterprise Wi-Fi. 

Edited by Junctionmad
Link to post
Share on other sites

2 hours ago, oorail said:

 

Obviously someone didn't look at the code! :)

I'm trying to be on your side. But don't expect people to start by looking at code. Railway modellers generally aren't interested in code unless they are first convinced that there is a system that might be useful to them - and maybe not even then.

 

Quote

The track module is more like a "track connected decoder", the controller part is handled via the API. The track module is basically a much more powerful and programmable decoder (try comparing specs on the ESP32 to a DCC decoder). 

I find this confusing. A DCC decoder is mounted inside a locomotive. Wireless controllers for DCC systems are now commonplace - they send wireless commands to the DCC master control unit.  As far as I can tell your module is located on the baseboard and it is a wireless control system for DC track power and if multiple trains are to operate the traditional cab-control track section wiring will be needed. (I am trying to use language that model railway folk will be familiar with).

 

...R

Link to post
Share on other sites

@Robin2 The way I read it is it just cab control, but digitised. This will mean that it will provide the same benefits and problems, albiet changing between blocks may be slicker. The biggest detraction is going to be that it back the the track being in control and dictating what can be done as I see it as one train per block, not like DCC where you can have as many trains as the available power (almost). Then there is the challenge of needing to sectionalise the layout to provide the individual blocks for control - that this biggest drawback that people bring forward to me when discussing automation and computer control, their views aren't going to change their views because the electricery is pure DC rather than a digital signal.

 

It would be nice to see it succeed, even Hornby are touting this sort of concept with their new Bluetooth control, but they have been talking block control for years and it has never appeared. 

 

Good luck to @oorail , though I suggest the he doesnt go to Dragon's Den for funding as he may receive a bit of grilling.

Link to post
Share on other sites

3 hours ago, oorail said:

With DDC its literately custom PWM (speed supply) -> track -> motor.

With DCC its AC-signal -> track -> DCC decoder -> process DCC signal -> convert AC-DC -> motor.

Exactly!

 

If you control the track power, you have all the drawbacks of track-wheel connectivity. If your lighting module is not controlling the motor, then that's also messing up any armature feedback through the track 

 

DCC puts the motor controller in the ultimate location, directly against the motor.

With buffering, which many newer decoders include and is a simple add-on for most others, temporary loss of track connectivity is irrelevant.

 

 

2 hours ago, oorail said:

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?

Garbage.

You are comparing two totally different things in a meaningless way.

 

The performance of whatever CPU is in a device is irrelevant, as long as it is sufficient to do the job properly. 

DCC is a signalling protocol that does not require radio or cause interference to other services.

 

And using WiFi is, to be blunt, idiotic.

The ESP32 is 2.4GHz only. With any system using 11n in the area, there is not sufficient bandwidth for even two simultaneous transmissions without collisions. In many cities 2.4GHz systems slow to a crawl or just give up at times due to congestion & hidden station effects.

 

 

2 hours ago, oorail said:

So it does indeed need "special components", your DCC decoder and DCC controller are both special components.

More garbage.

The components used in DCC decoders are all off-the-shelf parts. Anyone can build them from various kits or by buying parts & using stripboard or whatever.

 

And source code?? There are dozens if not hundreds of examples freely available 

I've just found an N-gauge decoder design, even - source code included and about $5 in parts to build:

http://web.nucky.jp/dcc/decoder4/onecoindecoder4.html

 

Or a source package on github: https://github.com/Railstars/Aegaeon

 

And of course all the MERG stuff, which is dirt cheap, extremely well designed, and with free source code.

 

 

1 hour ago, oorail said:

Its not actually a proposed system, you can download the code and run it now

IF that were the case, I may have been slightly more impressed by the idea - but the github repository apparently contains nothing but waffle and blurb.

 

 

2 hours ago, oorail said:

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).

 

You can run any number of locos independently from one controller on one layout.

 

Track power control means one loco per track section & one controller for each section. You need as many controllers as locos, and without the seamless running of DCC systems.

 

Link to post
Share on other sites

1 hour ago, Junctionmad said:

Nope the problem is every layout is a separate Wi-Fi domain and the lack of channel space means there is poor connectivity 

 

this means that Wi-Fi can’t get a clear Chanel because there’s isn’t an enterprise wide system in place rather large numbers of individual access points 

 

it has already caused significant issues at large exhibitions , it’s not an issue of enterprise Wi-Fi. 

 

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 :)

Link to post
Share on other sites

1 hour ago, WIMorrison said:

@Robin2 The way I read it is it just cab control, but digitised. This will mean that it will provide the same benefits and problems, albiet changing between blocks may be slicker. The biggest detraction is going to be that it back the the track being in control and dictating what can be done as I see it as one train per block, not like DCC where you can have as many trains as the available power (almost). Then there is the challenge of needing to sectionalise the layout to provide the individual blocks for control - that this biggest drawback that people bring forward to me when discussing automation and computer control, their views aren't going to change their views because the electricery is pure DC rather than a digital signal.

 

It would be nice to see it succeed, even Hornby are touting this sort of concept with their new Bluetooth control, but they have been talking block control for years and it has never appeared. 

 

Good luck to @oorail , though I suggest the he doesnt go to Dragon's Den for funding as he may receive a bit of grilling.

 

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. 

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...