# Transponding and Detection zones



## NedsTJ (Apr 4, 2008)

After 3-4 months of digging, hauling, cutting, ripping up, redoing (snipped)... 
I was actually running trains for over an hour last night...(after spending 15 minutes trying to remember that I used the LAST two digits of the engines number as its address...) 

Anyway, I'm getting ready to wire the system with a Digitrax BLD168. Going to make use of the transponding for train control via a laptop (there's another post around here somewhere that I'll be resurecting soon I hope!). But a simple question that I can't easily find the answer to. Each BDL168 Zone has 4 detection sections. When using the transponding, does the BDL168 report to Loconet the section that the Engine is in within that zone, or just that the section is ocupied and that the Engine is in that zone? In other words, will it report that Engine 32 is in Zone A - Section 3, or will it report that Engine 32 is in Zone A and that section 3 is simply occupied? 

Granted, the above might only make sense to a few ppl on the board, but those are the ones I want to reach! (hopefully before I start wiring. )


----------



## craigcoffman (Jan 2, 2008)

This is definitely a question for Bob Grosh. If he dosn't chime in soon, send him some email. 

-- 
craig


----------



## SteveC (Jan 2, 2008)

Here's a link back to a topic in the arvhived MLS forums, that might be of interest until Bob cruises by. Scroll down to the 6th reply from the top, then locate the _DCC does provide a much better way of creating an automated railroad._ section.

Archived - DCC in Large Scale Forum/Topic: Garden Railways DCC article

You may also find this little article put together by Bob interesting.

Animation System


----------



## bobgrosh (Jan 2, 2008)

There is little information about transponding in the garden. I decided to provide enough info to get you statred and explain the diffference between Transponding and detection. 

Spent all day doing it 
Then MLS ate my post. 

When we get an editor, I'll try again.


----------



## bobgrosh (Jan 2, 2008)

Hi Ned 
Posted By NedsTJ on 09/09/2008 6:00 PM

After 3-4 months of digging, hauling, cutting, ripping up, redoing (snipped)... I was actually running trains for over an hour last night...(after spending 15 minutes *trying to remember that I used the LAST two digits of the engines number as its address*...) Anyway, I'm getting ready to wire the system with a Digitrax BLD168. Going to make use of the transponding for train control via a laptop (there's another post around here somewhere that I'll be resurecting soon I hope!). But a simple question that I can't easily find the answer to. Each BDL168 Zone has 4 detection sections. When using the transponding, *does the BDL168 report to Loconet the section that the Engine is in within that zone, or just that the section is ocupied and that the Engine is in that zone?* In other words, will it report that Engine 32 is in Zone A - Section 3, or will it report that Engine 32 is in Zone A and that section 3 is simply occupied? Granted, the above might only make sense to a few ppl on the board, but those are the ones I want to reach! (hopefully before I start wiring. ) 





Use the last two digits for all locos.

Use four digits for all cars. Add 1000 to car addresses 99 and below.

Loco 145 becomes 45

Car 17 becomes 1017

When you start doing automation or consisting using decoder assisted consisting, you will understand why.



Transponding and block detection are two different technologies.

(A) They use two different sets of messages to communicate over LocoNet.

(B) They have two different nomenclatures:

    (1) Transponding tracks decoder addresses in TRANSPONDING ZONES

    (2) Block Detection detects the absence or presence of current drawing objects in DETECTION BLOCKS.

(C) Transponding zones make NO electrical connection to the BDL168, the wires simply pass THROUGH 

       the center of receivers that plug into headers on the BDL168.

 (D) BLOCKS get their DCC power from the BDL168 and must be soldered to the edge connector of the BDL168.





Neither BLOCKS or ZONES should be confused with POWER DISTRICTS or POWER SUB DISTRICTS.



It just happens that both off these separate technologies share the same power source, LocoNet interface and circuit board for economic reasons.



You can use the BDL168 for only BLOCK DETECTION

You can use the BDL168 for only Transponding

You can use the BDL168 as only a function decoder ( It can drive 16 LEDs for a control panel).

OR 

You can use the BDL168 to do all of the above.




Some examples:

DETECTION EXAMPLE

Divide a circle of track into 8 detection BLOCKS. (Wire each section of track to the edge connector of the BDL168.)

Place a loco on the circle.

The BDL168 sends messages as follows; ( I translated them from binary to English.)

 DETECTION BLOCK 4 is OCCUPIED



Run the LOCO and the BDL168 sends this:

DETECTION BLOCK 5 is OCCUPIED, DETECTION BLOCK 4 is EMPTY

DETECTION BLOCK 6 is OCCUPIED, DETECTION BLOCK 5 is EMPTY

DETECTION BLOCK 7 is OCCUPIED, DETECTION BLOCK 6 is EMPTY



Remove the loco from the track and it sends this:

DETECTION BLOCK 7 is EMPTY





*TRANSPONDING EXAMPLE*

Divide a circle of track into 8 Transponding ZONES. (Wire each section of track to through an RX1 to the booster. DO NOT CONNECT ANY WIRES TO THE BDL EDGE CONNECTOR) 



Place a loco on the circle.

The BDL168 sends messages as follows; ( I translated them from binary to English.)

 LOCO 3 ENTERED Transponding ZONE 4



Run the LOCO and the BDL168 sends this:

 LOCO 3 ENTERED Transponding ZONE 5,  LOCO 3 left Transponding ZONE 4

 LOCO 3 ENTERED Transponding ZONE 6,  LOCO 3 left Transponding ZONE 5

 LOCO 3 ENTERED Transponding ZONE 7,  LOCO 3 left Transponding ZONE 6



Remove the loco from the track and it sends this:

  Nothing for a second, then  LOCO 3 left Transponding ZONE 7



*COMBINED EXAMPLE

*Divide a circle of track into 8 detection BLOCKS. (Wire each section of track to the edge connector of the BDL168.)

Feed the wire going to BLOCKS 5  and 6 through the center of RX1 # 2

Place a loco on the circle.

The BDL168 sends messages as follows; 

 DETECTION BLOCK 4 is OCCUPIED



Run the LOCO and the BDL168 sends this:

DETECTION BLOCK 5 is OCCUPIED, LOCO 3 ENTERED Transponding ZONE 2, DETECTION BLOCK 4 is EMPTY

