# Two-way communications?



## Shdwdrgn (Dec 23, 2014)

I'm treating myself to a crash course on DCC this week, and after reading through the basic info thread, plus a lot of good info on the DCC++ wiki, I'm still left with some gaps in knowledge that probably don't fit under the beginner threads...

I have been playing with using an esp8266 (similar to arduino but with wifi) to control my trains, and I can see a significant advantage to reworking my ideas to jumpstart off of the standard DCC implementations. I've even found some projects where the DCC commands are additionally sent over wifi. However I have a couple of initial questions that I'm not sure if the DCC protocol allows for?

Keep in mind here that because of the processing power available in the esp8266, I plan on making my locos 'smart' -- basically able to read track occupancy signals, set turnouts, and navigate their own path to their destinations...

1) Can devices other than the base station send commands out? Obviously a loco won't have the power source to affect the track voltage, but with the addition of wifi signaling, this perhaps becomes an option. So could a loco send out a standard DCC command over wifi? Or maybe I'm looking at this wrong, and the base station would actually pick up those wifi signals from all sources and still be the only source of signals being sent over the tracks?

2) What about reading current states? I've seen a lot of commands for changing the state of things, but nothing about how to read them. Could I, for instance, have a controller that sets a variable (I guess this would be a CV?) indicating that a block is occupied, and then have my loco somehow request the status of that block as it approaches?

Of course I'm not above modifying the code on either the base or decoder to suit my own needs, but first I want to know if any forms of DCC already implement features like this. I'd rather try to work within the existing structure to maintain compatibility, I just need to be able to handle simple two-way communications so each loco can detect and control information about the path in front of it.


----------



## fcwilt (Sep 27, 2013)

Hi,

RailCom (by Lenz) is the basis (as I understand it) for the NMRA proposed version.

http://www.dcc4pc.co.uk/railcom_uses.html

Due to the work involved in fitting RailCom compatible decoders to all of my locos I have not really paid any attention to the technology and have no idea what is is capable of.


I don't know of any DCC implementation that allows multiple command stations however different manufactures have implemented additional control/sensing networks, like LocoNet.

These networks DO allow for multiple sources of commands and can be used to control the command station causing it in turn to control trains.

A loco fitted with a "decoder" that supported WiFi could send commands over a LocoNet type network.

Frederick


----------



## Shdwdrgn (Dec 23, 2014)

Thanks, gives me more to read up on. And for what it's worth, I'm not really expecting any of the standard DCC command stations or decoders to work with all of this, my setup will be 100% arduino-controlled, however there is always the possibility of new locos being placed on the track and manually controlled. They wouldn't need to recognize all the fancy commands, but they also should not be confused by them.

Oh that reminds me of one other issue I was thinking of... Does DCC have some means for a loco or other decoder to acknowledge that it received a command? I would assume not since most devices couldn't modify the track voltage to send their info back to the command station.


----------



## fcwilt (Sep 27, 2013)

Hi,

To the best of my knowledge only decoders supporting RailCom can support two way communication but if that includes acknowledging commands - I don't know.

I imagine that is all in the RailCom specs somewhere.

Frederick


----------



## Shdwdrgn (Dec 23, 2014)

Just took a peek on their site... interesting technique, but I think it will be much easier to implement through wifi. I just have to modify the command station code to accept incoming wifi messages and push them out through the track.

My initial thoughts are to have the locomotives accept commands only through wifi (reducing the amount of signals that have to go through the tracks, and making them more reliable since dirty track is a high probability for my location), then I would have things like turnouts and animated structures get their power and commands from the track bus. Basically anything that is fixed in place and read-only would be attached to the track bus, and everything else would use wifi. Does that make sense? And does it sound like it would work reasonably in an extended DCC environment?


----------



## fcwilt (Sep 27, 2013)

Hi,

Given the electrical noise that can occur on the track (wheels, motors, etc) I don't suggest using the track as a "bus" for control/sensing needs.

On my layout I have a dedicated LocoNet compatible bus created using RR-CirKits Simple Serial Bus products.

