Hi Resolution Block Detector (Video #33)

[@averageguy7136]

I embedded IR photodiodes in between the tracks and have good lighting shining from above the layout. When the train rolls over the sensor it blocks the IR light from above and thus indicates the block is occupied. This is much simpler than using both an IR LED and sensor together.

[@IoTT]

That's cool, a simple solution if your use case allows for it. I would think the approach is somewhat challenging though if you have tunnels, covered hidden yards or if you do day/night cycle simulations.

[@robleathley6024]

You must be clairvoyant! I've just been researching detector circuits for my DCC layout. I've been following your videos for quite some time and really like your signal system videos. I'm trying to come up with something that would work with N-scale using very small RGB LEDs and an 8211 adapter board as per your video. Also trying to 3d print the signal masts. So far still in the experimental stage but I'm getting closer. Was just getting ready to figure out how to detect the trains. Your idea seems very innovative so I'm eager to see your next installment. Love your work!

[@IoTT]

Thanks for the feedback, Rob. I appreciate. Keep in mind, what I show in this video is very experimental, but I think there are situations where this could be a cost effective solution. More research to be done, though. The good news is, a sensor system like this could easily be adapted to the NCE cab bus ;-)

[@brianw8433]

here is a link to 3d printable signals - customizable on thingiverse www.thingiverse.com/thing:4025702

[@IoTT]

Thanks, that's cool. I did not know that link.

[@scentgrasslakerailway]

Hans Tanner is an absolute genius! I only wish I had a modichum of his intelligence.

[@IoTT]

Well, thank you, but of course this is an exaggeration ;-) All I am doing is trying to have fun by combining existing technologies to find new use cases. Glad if this is helpful for some folks ;-)

[@JamesGipeGipe]

Great stream friend happy holidays

[@thomasm1964]

Excellent video - very informative, thank you.. One small quibble: the English word is axle, not axe.Really not a criticism. The day I can present a tutorial in German that is as fluent as your English is the day I run naked three times through Trafalgar Square!

[@gsmjr8502]

Run, Thomas, run !!! I will see you on KZbin doing your run.

[@thomasm1964]

@@gsmjr8502 Ah, I WAS going to do the run ... but we're in permanent lockdown forever now so I can't! Trust me: the lockdown has preserved what remains of your mental health. You would not have been able to unsee what you would otherwise have seen!

[@andrewstewart1159]

Summed up my thoughts exactly!

[@donh8833]

How does it do with black colored trains?

[@IoTT]

I did not particularly test for it, but did not notice any difference for various rolling stock. I tend to think the usually used plastic material is reflective enough even in black color (steam engine shells typically are not made from carbon... ).

[@davidrichie9570]

Wow! Is there a version of this product that can talk directly to Loconet, without all the JMRI and Arduino stuff in the middle and all the programming? In other words, something analogous to a BDL168, that can send signals directly to Loconet, which then can be interpreted by Loco and Co Train Controller software?

[@IoTT]

Yes, the software that you can download from the Github page has the LocoNet access in it. For this video, I simply decided not to use the hardware interface and send the LocoNet messages wireless via MQTT. But that is just a matter of adding the LocoNet interface and configuring it. See videos 31 and 32 for more information.

[@davidrichie9570]

IoTT Vielen Dank!

[@brianw8433]

excellent video and topic. I have the ir sensors on my dcc layout - they lie between the sleepers. Some cars trigger better than others - some locos need a small piece of white tape to trigger. In any case I use a debounce of 5 secs to stop the associated signals and crossings from bouncing. I have been thinking about a better solution that does not require ripping out track and rewiring. following closely - enjoy all of your content. :) happy holidays

[@IoTT]

Thanks for your feedback. I agree, reliability is a little bit an issue with reflection sensors. And the search for alternatives is definitively a good thing. I think with recent developments in sensor technologies and AI (e.g. image recognition) there will be completely new ways available to not only do block detection but also train identification. We will see.

[@AndreasSpiess]

Another guy with a Swiss accent! Good channel. Did you check the VL53L1X? It has double the range ( maybe helps with the small trains)

[@IoTT]

Thank you, Andreas. Even after living abroad for more than 20 years I find it hard to hide my Zueri-Schnurre! So, as you did, I make it part of the brand ;-) And saying that your channel has not been an inspiration for IoTT would be a lie for sure, so thanks for your work. I am aware of the VL53L1X and reference it towards the end of the video as future activity, so we will see. Even more important than the longer range is the fact that the viewing angle can be limited by selecting the size and location of the active reception area on the chip. That makes it really interesting.

[@jurigelato4366]

Will it work on parallel tracks as well? I ask because the beam is a cone and at some distance a train running on parallel track might be detected at some distance.

[@IoTT]

I tried it with both, N-scale and G-scale, and in both cases I was running out of the reliable distance before I got a signal from the neighboring track. So, yes, it works on parallel tracks. And while testing, I also noted the width and height of the detection area are not the same, so sensor orientation is important. It looks, the receptive area is more an oval then a circle. This is interesting, because the datasheet depicts both cones as round cones. I think the observed oval shape comes from the overlapping of the two circles, but I'm not sure. Overall I think the opening angles of both cones are rather big, so finding ways to narrowing them would be a nice approach. I found one video in KZbin where someone tries to use a lens from a hard drive head to focus the IR beam. It was not successful, but I think it is the wrong approach, anyway (besides that the manufacturer in the datasheet strongly recommends not doing this as the laser all of a sudden might become class 2 and more dangerous). I think it would be better to have an optic in front of the receiver, that reduces the detection angle to say 2 degrees. That way we could 'aim' the receiver parallel to the track and no harm could happen because the emitted beam is unchanged. The VL53L1X seems to do something similar by allowing the user to select a reduced receiver area for detection. That essentially has the effect of narrowing the angle of the reception cone. We will see what that does as soon as I have time to play with it some more.