DETECTION BLOCK 6 is OCCUPIED, DETECTION BLOCK 5 is EMPTY

DETECTION BLOCK 7 is OCCUPIED,DETECTION BLOCK 6 is EMPTY, LOCO 3 LEFT Transponding ZONE 2



Remove the loco from the track and it sends this:

DETECTION BLOCK 7 is EMPTY.



Note: In the last example ZONE 2 contains BLOCKS 4 and 5.

We could just as easily split the wire from BLOCK 5 and divided it into ZONES 2, 3 and 7

We could also take the wire feeding the second group of blocks and feed it through ZONE receiver 2. This would make Transponding ZONE 2 contain detection BLOCKS 5, 6, 7 and 8. Digitrax divided the 16 blocks into four groups of four BLOCK each. These are sometimes referred to in Directrix's documentation and DETECTION zones (groups of four blocks) and should not be confused with TRANSPONDING ZONES. This was done to make it easy to combine several BLOCKS into a single ZONE. Without this capability, you would eventually find it impossible to get all the needed wires through the center hole of the receivers.








Study these examples and we can see that we can:

put several BLOCKS in one ZONE,

put several ZONES in one BLOCK

put ZONES on track that has no BLOCKS.

put BLOCKS on track that has no ZONES.





So, HOW DO YOU PLAN THE WIRING?



Let's look at an example.

We have a computer that need BLOCK DETECTION to operate a display panel, manage signals and some interlocking. It needs BLOCK DETECTION.



We have a second computer that animates the lights in passenger trains and automatically plays sounds in on-board sound decoders in our locos and cars. It needs TRANSPONDING ZONES and BLOCK DETECTION.



We have a dedicated single board computer that assigns virtual sound decoders to loco addresses and plays the loco sounds through a 5.1 surround system to make the sounds appear to follow the locos. It needs TRANSPONDING ZONES. 


 


To avoid losing this post AGAIN!, My complete reply will be done in installments. 
Next. I'll cover planning zones and blocks. 
In installment 3 I'll cover some pitfalls and super secret, but very simple fixes.


----------



## NedsTJ (Apr 4, 2008)

Thanks for the reply Bob! Definitly cleared up a few things, although I think I was on the right track. Your post has made me rethink how I'm breaking up the detection blocks to make the most use of the 4 zones on the BLD168. Look forward to hearing more tips and tricks! I'm hoping to put the controller and wiring box together this weekend so I'll be doing some testing soon and be bugging you with more questions I'm sure.


----------



## Steeeeve (Sep 10, 2008)

I've been reading over a lot of the posts from Bob on DCC and yet so many questions still flood my mind. My main question is can you still get "detection" type results from transponding. What I mean by this is can you still find out the location of a loco (for example) on the track without a detection system installed. For example, can transponding tell you speed? If so then a simple program could calculate distance from a change in zones and thus where it is on the track. It just seems like detection is not a great idea for the outdoors and if you want the ability to have 100% automation outdoors you will need some different technology. Then again, I'm new at this so what do I know  

Thanks for the great reads Bob!


----------



## bobgrosh (Jan 2, 2008)

Posted By Steeeeve on 09/20/2008 8:14 PM
... 
My main question is can you still get "detection" type results from transponding. What I mean by this is can you still find out the location of a loco (for example) on the track without a detection system installed. 




First, A detection system can NOT tell you the location of a loco. It tells you that "something" is in a detection block. Could be a car, or some other loco in that block. Some computer programs attempt to figure out where a loco is by using detection. They do this by saying; 
If something entered block X, 
AND only loco NNNN has a speed set greater than zero, 
THEN loco NNNN must be in block X. 

There are problems with this: 
Maybe the train was backing up, and it was a lighted caboose that entered block X. 
Maybe there were two or more locos running at the same time. 
Maybe someone set a lighted passenger car somewhere in block X while loco NNNN was running. 


OK, so I'm going to have to narrow down your term "location of a loco". 
Let's assume you are only running one train. You are pulling it. There are no detectable cars ahead of you in track section X, or the following track section Y. You know the length of track section X. 

Let's also say you want to measure the actual speed of the loco. 

Here is how it is done with Block detection: 
The instant the first wheel of the loco enters block X, you start a timer. 
The instant the first wheel of the loco enters block Y, you stop the timer. 
Now you can calculate the speed from the length of bloc X and time it took to reach block Y. 

Here is how it is done with feedback (Transponding): 
The instant the LAST wheel of the loco enters zone X, you start a timer. 
The instant the LAST wheel of the loco exits zone X, you stop the timer. 
Now you can calculate the speed from the length of zone X and time it took to pass through Zone X. 

You will get exactly the same CALCULATED result for detection and Transponding. 

Now look at the differences: 
(1) Block detection tells you that something went through block X at speed S. Transponding will tell you that loco NNNN went trough block X at speed S. 
(2) Block detection requires that both sections X and Y are empty. Transponding does not care if or how many cars or locos are in sections X or Y. 

From this example we can see that to automate a dozen trains with block detection, we must have an empty block in front of, and an empty block behind each train. That's three blocks per train. Worse, if we decide that a block 20 feet long is sufficient for stopping a train, but our train 22 feet long (or longer) , then we need four (or more) blocks per train. For 5 trains, you need 20 or more blocks. That equals 21 wires, a common and 20 block feeders. 

Lots of wires buried in the wire-grass. 



Posted By Steeeeve on 09/20/2008 8:14 PM
... 
For example, can transponding tell you speed? If so then a simple program could calculate distance from a change in zones and thus where it is on the track. 




OK, we know we can see the speed, but WHERE IS IT! 

First some assumptions: 
(1)Lets say the software calculates the actual speed in feet per second every time it goes trough a zone. 
(2) It uses a moving average and stores 28 different "real" speeds for each loco. ("real" speeds can be found for any given DCC speed setting) 

If this is the case, then you can calculate the location of the loco even if the user changes direction, speeds up or slows down. It would also adjust to different loads (longer trains). 

Now let's compare feedback to detection as it relates to our automation example above where we needed 21 wires. 

