For advanced users the following may be of interest. These features are in the background and are designed to make Orbiter simple and easy to use.
First, Orbiter Radio Frequency “Reader Protocol” “ORP” and “Reprocessing” ability are key. Reader protocol is inside the RFID reader while application software is inside the laptop server. As background LLRP (Low Level Reader Protocol) is the core embedded reader software for the GEN II International Standard. It is primarily used for supply chain RFID (Radio Frequency Identification) tagging. LLRP was originally the protocol used to control door access proximity cards. It was first developed in the 1970’s. Even though it has been updated periodically since then, it still is lacking reliability for race timing. This is especially true when moving the timing detector on the fly during an active event. Other detector timing software does not allow moving and switching detection points on the fly like Orbiter. Over the last 15 years Orbiter has made 53 reader software updates. This shows the importance of Reader to Orbiter’s success.
Thus, we developed a replacement called ORP. Orbiter wrote ORP software because when the Orbiter readers are moved on the fly, and moved from time point to new time point in the middle of a race, connectivity and orderly data can be an issue. ORP method is robust and designed to handle these unique race setup situations. This ensures reliable tag detects times are posted inside the reader. Data flows to the laptop / tablet server with 100% assurance once a connection is re-established. With ORP the connection may be broken, yet timing continues to happen in real time uninterrupted back at the RFID reader.
Secondly, Orbiter has a robust automated “Reprocessing” feature that allows tag detects to come to the application in any disruptive time order and sorted correctly. For example, finish time may come to the lap time before start time. This happens due to readers downloading their data to your laptop server at any time. This allows for real time or after the race communication with the readers. The Orbiter reprocessing software automatically sorts this out. Results are automatically sorted and produced in the correct time order. This is especially important when there are multiple RFID readers all passing accurate time stamped tag detects to the server, but out of sequential order.
Reprocessing also allows any setting on the computer to be changed after the fact. This happens when there is human mistake such as assigning bibs incorrectly. Or, any number of mistakes like setting minimum lap time incorrectly. The good news is that as long as the Orbiter reader detected the bib “beeped”, a correct time stamped is permanently logged. The correct time is stamped because each reader has a clock inside that is synchronized with the server clock. Reprocessing allows the original time data to be used, the mistake later corrected, and the result to be shown as if new. Because the Orbiter system is automated, a person is no longer required to oversee the correction process.
Thirdly, every tag detect is time stamped inside the reader as they happen in real time. Each tag detect ID is Time Stamped at the Reader and held in memory on a FIFO bases. FIFO means first in first out. The reader LED and Beeper flash instantly. Since there is no latency, this is the reason that a timer can calibrate the location of the start finish line. When the Orbiter reader is set to “Last Tag Detect Seen” the absence of a beep is the point the time is stamped. These points are exact and instant to locate. Unlike some competitive systems that often average 7 second delay by which the runner has long past.
Fourth, “Bollard Control” is another Orbiter innovation for mobile readers. This allows one to many detectors to be controlled and monitored from your lap top. Just like NASA mission control, you monitor and see the condition of all you readers from the timers table. No need for LED’s, knobs and switches on a remote reader plastic control pelican box as is the case with other systems.
Fifth, The Ability to “Clone” or Copy events is of great help to those that run the same event back to back. An Example of this is Fitness Assessment Tests. With “Cloning” in just 4 key strokes, a new test may be set up using the same RFID chip tags.
Sixth, “Gestation” and “Decay” periods are a unique tool used by Orbiter. They determine how tag detects are used in odd situations like transitions in a Triathlon. They help make the reader independently smart. Because Orbiter software resides inside the RFID reader, Orbiter is able to make the time point readers truly smart. This allows them to make decisions without a network connection. For example, when a runner is in a Triathlon Transition, comes out of the Transition, but then realizes they left something back inside and returns, then exits a second time. Orbiter readers know that this is “one” transition and automatically posts it as such.
Seventh, With Orbiter the RFID Readers “Talk First” to the Host, this increases reliability and efficiency of passing data to the host. The readers lay dormant and as soon as a tag is detected the reader knows where to send data. Flash! Most other systems use Dynamic IP methods used by retail software. Dynamic IP has extra handshaking happening to establish the connection as IP addresses are assigned and reassigned. This method is more appropriate for mobile phones than race timing. Dynamic IP has too much handshaking and this increases risk of failure to produce timely results.
Last Tag Detect Seen is accurate and reliable timing method for Bike races and many other events. This is because the antennas are pointed at the riders blasting a full 24 volts of power. This pre-energizes the RFID placards in a dense riding pack. The detection happens on the spot the readers are placed. Not before the reader as is the case with first tag detect seen. What makes Orbiter’s method unique is that this is all done automatically inside the reader. This allows complete mobility and the ability to toggle from first tag to last tag detect. Plus, this setting is individualized to each reader.
Timers report when using Cloud based registration, timing, and reporting, the most difficult Connection to the Cloud is in a race with tens of thousands of people. The connection problem is solved with Orbiter. This is because when Orbiter’s military Wi-Fi is used, Orbiter’s powerful narrow band takes precedence over other Wi-Fi. Plus, the fact we are on a private network, overwhelms retail Wi-Fi and Orbiter gains a solid connection.
Likewise, with retail cellular, when there is a lull in data transmission from the timer, the connection is automatically disconnected by the cell company. The expectation is that it will normally be re-established dynamically when data flows again. However, with thousand of people at the race, connection is very difficult to re-establish due to competitive cell phones. The timer’s cell modem has to fight to regain the cellular connection to the cell tower. The timer is competing with all the spectators cell phones around him on an equal footing. With many Cloud based systems, if the Cell or Wi-Fi connection is broken, then Registration goes down and there are no real time results”.With Orbiter the cellular connection, the connection to the tower is always kept “ON”. The Orbiter connection by software is not allowed to be broken in the manner that a dynamic IP breaks. Through software slight of hand the method of keeping the connection “ON” does not impact data plans or cost the timer more. Orbiter connection to the cell tower has as similar priority as an emergency service like police and fire. Thus, the race data securely travels back to the server without interruption.
In summary, there are actually many more software advancements but the above give you an idea the depth of service we provide you. The aim is ease of use and Orbiter continually improves as new technologies and tools are available.