Digital DC (DDC) - Open Source Project

[oorail]

1 hour ago, Junctionmad said:

I’m all in favour of people creating projects. 
 

what I don’t like is then creating ridiculous comparisons and running down a clearly successful method simply to self justify their own effort. it’s simply a form of confirmation bias 

 

many of us hear have 30 years or more in DC and DCC and can see what is meaningful and what is not. Equally making stupid claims about speed steps and AC -> DC waveforms just heaps nonsense on ridiculous. ( not to mention processor speed comments ) 

 

justify it on its own merits thanks, dont be a shrill 
 

 

 

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

[oorail]

1 hour ago, Junctionmad said:

 

dcc biggest advantage is its standardisation, allowing mix and match. Wi-Fi and Bluetooths biggest issue is the corresponding   lack of such standards 

 

 

 

 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.

 

[jamespetts]

This is very interesting - I particularly approve of the open source nature of this project and the choice of the GPL v. 3. There is much to be said for bringing open source to railway modelling wherever possible. Anything that improves people's freedom from the oppression of so-called intellectual property is a very worthwhile thing indeed.

 

I was not initially minded to respond to this topic, as computer controlled DC is unlikely to be useful to any of the model railway projects on which I am currently working or which I am planning (for reasons which I outline below), but in light of the positively abusive responses from a number of people, I thought that the creator of this project deserved some rational, constructive and impartial feedback.

 

Those who are overtly hostile and emotive in their feedback are clearly (by reason of that very behaviour) not attempting in good faith to give rational constructive feedback. There is no conceivable justification for any degree of overt hostility whatsoever to somebody who has done nothing other than release an open source project for comment, no matter what flaws that that project may have. There is a fundamental difference between the rational criticism of a flaw and overt hostility. The latter can only be an attempt to intimidate. It is positively reprehensible. There is something very, very wrong that the moderators have not already taken decisive action against these wrongdoers. Feedback by those who behave in that way can only sensibly be regarded as utterly worthless.

 

In any event, as to the constructive feedback itself: I notice that the Github repository appears to be missing the source code; is this an error? I had hoped to have a glance at it. Is it written in C++?

 

Judging from the video, you have been able to get what appears to be acceptable latency over an HTTP interface on what is presumably a wireless LAN, judging by the interval between pressing "enter" and the reverse command being given. Using wi-fi and standard HTTP commands, it should in principle be possible quite easily to program a huge range of interfaces to control this. Although theoretically less efficient than, say, sending 8 or 16-bit binary commands via UDP, I strongly suspect that, with reasonably modern hardware, the additional overhead of sending text commands by HTTP will be trivial.

 

The standardisation could in principle mean that anybody on the same wi-fi network could easily spoof commands; but, for home use at least, this is unlikely to be relevant given the requirement to be on the same wi-fi network. My knowledge of wi-fi protocols and hardware is not sufficient for me to comment on the question of whether the need for independent networks of this sort is likely to be a problem at exhibitions and whether, if it is, there is a possibly acceptable workaround. Your responses suggest that you have considered this, but it is not entirely clear that the issue of having to have individual networks for each group of operators (i.e. layout) has been considered. My apologies if I have misunderstood and this has been considered.

 

Moving away from the fundamentals of the computer control and to the railway modelling aspects, digitally controlled DC is an interesting idea. I am (vaguely) aware of the MERG alternative, which, as you note, uses CBUS. I am not sure that it is clear that wi-fi is obviously superior or inferior to CBUS in this application; but there is much to be said for having multiple options (one of a wired and one of a wireless system), especially since both are open source.

 

The particular advantages and disadvantages of digitally controlled DC as opposed to DCC (and two other theoretical alternatives, on which more below) are complex, as are the advantages and disadvantages compared with analogue DC control. The principal advantage over analogue control is the ability to have the computer automate tasks that would in an analogue system be tasks of the operator, and that the operator might not find enjoyable to do manually. Section switching in cab control might be one of those things. From what I have seen so far, this system does not by itself provide that functionality, but I can see that it could (reasonably) easily be added on. The more useful things (1) that can efficiently and reliably be automated; and that (2) people would rather not have to do manually (or often get wrong when done manually, such as section switching in cab control), the more useful that this will be compared to conventional analogue control. The disadvantage over conventional analogue control is likely to be the user interface, as a mobile telephone touch screen is not likely to be as good a user interface as a dial/knob for controlling the motion of model locomotives. No doubt, a physical controller could be built to work with this system; but there would then need for there to be a seamless way of it integrating with whatever automation features make this system worthwhile compared to simple analogue control, and it would also add cost (which may be more important to some users than others). One particular advantage of this system is that it allows a degree of digital automation at very low cost by re-using existing hardware and/or using inexpensive standard hardware.

 