These devices handle occupancy sensing, turnout control, signal control, etc.

Frederick


----------



## fcwilt (Sep 27, 2013)

Hi,

Something crossed my mind.

Depending on the distances you would like to cover Bluetooth might be a better option than WiFi.

Frederick


----------



## Shdwdrgn (Dec 23, 2014)

What I meant by the 'track bus' is that the DCC signal would already be present on the feeders going to the track -- and I could run more feeders to any items that weren't directly beside a track. The noise from the loco wheels was exactly why I *don't* want to try controlling the locos directly from the track (plus the need for fast 2-way communications).

As for bluetooth... I had originally planed on going that route, but then I decided to use web pages to build controllers for the locos so that I could just load up the page from a tablet or cell phone. This makes Wifi a better choice, and once I discovered the esp8266 chips the matter was settled for me.


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> I'm still left with some gaps in knowledge that probably don't fit under the beginner threads...





Shdwdrgn said:


> 1) Can devices other than the base station send commands out?


The DCC signal is communicated by switching the polarity of the track voltage. This makes the signal very tolerant of any motor or other noise. Because the DCC signal controls the track voltage, there can only be only be one source of commands. And because commands are infrequent, not much bandwidth is needed -- the available bandwidth can support many locomotives.

The command station repeatedly sends address and command to each active loco. If a decoder misses one, it will get the next one.












Shdwdrgn said:


> So could a loco send out a standard DCC command over wifi? Or maybe I'm looking at this wrong, and the base station would actually pick up those wifi signals from all sources and still be the only source of signals being sent over the tracks?


in DCC, there's no need for a loco to send information back to a command station during normal operation.

However, I believe all multi user commands stations communicate with handheld controllers using an approach similar to HDLC where one master communicates with multiple slaves by sending a slave address with information or polling for information from the slave. RS-485 is a common 2-wire bus that allows multiple endpoint to share the bus.

Of course a base station could communicate with other types of devices with other methods (e.g .wifi, bluetooth, ethernet). I believe DCC++ supports ethernet between the command station and a controller (handheld).

In order to save wire and minimize the spaghetti under large layouts, approaches like C/MRI are used to allow PCs to control signals and turnouts and read block occupancy and turnout positions by communicating with nodes that support 8/16/24 inputs/outputs in an area of the layout. A common approach for communication is again RS-485. But other methods could be used, perhaps ones that further minimize wire.




Shdwdrgn said:


> 2) What about reading current states? I've seen a lot of commands for changing the state of things, but nothing about how to read them. Could I, for instance, have a controller that sets a variable (I guess this would be a CV?) indicating that a block is occupied, and then have my loco somehow request the status of that block as it approaches?


not sure how standard this is, but decoders can send information by altering the current drawn by applying voltage across the motor. The station programming the loco can sense the current and read this information. Programming CVs and reading them back is only done on a programming track with one locomotive at a time.

CV values programmed into the decoder are static and don't need to change (see Configuration Variable). They are stored in non-volatile memory, persistent across power cycles.




Shdwdrgn said:


> Could I, for instance, have a controller that sets a variable (I guess this would be a CV?) indicating that a block is occupied, and then have my loco somehow request the status of that block as it approaches?
> 
> ... I just need to be able to handle simple two-way communications so each loco can detect and control information about the path in front of it.


not sure what a loco would do with occupancy information. are you suggesting that it would know what block it occupies and convey this back to the command station? How precisely would it know it's position in the block, if the entire train has entered the block?

Dispatchers today can control turnouts and signal. They can determine if a train is occupying one or more blocks. A dispatcher would know if a train needs to stop in a block and is clear of another in order to allow another train to pass. A train engineer would know to stop by watching the signals. In may ways, a person running a train on a fully signaled layout is not much better that a DCC decoder following commands conveyed by the signals. 

It's very different if your switching cars, need to throw switches, pick up and drop off cars in precise locations


----------



## wvgca (Jan 21, 2013)

gregc said:


