Different way to do detection/occupancy


crusader27529

New Member
I've designed a system that can detect anything entering a block without ANY modifications to a locomotive or rolling stock.

It doesn't care about what's powering the train, so it works with DC or DCC.....and it's public domain.

Instead of reproducing the entire discussion where I initially showed it, please reference this:

http://www.trainboard.com/highball/index.php?threads/different-way-to-do-detection.91951/

I'll respond to questions on this forum or on TrainBoard.....

The system is Arduino based, and can be implemented in the $10/block range, depending on how fancy you want to build the modules.
 
I've designed a system that can detect anything entering a block without ANY modifications to a locomotive or rolling stock.

It doesn't care about what's powering the train, so it works with DC or DCC.....and it's public domain.

Instead of reproducing the entire discussion where I initially showed it, please reference this:

http://www.trainboard.com/highball/index.php?threads/different-way-to-do-detection.91951/

I'll respond to questions on this forum or on TrainBoard.....

The system is Arduino based, and can be implemented in the $10/block range, depending on how fancy you want to build the modules.
How is this any different than the cross track beams used as detectors in things like the Twisted Trains and Train Boss "hot box" detectors, other than maybe perhaps the programming of the Arduino?
 
How is this any different than the cross track beams used as detectors in things like the Twisted Trains and Train Boss "hot box" detectors, other than maybe perhaps the programming of the Arduino?


All those "hot box" detectors know is when a train passes a certain point. The system crusader27529 has developed counts and keeps track of the axles entering and leaving a block so that it can report block occupancy.
 
All those "hot box" detectors know is when a train passes a certain point. The system crusader27529 has developed counts and keeps track of the axles entering and leaving a block so that it can report block occupancy.
I know what those units are. I run trains through them all the time. No, they don't just know when a train passes a certain point. They count axles, speed, length of train, compute the probability of a pretend hot box etc. But none of that was the question. The question was; how, if at all, their dual beam sensor is different from what the one used in the system crusader?

The question behind the question is - The sensors on the "hot box" detectors get confused when a train stops over them. How does this system deal with that issue. Where I suppose a train would be half in and half out of a block and stops.
 
I know what those units are. I run trains through them all the time. No, they don't just know when a train passes a certain point. They count axles, speed, length of train, compute the probability of a pretend hot box etc. But none of that was the question. The question was; how, if at all, their dual beam sensor is different from what the one used in the system crusader?

The question behind the question is - The sensors on the "hot box" detectors get confused when a train stops over them. How does this system deal with that issue. Where I suppose a train would be half in and half out of a block and stops.

You really need to read the technical part of how it works, but here's the short version:

It uses quadrature detection in a sophisticaed state machine to determine which direction a detected thing (wheelset, truck or whatever) is going as it passes the detector AT THE BLOCK BOUNDARY, and sends a signal to counter modules for the blocks adjacent to itself to count up or down. The counter module for each block keeps track of how many things are in a block, and ZERO means the block is unoccupied.

Simple.....if you think this is like a hot box detector (however that works) then you don't understand what this actually does.
 
Time will tell if it can work in the real world.

One dropped count or extra count and the occupancy state could become invalid.
 
is there a diagram showing a schematic, as well as a diagram that shows the geometry of the sensor and the track?

On the trainboard site there are downloadable files with the code for the system, some more documentation and schematic/pcb layout data. The schematics and layout require KiCad, which is free.

There are photos of the boards, plus video of the system in operation. The geometry is one IR LED across the track from 2 TSSP4038 IR sensors placed in a partially overlapping arraingement so the 'lenses' are about 1/4" apart, center-to-center. That's very different than your hot box detector, which is nothing more than a toy to simulate the operation of a prototypical hot box detector.

The only external components required for operation besides the Arduino modules are the 2 IR sensors, and the IR LED and current limiting resistor. The only other components are some LEDs to show status, purely for convenience.....they are not required.
 
Last edited by a moderator:
Time will tell if it can work in the real world.

One dropped count or extra count and the occupancy state could become invalid.

The system is amazingly accurate, but also allows for clearing a block manually if needed.

Although an incorrect count is possible, the most likely reason to clear the block is because of 0-5-0 switching that has removed something from a block. Adding something to a block is not an issue because when anything leaves the block, a count down is sent to the block that it's exiting from, and since the count can't be negative, the count is correct at that point. When a transition across a block boundary is detected, the detector module sends a count up signal to the block the thing is going into, and sends a count down signal to the block that the thing came out of. Because of this, the system keeps track of all transitions into and out of a block.

The system also has memory so that block status is maintained across power cycles. That's needed because the inherent design of the system needs a transition to detect an object. Without memory, the system would lose track of what's in the blocks when power was shut off, and wouldn't know where anything was until the objects moved across a block boundary.

PLEASE READ THE DOCUMENTATION! It details all these operations and circumstances, and how the system works. Also, the code is relatively easy to follow along, even if the state machine is complex.
 
Last edited by a moderator:
If you look at all the videos (10 short videos) you'll see how it works in detail.....the newer videos are better, but watch them all for a thorough explanation and examples of how it functions.
 
Time will tell if it can work in the real world.

One or two dropped counts or extra count and the occupancy state could become invalid.
I would think that setting a user-variable that 'forgives' a few dropped or false added counts would be a simple fix in firmware.
 
I would think that setting a user-variable that 'forgives' a few dropped or false added counts would be a simple fix in firmware.


You're not understanding how the system works......there are NO interfaces to allow adjusting parameters. Adding anything like that would require engineering a relatively expensive interface to each counter module. Do you really want to have to periodically connect to the counter modules to adjust a count? How would you know how much to adjust a count? It'd be easier to simply clear the block count once the block is empty. I don't care exactly how many things are in a block, just it the count is 0 or not. The only interface (besides the simple signaling) is an output that says OCCUPIED. If there are more cars in a block than expected (adding cars to a train without detection), simply moving the cars out of the block corrects the count. If there are less cars in the block, once the block is empty, a simple reset of the block count resolves that.....no user controlled adjustment to a count is needed.

The accuracy of the system rarely results in an incorrect count.
 



Back
Top