Compared with DCC, a disadvantage is likely to be less flexibility with which locomotives can simultaneously be controlled from where, and the need for forward planning on a layout to add isolation sections wherever multiple locomotives may need to run simultaneously. Particularly difficult to plan will be movements in which one locomotive remains stationary whilst another couples to it (and the same with multiple units). This can certainly be done with accurate stopping precisely over an isolation section, but it is much more difficult than with DCC and the whole layout would have to be built from scratch with the exact stopping places already planned. This is exactly the same issue as with analogue controlled DC, of course.

 

Another disadvantage is likely to be the inability to have lights independent of movement, which is a particular advantage of DCC. Sound is another possible issue, although my own preference is against sound at the current state of development, as one cannot get a realistic overall soundscape to match the realistic overall visual scene that one can create - but that is another matter.

 

Stay-alive capacitors are another particular advantage of DCC and therefore disadvantage of a digital DC system by comparison with it; a DCC controller can be sustained with a high capacity stay-alive capacitor to allow for reliable running over very problematic track and yet retaining immediate responsiveness. Whilst a stay-alive capacitor is possible in DC, by design, it will reduce the responsiveness of the locomotive to any reduction in commanded speed, and will do this to a greater extent the greater the capacity, severely limiting the useful capacitance of such a system in a DC locomotive.

 

A particularly complex case is full computer automation. For full automation in DCC, one has to divide the track into many fully isolated sections in order for train detection to work reliably. Therefore, one loses one of the main advantages of DCC, being its ability to control multiple locomotives differentially without any track isolation at all. In such circumstances, the idea of just using DC instead is in many ways attractive, as it then removes the need to equip all the locomotives with decoders. However, there are problems with this approach. The lack of light and stay-alive functionality I have mentioned above; stay alives are especially important for automation because of the importance of reliability to automation. The lack of these features is not fatal to automation working with the DDC system, but it is a distinct disadvantage compared to DCC. A bigger issue is the lack of compatibility with major automation software, especially TrainController and iTrain. Automation with other software, such as JMRI, is possible, but because JMRI almost entirely lacks automation abstractions such as the concept of a schedule, automation in JMRI involves either an entirely procedural (and thus very fragile) script, or writing what would essentially amount to a major piece of software in a scripting language, which is not practical. TrainController and iTrain are the software packages that make complex automation possible without the user having to write most of the necessary software nearly from scratch; unless and until they become compatible with DDC, it is unlikely to be a product of choice for those seeking to have complex automation of a layout. Of course, this may change fundamentally if anyone ever adds serious automation abstractions to JMRI, and may be a different proposition for smaller layouts which need much simpler automation that can easily be accomplished in JMRI. Indeed, I suspect that people who are after relatively simple and low cost automation or partial automation are probably those who are, at this stage at least, most likely to be interested in this system, as it allows for automation without the need for DCC decoders (as does the MERG system, of course; but some might find wi-fi easier to use; it is difficult to comment on the comparison without having tried both).

 

Another possible issue with automation, although I do not know whether this is an actual issue, is back-EMF. Good DCC decoders (especially those of the Zimo brand) have a very accurate back-EMF system which allows a very predictable relationship between the speed step and the actual speed (albeit this can be broken by the effect of the motor warming up with use). This predictability can be (and is) exploited by software (TrainController is especially good at this) to produce very accurate stopping in a fully automated system using dead reckoning. If the DDC system cannot do this, then it is less advantageous for automation compared with DCC. If the DDC system can not only do this, but somehow overcome the motor heating system, then it is somewhat more promising for automation.

 

The automation issue, the stay alive issue and the lighting issue are together (but mainly the first) the reasons that the DDC system is not likely to be suitable for my own needs.

 

