Where to now?
StaRFIshrail has been tested with O, HO/OO and N gauges. O gauge needs the larger 45mm by 30mm aerial, while HO/OO and N gauges need the smaller 25mm by 15mm aerial. O gauge is more likely to need aerials under the track, but this will depend on the thickness of the baseboard and the track bed - you may well find that the 30mm read distance works. More work need to be done to test O gauge properly.
At present, interfacing is via CBus on MERG standards, and JMRI and RocRail on Ethernet. As both firmware and software can be updated by users using files available over the web, other interfaces can be incorporated without altering the Hub in any way. New interface formats must, however, be transported on either CAN, USB, or Ethernet. There is an option switch on the Hub, so new interfaces can just be added, without affecting the present interfaces. Please contact me if you have a different railway operating system that you wish to interface to StaRFIshrail, or, for developers, there is more information that could be sent from the hub.
Several videos on line have indicated that speed and direction are not attributes that RFID can handle. Whilst this is true of single-shot reader points, StaRFIshrail can potentially derive speed and direction.
The StaRFIshrail system is dedicated to multiple RFID points, so this feature could be used. By, say, having two RFID points fairly close together (maybe 100mm), the speed and direction of a single tag over the two readers could be worked out by software in the hub. Two RFID points either side of a signal could have great operational advantages, as you could make sure a loco did not over-run a red light, and you could also derive block occupancy more easily. Unlike the original IDLA12/20 system (and maybe RC522 as well??), I am reading and getting data from the tags continuously, at 90 times a second, and can precisely time the read times to an 11mS window - from this speed can be worked out.
What could be done with this data at present I have no idea - maybe if multiple RFID points is seen as a complete detection system, then additions can be made to, say, JMRI, to use the data available.
It will be difficult to bring down the cost of the readers and aerials. This is because how ever many are made, in electronic terms, it is still low volume production. High volume production, which would be defined as in the millions, would never happen with the demand in the modelling community - hence we would never be able to reach the price point of, say, the RC522 reader.
However, if multiple RFID points is accepted as a way for train detection and block occupancy, then the cost of the hubs could be brought down. A hub capable of accessing 64 RFID readers would probably be only 25% more expensive than 32, whilst one accessing 128 RFID readers about 75% more expensive than 32. The cost of the power supply needed would also be less per reader.
The hub has 512k Bytes of extended memory space, so it is possible to set up tables to marry the UID of the tag to the DCC address of the Loco. This can be looked up in real time, and instead of the 5 bytes of the UID being sent out from the hub, the first two bytes could be the loco identification. Or, any other sort of lookup table between UID and output could be done.
If you have any ideas or requests on how the StaRFIshrail system could be improved or added to, please contact me. Remember that both firmware and software can be updated by files sent over the web or by email, so you will not need to ever buy extra components to get the latest or different versions.