If we have three Transponding zones, then as soon as a loco crosses a boundary, between two zones, we can determine it's speed, orientation on the track, and calculate it's position. (We have to assume that the initial condition is that all locos are stored someplace else, like a yard or siding, enters one of our three zones, and has a real speed table already stored from previous sessions.) 
Now, since we know the speed and direction, we can calculate the location and automate five trains running at the same time. The difference. we don't need empty zones in front of or behind each train. Three zones only require four wires, (a common and three zone feeders.) 

In theory, no matter how many trains, we run, we only need three zones. 

Theory hits reality!!!! 

The above assumes that wheels don't slip, locos always run at the speed we set, and the sky doesn't fall. 

The real limit depends on the spacing between trains, and the ability of the train to move at a predictable speed. 

I'll use the mainline of the ALLY as an example. 

I have 234' 8" on my main loop. With 5 trains, each averaging 12', I have 60 feet of trains running. That leaves 174 feet of empty mainline, or 34 feet between trains. (234' 8" times LGB's scale of 22.5 equals 5280 feet or one mile.) At 60 scale MPH (worst case) the train passes through three zones in one minute. (A mile a minute is 60 miles per hour and there are three zones). 

So, a trains exact location is known every 20 seconds when it crosses a boundary between two zones. (60 seconds / 3 zones = 20 seconds) 