I mentioned above two other theoretically possible systems. One is one in which the locomotive itself has a wireless decoder of some sort and takes power from the track (either DC or DCC; it matters not which and one can be rectified to the other). The other is one in which the locomotive has a wireless decoder and takes power from an onboard battery. In either case, the signal is sent, not along the track, but wirelessly.

 

The latter of the two systems, probably the most ideal if well implemented, already exists. There was a stand at Warley 2019 demonstrating this. It has been in existence in one form or another for some years, although, owing to the current state of battery technology, is still relatively primitive. The batteries in this system charge either through the track (DC or DCC) or with under-track wireless charging.

 

The former of the two systems I am not aware of existing independently, although in a sense the track based charging of the battery system is similar to this. However, two things can be noted about the wireless controller, power from track system: the first is that it does not rely on nascent battery technology; and the second is that it can very easily be converted into a track charging battery system when the battery technology improves without changing the standards.

 

The reason that I mention all of these things is that I notice that it is proposed to have onboard wi-fi controllers (optionally) to provide feedback. If versions of these controllers could be made that (1) controlled the motors, lights, etc., and acted so far as the locomotive were concerned as DCC controllers (preferably fitting into existing DCC sockets), but; (2) took instructions over wi-fi rather than through DCC, then you would have a potentially revolutionary system. I imagine that it could readily use the same protocols as DDC (and thus be fully compatible with it), and could also in principle be controlled by a device which accepts something like a LocoNet input so that TrainController and iTrain would recognise it and be able to interact with it (indeed, if you could get a LocoNet bridge working and allow your DDC system to pretend to be a DCC command station, you could overcome the compatibility issues with iTrain and TrainController with DDC, too).

 

Thus, if you were able to design and deploy a set of protocols and hardware that would bridge compatibility between DCC, DC, rail powered wi-fi and dead rail, all with open source standards, as well as being backwards compatible with existing software, the potential would be enormous. I imagine that it would be a large and uncertain undertaking, especially the hardware decoders perhaps, but with a large prize to all modellers if it could be achieved. Even if you wanted to achieve this, the current DDC system I can see would be the sensible place to start. Whilst the possible advantages of this system are complicated, it would be lovely to see its development continue.

 

Very best wishes with this very interesting project. The more open source projects that there are in the sphere of railway modelling (and generally) the better (whether flawed or not).

[Andy Reichert]

Since I designed and built electronic DC throttles with PWM to the track back in the early 70's I guess I have some relevant experience. A few points I found might be worth considering before setting any updated version in stone.

 

1. A pure PWM at 12 v connected to track makes good wide band radio station.  It's also very easily detected by the authorities. Slugging the rise time helps cut down the radiation, but it cuts down the slow speed performance dependability as well.

 

2.  Even though a PWM driver is much more likely to make sure a poor mechanism doesn't stall, it's far from 100% reliable.  So I switched very rapidly from open loop to closed loop control to get much nearer to 100% response to the speed control setting . But even then I was using manual control, so could always intervene if a loco didn't do what was asked. To expect computer control to be reliable with open loop, one should anticipate a great deal of disappointment.

 

3. I'm currently building a 2 rail wired "Grand Union". Given that the prototype would be able to handle several street cars queued nose to tail at each of the four entrances and then allow them to follow each other through when each clear signalled non-conflicting route becomes available, I  immediately  discounted the use of block sections control.

 

Andy

[Robin2]

10 hours ago, jamespetts said:

but in light of the positively abusive responses

Mud has been thrown in both directions - all of it pointless.

 

...R

[RobjUK]

On 11/02/2020 at 00:19, oorail said:

 

I'm guessing from your tone the existence of this has sort of upset you. No worries, you don't have to use it!

 

 

Not in the slightest - but I have a deep dislike of people trying to use buzzwords and empty claims to sell things or extract money from non-technical people.

 

Your "advertising approach" is such broad claims ,with no technical info about _how_ it supposedly does everything you claim - and a load of factually wrong or misleading comparisons.

 

 

I apologise for the github comment, there is a single program code file; the description made it appear at first sight to be another text document.

 

However looking through that, the track control is nothing but open-loop PWM; no current sensing, no back EMF sensing.

It still does not back up your claims of superior control.

 

 

