More and more model railroaders are becoming interested in using RFID techniques on their railroads, typically to identify rolling stock. The RFID4MRR Yahoo group contains ongoing work on this.
Must be extensible to multiple kinds of RFID tags, including ones with large amounts of information. Implementation must not require a specific kind of reader.
Must allow more than one RFID reader on a node.
Efficient protocol for multiple consumers of RFID information.
Some way of keying standard consumers that an RFID read has occurred, so they can e.g. show a light or trigger some other process.
More than one reader on the layout implies that location information is needed with the results of the read. Messages contain their source node, but that's not the entire identification of their source reader.
Uses global event to advertise that a node will be providing information from one or more RFID units.
Use a node-specific event to indicate that a reader has read information. One such event per attached reader. Interested consumers could then act, either on that or by doing a datagram read for the RFID information itself.
Need to signal failed reads?
Provide a way to register to receive datagrams of RFID information when reads occur.
Notes from an email discussion in November 2009 about use of RFID tags with OpenLCB.
My next question is about RFID tags, the 64 bit tags have 40 bits of data. The EM4102 spec seems to have a 32 bit global unique number plus an 8 bit version/user code. So it seems that a minimum size for an event would be 6 byte NID + 4 bytes of tag. (Pity the NID was not 4 bytes, so it could all fit in one packet as an 8 byte event).
I'm thinking that it would be nice if the RFID tag event could be used like any other event to select a route for a train or turn on an LED.
But, an RFID reader can only send the tag, with the NIDa in the header needing to be translated to a full NID by a consumer. Perhaps translating an RFID tag event to a normal event needs to be done by a larger node or PC. Have RFID tags been considered ?
Well, we could allocate a unique Event# range to EM4102 tags, by
assigning the top three bytes a unique number, and leaving the bottom
5-bytes for the EM4102 40-bit GUID. Then the event# derived from each
tag would be guaranteed to be globally unique within OpenLCB. Even
better, if we only need 32-bits from the
tag-GUID.
[ Event#s are required to be globally unique. Constructing an
Event# from a (globally unique) NID is only one way to ensure global
uniqueness. ]
I expect other tags will need other prefix bytes
to make them unique. (We may not be able to support a large number of
different tags.)
Using a tag-id as an event is useful for the blue/gold programming, too, as a tag could be directly associated with some consumer actions.
There's a brief mention of them in the Datagram doc: <http://openlcb.sourceforge.net/trunk/documents/DatagramProtocol.html>
The idea there was that they'd be sending information from a point to a point, e.g. reporting to a central yard processor as a train arrives, so a datagram was fine.
If one wants to put both tag and location in a single 8 byte event, you certainly can, you just can't use the node ID to do it. So how to allocate the 64-40 or 64-32 other bits?
Since the source NodeID is carried _separately_ from the EventID in every produced-event message, one approach would be to define a unique upper 24 or 32 bits for "RFID Event", and then key location to the source NodeID (reserving that much space for well-known events is easy, since you're really only reserving a small part of it). You could even allocate a little more space if desired, e.g. for an extra couple of status bits, but you can't go too far that way.
Site hosted by
This is SVN $Revision: 721 $