> not sure how standard this is, but decoders can send information by altering the current drawn by applying voltage across the motor. The station programming the loco can sense the current and read this information. Programming CVs and reading them back is only done on a programming track with one locomotive at a time.


Yes, DCC [at this point anyways] is one way communication, to do a CV read the command station basically sends an interrogation packet such as "Is the value of CV1 equal to '1'?", If the decoder recognizes the question, and if the value of the CV equals the question value, then the decoder draws a 60ma current pulse .. if not the decoder does nothing ..
If the command set doesn't see the current draw, it tries the next value, ie: "Is the value of CV1 equal to '2'?", until it receives a response indicating yes, or times out ..
I read this in some NMRA document, but don't remember which one..


----------



## Shdwdrgn (Dec 23, 2014)

gregc said:


> not sure what a loco would do with occupancy information. are you suggesting that it would know what block it occupies and convey this back to the command station? How precisely would it know it's position in the block, if the entire train has entered the block?


Most of what you say makes sense and corresponds to what I've already picked up about DCC, but I thought I'd touch on this particular part. The ESP8266 computer chips on my locos will be handling all the logic of operations... yes I can take over manual control of a loco, but when I release that control I want them to go back to their assigned tasks. Each loco will have its own set of routes to follow, and to run automatically they MUST be aware of not only what block they are currently in, but also whether other blocks are occupied. The hardest part here is having each loco plan ahead so they don't end up in a deadlock with two locos facing each other in adjacent blocks, each waiting for the other block to clear.

As you and wvgca have said here, there's obviously no method available in standard DCC to let a loco or other decoders query for complex information, let alone allowing for a large amount of information to be requested from multiple locos at the same time. This is why I think leaving the simple stuff -- like throwing turnouts or operating other simple actions on the layout -- will be fine receiving their data over the rails, but the locomotives themselves need the much larger 2-way bandwidth available from wifi.


----------



## gregc (Apr 25, 2015)

Shdwdrgn said:


> Each loco will have its own set of routes to follow, and to run automatically they MUST be aware of not only what block they are currently in, but also whether other blocks are occupied.


A fully automated and adaptive system would need:
- a description of the routes and times to run trains
- a mechanism to establish a route thru control of turnouts, ahead of a train, cognizant of other train locations
- a mechanism to determine train (engine/caboose) location
- a mechanism to determine when trains are in conflict and a train must be delayed from crossing a particular point based on the location of other trains.
- a mechanism to signal/control train speed or to stop


----------



## DonR (Oct 18, 2012)

There is a video of a fully computer controlled multi
train layout here on the Forum if we can find it.
Thru detectors the system was able to slow and
stop trains to avoid collisions at turnouts and
crossings.

Here is a small switching layout that is demonstrating
computer control of a switch engine.






Don


----------



## RT_Coker (Dec 6, 2012)

Or an “inexpensive” automated model train system could require just:

Locomotives with:
a)	Bluetooth for reliable and low-cost wireless-two-way-communication (as in existing small Bluetooth-robotic-boards).
b)	Tachometer-sensor for precision scale-distance-control.
c)	Precision-known-location-detection (as in a magnetic-relay).
d)	Locomotive firmware (as in open-source for a low-cost option). 

Layout with:
a)	Bluetooth-track-section-control(s) for low-cost control of locomotive-access to individual track-section(s) and their turnouts (as in existing small Bluetooth-robotic-boards).
b)	Precision-known-locations (as in small magnets under the track).
c)	Track-section-control firmware (as in open-source for a low-cost option).

Bluetooth-control-unit (as in ~$100 10’ tablet).
a)	Control application software (as in open-source for a low-cost option).

Bob


----------



## Shdwdrgn (Dec 23, 2014)

@gregc -- Sounds about right. Additionally, when two trains might be in conflict, there needs to be a priority. For example, any switching operations that happen to cross the mainline need to get out of the way before the express train comes roaring through.

Routing will be somewhat fluid, but dependent on specific circumstances. One freight train may head to town A when there are cars waiting at two different spurs, but another train may go in when only a third stop has empties to pick up. A switcher will have a short path, so any time cars get dropped off, it will head over and move them to their docks, but perhaps only bring a string out for the freight train once it has collected at least three cars.