If the device code you show in the video is supposed to be internal to the system, what is the point of the monstrously complex "API" - you only actually need to set and retrieve a very few parameters from each power controller channel and the entire set could always be in a single tiny data block, just a few bytes each each way, with just one form of interaction.

 

Having the massive "API" with many different functions passing a single parameter each seems incredibly wasteful, when a single call could pass an entire structure each way all in one go. That would also need a lot less WiFi channel occupancy.

 

 

On 11/02/2020 at 00:19, oorail said:

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?

 

The difference is trying to measure motor feedback at the motor, or remotely through an variable connection.

 

And you cannot properly measure motor current or back emf for precise control if there is another load (such as lighting) across the motor - it's the lighting (in your concept) that would affect motor control, not the other way around. 

 

 

On 11/02/2020 at 00:19, oorail said:

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. 

 

The ESP32  is only available with 2.4GHz WiFi as far as I can find, so other bands are irrelevant.

 

And, you have just proved your total ignorance of WiFi operation - the channel numbers are a leftover from earlier systems and a single actual WiFi transmission requires the bandwidth of multiple numbered channels - either four or eight.

 

With proper planning a maximum of three systems can coexist, using 20MHz bandwidth. If anything uses 40MHz, it effectively takes over the entire band

This is an example of channel usage - but remember you only have 1-11 in the USA, not 1-13 as in Europe..

https://i.stack.imgur.com/CG9d8.png

 

  

On 11/02/2020 at 00:19, oorail said:

Dozens? Hundreds? So far you've provided two? 

 

Which is enough to prove that source code examples for various DCC implementations exist & it's not a totally "closed source" system as you claim - I've got better things to do than trawl google.

 

And any decent programmer can knock up a DCC decoder program in a few hours; that's the point of the open standards and publishing all the signal waveforms and timing requirements, so anyone can create compatible equipment for themselves.

 

I've written two decoder routines on two very different devices, just for the fun of it - one on an 8 pin PIC and another on a DSP chip. I've not used them for anything so far & I may never do, it's purely technical interest and to see how efficient I can make the code.

 

 

On 11/02/2020 at 00:19, oorail said:

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. 

 

But still only one loco per block, so you cannot have locos continuously in close proximity, or simply connect a controller to a layout and run as many things on it as you wish.

 

 

Overall, if you have some original and technologically good ideas for power/speed control to locos, good for you - go with it.

 

 

But so far, the actual "power control" system that feeds the track is nothing more than open-loop PWM that can be done any number of ways with off the shelf parts - there is no precise speed control or load sensing, and trying to do such things from a track power controller can never possibly give as good a result as having the speed controller at the motor. 

 

The signalling method is a totally separate issue, and irrelevant if the motor cannot be properly made to respond as commanded.

 

 

I get the impression you have never actually examined the full details of how a DCC decoder (or any closed-loop motor controller?) works and interacts with the motor, or you would not have made the invalid claims of superiority of your system.

 

 

[Designing, programming, manufacturing and repairing industrial control systems ranging from radio links and embedded controllers through to heavy industrial drives, robotics and machine tool power and control systems, for many years. Plus electronics, programming & radio design (licenced ham operator since 1979) as hobby interests].

 

[jamespetts]

1 hour ago, Robin2 said:

Mud has been thrown in both directions - all of it pointless.

 

...R

That is not an excuse for abusive behaviour. It is clear beyond any doubt that the abuse was initiated by those seeking to criticise the proposed system, and the validity of the criticism of the abusive behaviour is entirely independent of the validity of any of the substantive criticims made by the abusers.

[Robin2]

13 minutes ago, jamespetts said:

 It is clear beyond any doubt that the abuse was initiated by those seeking to criticise the proposed system,

Perhaps you would be good enough to post links to some examples. I can see that there are different points of view, but I can't say I have seen any abusive comments. Much of the discussion has degenerated into the "it's a biscuit, no, don't be silly, it's a bar" category.

 

If there really are abusive comments the correct thing is to report them to the Moderator.

 

...R

Edited February 12, 2020 by Robin2

[jamespetts]

1 hour ago, Robin2 said:

Perhaps you would be good enough to post links to some examples. I can see that there are different points of view, but I can't say I have seen any abusive comments. Much of the discussion has degenerated into the "it's a biscuit, no, don't be silly, it's a bar" category.

 

