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
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.
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.
Does your system do any of that?
Sheldon
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.
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.
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.
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…
Sheldon
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.
Dave H. Painted side goes up.
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.
So, when an engineer is walking beside his train as he’s operating it, and he determines that a block count is wrong (simply that a block shows occupied when it’s empty) all they need to do is reset that block count. The usual reason for that is that there are less things leaving a block then that came in…from an undetected siding or similar operation, no
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…
Sheldon
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?
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…
Sheldon
The placement of the sensors is absolujtely simple and NOT critical because it uses 2 sensors that are digital, not analog.
I use available Arduino ORO Mini modules which cost in the $2 each range on EBAY. The detector module and the counter module each require an Arduino, so simply put, it requires one of each per block. The modules plug into a ‘shield’ board that simply supplies connections to the outside world and a place for a few LED indicators. The detector module also connects to the sensor module (just 2 sensors) and an IR module (IR LED and a resistor), and that’s it.
I don’t expect anyone to replace their current based system with this unless they have problems with their implementation. The system supplies simplistic red/green signal outputs for entry signals to the block plus also supports one turnout per block. The signal outputs are for simplistic signaling layouts without complex aspects. It also supplies a simple logic level signal to indicate that the block is occupied.
It in no way is a complete signaling system, so don’t try to compare it to a colmplex custom setup on a layout. It’s a block detection system that give simple signaling for free.
Please do NOT think that
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.
Sheldon
I agree that the realistic use of the system should ONLY be for signaling.
I can’t tell you how many times (in pre detection times) where the caboose would partially derail, and would still be part of the train, making the end of the train invisible. I thought that the purpose of detection would be the absolute detection of ALL parts of a train, mimicing the safety required in the real world. Being able to detect every car obviously meets that requirement, and I’m willing to live with an occasional ‘false positive’ concerning detection than a ‘false negative’ by not being able to detect every piece of rolling stock.
Detecting everything that crosses a block boundary and being able to keep track of what block it’s in is just an elegant solution that current detection misses.
Just my $0.02 worth, and why I designed the system as I did. FYI, the original design had light pipes in the rails for the IR source and detection, but the implementation was fragile, expensive and not doable without special tools, so that was not viable.
Well, there is a subset of the hobby that likes fully automated operation (not me). So accurate detection can be critical for their layouts to oeprate properly. An operator controlled DCC layout, if the detector malfunctions and shows a green signal when there clearly is a train in the block ahead, well, you stop. An automated system would just think the block ahead clear and plow right into the train up ahead.
The club I belong to has a modular layout we show at difference venues, where the temperature and humidty can vary greatly. We use current sensing, with current sense transformers, not diode drops, and have not had to adjust it once set. The signal system works quite reliably. The club spec is a single 10K resistor per car, but my feeling is that if a car is left standing across a bloc gap it should eb detected in both blocks, so I outfit my rollign stck with one 10K resistor per truck. This is actually not difficult because a) I use all metal wheelsets and b) I use the same wheelsets for almost every car, only a few need a different type, or already come with metal wheels. So I can build them in batches, one of my parts boxes has a space with resistor wheels, the other non resistor, so as I bild a car I can just grab the wheelsets (pre tested and painted) and install them. After the first couple, when I manage to shoot a SMD resistor from the tweezers, I’m settled back in and the process is almost therapeutic, churning out a few packs of resistor wheels for stock.
Arduinos are cheap. I just ordered a Mega, which has 54 I/O lines (way more than needed for this applciation, but for some of my planned “control nodes” I may get close - 2 pins for the RS485 interface, several servo outputs to move the points, the various signal LEDs for the interlocking, and the associate block detector inputs for the blocks as well as independently sening the interlocking to prevent changing routes under a moving train. I paid $13 for this, and it wasn’t the cheapest one
I may have enough IR parts laying around to mock this up and see how it works. I just can’t see myself using this vs a transformer based current sense system, in part because I agree with Dave in that at least some of the positionign MUST be critical in order to accurately have the same thing to count each time. I don’t deny that it IS an accurate counting system, but to block the beam consistently for various types and styles of rolling stock as well as steam and diesel locos is not a trivial issue. No, it does not really matter if it counts wheels, trucks, skirts, ladders - as long as it does so CONSISTENTLY - that is the key to the idea of comparing count in to count out being able to accurately determine block occupancy. I also have all my currently ready to go rolling stock equipped with resistor wheels and the only dummy loco I have actually has a sound decoder in it (with a BIG speaker) so even it detects with the current sensors.
–Randy
Well, with the quadrature design, it is basically immune to small, trivial edges normally associated with analog detection that would require a more precise positioning of the ‘beam’. For lack of a better term, it’s far from a beam, and more like a flashlight.
Not having actually experienced how the system works, I understand your reluctance, but my experience says otherwise. The system ignores small interruptions in the beam because the logic of quadrature requires a state where BOTH of the detectors be covered at some point in the detection cycle, and the distance between the detector ‘lenses’ is about 1/4". So, anything less than that cannot be detected, and the system is essentially immune to the things that normally would cause inaccurate detection.
The things that usually cause an inconsistent detection are nullified by the quadrature detection logic. Accuracy IS consistency…
I’ve been thinking about some optical detectors to help me park trains on hidden staging tracks without fouling the switches.
And for hidden staging, point detectors are a great choice. But if you think about it, that is the same reverse signaling I talked about before, letting an operator or dispatcher know where the train is.
Sheldon
It’s really starting to make me mad with the responses I’ve gotten in general about this topic… It’s all the same, “I think it won’t work…” or “My system is better because I set it up and it works for me…” or “I prefer another system because yours is too different…” or something similar. I want constructive criticism, but until YOU have actually tried it, other criticism is almost completely unfounded because YOU HAVE NO DIRECT EXPERIENCE WITH MY DESIGN. At least on other forums they at least accepted that it might work, and criticism was just feature and operations related, not know-it-all CRAP about something that most who responded know little to nothing about. I’m giving up with this forum as a way to present anything new…only a few actually had the common courtesy to look at the other presentations before making comments.
I think your system will work just fine. But me personally, I have no interest in conducting the testing for you. The one problem it solves is not a problem for me, but that aside, I’m simply not one in favor of change just for change sake.
Seven or eight years ago I spend a lot of time on here explaining how my advanced cab control system works. Some were interested, lots of others gave me a hard time. Some of the DCC crowd back then were like religious fanatics, actually telling me not to talk about better DC systems as it would hurt the “conversion” to DCC.
And because I was honest when asked, and explained to a moderator that I had no plans to “sell” working systems, but was considering writing a “how to” book, pages of technical info was deleated. I did write the book, I purposely never published it.
I still explain the system, or parts of it, when asked, if I have time, or if it seems related to the topic of a post - like this one.
Honestly
crusader27529:
I can understand why you feel the way you do.
Personally, Arduino intrigues me and any potential application is worth studying. For what it’s worth, I support your endeavours.
Dave
crusader:
I sent you a PM.
Dave