Locations are one of the most important pieces of data to make all this work. I have some pretty small programmable RFID stickers to get accurate positions of all cars passing a few key points. I think I may use a combination of IR LEDs and hall-effect sensors (magnetics) through the rest of the track, and probably keep fairly small block sizes of only a couple feet. The main computer would keep track of how many items go into a block, then clear it when that many items leave the block. I think someone else was working on a similar concept last year and was having great success with it.

Additionally, I want to use lighted signals at each turnout to also talk to the locomotive. You can send short-range signals through regular LEDs, or possibly just embed more IR LEDs right under the track. Using a technique called differential Manchester encoding, you can send a continuous stream of information, and the receiver will automatically sync with the start of the transmission.

With enough information, each loco should know if it should stop, proceed slowly, or has a clear path ahead. It could set any turnouts within each unoccupied block for the desired path, and potentially even be given information about alternate paths (such as moving over to a passing track to make way for a higher-priority train).

Now the trickiest part of all is going to be the operations which require disconnecting or hooking up to cars. One possible idea here is building miniature strain gauges to go in the couplers of each loco, so it can tell when it runs in to something or successfully disconnects a string of cars. Add this in with some sensors around each magnetic uncoupler, and there's a good chance I can create some successful operations.

Writing the code is easy, there's really nothing more than a large collection of logic functions to handle each particular task. And if a task can't be completed reliably, it probably means adding more (or better) sensors to tell the computer what is happening. However the point of this thread is to consider using existing DCC protocols (even if I have to add some of my own codes for the two-way communications), rather than writing my entire code base from scratch. And if I can build on an existing protocol, it may be useful to others in the community.


----------



## Shdwdrgn (Dec 23, 2014)

@DonR -- very cool. And I always see someone at the shows demonstrating a system that may be similar. It does give me another idea though -- IR LEDs can also be used for rudimentary distance sensors, which I wanted to incorporate in each loco for last-chance collision avoidance... However, I could also use this at the end of each spur to let the switcher know how close it is to the end of the line when backing up with some cars to drop.

@RT_Coker -- yeah I still follow your progress, but it seems like you wrote a whole new system, and I'd rather make the attempt to work from existing systems. Bluetooth has its uses, but I'll stick with wifi for this.


----------



## RT_Coker (Dec 6, 2012)

Shdwdrgn said:


> @RT_Coker -- yeah I still follow your progress, but it seems like you wrote a whole new system, and I'd rather make the attempt to work from existing systems. Bluetooth has its uses, but I'll stick with wifi for this.


More like a whole new way of thinking (a system-engineering approach). The new hardware is basically just tachometers and Bluetooth. 
Bob


----------



## gregc (Apr 25, 2015)

RT_Coker said:


> Or an “inexpensive” automated model train system could require just:


don't understand why technology is listed as a requirement. Shouldn't the technology fulfill the requirements.


----------



## fcwilt (Sep 27, 2013)

Shdwdrgn said:


> However the point of this thread is to consider using existing DCC protocols (even if I have to add some of my own codes for the two-way communications), rather than writing my entire code base from scratch. And if I can build on an existing protocol, it may be useful to others in the community.


Hi,

A couple of thoughts.

A centralized control system like TrainController is perhaps more akin to the way the prototype works.

The idea of each train being autonomous seems odd to me.


As to sticking with the DCC protocol. That protocol was designed with the limited bandwidth of the DCC hardware.

And as capabilities were added the protocol was expanded in strange ways.

With WiFi as your primary means of communication I would strongly suggest an new, clean, optimized protocol.


Frederick


----------



## RT_Coker (Dec 6, 2012)

gregc said:


> don't understand why technology is listed as a requirement. Shouldn't the technology fulfill the requirements.


My “could require just” is not a list of “requirements”.
It is a list of items that could do the job of “inexpensive automated model train system".
Bob


----------



## Shdwdrgn (Dec 23, 2014)

