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
