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. 