@fcwilt -- The DCC protocol is well-established, and ives me the option of using some off-the-shelf components so I don't have to build the *whole* system from scratch. I'm just thinking of it more as a framework to start from, and looking into it as a possibility. I already have a working system that runs from a simple server (akin to the controller in DCC) and uses wif for full 2-way communications. Basically in my system, a web page acts as the controller for each loco... the web page says I want this loco to go to this speed. The loco, in turn, ramps the speed up or down at a progressive rate so there's no sudden starts or stops, and continually sends back messages saying I'm now running at this speed, so the web page can accurately show your target speed and the actual speed of the loco. That all works great, and even if I decide to not use DCC in my project, at the very least the study of DCC is giving me some new ideas and helps me think about situations that I haven't considered yet.

The idea of locos being autonomous... I knew coming in that this is not a popular idea with most people. Folks want hands-on, they want to RUN their trains, not simply watch them. I'm a bit odd in that manner, but my goals aren't as different as they appear. The code I write for the computers is my way of running things, only I can run a whole lot of trains at once. I am excited by the prospect of having a lot of action happen on a large layout, and the various routes and goals of each train create a complex set of possible interactions. As a comparison, I write server code for a project that works on multiple servers world-wide. Some tasks are performsed by the users, entering their particular data, but most tasks happen automatically, responding to changes as servers go offline and new servers are created. The entire complex narrative is like a dance to me and I monitor it every day to see what might happen next. This isn't my job, this is just a side project I do for fun... Building a computerized train layout may be on a smaller physical scale, but it opens up a lot of new possibilities and much more complex programming requirements to make the flow of the trains smooth and uninterrupted, make them seem like they have human operators and not just a lot of logical code.


----------



## JerryH (Nov 18, 2012)

DonR said:


> There is a video of a fully computer controlled multi
> train layout here on the Forum if we can find it.
> Thru detectors the system was able to slow and
> stop trains to avoid collisions at turnouts and
> ...


Are you thinking of this one? See posts 302, 313, 413,& 420

http://www.modeltrainforum.com/showthread.php?t=14852


----------



## fcwilt (Sep 27, 2013)

Shdwdrgn said:


> The idea of locos being autonomous...


I wasn't clear. I'm a fan of automation.

My layout is automated using TrainController.

Centralized control like that is akin to the real world.

It is just the idea of distributing the "intelligence" to individual trains that seems unusual.

A challenging project to be sure but it would seem to be adding complexity (the need for the trains to communicate with one another to co-ordinate activity) with little benefit over a centralized control system.

Looking forward to hearing how the project is progressing.

Frederick


----------



## RT_Coker (Dec 6, 2012)

fcwilt said:


> The idea of each train being autonomous seems odd to me.