If there really are abusive comments the correct thing is to report them to the Moderator.

 

...R

 

The following are examples of abusive emotive replies and/or inappropriately personal comments from this thread:

 

 

you clearly have zero idea about the uses for a bi directional layout control bus 

 

And using WiFi is, to be blunt, idiotic.

 

he github repository apparently contains nothing but waffle and blurb.

 

what you says is largely nonsense for 2.4ghz solutions 

 

its you , with nonsense 128 versus 1024 speed steps stuff that should be afraid , afraid of speaking nonsense

 

Your knowledge of signalling and absolute block is very limited.

 

I’m all in favour of people creating projects. 
 

what I don’t like is then creating ridiculous comparisons and running down a clearly successful method simply to self justify their own effort. it’s simply a form of confirmation bias

 

but don’t be blinded as to what you are developing , it’s merely a peculiar form of DC largely to satisfy your own technical interests.

 

 

[Robin2]

Could perhaps be classified as "a robust exchange of views"

 

I agree that most of it is pointless (on both sides), and perhaps not as polite as it might be, but I wouldn't classify it as abuse.

 

...R

Edited February 12, 2020 by Robin2

[jamespetts]

3 minutes ago, Robin2 said:

Could perhaps be classified as "a robust exchange of views"

 

I agree that most of it is pointless (on both sides), and perhaps not as polite as it might be, but I wouldn't classify it as abuse.

 

...R

 

No, it is definitely abusive. There is no conceivable justification for such reprehensible behaviour.

[Robin2]

6 hours ago, jamespetts said:

 

No, it is definitely abusive. There is no conceivable justification for such reprehensible behaviour.

I don't agree, but if that is your opinion you should report the abuse to the Moderator.

 

I note that the OP has not complained about anything that has been directed at him.

 

Maybe another way of looking at is if it's not appropriate for a report to the Moderator then it isn't abuse. Abuse is a serious term that should not be used lightly.

 

...R

Edited February 12, 2020 by Robin2

[Junctionmad]

I must offer my reply here  ( given the OP has equally attacked me " the what are you  frightened of comments ")

 

what annoyed me about this thread , is not the OPs project.  Its his attack on DCC using quite frankly spurious technical comments that makes the comparisons technically ridiculous and I note that he has avoid replying in any detail to those specific issues 

 

for example one of my comments was mentioned  in relation to my comment about 128 versus 1024 speed steps 

 

Any engineer worth his or her salt making this comparison will know that any model railway motor simply cant " resolve "such tiny voltagesteps into any appreciable control benefit , in fact it can hardly resolve 28 speed steps 

 

Hence my robust technical retort 

 

"Your knowledge of signalling and absolute block is very limited. "

 

was based entirely on the OPs rather ridiculous comments about absolute block , AND , I went on to provide concrete examples of multiple locos/trains in a block 

 

as for my comment 

 

"what you says is largely nonsense for 2.4ghz solutions  "

 

I am being factually correct , here , what the OP claimed is quite frankly compete nonsense in 2.4Ghz , which is the spectrum where the ESP32 operates ( and I have developed solutions for the ESP32 and I know how it works ) 

 

I have 30 years of work in Wifi and embedded systems and I dislike when someone dismisses comments by using buzzwords, " technical hand waving " and references to enterprise solutions that have no applicability 

 

 

 

As I said , in all honestly , I have no problem with the OP coming here are outlining his particular model railway control solution and as I said , I wish him well in his endeavours . I and well aware that many creators of solutions tend to get over committed to the brilliance of their creation , and see everything else as inferior.  However either "DDC" stands on its own two feet or it doesn't .  Simply lambasting DCC, on very spurious technical grounds ( the  classic one is the AC->DC->AC criticism ) simply opens you to ridicule , which he has received from several knowledgeable contributors 

 

 

Edited February 13, 2020 by Junctionmad

[DaveArkley]

22 minutes ago, Junctionmad said:

I must offer my reply here  ( given the OP has equally attacked me " the what are you  frightened of comments ")

 

 

I must offer my 2 pence. 

 

This has become an endless cycle of 'justification' for some appalling posting by both parties. Such personal attacks are boring and pointless. I'm blocking this thread and I've reported it to the mods as it no longer has any relevance to model railways.

 

Dave