We can also see that the loco is traveling 3.9 feet per second. Since there is 34 feet between trains and one train might be going slower than desired while the other is going faster, each train must stay within HALF the 34 foot distance from it's calculated position. Now we have enough information to calculate how accurate the loco must maintain it's speed. ( one half of 34' divided by 20 seconds equals .85 feet per second. ) 
So. each loco going 60 scale miles per hour must maintain a speed between 3.05 fps 4.75 fps. That is the same as saying the train must go 9.3 feet per second +/- 22%. 

On the ALLY, running LGB locos, I measured typical errors in the speed through each zone at +/- 2% to 3%. That more than enough accuracy to maintain a 34 foot spacing between trains. When I was controlling one train, and the computer was controlling the other four, I could change speed or even stop suddenly. When I did that, the trains would all slow or stop within three or four feet of the 34 foot spacing. 

If you are still following this, You will notice that with Transponding, we don't set signals red and then stop trains and wait for the signals to turn green in order to keep them from rear ending the train ahead. Instead, we can adjust the loco's speed to maintain a set distance from the train ahead. 

But, what if we WANT to use a signal system? 

Lets go back to the first question: 



Posted By Steeeeve on 09/20/2008 8:14 PM
... 
My main question is can you still get "detection" type results from transponding. 






I suspect what you are really asking is. "Can I use just Transponding and run an existing automation program that is written for block detection." 

OK, Yes, but you need to trick the system into thinking there is a block system. 

Programs like RR and Co. expect you to set up blocks, signals, triggers and such based on LocoNet block occupancy messages. 

JMRI has a lot of example scripts to operate trolleys back and forth, measure scale speed or make trains alternate passing sidings. They all depend on block detection. 

However. JMRI also has a script called reporter. It updates a memory table containing a list of Transponding zones. The script does not accomplish anything useful, it is just an example. It displays a list of all your Zones in the left column. In the right column, it displays the DCC addresses of all the cars and locos (Transponders) in each zone. I modified the reporter script to track the positions of locos. However you could also modify the script to send block detection messages out on LocoNet. 
I have not needed this, but it should be simple. 
In English, instead of JAVA, the added lines would do this. 

IF Zone X is blank, Send BLOCK X is empty 
ELSE Send BLOCK X is occupied, 

With this simple addition, we can put the reporter in the startup list and anything listening to LocoNet will think that you have block detection connected, even if you don't. Even another computer connected to LocoNet running some other program would see these messages and think they were coming from a BDL168 card. The reporter sends block messages out on LocoNet even if you have no blocks wired up. 

Of course, you would need 20 detection blocks to automate 5 trains so now you would need 20 Transponding zones to run 5 trains. That's still a lot of wires in the garden. 

If you are industrious, you could add more code to the reporter script, or write a separate script using speed calculations to divide the layout into VIRTUAL detection blocks. You could simulate hundreds of blocks, each a foot long if you wanted to. Then you could use RR and Co's program, or any other that used blocks to control signals to stop trains. Imagine, a hundred blocks with only one BDL168 card and just 4 wires! 

It would work, until the sky fell. 

OK, I'm staring to sound like chicken little. 

What do I mean by the sky falling? 

Examine what you want the system to do. 
Do you just want to automate some trains? 
Or... 
Do you want a collision avoidance system. 

Most block automation is really just a collision avoidance system. Blocks are "wired" so that if they are occupied, the block behind it is set to red. "Stop in this block if the NEXT block is occupied". (OK, they are a little more complicated than that, but that's the general idea.) 


If you use feedback ZONES to simulate blocks, it will work fine until you have a problem. If a acorn falls on the chicken dance car, bounces under the wheels and jams there, what happens? 

If we use the ALLY example above, and run 5 trains in three zones, then there are two trains in a single 79 foot zone. The software simulates blocks. It does not know the loco is spinning it's drivers in place. It continues sending block messages and the system has no way of knowing the loco is stuck. We can predict when the loco should reach the end of the zone. At 60 scale miles per hour, it should never take more than 20 to 22 seconds. We could shut down the following train if our lead train take more than 22 seconds to cover that 79 feet. The problem is, the train behind our chicken little train is only 34 feet behind us and is traveling at the same speed. 

The same problem will occur when the acorn simply fouls the coupler and brakes the train apart. 


Is there a solution? Can we build a collision avoidance system or broken train detection system just like the modern railroads use? Can we do it with Transponding? 

Yes, rather than tell you, I'll let you put on your thinking cap. 

(Hint, puts a SFX sound card in the caboose or last car.) 


I think that is enough for now. Installment 3 next week. 


B0B


----------



## Steeeeve (Sep 10, 2008)

I understand where you are going with this. Basically you predict speed based on historical data, your own track length, your throttle, and perhaps a few other variables. This would allow virtual detection blocks because you could predict locations and fool the system into saying "in block X" which could be 1 of 360 (for example) blocks...or 255 for the computer nerds (I saw that in another thread you had). 
Now, if you start predicting where a loco should be and if not there you cut the switch then you end certain things you might want to have or make it more complicated. Furthermore, you might run into issues with a track that has a main loop and perhaps some inner loaps...etc. 
Let me explain a little further but first let me answer your puzzle. 
If you have transponding in the first and last car you can basically calculate the length of the train and you would know when the loco passed and the back car didn't that something was up. In theory (on you example) you will have a 12ft train then 34ft and then a 12ft train then 21ft open on your 79ft zone. Might not be enough time for the back train to stop..even more so if it rolls backwards. If the train break right at my example, by the time train 1 hits the new zone we have back or train 1 sitting at the 46ft marker, train 2 at the 34ft marker. 12ft later the system says where is the back of train 1 and shuts things down. Back of train one is still at or around 46ft marker and train 2 has gone 12 more feet to the 46ft marker. Isn't that a hit? Perhaps I am missing something thoug...it is late for me " border=0> 
So this gets to my main point of what I am trying to do with DCC. Basically I want automation with the option of manual with the program adjusting for this. 
Lets say I have 5 trains 10ft long on a track that has an out loop and in loop and a few other surprises. One train is a passenger train. Lets say the train station is also side stepped (i dont know the train term for this) out from the main line (goes out and comes back to the main line after people are picked up). What I want first...in full automation mode...is for the switch to kick when it knows the passenger train is coming in and then train goes off to the side and then when the train is on it kicks back so the CSX train will go on by the left side of the passenger train on the main line no problem. The passenger trains has its lights turn on full or whatever and plays a little sound, sits a few seconds and then waits for the CSX train to clear and goes on. Obviously these trains would have defined routes but could adapt to changing circumstances such as one train going manual. Say the Norfolk Southern train is being run by me at varying speeds and various routes. The automated trains should adapt and change speeds or stop to make sure that 1) they don't slam into another train and 2) to still complete their scheduled routes. So basically I want collision avoidance and automation. 
Complicated, of course, but it seems like it could easily be done with transponding assuming a few can do a few more things (which I don't know because I don't have it yet). In theory if the transponder on the loco is sending out a packet every 1 second exactly then you could calculate the time to receive the packet and the differences so you could see exactly where on the track the loco is. This could easily fail though because packets are often lost I'd assume and different weather conditions can cause an issue with a signal. 
I guess I am not certain what the transponder can send or does send. If only an address and confirmation of packet received then really you could only hope for the above calculation that could easily fail. 
I suppose you could write a complicated script that would recalculate the time it would take for a loco to get to a new zone because of forced changes in speed thanks to a manual loco on the track. This would certainly do the trick but you would also have to adjust distances between locos and this could get complicated. All of this also depends on your track and if you change something...so does the program. 
Well, that is my random thoughts late tonight. I might add more and think about your quiz a little more too. 
Great info Bob thanks so much! 
Steve


----------



## bobgrosh (Jan 2, 2008)

Posted By Steeeeve on 09/21/2008 8:56 PM
I understand where you are going with this. Basically you predict speed based on historical data, your own track length, your throttle, and perhaps a few other variables. This would allow virtual detection blocks because you could predict locations and fool the system into saying "in block X" which could be 1 of 360 (for example) blocks...or 255 for the computer nerds (I saw that in another thread you had). 
Now, *if you start predicting where a loco should be and if not there you cut the switch* then you end certain things you might want to have or make it more complicated. Furthermore, you might run into issues with a track that has a main loop and perhaps some inner loaps...etc. 


And therein lies the problem. We are predicting where it is, but we don't know for sure where it is. We can't "throw the switch" since we won't know the loco got stuck or the train came apart until it gets to the end of the Zone. If we run more than one train in a Zone there is no positive way to implement "Broken Train Detection" . At least not without some other method of physically tracking the position of the train in a zone. That is where the SFX sound card comes into play. I'll get to HOW in a minute.


Posted By Steeeeve on 09/21/2008 8:56 PM

Let me explain a little further but first let me answer your puzzle. 

If you have transponding in the first and last car you can basically calculate the length of the train and you would know when the loco passed and the back car didn't that something was up. In theory (on you example) you will have a 12ft train then 34ft and then a 12ft train then 21ft open on your 79ft zone. Might not be enough time for the back train to stop..even more so if it rolls backwards. If the train break right at my example, by the time train 1 hits the new zone we have back or train 1 sitting at the 46ft marker, train 2 at the 34ft marker. 12ft later the system says where is the back of train 1 and shuts things down. Back of train one is still at or around 46ft marker and train 2 has gone 12 more feet to the 46ft marker. Isn't that a hit? Perhaps I am missing something thoug...it is late for me









OK, Time out!!!
We need two definitions.
COLLISION AVOIDANCE
This means the helper applications slows or stops a train to avoid rear ending, and does not pull out of a siding in front of or into the side of a passing train. Collision avoidance assumes that all the trains are working properly, not derailed or suck on an acorn.

BROKEN TRAIN DETECTION.
This is a feature we need in case a train becomes stuck, derails, or comes apart. Without broken train detection, the system can't avoid a collision because it does not know where the rear of the train really is located.

Since we are using virtual blocks, we do not have physical confirmation that the caboose is where the system THINKS it is located.
For most garden railroaders, with short trains, slow speeds and the fact that we want to control our own trains, we don't need "Broken Train Detection. We tend to watch our trains. We really just want helper applications to make life simpler. "Collision Avoidance" based on the assumption that the train has not derailed or broken apart will satisfy most of our needs. If we really want Broken Train Detection, we can do that with Transponding, but it takes an extra step.

Let's imagine a 1,000 foot long Transponding zone. Ten locos are in the same zone. Since we don't have a physical confirmation (IE 30 actual block detectors), if the first loco derails, we would have a pile up. At best our broken train detection would shut down the trains when the first loco takes longer than expected to reach the next zone.

Now, what if we were building a display railroad for a hospital that had to run unattended 24-7? Or, what if we ran $6,000.00 brass imports with $500.00 brass passenger cars? Well, we would want to have a method that would report the ACTUAL position of each loco and caboose. Or we would never let the HELPER application take control. 

Well, one choice is to put in four Transponding zones for each train. Just like a block system. We want to avoid that. To many wires and to expensive.

If we just put a transponder in the caboose, we are still relying on a computer to CALCULATE it's position. we don't have a physical confirmation of it's actual location.

That is, we don't have a physical confirmation of it's position, UNLESS we can measure how far it has traveled once it entered the Transponding Zone.

OK, time to explain a few things about the Digitrax SFX sound cards. Including a couple secrets.

 They have a chuff cam input.
 If you have Transponding, you can read back CV's on the main.
 They are the first and so far, only, user programmable sound cards for trains.
 Most sound decoders can have new sounds loaded in them. That is not what I mean by programmable.
Most sound decoders can have their characteristics changed by editing CVs. That is not what I mean by programmable either.
SFX decoders also do that, but in addition, you can write entirely new programs for them. (I'm not saying it is easy, but it can be done.)
This opens up all sorts of capabilities.
The fireman can call out accurate mile-markers based on the chuff cam and calculated from the driver diameter and the scale of your loco. Tis is standard in the code that ships with all SFX decoders.
You can build one into your volt meter to "speak" the zone number when you connect the meter to your rails. (custom program)
You program the decoder to keep track of miles traveled, estimated water usage and have it make a boiler explosion sound if you don't stop at the water tower. (someone else did that)

So, If we _really_ want broken train detection, we can:
Use the SFX sound decoder cam input to count wheel revolutions in a caboose. We program it measure the actual distance the caboose has rolled since it entered a Transponding zone. We can update the distance we have traveled since we entered the zone in a user defined CV. When the HELPER application calculates that the caboose should have entered a new "virtual" block, the application can do a Ops mode read of the CV to get a confirmation that the caboose has physically moved the required distance. If it has NOT, then the train is broken and the application can take action. We have a PHYSICAL confirmation of the caboose's location, not just a predicted location of where it SHOULD be.



Posted By Steeeeve on 09/21/2008 8:56 PM
So this gets to my main point of what I am trying to do with DCC. Basically I want automation with the option of manual with the program adjusting for this. 

OK. I believe the best term for what you want is a "HELPER APPLICATION" 
YOU run the train. The HELPER sits in the background ready to assist you or even take over for you.

Notice that a helper application is fundamentally different from the typical automated model railroad where you spend months defining the layout and preprogrammed scheduled operations. Most automation systems consider a live operator to be an uninvited guest that throws a monkey wrench in its finely tuned schedule. A good HELPER application just helps out a live engineer, takes over when required and turns the controls back over to the engineer the instant an engineer resumes operating the controls.



Posted By Steeeeve on 09/21/2008 8:56 PM
Lets say I have 5 trains 10ft long on a track that has an out loop and in loop and a few other surprises. One train is a passenger train. Lets say the train station is also side stepped (i dont know the train term for this) out from the main line (goes out and comes back to the main line after people are picked up). *(I don't know either. we can just call it a double ended siding or passenger siding. )* What I want first...in full automation mode...is for the switch to kick when it knows the passenger train is coming in and then train goes off to the side and then when the train is on it kicks back so the CSX train will go on by the left side of the passenger train on the main line no problem. The passenger trains has its lights turn on full or whatever and plays a little sound, sits a few seconds and then waits for the CSX train to clear and goes on. Obviously these trains would have defined routes but could adapt to changing circumstances such as one train going manual. Say the Norfolk Southern train is being run by me at varying speeds and various routes. The automated trains should adapt and change speeds or stop to make sure that 1) they don't slam into another train and 2) to still complete their scheduled routes. 

Some typical HELPER applications.
[*] The HELPER figures out the stationary address of the next turnout ahead of your train. You push a function button to flip the next turnout ahead of you.
[*] You assign three function buttons to three passenger stations. Turn on one or more of those functions and the HELPER will automatically stop at those stations. Any switches that need to be thrown are handled by the helper. Other functions can represent options like resume after a set time or resume after X number of trains pass the passenger siding. Of course you can resume any time you like by simply starting the train back up. You are in control. The HELPER will handle all the turnouts for you so other trains can pass. After all, that is what HELPERS are for. Doing all the dirty work.
[*] You are running a train, you turn on F13 and the HELPER automatically slows at speed restricted zones and rings the bell. It also blows the crossing signal at grade crossings. He slows when approaching other trains. In effect, F13 lets your helper get some throttle time while you serve guests coffee.
[*] You release a loco from your throttle while it is running. If F13 is OFF, the helper parks the train at the next available station. If F13 is off, the helper does not park the train but continues running as if F13 was ON. (slowing, blowing the whistle, stopping at stations if those functions are ON, etc.
[*] You stop a passenger train and cause the sound decoder to shut down the prime mover (Normally F6). The helper application goes through a long timed sequence of turning on and off various lights and sounds, not just the loco, but all the cars it was pulling, It simulates the train crew cleaning the cars and ends with all lights off. Then the helper dispatches the loco so another user can select it.
[*] A HELPER can either warn you or, optionally, if F13 is on, slow or stop to avoid other trains.
[/list] 
So, If a helper application can do all those things, I believe that is exactly what you are asking for. Is that what you want? Is there something I left out?


Notice something different about the helper application I listed above? It is TRAIN oriented, not TRACK oriented. It is just like Transponding (train oriented) , versus Block Detection (Track Oriented). Instead of configuring a computer program to simulate a scheduled passenger service, the operator schedules his stops using function buttons on his hand held. In effect, the operator acts like a train conductor, he schedules tasks for the helper to perform when the helper is running the train. This is probably more like the old backwoods and branch-line way of doing things and seems to me to be a better fit for the trains many of us garden railroaders run.
Some quick example of scheduling:
[*] You are running an express passenger train. On your throttle you turn on two functions, F10 (stop at Ruby Springs) and F11 (Stop at Mill Creek) You turn off F9 so the train just stops, holds any other trains behind it, waits s specific time and then resumes running. 
[*] You are running a local passenger train. You turn on all three station function, F10, F11 and F2 (Peach Falls). You turn on F9 (stop at stations and hold until another train passes) and turn on F14 (Don't always stop, unless to take on fuel or if the flag is displayed at the station indicating passengers need to be picked up.)
[/list] Notice that you can set as many different schedules as you have trains. You can use a Pacific for the express in the morning and use a F7 AB set for the same train in the afternoon. If we assign one more option to another function, we can tell the loco to revers direction when it stops at a station. Perfect for a trolley.

Posted By Steeeeve on 09/21/2008 8:56 PM
So basically I want collision avoidance and automation. 

Complicated, of course, but it seems like it could easily be done with transponding assuming a few can do a few more things (which I don't know because I don't have it yet).

Doesn't have to be complicated. Helper applications are like single purpose robots that can be assigned to multiple locos. We program one behavior, (Like slow to 20% and ring the bell in a yard zone) or (stop in a station Zones) or (blow a whistle in a grade crossing zone). We can then assign those behaviors to as many locos as we need. These behaviors do not need to know anything about you track plan. All you have to do is assign "fixed signals)) aka "signs" to each Transponding Zone. A zone with "P", "Y" and "X" assigned to it will let our robots know this is a "P" passenger station. "Y" yard, and "X" grade crossing. 

Other than assigning these "signs" to the zones, nothing else needs to be done concerning the track. Changes are easy. It you physically move your grade crossing to another location on your layout, simply delete the "X" assigned to Zone A and add an "X" to zone B.


Posted By Steeeeve on 09/21/2008 8:56 PM
In theory if the transponder on the loco is sending out a packet every 1 second exactly then you could calculate the time to receive the packet and the differences so you could see exactly where on the track the loco is. This could easily fail though because packets are often lost I'd assume and different weather conditions can cause an issue with a signal. 
I guess I am not certain what the transponder can send or does send. If only an address and confirmation of packet received then really you could only hope for the above calculation that could easily fail. 
I suppose you could write a complicated script that would recalculate the time it would take for a loco to get to a new zone because of forced changes in speed thanks to a manual loco on the track. This would certainly do the trick but you would also have to adjust distances between locos and this could get complicated. All of this also depends on your track and if you change something...so does the program. 
Well, that is my random thoughts late tonight. I might add more and think about your quiz a little more too. 
Great info Bob thanks so much! 
Steve 
Let's examine the concept of virtual blocks. In order to implement collision avoidance, we need some sort of blocks that we can set a flag for.

I already covered the "P" "Y" and "W" signs. By the way, I painted old leftover pieces of rail yellow and lettered them with "W" "Y" etc and drove them into the ground to mark my zones just like the real railroads. How I can see the same signs the robot "sees" in the software. 

We can also have a "S" assigned to a zone for "Stop". Rather than you assigning "S" to a zone, the robots add or remove the "S" to zones as needed to stop or release other trains. An example of how this works:
A passenger siding needs three zones with signs assigned to them, An approach "A", the passenger siding "P" and a the exiting or departure zone "D". A loco enters the zone with the "P" sign, stops and sets the turnouts so other trains can pass on the main. When it is ready to depart, it then adds a "S" sign to the "A" track. This stops any train attempting to ram the passenger train when it pulls out of the station. Once the loco has exited the station and is completely on the departure track it then removes the "S" sign from the approach track.

Now we can see there is a problem with this simple collision avoidance example.

The robot does not know how long the approach siding is. If that zone is really long, it could be stopping trains at the other end of the garden, clogging up operations there. If it is to short, really fast trains may not be able to stop in time. We don't want to add more wires and make a proper length zone for the approach. That is a waste of a transponder receiver.

Enter virtual blocks to the rescue. Now the robot can set out a "Stop" sign a fixed distance behind the passenger train. The stop sign could be in a virtual block 20 feet behind the train even if that block is only in the last 20 feet of the approach zone. If the approach zone is shorter than 20 feet, the block with the stop sign could even be in a zone previous to the approach Zone.

Setting up blocks is not complicated either.
There are three steps: (1) To configure the virtual blocks you will need to run a single loco, (no cars), around one of the layouts loops twice without changing it's speed. (2) Then run that loco through one zone at a slow reliable switching speed. (3) Then run that loco, at switching speed, on the rest of the layout. Stop at each turnout, and then throw it. (all turnouts must be DCC controlled). Be sure to hit emergency stop just prior to the loco reaching any dead ends. 

That's it! The loop you started with is converted to 360 exactly equal virtual blocks. The rest of the layout is divided into as many virtual blocks as needed of exactly the same size, and the turnouts stationary addresses and their exact location will be stored.

A any new loco will need to be run at a constant speed through any one zone. 

If you add a new turnout and siding, the robots can't use them until you manually take control and run a loco on the new track. If you change the length of the lain loop, you will have to reset the program and start at step 1.

You can manually enter the measured length of any one zone and enter it in inches or cm. Then enter your scale. These two values will allow the system to display scale speeds in miles per hour or kilometers per hour.

So, you see, using Transponding is not complicated at all. Since it is a new concept that goes counter to the conventional block oriented systems, it seems like black magic. hard to understand until you understand the concepts behind it. And then there is the lack of software. When I originally wrote mine, I messed up. I wrote it using a proprietary ($6,000.00 per copy) development system. It's not like I'm going to find any hobbyist willing to share some of the development work. Finally, I had to bite the bullet and learn a new computer language. JAVA, what a pain. But, at least most of the mundane tasks of decoding LocoNet are handled and there is a lot of example code to handle tasks like opening a throttle, throwing turnouts and such. since JMRI is open source code, my hope is that others will finally find Transponding as useful as I have and be able to accomplish cool things. I'm willing to share code and methods with anyone who takes the time to install and learn how to use JMRI and customize simple scripts

OK, off topic a little.
Look at this link: Surround Sound
After years of waiting they are finally taking orders. Mine is ordered and scheduled for shipment mid October.

Later
B0B


----------



## Steeeeve (Sep 10, 2008)

Thanks again Bob,

I hit a bit of a snag today with work (stupid economy) and in the process might have screwed over a forum member which I feel bad about since I promised to buy some equipment and now can't (sorry nick). 

Anywho,


I was not aware a sound card could do that and that certainly changes everything. The best part about having the rotation calculation in the back of the train is that you 1) don't have to worry about wheel slipping and 2) you know when a detachment occurs. 

According to Digitrax's website, they are going to have their decoders have this same "distance traveled" application by counting the rotations. This pretty much lets you know exact locations, derailments, train identity, and any other information you could ever want to know to make automation work. http://www.digitrax.com/ftp/bdl16rx4pm42appnote.pdf


10. Distance Measuring Equipment (DME) (Coming Soon)
This is a variation of the input sense line in which the input line is used to count axle rotations and provide this as position information to the LocoNet. This allows precise positioning of rolling stock based on actual wheel positions for specialized applications. This information is encoded by the transponder in a different manner to input sense lines.



9. Rolling Stock Input Sense Lines (Coming Soon)
Transponding incorporates multiple input sense lines from each transponder that may be used to alarm, alert or report to LocoNet when a change occurs on that input line to the decoder. This may be used for example to indicate the pantograph position on an electric loco or it could be used to indicate the presence or absence of a container load on an intermodal car. Additional feedback possibilities are endless and limited only by the imagination of the modeler.


Do you know anything more about these Bob? Perhaps when we will see them. 


As for my application with the passenger siding, you really can do it by maintaining only three zones with the idea of "virtual blocks". Once you have the location down, you know exactly when to flip the switch. 

Finally, I read the SurrondTraxx FactSheet. It looks nice and I'm wondering (since it limits you to 6 zones) if you can use the same concept of virtual blocks and create virtual zones if you wanted to waste money. Basically you create as many zones as you want and it makes it so you can have numerous speakers as if it is following the train around.


----------



## bobgrosh (Jan 2, 2008)

Posted By Steeeeve on 09/23/2008 3:46 PM
Thanks again Bob,

I hit a bit of a snag today with work (stupid economy) and in the process might have screwed over a forum member which I feel bad about since I promised to buy some equipment and now can't (sorry nick). 

Anywho,


I was not aware a sound card could do that and that certainly changes everything. The best part about having the rotation calculation in the back of the train is that you 1) don't have to worry about wheel slipping and 2) you know when a detachment occurs. 

According to Digitrax's website, they are going to have their decoders have this same "distance traveled" application by counting the rotations. This pretty much lets you know exact locations, derailments, train identity, and any other information you could ever want to know to make automation work. http://www.digitrax.com/ftp/bdl16rx4pm42appnote.pdf


10. Distance Measuring Equipment (DME) (Coming Soon)
This is a variation of the input sense line in which the input line is used to count axle rotations and provide this as position information to the LocoNet. This allows precise positioning of rolling stock based on actual wheel positions for specialized applications. This information is encoded by the transponder in a different manner to input sense lines.



9. Rolling Stock Input Sense Lines (Coming Soon)
Transponding incorporates multiple input sense lines from each transponder that may be used to alarm, alert or report to LocoNet when a change occurs on that input line to the decoder. This may be used for example to indicate the pantograph position on an electric loco or it could be used to indicate the presence or absence of a container load on an intermodal car. Additional feedback possibilities are endless and limited only by the imagination of the modeler.


Do you know anything more about these Bob? Perhaps when we will see them. 


As for my application with the passenger siding, you really can do it by maintaining only three zones with the idea of "virtual blocks". Once you have the location down, you know exactly when to flip the switch. 

Finally, I read the SurrondTraxx FactSheet. It looks nice and I'm wondering (since it limits you to 6 zones) if you can use the same concept of virtual blocks and create virtual zones if you wanted to waste money. Basically you create as many zones as you want and it makes it so you can have numerous speakers as if it is following the train around. 





First, the features you linked to. They are part of the protocol. That is, they were designed in, but not implemented, or perhaps only not documented by Digitrax. I have experimented with the SFX decoders and confirmed that the hardware is in there. There MIGHT be firmware in the decoder to implement those features that has to be turned on by some "undocumented" CV. That is a lot like the playable whistle. The feature was implemented in the DT400 years before anyone knew it was there. Only when Digitrax and SoundTraxx released decoders capable of accepting analog whistle commands, did Digitrax document the pressure sensitive F2 button. Currently, the only way to implement these features is to add user supplied code. One thing I have learned about Digitrax, like the playable whistle, they will add features to one component, like a decoder, then not say a word about that feature until they implement a feature in a throttle that can be used with the feature in the decoder. It is a pleasant surprise to find out that all your old hardware works with the latest new piece of hardware. Since the new two way throttle is due out by January, I expect we may discover some surprises having to do with Transponding. After all, what good is t bidirectional decoder without a bidirectional wireless throttle. I'm going to bet that there might be some messages show up on the screen of the new throttles that we didn't know our decoders could even send.



The SurroundTraxx system contains a fancy audio 6 by 6 mixer. Think of it as six Tsunami Sound decoders on the inputs, and six speakers on the outputs. Each speaker handles a "SOUND ZONE" ( NOT THE SAME THING AS A TRANSPONDING ZONE" 

As a train moves through Transponding zones, the mixer takes a Tsunami input and fades it up to the corresponding SOUND zone, while fading it down in the SOUND zone it left. 

If you look carefully at the examples, a train can move through ones Transponding zone near the front of the layout. If the train goes LEFT to RIGHT, you hear the train in that Sound Zone and it sounds like it is moving left to right because of the fading. Then, the train can loop around and go through the same SOUND ZONE again in the opposite direction and at the rear of the same scene. This time it is in a different Transponding zone. Again, you hear the loco, and because of the fading. This time, it sounds like it is moving from RIGHT to LEFT. One cool feature is that on the back Transponding zone, you can make the loco sound farther away and also have a different echo. 
As you can see, there is not a 1 to 1 relationship between Transponding zones and sound zones.

As to creating virtual blocks, It sounds possible. It is one of the things I want to try once I get the system. 

One thing not mentioned anywhere.

I got this in one of my long phone calls to the SurroundTraxx engineer. The Surround trax system has coded into it all the sounds available from SoundTraxx. It also has programed into it six virtual Tsunamis. They mention that you can run any six locos at the same time and they will seem like you have six Tsunami's installed. That has led people to conclude the relative cost of the system plus speakers and Transponding hardware is slightly higher than buying six Tsunamis. 

*The truth is, the SurroundTraxx system maintains a roster of 100 locos. *

You can configure all 100 locos with virtual Tsunamis. Each one can have different sounds and CV settings. The only limitation is that you can only run six at the same time. The system automatically selects the correct virtual sound decoder when you select a loco stored in your roster. If you are running six locos, all using Surround sound. you have to release one of them before you select the seventh loco. That is a lot like having 9999 loco addresses but DCC systems only let you run 22 locos at a time. Based on 100 locos that drops the cost of sound to about 6 dollars per loco. Even if you have only 10 locos, the cost is half what it would take to install decoders in all of them. 
One cool thought...
When a friend brings over a loco without sound, put a car with a transponder behind it. assign a virtual sound decoder to the car's address and B A M ! ! ! your friends loco has sound.


----------



## Steeeeve (Sep 10, 2008)

SurroundTraxx seems like a powerful tool which will eliminate some of the issues you might have with an internal sound card. The only reason I say "virtual sound zones" is that you might have the ability for 6 speakers but if you have a lengthy track this could be too little sound or over too broad of an area. 

Not only that, but don't you have to make it the same as transponding zones (at least in how we discuss things detection is gone so no blocks are left)? The sound system has use blocks like transponding does (not block detection for those reading), right? 

Back to transponding. Is JMRI the best software program? It seems the open source certainly helps.


----------



## bobgrosh (Jan 2, 2008)

Posted By Steeeeve on 09/23/2008 7:35 PM
SurroundTraxx seems like a powerful tool which will eliminate some of the issues you might have with an internal sound card. The only reason I say "virtual sound zones" is that you might have the ability for 6 speakers but if you have a lengthy track this could be too little sound or over too broad of an area. 

Not only that, but don't you have to make it the same as transponding zones (at least in how we discuss things detection is gone so no blocks are left)? The sound system has use blocks like transponding does (not block detection for those reading), right? 

Back to transponding. Is JMRI the best software program? It seems the open source certainly helps. 


That is correct. They say speakers need to be 2 to 8 feet apart. If that is accurate, then, at the most, one unit would cover 48 feet. My railroad spans 100 feet. Nobody has experimented with one outdoors, so we don't know if the speakers can be spread out, or perhaps even need to be closer. I only ordered one system, it may take 2 or 3 to accomplish anything convincing. We shall see. At any rate, you need AT LEAST one Transponding zone per speaker zone if the system is to operate in a stand alone mode. As You suggested, it seems possible to send fake Transponding messages out from a PC running JMRI so that SurroundTraxx would see 6 virtual Transponding zones even though only one physically exists.

As to JMRI, It seems to be the only logical choice for now.


----------



## Steeeeve (Sep 10, 2008)

Seems Soundtraxx made this for the smaller scales because, based on my limited knowledge of sound systems, you can easily add my speakers to a system just so long as you have the outputs. The logic is no more difficult than your sound card in your computer. I guess if they didn't to do this then you are stuck buying more than one system. I wonder if future production will change this. 

Also, seems like this setup is only useful once you have over 6 or 7 locos. At that point you have more sound cards in your loco than the cost of the system thus negating any benefit of having it in the loco. I recall those sound cards being $100 a pop which is no joke. If you have 20-30 locos then that can be pricey. This actually brings me to my next point. The system limits to 6 locos but what if you are using sound elsewhere on your layout? What if you want your caboose to make a sound or perhaps a house on the side of your layout make a sound (like a person waving to the train saying "hi") or even a train station saying "the 115 to Richmond will be arriving shortly". Does this system limit those items as well?


----------



## bobgrosh (Jan 2, 2008)

Posted By Steeeeve on 09/24/2008 9:14 AM
Seems Soundtraxx made this for the smaller scales because, based on my limited knowledge of sound systems, you can easily add my speakers to a system just so long as you have the outputs. The logic is no more difficult than your sound card in your computer. I guess if they didn't to do this then you are stuck buying more than one system. I wonder if future production will change this. 

Also, seems like this setup is only useful once you have over 6 or 7 locos. At that point you have more sound cards in your loco than the cost of the system thus negating any benefit of having it in the loco. I recall those sound cards being $100 a pop which is no joke. If you have 20-30 locos then that can be pricey. This actually brings me to my next point. The system limits to 6 locos but what if you are using sound elsewhere on your layout? What if you want your caboose to make a sound or perhaps a house on the side of your layout make a sound (like a person waving to the train saying "hi") or even a train station saying "the 115 to Richmond will be arriving shortly". Does this system limit those items as well? 


It is made for all scales, but, since the tiny speakers in N sound EXTREMELY bad, it is EXTREMELY attractive for "N"
For HO, it is fairly attractive.
My "G" scale locos sound pretty good, but not as good as playing the same sound card through my Sony 51. Home Theater System with my Sony speakers and sub-woofer. Since I got a new Home Theaters system, it will be the old Sony system, speakers and sub-woofer that I will be using with the SurroundTraxx system . So, I didn't get it to save money on sound cards. In fact I just ordered another 12 sound cards.

Just like the Tsunami, each virtual sound decoder is polyphonic. It generates each sound individually and then there is a dynamic mixer to produce all the sounds for the loco. There are two outputs from each virtual decoder, one for the normals speaker and another for the sub woofer. There is also an effects processor for each polyphonic sound and a equalizer. since each Tsunami is able to play, mix and equalize at least 8 sounds and there are 6 of, each with another computer controlled equalizer and then they are to multiple speakers in varying amounts to follow up to six trains at once, we easily are dealing with 48 sound sources all having various effects applied. My understanding is that the limit of six is purely a function of processing power. I wrote software and built systems that automates radio stations. Even the $800.00 sixteen channel sound cards I use in my Radio station computers would have a hard time doing what the SurroundTraxx does.

I can think of no reason that the SurroundTraxx system would limit any of those items. In fact, I intend to use SFX cards in my stock cars, passenger cars, cabooses and stations. I also have three Fantasonics Cd's for ambient sounds, (saw mill, lumber operation and flag-stop station.) I plan to add the "small harbor and water falls CD's. These will all be migrated to DCC controlled solid state players eventually.


----------



## jbooker (Jan 15, 2008)

Old post, I know...haven't seen Bob Grosh on here in forever, but maybe he's still out there somewhere...
I'd love to work together on the software for virtual transponding zones. Does anyone know how to get in touch?
Josh


----------