The trains should have autonomous capability in the same way that real trains (with operators) run independently until they need to coordinate their activity (by requesting/receiving and latter relinquishing control of a track-section(s). The “autonomous” train can also be run manually from the controller.

Also:
When trains can except/store/execute easily understood commands, they can be fun to “program”. The examples are in the robotic kits that are use by school kids in school robotic competitions. My main “requirement” is for the system to be capable of attracting new and younger users into the hobby.
Bob

Bob


----------



## gregc (Apr 25, 2015)

RT_Coker said:


> When trains can except/store/execute easily understood commands, they can be fun to “program”. The examples are in the robotic kits that are use by school kids in school robotic competitions.


to "program" can be done at different levels:

commands can be "programmed" at a primitive level, such as move forward at some speed or for some distance (or some point), stop, throw a turnout, move backwards some distance/point, de/couple car, move forward ...

or they can be at a higher level, such as drop car C off on track T at industry I, ... In this case, the intelligence can be in the locomotive and it determines what primitive commands to execute

or you can "program" at yet higher levels, such as here's a switch list of cars to drop off/pickup and existing car location. execute it


the levels of processing power available suggest the last is possible, would be more challenging to develop and I think more useful.

Each level can be developed independently on top of an earlier level but may require different amounts of layout HW to support it (e.g position detection).

Processing in a loco can collaborate (2-way comm) with a central unit that knows the positions of all cars, industries, routes and turnouts.

i think having a strategy for developing in stages would be key.

there was a Smithsonian magazine article (1990s?) describing the research at the MIT artificial intelligence lab that described this approach. Non-monolithic intelligence. I believe it supported the robotic missions to Mars.


----------



## DonR (Oct 18, 2012)

JerryH said:


> Are you thinking of this one? See posts 302, 313, 413,& 420
> 
> http://www.modeltrainforum.com/showthread.php?t=14852


You nailed it Jerry.

That is the thread I remembered. Locos,
turnouts et al fully computer controlled with
the ability to avoid collisions.

It seemed to me that this is what the OP
had in mind.

Don


----------



## fcwilt (Sep 27, 2013)

RT_Coker said:


> The trains should have autonomous capability in the same way that real trains (with operators) run independently until they need to coordinate their activity (by requesting/receiving and latter relinquishing control of a track-section(s). The “autonomous” train can also be run manually from the controller.


Understood - for me it's simply a question of the extra effort to create a distributed system for a model railroad as opposed to a centralized system.

The end result of either approach will likely be quite similar.

As I said it's a fun and interesting project but I, so far, do not see the practical benefit of a distributed system.

I will follow this project with great interest just the same.

Frederick


----------



## Shdwdrgn (Dec 23, 2014)

Actually I was thinking of autonomy in the sense of my time period, around 1900... Each train had a schedule to follow, but it was up to the engineer to follow the track signals and generally avoid collisions. The crew was likely also responsible for manually throwing each turnout as well, at least in remote areas. Plus they would have to make stops along the way for coal and water.

In my grand scheme, there will be a central computer that handles all the data collection and keeps track of what tasks (schedules) need to be performed by each train. It would probably make more sense to have the main computer send out the tasks one at a time to each loco... when the loco finishes that task it asks for whatever is next... but once the loco has a new destination it handles all of the steps required to make it to that destination, including the steps at the end of the line which may include refueling or dropping off/picking up some cars.

I've seen samples of some of the sheets used to create a schedule for a mainline or yard loco. I'm thinking it is a good format to generate my own schedules, then let the locos interpret that data and act accordingly, and it would be something that others are already familiar with. Plus having the information in tables like that makes it easy to change the schedule or make up something new on the fly.

As for practicality... Stamp-sized computers are dirt cheap these days. The chips I'm using right now cost about $2 each and have a lot of processing power in them. Yes you can have one big computer managing all of the action on the layout, but what if the data gets out of sync? By having each loco take care of itself, it can respond to the information it sees at that moment, most importantly collision avoidance. And there is likely to be a lot of that happening while the code is being developed! The tasks I'm giving each loco should be fairly simple, following a map of block numbers and turnout directions to reach a given destination. Also there are techniques these days to flash new code to the chips over wifi, so updates can occur automatically.


----------



## fcwilt (Sep 27, 2013)

It should be an interesting project to follow.

Please keep us up-to-date.

Frederick


----------



## Shdwdrgn (Dec 23, 2014)

Oh I certainly will. Unfortunately this is expected to be a long-term project, and I don't even have the framework of a layout yet. I set up the 4x4 test track with three spurs in order to get started on sensors and coding, where I can test having two locos taking turns around the loop or moving across spurs when the other train is on the other side of the loop. And more importantly, being able to test techniques for computer-controlled uncoupling. I should be able to develop about 75% of my code on this test oval.

The problem, as always, is time. I'm in the middle of building an HOn3 2-8-0 from a kit, still working out kinks in my layout plans (I actually redesigned the base frame yesterday), and taking care of my internet servers. Just so many things to juggle, but once I get the motorcycle rebuild finished then I can focus heavily on getting the winch and framework built up in the garage. Of course then I'll have about 60 turnouts to build... IT NEVER ENDS!!!


----------



## Cycleops (Dec 6, 2014)

I think you have a ways to go but it'll be interesting to see it when up and running.


----------