[@DuncSargentsKarstValleyRR]

You did that really well! --dunc

[@IoTT]

Thank you!

[@stefantrachsler2873]

great idea

[@IoTT]

Thank you, Stefan. Greetings to Switzerland ;-)

[@GeneralThargor]

Technical videos are always better with a German accent, it has inbuilt authority.

[@IoTT]

Swiss accent, in this case. Also adds precision to the game ;-)

[@GeneralThargor]

@@IoTT awfully sorry, I didn't know you were Swiss. Excellent content which I'll be using as a resource as I build my own rail network. Automation and intelligent control are what I want.

[@geoffreymcdermott65]

I admire your disign goals, specifically not having to modify rolling stock to be detectable, but I doubt that this type sensor will be practical. I've implemented block detection that counts things passing a block boundary, and can determine direction, so it can accurately keep track of occupancy. It includes memory for each block, so it remembers occupancy status and how many things (wheels, axles, trucks, etc.) are in a block. The code is reliable, runs on an Arduino NANO, and should cost about $10 per block, but that's for JUST a detection signal, and some simple, local signaling. It also supports one turnout per block, and keeps track of occupancy from all 3 block boundaries. The current status of the project is that I'm trying to build mounts for the sensors that scan across a rail, but my skills are lacking. I have working protypes using sensors that scan across the track, but they're prototypically unacceptable. The new sensors are placed in an extra tie that's added between existing ties. If IOTT is interested, we can colaborate, and the priject is completely OPEN SOURCE. There's some youtube video I did some time ago that explain the system and show it operating on a very small 'layout', but the video production quality is poor. I had installed the system on one block on my club layout, and it ran very well, and reports status at power application. Contact me and we can discuss [e-mail].

[@IoTT]

Thanks for the feedback. From what I see on your videos, you have a nice system, exactly what I describe in my video as event based detection. And compared to many other examples, you have implemented directional counting, which of course is a precondition for successful block control. Well done. Of course I wonder what your new solution for the sensor arrangement looks like. I think that in order to have a reliable count, an optical barrier with interruption is much better then reflection. But making it small is for sure a challenge. One thing I would recommend though is separation of detection and block control in order to make your system work with other systems. I would suggest to just transmit a block occupancy message to the control bus of whatever command control system you want to support. If you do that, standard software or signaling hardware can pick up the information and go from there. And regarding practicality, I don't think there is any type of sensor that fits everything. There are situations where an approach sensor as I did in this video might do the trick, other locations where even your sensor going across the tracks might be the most effective solution, e.g. in a large hidden yard, and in many cases simple current sensors still might be the cheapest option. I think, there is reason for diversity in geometry and technology, but what is important is that those can be combined, hence the common use of the cab control bus for information exchange. Just my thoughts.

[@geoffreymcdermott65]

@@IoTT Thanks for the compliment......I think your work is superb. The current implementation uses 0.040" or 0.060" FO strands for detection, and are at the height of the rail head. I don't really expect detection or signaling IN the yard, just at the block boundaries going to the mainline. I only expect an external signaling system to actually do the work and just react to the detection signal. The simplistic local signaling was implemented because since I decided that a third boundary was required to be practical, and I needed a way to detect that a turnout was thrown against the main, and a local signal provided that. My skills for 3D modeling is poor, so maybe we can colaborate some. Besides the extra tie for the rail sensors, the other end of the FO needs to 'attach' to the detector IC and the IR source LED. Want to help? If you actually had the patience to watch all 10 videos that I did, you deserve a prize......even I think that they're difficult to watch, but do show how it works, and that it does work.

[@IoTT]

I assumed OF strands would be the next method to try. I think this could be the way to go and at one point I have played with those myself. So, it could be interesting to look into it again and a little deeper.

[@58Crood]

I like the idea, but how would you mount these on the layout, so they are hidden? Have you ever experienced half hall magnetic detection as shown here? create.arduino.cc/projecthub/Steve_Massikker/using-ir-hall-type-sensors-for-train-detection-210f53?ref=tag&ref_id=train&offset=2

[@IoTT]

Thanks for the feedback and the link. Hall sensors are a good example for event sensors and it is very easy to hide them under the track. The downside is that every detectable object must be equipped with a magnet and the detection of travel direction is not trivial. Not a problem on a double track with trains only going one direction on the same track. As for hiding the ToF sensor, you're right, that may be difficult depending on the scale and situation. It is no problem to hide it in a G scale bumper, for example, as the sensor itself is only about 10x10mm. For smaller scales, it is difficult, but then there are many situations where optics don't matter, e.g. hidden yards. So, it all depends. I don't think that there is one single sensor type for every situation, therefore I think it is important that all sensors at the end provide a block detection signal that feeds to the cab bus of the command station, in my case LocoNet, but could be NCE cab bus or Lenz xbus or xyz. If so, we deal with standard information that can be picked up by standard software and the providing sensor is less important, hence can be optimized for a given situation, either event detection with counting or level detection and all kind of technologies.