MTH RealTrax ITAD 40-1028 for Detection & RFID for IDENTIFICATION

Thank you for the recognition, it's much appreciated.   But, you really want Stan2004, GRJ, PLCProf or some of the others that are much more knowledgeable than I am. I use GRJ's isolated rail relay devices (don't even have any Itads), that he developed in another thread here and I believe Stan had some input as well as possibly some others here. I'm just a follower trying to learn and user of the end products.

RayL posted:

...

That's only part of it -- I have 2 of the 40-1028 ITADs that I can't get to activate unless I cover the window completely.

Regardless of how I adjust the range control, the relay will only 'click' when the window is completely covered.

...

Could the relay "click" be from it de-activating?  If you do an OGR search on "MTH ITAD" you will find threads decrying over-sensitivity to ambient light.  So if you are testing this on a bench with a desk lamp nearby or near a window during the day, ambient light can activate the ITAD...and only when you block the sensor window does it de-activate.  This would explain the backwards behavior.  If this applies, as you can read about in more detail in the other threads, some ideas include re-positioning (not always practical with the lock-on design) or fabricating a shade/awning or similar shielding to give the sensor what amounts to tunnel-vision.

I have not seen the guts of the MTH ITAD, but for similar devices like the Lionel 153IR, the range control knob only adjusts the brightness of the transmitted IR beam.  This IR beam bounces off the passing train back to the IR sensor which activates the relay.  So if it is indeed ambient extraneous light activating the ITAD, messing with the range/sensitivity control is ineffective which can be confusing.

Of course you may simply have defective units.  If this is the case and out-of-warranty, are you considering DIY troubleshooting/repair?  I will assist if you can post photos and are handy with a meter and soldering iron.  Or if you are just going to toss them, consider sending one to me as I've been curious to see the MTH ITAD design and I can post a teardown report here for future reference.  Previous threads have given confusing/conflicting statements on the functioning and wiring of the MTH ITAD.  Here's a teardown I did for the 153IR which another member sent me.

Stan;

Thanks for your reply.

I'm going to do some more investigating regarding the sensitivity to ambient light.

However, you didn't respond to my remarks about the 'delay' function and just exactly what is being delayed.

I check things out very carefully and get back to you.

And Yes, I may give you one of these ITADs -- I found a MUCH better product called the "MRD1-V" from AZATRAX.COM.

What I'm actually pursuing is the use of these 'train detectors' to feed micro controllers like the Arduino nano in order to control things. My first project is to sense when a train is approaching a crossing from either East or West and then close the gates and send a command to the engine to blow the horn with the crossing signal. I have a program running in an Arduino Uno that uses a radio to send commands to the engine through the TIU just like the MTH Handheld controller does.

I'll let you know how my investigation of the MTH RealTrax ITAD (40-1028) goes.

The MTH ScaleTrax ITAD (45-1028) is a much nicer product.

Ray

The delay function operates as you would think; that is, it keeps the relay closed for some adjustable time after the train clears the sensor.  I looked at your Azatrax description and it would be what they call the "Continuous Mode".

I did not explicitly mention it because if ambient light is triggering your sensor, the delay setting would appear to operate backwards too. The relay would click some variable delay AFTER you blocked the sensor window.   So the delay would appear to be a delay-before-trigger rather than the expected delay-after-trigger.

Of course what's nice about the MTH and Lionel products is they are packaged whilst the Azatrax modules appear to be "loose" LEDs and photo-sensors that you must mount and disguise.  If you are using an Arduino it could easily handle the delay/drop-out timing.  And if you don't mind the "loose" transmitter and receiver components, why not use a $1 (and up) eBay IR transmit-receive module rather than the $20 Azatrax module?  If using an Arduino, you have 5V DC available which is what these eBay modules use.  And if you are using the transmissive mode (breaking a beam across the track), you can just buy loose IR LED and IR phototransistors for, say, 25 cents for a pair.  I've written about these techniques in several OGR threads which I can dig up if this is of interest.

Stan;

Thanks very much for all your replies. I can see that you and I are going to be conversing on these and other technical matters over time.

First, let me say that pretty much everything I said about the ITADs I was tinkering with is WRONG. You were correct about the issue of ambient light being a problem. I just got done testing all 3 of my RealTrax ITADs and they all work. I also tested the ScalTrax ITAD and it works as well. The delay is just as you described it -- how long to wait until relay dropout after the train is no longer sensed.

On the matter of the eBay IR tx/rx pairs, I may take a look at them -- thanks for mentioning it.

Ray

RayL posted:

... I can see that you and I are going to be conversing on these and other technical matters over time.

Let the games begin! 

Stan2004;

I don't have the subscription level that allows me to simply send you a direct post, so I have to resort to 'replying' to a previous post even though it might not be directly related to what I wish to talk about at this time -- it's actually somewhat related.

I have everything I need in the way of IR detection so I'm able to detect when one of my 3 engines is at some particular point on the layout, so I can then take some action.

Here is my 'real' problem: Can you think of some way (with 'reasonable' cost) that I can detect the particular engine that has come into 'view' of the area of the layout that is of current interest?

To say it another way: How could I tell that my GG1 is the engine I'm detecting as opposed to one of the other engines like the GP9 or the 2-8-0 steamer?

Some of the ways that exist are to process an image of the engine taken in real-time, RFID, etc.

I was hoping to not have to install any active circuit on the train (only passive circuits) and thereby provide all active circuitry somewhere on the layout nearby the point of detection if necessary.

The idea of using a camera to take a picture (JPEG file) and then process it to identify the engine seems like it might be considerable work (probably have to use OpenCV library) and I don't know if the horsepower I'd need would be there in an Arduino or Raspberry Pi micro controller.

On the other hand, RFID appears to be promising except I have to use a very small RFID tag with a very small antenna and that means the RFID reader must be very close to the tag in order to sense the tags response.

Currently, I'm considering the PN532 NFC/RFID Controller Shield for Arduino from Adafruit.

It can be used with a plastic 'nail' tag which is about 7 mm dia. and 4 mm thick.

If I could place the 'nail' tag (head only) somewhere on each engine without it looking to weird,

then I could put the reader along the tracks so it would be with 2-3 inches of the tag as the train went by. This approach might work?

I can't think of any other way to sense which particular engine has passed the detector.

If you have any ideas, I'd like to hear them.

Ray

stan2004 posted:

RayL posted:

... I can see that you and I are going to be conversing on these and other technical matters over time.

Let the games begin! 

 

As I said, I've posted extensively on the topic of IR occupancy sensing though mostly from a DIY, roll-your-own approach.  I am still very much interested in peeking inside the MTH ITAD to better answer recurring questions on how it should be hooked up to [fill-in-the-blank].

 

If you are going the Arduino approach with discrete IR LEDs and IR phototransistors, this can dramatically drop out-of-pocket cost vs. using ITADs or modules from Azatrax and the like.

 

As shown above, an LED-phototransistor pair is about 25 cents.  Each would need a resistor to connect to a 5V Arduino input/output pin.  Note in the 2nd example eBay has a board module with the resistors on it for a bit more.  Additional modules shown have the transmitter-receiver pair with additional electronics with features such as a trimpot to adjust the LED current (much like the Range adjustment on an ITAD).

 

As you have witnessed first-hand, there can be issues with ambient Infrared energy masquerading as a reflection from a passing train.  More sophisticated ITAD devices (such as the Lionel 153IR) pulse the IR LED at some frequency (in the kHz or thousands of times per sec)...and then have the receiver "tuned" to look for IR reflections at this magic frequency.  Since ambient light would not be pulsing at this magic frequency, ITADs using this method generally perform better.  There are even eBay modules that incorporate these so-called modulated IR LEDs and matching detectors.

 

Above is from an earlier thread so prices/availability are questionable but at least give you an idea of what's out there.  If you are a hard-core programmer, you can write code to do the LED pulsing (on the transmit side) and frequency detection (on the receive side); this allows you to use the naked components shown earlier.  What the above modules do is simply let you send a simple "ON" command to start the modulation, and returns a simple "ON/OFF" digital signal indicating detection of the modulated reflection.

 

 

 

stan2004 posted:

RayL posted:

...

That's only part of it -- I have 2 of the 40-1028 ITADs that I can't get to activate unless I cover the window completely.

Regardless of how I adjust the range control, the relay will only 'click' when the window is completely covered.

...

Could the relay "click" be from it de-activating?  If you do an OGR search on "MTH ITAD" you will find threads decrying over-sensitivity to ambient light.  So if you are testing this on a bench with a desk lamp nearby or near a window during the day, ambient light can activate the ITAD...and only when you block the sensor window does it de-activate.  This would explain the backwards behavior.  If this applies, as you can read about in more detail in the other threads, some ideas include re-positioning (not always practical with the lock-on design) or fabricating a shade/awning or similar shielding to give the sensor what amounts to tunnel-vision.

I have not seen the guts of the MTH ITAD, but for similar devices like the Lionel 153IR, the range control knob only adjusts the brightness of the transmitted IR beam.  This IR beam bounces off the passing train back to the IR sensor which activates the relay.  So if it is indeed ambient extraneous light activating the ITAD, messing with the range/sensitivity control is ineffective which can be confusing.

Of course you may simply have defective units.  If this is the case and out-of-warranty, are you considering DIY troubleshooting/repair?  I will assist if you can post photos and are handy with a meter and soldering iron.  Or if you are just going to toss them, consider sending one to me as I've been curious to see the MTH ITAD design and I can post a teardown report here for future reference.  Previous threads have given confusing/conflicting statements on the functioning and wiring of the MTH ITAD.  Here's a teardown I did for the 153IR which another member sent me.

 

 

"Or if you are just going to toss them, consider sending one to me as I've been curious to see the MTH ITAD design and I can post a teardown report here for future reference."

Stan2004; If you want one of the MTH ITADs, I'll need an address to mail it to. I'll send you the RealTrax 40-1028. It does work! I'll look for your 'teardown' report.

Ray

RayL posted:

Stan;

And Yes, I may give you one of these ITADs -- I found a MUCH better product called the "MRD1-V" from AZATRAX.COM.

Ray

I have the Aztrax detectors.  Work like a champ with incandescent or LED lamps shining down on my layout, reliably trigger first time every time.  Granted I could go the computer route, but by the time I am done buying the board(s), the software, the programmer, getting my PC to talk to programmer, learning the language, saying words my mother would soap my mouth, the Aztrax was the quick and simple way to go.

Different strokes different folks.

RayL posted:

Stan2004; If you want one of the MTH ITADs, I'll need an address to mail it to. I'll send you the RealTrax 40-1028. It does work! I'll look for your 'teardown' report.

Mailing address just sent to your OGR email address.  Check your junk mail inbox

RRMAN;

I really like the AZATRAX products. They actually work!

However, there is ALWAYS something I want to do that is way too hard if not nearly impossible without a micro controller. So I have several Arduino and Raspberry Pi micros in my tool box and I also have controllers from Microchip Tech. (the "PIC" line).

If I wanted to, I could make my own and I'd do it if I needed something that wasn't out there on a shelf to buy.

Right now, I'm trying to decide how to detect a particular engine.

Gunrunnerjohn pointed me in the direction of Lionel's Sensor Track -- I'm currently looking into it.

Ray

As for your application for model train ID...

As a general comment, I think you're on the right track to ride on to the coat-tails of an existing hi-volume/consumer NFC technology especially if you can get a shield and raid already existing code.  Nothing profound here.

I'm NOT speaking from experience but IMO the problem with NFC technology specific to O-gauge would be parallel tracks.  That is, if you are using RF to detect objects within, say, a 6 inch range, what happens if the device of interest is running a few inches away on the neighboring track rather than the one you're interested in?  To be sure there are RF shielding techniques to "focus" RF energy...but it's not obvious to me you won't pull out all your hair messing with this!

I'd say the closest off-the-shelf "system" for model train ID is Lionel LCS which localizes to a specific track but it's not passive and not inexpensive.  I think think it's a non-starter for a DIY project if ID is the application.  There have been numerous schemes to print bar-code labels (passive) and optically scan passing devices. This of course gives you localized, per-track,, recognition which I think is a requirement.  So again it comes down to exactly what you are trying to accomplish.  An optical reader can detect whether the bar-code is being read forward or reverse to decode direction...and even sense speed.  Then you can argue multiple NFC detectors can do the same with a dab of software.

I guess I'm saying it comes down to exactly what you are trying to accomplish.  What's a must-have vs. a nice-to-have?  How fat is your wallet?   The same-old same-old engineering/cost tradeoffs.  As they say, good, cheap, fast...choose 2!

I realize this is a somewhat wishy-washy response - but worthy of further discussion.

If you need a foolproof method of train detection, I would suggest that you consider magnetic reed switches placed trackside with small magnets mounted on the trains. I have used every format of train detection on my layout and this is the most reliable.

Bob Walker;

Thanks for the response. I think you may have not picked up on the real problem. It's not object detection I'm trying to accomplish, but I'm trying to detect a specific object. i.e. I want to tell if the engine I just detected is my GG1 or my GP9, or some other engine.

Ray

stan2004 posted:

As for your application for model train ID...

As a general comment, I think you're on the right track to ride on to the coat-tails of an existing hi-volume/consumer NFC technology especially if you can get a shield and raid already existing code.  Nothing profound here.

I'm NOT speaking from experience but IMO the problem with NFC technology specific to O-gauge would be parallel tracks.  That is, if you are using RF to detect objects within, say, a 6 inch range, what happens if the device of interest is running a few inches away on the neighboring track rather than the one you're interested in?  To be sure there are RF shielding techniques to "focus" RF energy...but it's not obvious to me you won't pull out all your hair messing with this!

I'd say the closest off-the-shelf "system" for model train ID is Lionel LCS which localizes to a specific track but it's not passive and not inexpensive.  I think think it's a non-starter for a DIY project if ID is the application.  There have been numerous schemes to print bar-code labels (passive) and optically scan passing devices. This of course gives you localized, per-track,, recognition which I think is a requirement.  So again it comes down to exactly what you are trying to accomplish.  An optical reader can detect whether the bar-code is being read forward or reverse to decode direction...and even sense speed.  Then you can argue multiple NFC detectors can do the same with a dab of software.

I guess I'm saying it comes down to exactly what you are trying to accomplish.  What's a must-have vs. a nice-to-have?  How fat is your wallet?   The same-old same-old engineering/cost tradeoffs.  As they say, good, cheap, fast...choose 2!

I realize this is a somewhat wishy-washy response - but worthy of further discussion.

Stan;

You're correct in your analysis (all of it!). I don't have the issue with parallel tracks (and am not currently expecting to).

I checked out Lionel's ICS and again you're correct about cost. It's not the cost of the LCS gadgets that bothers me -- it's the cost of replacing my MTH PS2/3 engines with Lionel LCS engines!

Gunrunnerjohn pointed out that the sensor track could be adapted to other track (presumably MTH RealTrax) and if one does not have LCS equipped engines, then pull a Lionel LCS equipped boxcar.

I don't know if there is any alternative to the boxcar but I wouldn't want to put a boxcar on my PRR passenger train -- it would look funny.

I suppose one could take the guts of the Lionel LCS boxcar and insert them into some other car (for my PRR passenger train, it would have to be one of the Madison cars).

There are 2 alternative RFID solutions I may pursue;

1. a really small RFID antenna (Micro NFC/RFID Transponder - NTAG203 13.56MHz) from Adafruit in New York.

2. another antenna solution from Adafruit is the 13.56MHz RFID/NFC Plastic Nail

Each of these could be read with the Adafruit PN532 NFC/RFID Controller Shield for Arduino + Extras.

Two antenna solutions -- one reader.

The antenna to reader distance differs between the two. I like #1 but it requires the reader be almost in contact with the antenna.

#2 allows the reader to be 2-4 inches from the antenna -- easier to accomplish on the layout.

I'm also waiting for some technical info in an email replay from a company about Bar Code readers and the sizes of the bar codes.

Right now, without considering Lionel LCS, it looks like Bar Codes and RFID are the possibilities.

I think I've ruled out Computer Vision since it seems to require more processing than I probably have, but I'm not really sure since I don't really understand enough about CV to totally rule it out.

I'm having great difficulty in getting someone to deal specifically with my requirements.

Everyone I've talked to thus far seems to want to approach the CV issue in a completely general way and I'm not convinced that's really necessary.

I'm having a little trouble letting it slide, but I'll probably have to soon.

Ray

Stan;

I did find your response with the address in the junk pile, but I somehow managed to lose it.

Can you re-send so I'll have it for tomorrow morning.

Ray

Ray, a suggestion that might elicit more response would be to start a new thread not using MTH ITAD in title...or since you started this thread to modify its title with keywords like RF ID or whatever.  That is, I think you confirmed your occupancy detection application has been resolved (for now that is!) and we're now talking about identification.

As I muse about it, it might be useful to separate the occupancy issue from the identification issue.  While one might imagine using a common technology, I think it depends on what you need the ID info for?  Obviously if you only tag the engine you can't use it for occupancy detection to close crossing gates or whatever.  Even if you tagged every piece of rolling stock if your detection range is just a few inches, a long freight or passenger car or just about any engine would require multiple tags or else a stopped consist would not be detectable.

When you first posted about detecting the GG1 vs. another engine, I took the very narrow interpretation that you wanted to know if its the GG1 or something else.  To that end I can imagine a limited application where you simply place a 10 cent magnet on the GG1 and a 25 cent reed switch or solid-state Hall sensor on the trackbed.  Then if tomorrow you want the GP9 to be the "featured" engine, then you just move the magnet to the GP9 and now it will trip the detector that causes activates certain layout functions or whatever.  Or if the application is to just have steam-engines trip some action related to, say, a water tower or coal tender accessory, then the magnets would just go on steamers and not on diesels. Etc. Etc.  In other words it gets back to exactly what you are trying to do - not telling you anything new but wondering if by carefully sorting out the must-haves from nice-to-haves that perhaps there's a simple solution we haven't thought of! 

As for the CV application, my first thought was how on earth are you going to detect the different between different GP9's that only differ by engine number?  Sure, you could write software that first detects it's a GP9 then knows where to look on the cab for the engine number to then run character recognition software but really?!

As for LCS, I think you've ruled it out because its an active system requiring power on the engine side not to mention finding space to install it.  But since you say you're up on "PIC" like technology, it seems you could roll-your-own transponders blasting continuous unique ID patterns out an IR LED pointing at the track.  Using a 6-pin 50 cent SMT PIC with a SMT IR LED on a 1/32" PCB from OSH Park would be just a few bucks each and might be easily mounted under any engine running 2 power wires up into the engine to get 5V DC power. Don't need the fancy LCS track detectors - just use an IR phototransistor and let the Arduino decode the passing bit patterns.  Yes, there's some homework to be done but we're just talking!

Stan;

Got the address -- I'll get the ITAD in the mail in the morning.

I changed the Title for the thread as you suggested and added 2 keywords.

The first thing I should make clear is what I'm trying to do. Right now I'm only concerned about 3 very different engines: GG1, GP9 and 2-8-0 Steamer. I have 4 of the 2-8-0 Steamers but for now I'm ignoring that fact. Therefore, I hope to distinguish between the 3. I have no plans to acquire any more engines.

As for Train detection using IR -- I use 2 separate IR detection mechanisms; 1 to tell me the train is approaching the crossing so I can send a command to the TIU to tell the engine to sound the crossing signal; and the 2nd IR detection mechanism is used to control the crossing gates. Currently, I can handle the gates when the train approaches from either direction. I don't currently have anything setup to tell the engine to sound the crossing signal for the other direction.

I have 1 track and 1 crossing.

If I had the engine number (that's internal to the engine, which the TIU uses to command the engine to do something), I could tell the engine to sound the crossing sound regardless of which of the 3 engines it is that is now approaching the crossing. Right now, all I can do is limit my capability to one particular engine or I could send the command for the crossing signal to all 3 engines.

Sending to all 3 is out.

I have currently put the CV approach to Identification on the back burner. It is doable to distinguish, by engine number, between 2 otherwise identical engines, but it gets a little involved.

So, that leaves me to think about RFID.

However, your comment about the 'roll your own' transponder got me to thinking about it. As I understand it, you are essentially saying I would put a very tiny IR device like a TV remote under each engine but instead of only sending when a button is pushed, as in the case of the TV remote, this 'special' IR transmitter would send continuously and it would be up to the IR detector to make some sense out of what it received. To do that, I think you've suggested the IR stream would be sent to a PIC kind of processor to decode it.

I like it.

I'm going to give it some more thought.

Thanks for the discussion. I'm going to get the Adafruit micro RFID tag and the reader first and see how far I get with that approach.

Ray 

RayL posted:

...

However, your comment about the 'roll your own' transponder got me to thinking about it. As I understand it, you are essentially saying I would put a very tiny IR device like a TV remote under each engine but instead of only sending when a button is pushed, as in the case of the TV remote, this 'special' IR transmitter would send continuously and it would be up to the IR detector to make some sense out of what it received. To do that, I think you've suggested the IR stream would be sent to a PIC kind of processor to decode it.

What I was imagining is as follows.  You'd use a 50 cent PIC in SMT package.  It would be one with the internal oscillator which have about 1% accuracy in the current generation of PICs.  The PIC would be powered by 2 wires that you'd have to "steal" from the engine electronics; I figure this is not hard to do.  One PIC output pin would drive an IR surface-mount LED that continuously sends out a repeating serial byte at 38.4 kB or the fastest baud rate it can handle.  It is a send-only device.  This would be a very small board - less than 1/2" square - and because there are only 5 or so components and simple interconnections you might even be able to manually assemble it without needing to fabricate a PC board.  Total parts cost for the sender $1-2.

The track would have a 25 cent IR phototransistor to pick up the IR bit stream from the engine.  This would directly go to the Arduino which can decode the pattern using its async UART serial function.

This segues nicely into a couple of issues, some overlapping with the RF ID method.

As I understand it, your Arduino talks to the TIU to address a specific engine to activate the grade-crossing whistle/horn.  Does this mean you are already using the Arduino's async UART serial port?  Yes, there are methods to multiplex/share resources to double-dip, but that's another discussion.  This potential resource limitation might also apply to any NFC shield which I'd think would also want to use serial comm.

Then there's the aperture issue.  So an O-gauge engine traveling 100 sMPH is going about 37 inches per second down the track.  Yeah, who runs their engines at 100 sMPH through a grade crossing but need some parameter from which to do-the-math. So if an IR beam is pulsing downward from the bottom of the engine with an IR detector looking upward from the track, there will be a finite time over which the beam will be detected.  Let's just say this is a 1" lateral/horizontal distance.  That means the aperture at 100 sMPH is somewhat tiny 0.027 seconds.  Fortunately, you can send about 100 byte packets using 38.4 kB async in that time - but the point being you need deal with issues like resetting the serial port from corrupted/incomplete serial packets on the Arduino.  Error-handling using generic library software can be very lethargic.

RayL posted:

...

Thanks for the discussion. I'm going to get the Adafruit micro RFID tag and the reader first and see how far I get with that approach.

I'm not up on the latest technology here, but one issue from day 1 with passive readers is how long it takes to "power up" the passive tags.  So like the "active" optical method above, say the engine is zooming by at 100 sMPH.  If your NFC reader range is, say, 3", then you have less than 1/10th a second to transfer enough 13.56 MHz energy into the receiver to power it up, and have it send its identification data.  Is this aperture large enough?  And like the optical technique if you are already using the Arduino's serial port to talk to the TIU, do you have other Arduino resources to handle, in a timely fashion, the (I'm assuming) serial interface to the NFC reader module?

Anyway, this is all just discussion and the raison d'etre for forums like OGR.

So if the "requirement" is to only distinguish between 3 targets here's my latest scheme which doesn't require the use of a serial Arduino port (again, I'm thinking you might not have sufficient serial comm resources if the Arduino is already communicating serially with the TIU to send engine commands).  To be clear, I acknowledge the NFC method can identify/distinguish between gazillions of different targets.

Sooo.  Let's say you can position 3 magnetic sensors left-to-right or perpendicular to the direction of travel on the track bed between the center-rail and the outer-rail.  In the photo above I show 3 reed switches but these could be 3 Hall sensor chips which are equally small or smaller.  On the bottom of each engine, you mount 1, 2, or 3 tiny Neodymium magnet discs left-to-right centered over the 3 track-bed sensors.  So when an engine passes, either 1, 2, or 3 of the sensors will be triggered and this would identify 1 of 7 possible engines - with 3 "bits" there are 8 possibilities but the 000 case is when there is no engine passing which is the idle state.

So the 3 sensors would simply drive 3 Arduino digital inputs - no serial port required.  The software is arguably simpler.  You simply look to see if 1, 2, or 3 of the inputs are active which tells you an engine is passing over the sensors and of course implicitly tells you the 3-bit address/identity of the passing engine.  Tiny Nd disc magnets are maybe 10 cents.  Reed switches or Hall sensors are maybe 50 cents.

Since the "data" is parallel (vs. serial), the aperture issue is solved by simply using 3 capacitors to peak-detect a triggered sensor to "hold" the data for, say, 1 second to give the Arduino plenty of time to sample the 3 input wires for activity.  That's another 50 cents in parts.

I had considered the same concept except aiming 3 IR LED-detector from track-bed up to the bottom of the engine(s) looking for reflections.  So you'd just print 3 white/black stripe pattern left-to-right on the bottom.  Problem of course is you'd get reflections off of shiny wheel axles and who knows what else so I scrapped the parallel passive optical method.

Clearly this is a one-off alternative with perhaps no other application but at least is inexpensive.  It looks like that Adafruit NFC reader module is $40?  And passive tags are maybe a few bucks each.

Attempting to detect a specific loco is interesting and does not appear trivial. Although RFID would work,  a simpler arrangement which would employ multiple reed relays stacked vertically with a small amount of spacing in the track area of interest might be easier to implement. A magnet could be placed on the locos to align with the corresponding reed relay vertical location. I might just try this out.

Stan; Bob;

I think I'd like to play with the reed switches. What's a good source for the switches and the magnets?

On the issue of the Arduino talking to the TIU -- it's done just like the remote handheld, via a radio.

(SanDiegoMark helped me with the TIU radio connection.)

I don't use the serial port on the Arduino.

Also, I have both the Arduino Nano and the Arduino Pro Mini. I'm considering replacing the Arduino Uno I currently use with the Nano. My Arduino Uno is a 3.3 v version, which means I can connect it directly to the radio which is also 3.3 v. The Nano and Pro Mini are 5 v, so rather than use level shifters, I'll go with the 3.3 v versions of both the Nano and the Pro Mini.

I guess I can order the Adafruit RFID stuff today. I'll play with it and keep everyone posted on the results.

Ray

So here's a teaser. 

3 reed switches are mounted on the track; the yellow stuff is modeling clay to temporarily hold items in place.  On the truck is a holder for 3 Nd tiny disc magnets.  So either 0, 1, 2, or 3 magnets can be installed with idea being this allows identification of up to 7 different devices since there's effectively a 3-bit digital address (000, 001, 010, 011, 100, 101, 110, 111) with 000 being the idle case.  In this case the Nd magnets are 3mm diameter x 1.5mm thick - a few pennies a piece. 

I had these reed switches in my parts stash from DigiKey but I see they are obsolete.  Something like these 50 cent switches are probably equivalent based on a cursory look at the datasheets.

Here's a proof-of-concept:

The video first shows how there's sufficient position "resolution" such that a magnet can trip one-and-only-one reed switch without tripping the adjacent reed switch.  Obviously this is a necessary condition for the scheme to work.  Of course all this is possible with O-gauge dimension because of the ridiculously tiny size of rare-earth, high-power Nd Neodymium magnets.

Without going thru each of the 7 combinations (3-bit addresses), I just show the "101" address to trigger the two outer sensors but NOT triggering the center sensor.  This of course is another necessary condition.

Notice how the LED indicators remain on for a second or so after the train zooms by the sensors.  This gets back to my previous comments about aperture time.  Reed switches can respond incredible quickly (less than a thousandth of a second!) but if the electronics is not looking during that time, it will miss the event.  With the addition of a 5 cent capacitor, the triggers can be extended to give whoever is looking more time to get it together.

Again, this is just a proof-of-concept slapped together on a rainy afternoon.  There are many i's to dot and t's to cross.  I was just curious if this would even pass the laugh-test, release magic-smoke, blow up in my face, whatever.  If taking the next step I would change to Hall sensor chips instead of reed switches (smaller, solid-state no-moving-parts, no "fragile" glass housings, etc.).

As already discussed, this method is apples-and-oranges with the NFC method.  OTOH, the engine-side equivalent to the RF tag is less than 10 cents (for up to 3 magnets).  The track-side "interrogator" is less than $2 consisting of 3 magnetic sensors (reed switch or Hall sensor IC chip) and a handful of 5 cent resistors and capacitors.

Stan:

Your video is most convincing. I wasn't sure if the magnetic field would spread laterally and affect the other sensors but this puts that to rest.

I'm also curious as to the use of hall effect sensors. There are linear and latching types and apparently they can be oriented in several different ways. I know they are used for tachometer applications and are very responsive. But I couldn't find anything about operating them side by side as you propose to do.

I thought about the digital encoding technique a few days before you posted your idea on this and like you thought that it might work with reflective tape and photo-transistors. Some folks think alike. I believe your current proposal is well founded and already good enough for engine identification.

I look forward to more on this topic. Nicely done!

stan2004 posted:

So here's a teaser. 

3 reed switches are mounted on the track; the yellow stuff is modeling clay to temporarily hold items in place.  On the truck is a holder for 3 Nd tiny disc magnets.  So either 0, 1, 2, or 3 magnets can be installed with idea being this allows identification of up to 7 different devices since there's effectively a 3-bit digital address (000, 001, 010, 011, 100, 101, 110, 111) with 000 being the idle case.  In this case the Nd magnets are 3mm diameter x 1.5mm thick - a few pennies a piece. 

I had these reed switches in my parts stash from DigiKey but I see they are obsolete.  Something like these 50 cent switches are probably equivalent based on a cursory look at the datasheets.

Here's a proof-of-concept:

The video first shows how there's sufficient position "resolution" such that a magnet can trip one-and-only-one reed switch without tripping the adjacent reed switch.  Obviously this is a necessary condition for the scheme to work.  Of course all this is possible with O-gauge dimension because of the ridiculously tiny size of rare-earth, high-power Nd Neodymium magnets.

Without going thru each of the 7 combinations (3-bit addresses), I just show the "101" address to trigger the two outer sensors but NOT triggering the center sensor.  This of course is another necessary condition.

Notice how the LED indicators remain on for a second or so after the train zooms by the sensors.  This gets back to my previous comments about aperture time.  Reed switches can respond incredible quickly (less than a thousandth of a second!) but if the electronics is not looking during that time, it will miss the event.  With the addition of a 5 cent capacitor, the triggers can be extended to give whoever is looking more time to get it together.

Again, this is just a proof-of-concept slapped together on a rainy afternoon.  There are many i's to dot and t's to cross.  I was just curious if this would even pass the laugh-test, release magic-smoke, blow up in my face, whatever.  If taking the next step I would change to Hall sensor chips instead of reed switches (smaller, solid-state no-moving-parts, no "fragile" glass housings, etc.).

As already discussed, this method is apples-and-oranges with the NFC method.  OTOH, the engine-side equivalent to the RF tag is less than 10 cents (for up to 3 magnets).  The track-side "interrogator" is less than $2 consisting of 3 magnetic sensors (reed switch or Hall sensor IC chip) and a handful of 5 cent resistors and capacitors.

Stan;

I'm going to order the reed switches and the magnets. It looks like a reasonable solution to implement. Just curious -- what is the chip you show in the video?

Ray

That is very cool Stan!  How close did you have to get the magnets to the reed switches?  One concern I have is an old PW car with the shoe clipping the magnet block.

Consolidated Leo posted:

I'm also curious as to the use of hall effect sensors. There are linear and latching types and apparently they can be oriented in several different ways. I know they are used for tachometer applications and are very responsive. But I couldn't find anything about operating them side by side as you propose to do.

RayL posted:

 

 Just curious -- what is the chip you show in the video?

 

It is just a buffer chip to drive the LED.  It's meant to represent a "generic" digital input as you'd have on the Arduino.  That is, it requires low input-current which is how the capacitor works to easily extend the pulse detection time.  The "schematic" if you can even call it that is:

A 100K resistors pulls the input of the digital gate "high" until the reed switch closure drives it low.  The 100K value is a typical value used on digital inputs with some microcontroller chips even having this type of "pullup" built-in to the chip enabled/disabled by software.  Adding a capacitor of about 10uF makes the time-constant about 1 second (R x C = 100K x 10uF = 1 sec) which seemed like a reasonable starting point.

In this application, 3 sensors decode 3-bits in parallel, 1 bit per sensor.

SPST switches are of course 2-pin devices.  So 4 wires run from Arduino or equivalent to the "reader" board in the trackbed.  Ground would be common to all 3 switches, then 1 wire for each switch output.

Hall sensors are typically 3-pin devices.  So 5 wires run from Arduino to "reader" board.  +5V and Ground would be common to all Hall chips, then 1 wire for each Hall sensor output.

If you get beyond the experimental phase and reach implementation, there are details wrt noise, spike, glitch protection that might be worth discussion.  I think you mentioned a 3V Arduino so there may be some 5V vs. 3V level translation issues and what not.

gunrunnerjohn posted:

That is very cool Stan!  How close did you have to get the magnets to the reed switches?  One concern I have is an old PW car with the shoe clipping the magnet block.

The face of the disc magnet is about 2.5mm from the edge of the reed's glass body.  The disc magnets are essentially flush with the bottom of the acrylic sheet that holds them.  The bottom of the acrylic sheet is about 1mm above the top of the rail(s).  So there's another 1.5mm of clearance from the top of a rail to the top (highest point) of the glass body.

The nice thing about these axial magnets is you can simply stack them to make a stronger magnet.  So two 3mm discs, each 1.5mm thick, snap together to make a 3mm thick disc also of 3mm diameter of course.  Turned out I didn't need to do this.

Of course both magnets and reed switches (and Hall sensors) come in different grades of sensitivity.  But this is a different ball game with Gauss, Tesla, etc. instead of Vots, Amps, etc..  The experiment I showed was with the parts described!

And to your point, I'm sure there are a variety of O gauge anomalies or whatever you want to call them in terms of clearance, spacing, etc..  Then there's different variants of steel rails and how that might affect magnetic fields.  Another would be is Magne-traction...I wonder what kind of havoc that might wreak on trackbed magnetic sensors?

Magna-Traction, another wild card I totally forgot!

For all those interested in the use of RFID for train identification, here is the latest info I have:

I took delivery (from Adafruit) of the RFID/NFC PN532 Arduino shield as well as some tags.

The Adafruit stuff is more expensive than equivalent stuff from other suppliers (if anyone is interested, see me).

It all works very well. I have no interest in writing to the tags so all I use is the 'built-in' UID (either 4 or 7 bytes).

The tag I like best is the Micro NFC/RFID tag (6 mm x 16 mm). The drawback to this small tag is the short distance the tag has to be from the reader (about 1 inch). I'm currently working on determining if I can place the tag and the reader on the engine and layout so I can reliably read each time. The tag can easily fit under the engines I have and that leaves me with exploring the possibility of placing the reader under a 10 " piece of RealTrax.

The other tags (one of which is a 25 mm diameter plastic disk) can be read up to 3-4 inches from the reader.

With those tags, I could hide the reader somewhere on the layout inside of something like a building perhaps.

One other thing I'm exploring is the replacement of the Arduino UNO with a much smaller micro; the Pro Mini.

As if this wasn't enough, I'll soon be taking delivery of the reed switches and magnets, so I'll explore that approach as well.

Right now, my preference is for the RFID approach, but we'll see.

There is also one more thing I haven't yet figured out but it's no biggie. That is -- what to do when I change an MTH engine # in the DCS environment. I need to communicate that change to the engine identification setup.

I've often wondered about all those folks who don't revel in the sheer joy of technical challenges!

Ray

Sounds good, my preference would be the RFID solution, I think it has more promise.

The latest:

Today, I was able to mount the RFID reader and its host controller (Arduino UNO) under a 10" piece of RealTrax.

I then used the NFC/RFID Mifare Ultralight tag (6x16 mm) and moved it over the track at the height it would be above the track when its attached to the underside of an engine.

I was worried the plastic roadbed and the distance might prevent the reader from recognizing the tag.

It worked!

I have also decided to solve the problem of a DCS engine # change by writing the DCS engine # into the tag that gets mounted to the underside of the engine. Each tag has a little less than 512 bytes to play with.

Whenever an engine undergoes a DCS engine # change (through me changing it for some reason), I'll move the engine over the RFID reader and write the new DCS engine # into the RFID tag on the underside of the engine.

I'm working on 2 parts to this project:

1. Replacing the rather large Arduino UNO with the much smaller Arduino Pro Mini.

2. How to communicate to the program in the RFID reader host controller (an Arduino) to tell it to reprogram the RFID tag with the new DCS engine #.

I'll keep working on it.

I mentioned my progress to the OGRforum member SanDiegoMark and he likes it and is thinking of trying the same approach. He suggested the project might make a good article for one of the popular train magazines.

We'll see.

That's it for now.

Ray

Ray sent me a MTH RealTrax ITAD 40-1028 to mess with.  While I doubt anyone would attempt to repair or modify such an inexpensive item, I nevertheless dis-assembled it for learning - and here's my take on the schematic made by tracing out the double-sided circuit board.  There are missing/unlabeled surface mount capacitor values which I did not measure but not an issue for anyone skilled in the art.  

Internal photos

I do not know if the ScaleTrax ITAD (45-1028) is of the same design, but what I found interesting the low-angle or height of the beam that is meant to bounce off the passing train.  Above photo shows the sensor window and the emitter on the right side and detector on the left side.  You can see the purple-ish glow of the IR emitter (LED) which hits the passing train at just about the top of the wheels for a diesel engine or passenger/freight car.  Yes, the beam does spread out a bit but the reflection surface is not half-way up a boxcar side.  This goes to the comments about painting or modifying the surface for better reflection/detection of dark objects.

The other "mystery" which I've never found documentation is how it connects power to the relay common.  Answer: the right terminal of the AUX POWER INPUT is internally wired to the output relay COMMON terminal.  So this is what is directed toward the output NC terminal (when ITAD not triggered) or to the output NO terminal (when ITAD is triggered).  What this means is (when using AUX POWER) you can choose whether to switch AUX HOT or AUX COMMON thru the relay.  There are some applications where this may come in handy.  You can also use DC to power the ITAD though it needs about 13V DC.

When powered from track power, it is the outer rail that is steered to the NC or NO terminals.

As for operation, this unit is indeed very sensitive to ambient light.  The unit I was evaluating would trigger (without a passing object) with what I consider a moderately lit room irrespective of the RANGE setting.  So consideration must be given to where to locate it relative to windows, overhead lighting, etc.

Stan;

An excellent job of documenting the ITAD -- I'm glad I sent it to you.

I am making very good progress on my RFID approach to Engine Identification.

I decided to write each engine # into the EEPROM on the tag for that particular engine.

When the engine passes over the RFID antenna under the track, the the RFID controller (an Arduino), will retrieve the engine # and then send a command to the Arduino with the radio that I use to send commands to the TIU.

The engine will then sound the crossing signal.

Another decision I recently made was to use a RFID card to contain the 'engine table' for all my engines.

Any time I wish to update the RFID detector with a new engine #, I'll wave the special RFID card over the detector and since the card is a Mifare Classic Card (4 byte UID) the program will know it's supposed to write a new engine # into the RFID tag on the engine it just recognized. The engines use the Mifare Ultralight Card (7 byte UID) and that's how the detector program knows it's supposed to update the current engine RFID tag as opposed to sending a command to sound the crossing sound.

I'll write a small program to allow me to update the special RFID card used for holding the current engine table.

I'm also in the process of replacing all Arduino Uno R3's with Arduino Pro Mini's for control purposes. The Uno is really overkill for what I need it to do for the RFID processing.

Since the RFID board (Adafruit PN532 Breakout board) is 3.3 v, I ordered some 3.3 v versions of the Arduino Pro Mini to get away from logic level shifting.

When I finally get it all working, I'll post some pictures/videos along with any explanation that might be helpful.

Thanks again Stan for your very excellent work!

Ray