Different way to do detection....

crusader27529 Mar 10, 2016

  1. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    1. Why don’t treat each block like an entity with its own boundaries? The adjacent blocks would have common sensors and each block controller will not bother to communicate with the others.

    That would require much more HW, as it would double the number of sensor pairs, and would result in the same end. Also, there'd be a hole in the logic where the detector pairs wouldn't be in sync as the car traversed the boundaries. I was tryng to minimize the the HW and cost of the system.

    I'm in process to redesign the detector part of the system, with the detector and source on the same PCB, and using FO cabling to the rails to detect the transitions. I'm not very far along with the design currently. Besides being easier to hide the source and detectors, mounting in the side of the rails would alleviate the only issue that I've seen in testing on a real layout........ sometimes external parts on steam locos get detected on entry, but not on exit, because the parts are moving, and sometimes are not seen by the detectors. It only causes a false positive, which doesn't cause any real operation problems. Since the detectors can only detect things that cover and then uncover the sensors, the size of the things that can be detected is determined by the placement of the 2 detectors. If the rails mount the detectors, the spacing is dictated by the distance the wheel flanges will cover concurrently, and since the detectors are inboard of the rails, so extraneous detections of parts of a car/loco that are outside the rails can't happen.

    2. I am wondering if the Geoff’s Bunza DAP detector (http://model-railroad-hobbyist.com/node/26133) could be a replacement for the ir sensors. There is no need to be as a standalone circuit but as two ambient light sensors with one reference sensor nearby and the comparison will be done within the Arduino block controller. In this case the controller will count cars. The only problem is if will be enough time for the sensor activation and reading between the car passes.

    Counting cars was a possiblity when I initially started the project, but trying to find a height that was close to a standard, was impossible. The ONLY thing that was consistantly guaranteed to be in a standard place was the wheels/wheelsets.
     
  2. vasilis

    vasilis TrainBoard Member

    110
    39
    10

    Not really more HW. The way of the detecting and counting the enters and exits is the way You do. It can works with IR sensors. I proposed the ambient light sensor because they can hide between the track, count cars and no adjustment needed. I'm sorry, but i haven't much time now so i attempted to roughly sketch my thoughts. Í'm sorry for the quality.
    page1.png page2.png
     
  3. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    Ambient light sensors will not work because they inherently don't have good enough noise immunity. I modulate the source at 38KHZ because there is no known natural sources for IR at that frequency. Plus ambient sensors won't work in hidden/dark areas. The logic of how this all works is based on the premise that during the transition across the sensors the sensors will cover and uncover in sequence. It will only 'detect' transitions of the spacing of the sensors, nothing smaller, because something smaller can't cover both sensors concurrently.

    Counting cars is a possibility, but it would require the source/sensor pairs either to be mounted across the tracks(as it is now but much higher) or above the tracks if the sensors are between the rails. Plus the detection granularity would be a car/loco length, and issues like closely coupled cars or locos may not be detected reliably. Believe me, I considered many possibilities before I went down the design path that I chose.
     
  4. vasilis

    vasilis TrainBoard Member

    110
    39
    10
    The detection with ambient light sensors is based on the differential of light received compared to the reference sensor. From the link (it worths a reading) i placed:
    "This article describes a new design, using ambient light “seen” by the detector in two places – typically between the rails and just to the side of the track. When it notices the track light level fall below the level of the second sensor, it “indicates” the presence of an obstruction (car or loco). The beauty of this “differential” measurement is that it operates over a very wide range of light levels, does not require “aiming” to a target, needs no adjustments, and can be virtually buried in ground covering materials. Oh, …and it works! (I’m always amazed at that!)" And he is right.
    Also a car is longest than the distance between three ties so hides the sensors. My intention was not to change your course, but only share my thoughts like you do. Also i think that the way with the rs485 bus has the advantage of the one arduino per sensor and less wiring as is a two wire bus and no need the special treatment for the "one turnout inside the block" I liked your logic, but has too much wiring and two arduinos per sensor. The kind of sensors is one part of the problem and they can be ir if you like. Anyway, have fun. :)
     
  5. More_Tea

    More_Tea New Member

    4
    0
    1
    Great thread.

    Over the last couple of years I’ve been working on something very similar here in the UK.

    My counting detector uses a pair of Reed switches (A & B) that detect the presence of a magnet at each end of a vehicle.

    Count in or out of adjacent sections is achieved using A-AB-B sequential recognition.

    my board uses a pair of interfaced ATtiny 84s to talk on multiple I2C busses for each section.

    the master detector requests the last count from the other slave detectors and determines the state of the section and sends that information to the other detectors.

    I’m working on having up to 8 detector addresses available for each section with the state of each section available at each detector.
     
  6. More_Tea

    More_Tea New Member

    4
    0
    1
    Great thread.

    mover the last couple of years I’ve been working on something very similar.

    My counting detector uses a pair of Reed switches (A & B) that detect the presence of a magnet at each end of a vehicle.

    Count in or out of adjacent sections is achieved using A-AB-B sequential recognition.

    my board uses a pair of interfaced ATtiny 84s to talk on multiple I2C busses for each section.

    I’m working on having up to 8 detector addresses available for each section with the state of each section available at each detector.
     
  7. BigJake

    BigJake TrainBoard Member

    3,259
    6,173
    70
    I would use one magnet and two reed switch sensors, with overlapping (ideally 50%), but not identical, activation areas. Thus you would only need one magnet per vehicle, and the activation/deactivation order of the two reed switches tells you the direction. With direction information, you can then infer the side of reed switch pair to which the loco moved. And you can also tell if the vehicle stopped over either detector or the pair, and then reversed back off in the opposite direction.

    Think of the two signals from each reed switch pair as a gray-coded, two bit, rollover counter. It should only ever increment/decrement one count per monitored change. If you see a two-count change between readings, you didn't read it fast enough. This is akin to how incremental optical rotary/linear position encoders work, and they are very reliable. That two-bit count can also be used to maintain a larger count of magnet-equipped vehicles in each occupancy zone, if properly initialized at startup.

    You could use 1 magnet-equipped vehicle per train, or 2 (1 @ each end), but if 2, the system would need to be initialized with the train entirely in a given zone at startup, or have a way to tell the system that a train is straddling a reed switch pair.

    And you would only need one pair of reed switches at each boundary between occupancy zones!
     
  8. More_Tea

    More_Tea New Member

    4
    0
    1
    Much like Crusaders system the aim is to detect the passage of things over a sensor pair to determine block occupancy.
    My Reed switches are located as a pair between adjacent sleepers/ties. I have also included a negative count inhibit which will set the section count to 0 if it strays into the negative. I’m also planning on using a reset for if a block is left occupied after a “hand of god” or failure.

    One difference in my process is that the count in and count out operations occur at different points in the transition.

    With both switches inactive the processor is primed to count in.

    when the first switch is activated the direction from which the train has come is registered.

    when both are activated a count in is registered into the block into which the train is traveling. The processor then primed to count out.

    When one of the switches is deactivated the processor registers the direction the train is exiting.

    When both are once again inactive a count out is registered and the processor re primed to count in next.

    If both sensors are activated before a count out is registered the direction is cancelled until it is re determined by only one sensor activated.

    This reduces the risk of miscount at the boundary.

    Having the detectors on a bus allows multiple entrances and exits from any block. So far I am limiting this to 8 to keep the cycle time low.

    Just in case there are multiple counts within a coms cycle, each detector keeps a record of its local count between coms cycles transmitting the sum for the master counter to register.

    Counting by this method also reduces the risk of a count being missed if a pair of detectors register a count at the same time.
     
  9. S t e f a n

    S t e f a n TrainBoard Member

    167
    93
    6
    So what happened to crusader's project? He was building prototypes, wasn't he?
     
  10. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    I re-designed the system to use fiber optic cables (cheap from Asia) in order to make the detector parts fit between the rails, so they ONLY count wheelsets, not anything else. That works well, and I've implemented the connections from the counter to the detectors as RJ45, so cheap, easily made network cabling can be used. This also required minor changes to the PCBs that make up the system. The system also supports up to 4 detector connections to each counter module, so up to 2 turnout connections are supported.

    I have no desire to make a product for the system, and the code has been posted already, and it's well annotated. All the parts at Arduino NANO.
     
  11. More_Tea

    More_Tea New Member

    4
    0
    1
    Hi Crusader

    do you have any pictures of your new wheel detectors. I’ve always thought IR detectors to be too bulky for the smaller scales and as you have previously said susceptible to interference by other objects.

    I’ve gone for reeds and magnets for their small footprint and ease of prototyping.
    They could however be susceptible to activation by trains in adjacent lines when used to create a boundary within a crossover.

    Accurately detecting wheels is certainly the best method of detecting vehicles without modification.
     
  12. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    The original detectors were a 5mm IR source at 38khz and 2 TSSP4038 IR detectors mouinted as close to each other as possible.

    The new system uses all the same components except that the source and detectors are not trackside, but use fiber optical cable simply mounted to detect across the rails. The mounts weren't very good, but worked fine. they consisted of a 3d printed block with a groove in the center nfor the IR sourve and 2 grooves for the detectors. The FO cable just layed into the grooves and were mounted with glue.

    There are 2 types of FO available on EBAY, and the type needed are called 'end glow' meaning that the light doesn't show except at the end.....others let bthe light energy out along the entire lenght, and are used mainly for decoration.
     
  13. olequa

    olequa TrainBoard Member

    15
    7
    18
    Cru:
    I had to actually LOL when I came across your design, originally on the Model Railroader forum. I laughed because I had been working off and on (mostly off) for the last several years on an almost identical system. Last night I decided to do another search to determine the state of the art and found your post. Good for you to be an innovator! I read through all of your posts and saw how you encountered the same issues that I did and how you solved those problems. It was sad to see the attitudes expressed on the MR forum but not really unexpected. Funny how you were originally asking for volunteers to help test, since I was thinking about doing the same. Based on the responses to that on the MR forum I guess I won't try that one.

    I finally got my system to the demonstration stage just this week. I works fabulously, at least on my test track. Like you I count the rolling stock but I strictly count wheels. Thus I am not affected by fuel tanks or other paraphernalia hanging down into the IR beam. My detectors are small, using SMD components, and they are mounted inside but close to a rail with the IR source on the other side, not necessarily close. My detectors are about 3 x 24 mm and stick up above the rail head by 1 mm. Let the howling begin! Track cleaner cars will strike the detectors! The detectors are visible! The detectors will be affected by stray heat sources! etc etc I particularly enjoy hearing the visible argument, made by guys who don't mind seeing 5 scale inch diameter hoses dangling from their oversize Kadee couplers which also have a big ugly spring on the side.

    I originally had planned to make this a standalone system with lights to indicate block occupancy, all controlled by a single Arduino. I also started to incorporate a signal lighting function. But then I became familiar with JMRI and thought "this gives me opportunities". Let them do the work. So my system is now built to provide data to JMRI (and also receive data from JMRI). It now consists of a network connected by a CAN bus (no not that LCB thing). It uses only Nano microcontrollers. One is the master node and the others are the remote nodes. Each remote node has two detectors. In the best case, like a simple oval track plan, one node can provide detection for two blocks. Up to 32 remote nodes can be connected and thus 64 detectors. Each node sends data back to the home node on an adhoc basis. The home node connects to JMRI via a USB to serial connection. More than one of these systems can be connected to JMRI. It is heartwarming to see a JMRI screen show blocks occupied or not in real time using this system!

    But wait, there's more! Since I realized that the Nanos were being underutilized in this scheme, I added turnout activation to them. Now each of them can control 2 servo-driven turnouts each. These are controlled from JMRI, just touch a turnout icon and the turnout moves. Again, heartwarming. I suppose they could run Tortoise machines but I think that would require a little relay to be added.

    But wait, there's still more! The Nanos can detect turnout position as well and send that back to JMRI.

    But wait, order now and we will throw in another function! (Kidding. No product is offered for sale.) Each Nano can provide input to 4 three light signal heads, 128 in all. Again, the data for that comes from JMRI.

    So each of the 32 Nanos reads 2 BOD sensors, 2 turnout sensors, controls 2 turnouts and lights 4 signal heads. I'm thinking of changing the design a little to allow the Nanos to specialize in one of the three functions, namely BOD, turnouts, or signals. After all, some folks may not be interested in BOD or signals at all but still could use turnout control as an example.

    Drawbacks? There are some. I saw that you came across the same issues and addressed them. For one, there is the data retention issue. I determined that I cannot periodically save the axle counts to EEPROM. It takes too long and it doesn't really protect me from a power failure. There is a manual save button that is configured for use just before shutting down if you remember. But that also doesn't protect from a power failure. There is a brownout detection scheme that can be used. but really I think the best solution is to power this system from a UPS and just leave it running.

    There is also the 'hand of God' issue where he comes down from out of nowhere and raptures a car right off the track. Or mysteriously deraptures a car back onto the track in a different spot. This is what I call the zombies and ghosts syndrome. A zombie is a car in a block that the instrumentation says should not be there yet there it is. A ghost is a car that instrumentation says should be there, but you can't see it because it isn't. Zombies are easy to kill. Just physically remove the zombie. Or better, evacuate the block by driving all rolling stock out of it (past a detector). Ghosts are more difficult. They can be driven away by derapturing. I also incorporated a button that clears the count to zero in a ghost infested block. Really though, the rule should be that God is not allowed to rapture or derapture at his convenience. Do it from a special unmonitored siding, or do it carefully and by a rule on a monitored block.

    Of course, even if the data gets scrambled or lost somehow the solution is pretty simple. Run trains for awhile. The system will be good to go after all populated blocks have been evacuated at least once.

    As for the visibility issue the detectors are not very obvious, being so small. At least the emitter part should be disguisable in a trackside bush. Paint stuff to match the ties. Call it a defect detector. Most people won't realize that that is a lie. You can easily fool people.

    As for the track cleaner part, I think the detectors can be made with sloping ends so the pads don't get snagged. I wouldn't use such a cleaning contraption on my railroad but some folks do so have to deal with that issue.

    This system uses all off-the-shelf parts except for the detectors and emitters. Nano clones are less than $4, the CAN adapter is less than $2. I also use a Nano breakout board with screw terminals that are I think about $3 each.

    I built this for my own purposes and will use it for awhile to smoke out any bugs. Maybe I will release to the public at some point. The code is already on GitHub but currently in a private repository. JLCPCB made some detector/emitter parts for me that are exquisite and dirt (I mean dirt) cheap.

    Anyways, thanks for sharing your system with all of us. Good work!

    George
    Edgewood, WA
     
    S t e f a n likes this.
  14. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    When I was trying to resolve the memory issue, I initially would save the current block count periodically. But, I was never satisfied, as there always was a case where the saved count wasn't correct because the time between the count update and losing power was NEVER short enough. I was also concerned about the write cycle limits of the EEPROM on the Arduinos. I absolutely decided that I needed to 'continuously' update the count for the block, but it turned out that all I needed was to update the count as soon as a detection event occurred. Now, writing to any one area on EEPROM would rapidly degrade the part, so I deviced a way to 'walk' through the 2K of EEPROM (in the NANO's case), so no individual memory location was over-used......and it works like a charm. The case where a car was removed from a block manually was resolved with a simple Force Block Clear pushbutton for the rare cases this happened. Adding a car wasn't a problem, because the code never let the count go negative. It was really neat to watch the system in operation where atrain was longer that the block, and the counters were being driven from both ends simultaneously, both up and down as part of the train was leaving the block and part of the train was entering the block at the same time.

    I see all these efforts to detect for trains using magnets and reed switches or simplistic IR detection, and from the descriptions, they don't seem to grasp that the detection included a direction component, and it's at the wheel level. Using detection with detectors with such poor granularity would yield very poor results because what is being measured is too non-uniform and too large. They also don't grasp the simple fact that each detector is communicating to BOTH counters at the boundary of each block.

    I'm really interested in your detectors, as I decided to use FO just because of the size. I also had a version with the detectors and counter all on the same PCB, but the length of the FO cables that worked well didn't meet my minimum requirements. I'd love for you to let me see/use you detectors, as I'd prefer them over FO. The code I wrote was based on Free RTOS, with some significant advanced techniques to get a context switch between tasks down to 150usec insteact of the standard 'tick' rate of 15msec. And eventually, the code didn't need RTOS at all, and was based on multiple state machines that overlapped. That was a PITA to troubleshoot, but it was based on three fully functional state machines, so it was possible to do. The problems I had weren't unsurmouintable, but I've been doing this stuff for 40 years.
     
    Last edited: Feb 25, 2021
  15. olequa

    olequa TrainBoard Member

    15
    7
    18
    I'll get you some pictures in about a week as I need to get my DSLR back to get some quality close up photos. I had JLCPCB build my prototype pcbs but they could not cut them to size with their equipment. That is my one remaining hurdle, namely how to cut these very small boards out of the larger assembly that I will be receiving from this or another supplier. As I have no experience with this I'm fumbling with it at the moment.
    As far as saving the counts goes I don't have the luxury of continuously saving since one node on the network handles the counts for 64 detectors. So I have reached the conclusion that power failures are not allowed to happen ☹️. Or that they can be ignored since the utility related ones don't happen often and even if they do occur it's not the end of the world.
     
  16. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    What's different about your detector design? I use TSSP4038 sensors that use a 38KHZ reference, and reject anything else. There are MANY similar sensors, but they're not designed to be receiving signals continuously, and AAMOF, they treat receipt of a continuous signal as en error condition. How do you use whatever part you use? Did you design your own sensor instead of using an off the shelf part?
     
  17. Kitbash

    Kitbash TrainBoard Supporter

    2,089
    5,586
    73
    Very interesting. I like the concept. I've invested in current detection for my signaling. Investing in resistive wheels sets to place on several random cars and all cabooses. Plus, I've done the isolation (separation) of a hot wire after it passes through the current CT. I like what is proposed here.
     
  18. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11
    It's more than a proposal....it's real, and in my case, I've had it functional for 5 years........unfortunately, I was not happy that the IR components were relatively large, and positioned across the track. I do all this in my spare time, with minimal funds and even less equipment for troubleshooting the design as I develop things.

    My current design uses a FO strand to connect to the IR source and detectors. Because of multiple projects, I'm not quite ready to pull the trigger on a new design of the PCBs. When the 3 other projects that I'm engineering are ready (hopefully in a few months), I'll order PCBs for all them at the same time, then, I'll install the setup on my club layout.

    Have you seen the YouTube videos I did? Production wise, they're nothing to rave about, but stick around through them all to understand and see it functioning.
     
  19. Sumner

    Sumner TrainBoard Member

    2,798
    5,837
    63
    I guess I missed the link, could you post it again? Thanks,

    Sumner
     
  20. crusader27529

    crusader27529 TrainBoard Member

    247
    167
    11

Share This Page