I've designed and put into the public domain, a complete detection system that does NOT require any modification to any rolling stock or locomotives, and is independent of track power.
As such, it will work on DC or DCC or for that matter ANY form of power used for a model train. It's designed to be cheap and simple, yet reliable.
The system is Arduino based, and includes basic, simple signaling as part of detection, but if that's used is up to you. It supplies a simple logic level signal to indicate that a block is occupied.
The design was initially introduced on the TrainBoard forum, and I'm trying to get more exposure so more people will try it. There are videos and complete documentation that includes the code for the Arduino, schematics and single-sided PCB layouts so you can make the boards at home. There is also some technical details of how it works.
The estimated costs per block is between $9 and $16 depending on how fancy you get in the build process. The outputs are on 0.100 centers, so many types of connectors can be used, from simply soldering wires to the pads (not recommended) to simple pin headers, to screw terminals. The wiring to external devices is whatever you have around, and I use the wire from CAT5 computer cables.
Besides the Arduino modules, the only external components are resistors for the indicator LEDs, the IR sensor modules and the IR source LED and its current limiting resistor. Simplicity by design!
http://www.trainboard.com/highball/index.php?threads/different-way-to-do-detection.91951/
The video production isn't very good, and if you watch all 10, the final system implementation is worth it. Again, all the code and schematics and board layout is done, and the discussion should help you understrand how it works and how neat & reliable it is.....hopefully, you'll see what I mean and will give it a try.
I'll respond to any questions here and/or on TrainBoard.
Local enters the block with and engine, 10 cars and a caboose, 48 axles. Stops mid block and sets out 1 car at an industry. Departs block with an engine, 9 cars and a caboose, 44 axles.
Is the block occupied or unoccupied?
Dave H. Painted side goes up. My website : wnbranch.com
Sounds like we are being given a sales pitch. Isn't that against the Forum rules?
ENJOY !
Mobilman44
Living in southeast Texas, formerly modeling the "postwar" Santa Fe and Illinois Central
What part of public domain don't you understand?
I understand it perfectly......... I also have been around the block a whole lot of times.
Occupied, obviously......once the train clears the block, just touch the block reset, and all is OK.
Conversely, the same environment, but an 0-5-0 operation ADDS a car with 4 axles.....when the train leaves the block, is it occupied or unoccupied???
The answer is unoccupied, because the logic prevents the count going below 0.
Look at the videos and read the docs on TrainBoard.....actually, I count anything larger than a minimum size, which is about 1/4 inch. The system actually ends up counting trucks because they only cause 1 transition through the sensors, but I just count any appropriate transitions, defined by the state machine logic.
I don't have anything to sell other than the idea, and that's free!
Another interesting Arduino application.
Thanks crusader27529
Dave
P.S. I like the price for the plans. You can sell me as much of that as you want to!
I'm just a dude with a bad back having a lot of fun with model trains, and finally building a layout!
Please let me know what you think of the system, and ask any questions that you have.....
Looks interesting. I will take a look. I generally prefer current sense systems that aren't point based, so you can exclude sidings, and adding cars in the middle will definitely be detected. There are definitely use cases where a point detection system is more usable, and perhaps a combination of systems will get the best fo both worlds - easy to tell direction of travel while no issues with things like setouts. A current sense system can do direction, but to do so it must track the status of each block, and also know the railroad, so that if it sees block 5 active and the next one active is block 6, and it knows block 5 connects to block 6, then something just moved from 5 to 6. Not as easy as just seeing which sensor was tripped, east end or west end.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
I gave it a read, interesting enough approach.
But for me current detection works just fine.
Signaling and detection are generally about mainline operation. I model an era when mainline trains had cabooses. Light the caboose, and the whole train is detected. Size blocks properly, and use overlapping sub blocks for interlockings. Light most passenger cars, especially tail end cars. No worries, current detection works fine.
I run my trains with DC, so it is also easy for me to monitor direction.
And my interlocking sub blocks also lock out turnouts so they cannot be thrown under a train - just like a real life interlocking plant.
All done with $3 relays rather than computers or processors.
I use Dallee inductive detectors, pricey but rock solid reliable.
And the Dallee detectors have dry contact relays on board as the heart of my signal system - that combined with spare contacts on relays used to operate turnouts, is a complete signal system - with no processors.
All with wireless radio throttles...........don't need no processors here......
Sheldon
if you have a larger layout where a number of occupancy detectors are required, your looking for something that is reliable, inexpensive and worry and maintenance free, buried under the layout.
I'm sure that the Arduino board could be replaced by an 8-pin Pic processor, but even such an implementation would be more complicated than a simple diode drop detector. Of course, such detectors aren't intended for DC.
but modelers interests also justify approaches ...
greg - Philadelphia & Reading / Reading
What are all you current sensing guys going to do when battery powered, Bluetooth controlled trains are running on dead rails?
BTW, I'm going with current detection as well, but I've only gotten as far as putting the coils on my feeders. I guess I need to hurry up before there's no current to detect.
I have the right to remain silent. By posting here I have given up that right and accept that anything I say can and will be used as evidence to critique me.
This setup will also detect extra cars added to a train automatically.
As far as direction detection, the ONLY reason I care about direction is at a block boundary, so I can signal the block that the car/train came from that a car has left.....same thing for the block that the car in entering. That signal counts up a count for the block where the car is entering, and counts down for the block that the car is exiting from.
If the count is zero, unoccupied, otherwise occupied.....
The system works with ANY type of power, even battery, and detects ALL cars without modifying the rolling stock. The way it operates is completely different from the previous techniques used. It's very reliable and easy to setup.
First, running DC and using current detection doesn't make alot of sense to me, since the detection won't work when a block is unpowered.
Second, the only reason for direction detection is to determine which block to signal to count the number of cars in that block up or down, depending if the cars are going into the block or out of the block. You don't understand the detection logic.....
The state machine determines a valid transition at a block boundary and the direction of the transition, and signals the adjacent blocks (yes 2 blocks) to count up or down depending on the direction of the transition. When a count for a block is NOT zero, the block is occupied, and if it's zero, it's empty and unoccupied.
LOOK AT THE POSTED VIDEOS....it explains how the system works.
crusader27529:
Seems like you are being given a hard time. Please hang in there! (I'm sure you will).
It's kind of like arguing that the world is round 600 years ago.
crusader27529 I gave it a read, interesting enough approach. But for me current detection works just fine. I run my trains with DC, so it is also easy for me to monitor direction. Sheldon First, running DC and using current detection doesn't make alot of sense to me, since the detection won't work when a block is unpowered. Second, the only reason for direction detection is to determine which block to signal to count the number of cars in that block up or down, depending if the cars are going into the block or out of the block. You don't understand the detection logic..... The state machine determines a valid transition at a block boundary and the direction of the transition, and signals the adjacent blocks (yes 2 blocks) to count up or down depending on the direction of the transition. When a count for a block is NOT zero, the block is occupied, and if it's zero, it's empty and unoccupied. LOOK AT THE POSTED VIDEOS....it explains how the system works.
Obviously you are not familiar with the Dallee detectors or their system.
Respectfully, maybe you are the one who needs learn a little more about older systems what work just fine before you start telling people what they don't understand.
They do work when the train is stopped, because there is an accessory device that puts a high frequency bias current on the track. It has no effect on the loco or the lighted cars, but the inductive dectectors detect the presence of the parked loco or car.
And that's not the only way to do it. Maybe you should go into the MR archive and look up "twin T".
I detect direction because I can, polarity determines east and west, the dispatcher sitting at his CTC panel knows which way a train is moving.....
I understand exactly how your system works, it counts cars in and out, I get it.
I programed industrial PLS's all the way back in the early 80's when they were first invented.
Like Randy explained, I too am not big on the idea of fixed point detection. I experimented with it years ago. Sure, you have a better version of it, I agree. But it offers me no improvement over what I have now.
My system is fully intergrated, one button turnout route controls, interlocking signals, progressive walk around block control system and CTC dispatching are all done by one set of relays with multiple contacts.
The signal logic is nearly identical to what the prototype used for over 100 years.......
With a dispatcher on duty, my engineers just pick up a radio throttle and follow their train and obey the signals. Without a dispatcher they only need to select routes at tower panels located at each interlocking - the rest happens automaticly.
I even have Automatic Train Control. If you run a red signal, you will not run into someone elses block, your train will just stop because there are buffer sections not powered unless you have control of two consecutive blocks - and that feature does not even require any active or special equipment. Want to know the how it works?
Have to go to work now.
Do exactly what the prototype does, you add a track circuit for detection to the track. Since its for detection it doesn't need any sophisticated controls and doesn't have to be routed through switches.
Seems like you are being given a hard time. Please hang in there! (I'm sure you will). It's kind of like arguing that the world is round 600 years ago.
Not quite. There are some hurdles with the proposal. Like the first one I brought up. If you make a set out between detectors the system will have to be manually reset.
That's not an automatic system. That means somebody has to manually rest the signal system everytime the car count goes down on a train. Is there a detector to detect when the proposed detector didn't detect a set out?
How does the system detect a track occupancy after a pick up (I pick up 5 cars but leave the caboose on the main)?
What happens if somebody moves their hand (or a Bright Boy) over the track? Will it trigger an occupancy?
How do you hide the detectors so they aren't visible on multiple main track or controlled sidings (since they measure horizontally instead of verticaly like most optical detectors)?
Maybe all these things can be accomodated, but they are legitimate concerns.
I wouldn't want to use this type of thing to drive a signal system (and I model a dark railroad), but it might have a use as an automated OS bell. I wouldn't care about car count. Mount one in front of the depot and it would ping an OS based on direction. The hard part would be limiting it to one ping per "train" and handling trains working at the station.
dehusman Seems like you are being given a hard time. Please hang in there! (I'm sure you will). It's kind of like arguing that the world is round 600 years ago. Not quite. There are some hurdles with the proposal. Like the first one I brought up. If you make a set out between detectors the system will have to be manually reset. That's not an automatic system. That means somebody has to manually rest the signal system everytime the car count goes down on a train. Is there a detector to detect when the proposed detector didn't detect a set out? How does the system detect a track occupancy after a pick up (I pick up 5 cars but leave the caboose on the main)? What happens if somebody moves their hand (or a Bright Boy) over the track? Will it trigger an occupancy? How do you hide the detectors so they aren't visible on multiple main track or controlled sidings (since they measure horizontally instead of verticaly like most optical detectors)? Maybe all these things can be accomodated, but they are legitimate concerns. I wouldn't want to use this type of thing to drive a signal system (and I model a dark railroad), but it might have a use as an automated OS bell. I wouldn't care about car count. Mount one in front of the depot and it would ping an OS based on direction. The hard part would be limiting it to one ping per "train" and handling trains working at the station.
I have all those questions and more.
Will it seperately count passenger cars with working, always touching diaphragms? All my passenger cars are close coupled with diaphragms.
How about steam locos with close coupled tenders?
And if you count the wheels like you first considered, how would it know what a steam loco was?
Most of my cab unit diesels have diaphragms as well, I model that golden age when they were still new.......
I don't do much switching on the mainline, but I don't like the reset problem either.
My blocks are all longer than the longest train, so locos and last car detection works.
My CTC signals are all actually interlocking signals, with some tricks to make it look like I also have intermediate block signals. Dispatching at each interlocking is simplified to two actions - select the route, authorize the train - each requires a single pushbutton.
Does your system do any of that?
I don't think it counts cars, it actually counts "trucks" and it doesn't really care how many as long as the count in is the same as the count out. Diaphragms would proabably not affect the system, but skirts and fuel tanks would. As long as the detectors were the same height and the same angle to the track they should catch the same number of "passings", but the actual number is not particularly relevant (it doesn't matter if the steam engine is counted as 1 passing or six as long as it is counted the same in or out.) I would imagine that a skirted passenger car might be counted as one long passing. What this points out is that consistency of the detector positioning will be critical. If the east end catches the the skirt and the west end shoots below the skirt then it will screw up the count.
About the only edge case I could think of with a steamer is that the moment it passes the west reader the rods are up and the moment it passes the east reader the rods are down and it somehow hits two different counts. But that would probably be very unlikely.
My system counts ANYTHING that goes by greater than about 1/4".....I don't care what it is. I said trucks so you could understand what it's doing. It doesn't know or can't know what its counting, so your question about a steamer versus something else is moot. It's just counting THINGS. I've tested it on many types of cars and engines, but obviously noy all types. That's what I'm looking for with others trying the system. The Arduino modules can be re-purposed if you don't like the system. The investment is minimal.
The physical setup is trivial, requiring no adjustments other than to point the IR source as low to the rails as possible.
The system is simply a DETECTOR that has some simple signal outputs if you want to use them. Using bit for a more complex environment is way beyond the scope of simple detection. The digital output for OCCUPIED can be used to do anything you wish.
Dave H. Painted side goes up.
You are correct in what the detector does. As far as the issue with a steamer and the operating rods being detected, I've never had an issue in testing, probably because of the nature of the detection....the detectors must be covered/uncovered in a specific sequence to count as a valid detection. Plus, the vertical size of the rods preclude that they actually block detection......the IR output from the source diode is like a firehose, and actually is difficult to block.
The placement of the detectors is completely non-critical because the entire detector must be covered for it to operate, and because the output is digital, and is debounced in the firmware. And the detectors run at 38KHZ just like the IR stuff for TV remotes, which makes the detection very reliable and easy to setup.
Again, the system counts anything above a certain size, and is rediculously accurate/reliable in counting what goes by, so the counts from the various detector is also reliable and consistent. The reset was added because no system is perfect, and since the system has memory, some way to reset it was required.
Most point detectors do NOT actually keep track of anything, but just notify that something went by. This system is a BLOCK detector, not just a point detector.
I wonder how many of the people who are commenting about the system actually watched the vedeos???
It's obvious to me that most of the 'objections' raised are because people don't understand the way the system works AND likely are still referencing it against their analog experiences. You seem to understand it well.
OK, I get all that. Again, not keen on having to position the trackside sensors. I think Dave is right about that being critical.
I considered computerized block control years ago, it would have done all the signaling internally in the software. Eventually decided too much programing, too many inputs outputs needed, input/output hardware too expensive.
I have all the features I decribed to you and more for less money than it would cost to put decoders in my 130 locos.
How much is one Ardiuno module? How many would my 30 blocks require? Then I still need to build a control and signal system.
Again, maybe a newby would be interested, but for those with working dectection already, not enough better........
First of all, let me make it clear that each block is separate, and becuase of that, there is no system reset. When I say reset the system, I'm referencing the individual Arduino module/system, nothing more.
I think the only way to settle this budding dispute is for an independent, objective third party to test it and provide a thorough review of the pros and cons of this system.
Right now, we have the OP claiming that it is superior to other detection systems and everyone else, none of whom have tested it, saying it is not superior to other systems.
So, at the moment, it seems to be a draw.
Rich
Alton Junction
richhotrain I think the only way to settle this budding dispute is for an independent, objective third party to test it and provide a thorough review of the pros and cons of this system. Right now, we have the OP claiming that it is superior to other detection systems and everyone else, none of whom have tested it, saying it is not superior to other systems. So, at the moment, it seems to be a draw. Rich
It may be very good, it just brings nothing to the table that I don't have already.
In fact, I said earlier, that it sounds better than any other point dection based system I have seen.
But just like DCC, it would add no feature I need or want.......
From an engineering standpoint (electrical, not locomotive) all I did was to address some concerns and limitations of current detection, and 'solve' the problem by implementing detection is a different way.
I see current detection as an OK method, but to do COMPLETE detection similarly to prototype operation, EVERY piece of rolling stock would have to be detectable, and we know the issues with that.
First, the cost of modifying the rolling stock, and the PITA issues of adjusting the the sensitivity of the current detectors for the resistor based detction in the cars. And to do it correct, every wheel, not just one per car, but every wheel should have a resistor mounted. NOBODY will do that.
So, I decided that an alternative approach might work, detecting transitions of wheelsets across a block boundary, and that would feed a counter to determine if the number of things in a bloc was 0 (unoccupied) or not 0 (occupied). The primary goal was NOT having to modify rolling stock for detection. Along with this simplistic idea, the COST and ease of use and setup was also part of the design goal, and once I attained the goals setout, I introduced this system.
I think it works GREAT, but it is DIFFERENT and as such isn't necessarily understood.
I look forward to somebody trying the system, and will give any assistance required.
THANKS.
crusader27529 I think the only way to settle this budding dispute is for an independent, objective third party to test it and provide a thorough review of the pros and cons of this system. Right now, we have the OP claiming that it is superior to other detection systems and everyone else, none of whom have tested it, saying it is not superior to other systems. So, at the moment, it seems to be a draw. Rich From an engineering standpoint (electrical, not locomotive) all I did was to address some concerns and limitations of current detection, and 'solve' the problem by implementing detection is a different way. I see current detection as an OK method, but to do COMPLETE detection similarly to prototype operation, EVERY piece of rolling stock would have to be detectable, and we know the issues with that. First, the cost of modifying the rolling stock, and the PITA issues of adjusting the the sensitivity of the current detectors for the resistor based detction in the cars. And to do it correct, every wheel, not just one per car, but every wheel should have a resistor mounted. NOBODY will do that. So, I decided that an alternative approach might work, detecting transitions of wheelsets across a block boundary, and that would feed a counter to determine if the number of things in a bloc was 0 (unoccupied) or not 0 (occupied). The primary goal was NOT having to modify rolling stock for detection. Along with this simplistic idea, the COST and ease of use and setup was also part of the design goal, and once I attained the goals setout, I introduced this system. I think it works GREAT, but it is DIFFERENT and as such isn't necessarily understood. I look forward to somebody trying the system, and will give any assistance required. THANKS.
Respectfully, what is the need for detection beyond signaling?
Admittedly my approach skips over the idea of a lone car left on the mainline.
In the days of fixed operator DC layouts, it was also used to show train location to operators who could not always see their train.
It still works that way for anyone using a dispatcher.
Not detecting every car is a compromise I can live with, it has no effect on my operating scheme. So only cabooses and some passenger cars need "modification".
Please explain why you feel this feature is important for prototype operation.