At a timing location, we usually have to build a local network.
This network has many purposes:
access Internet from our main laptop.
access our boxes or decoders from our main laptop.
give access to the G-Live seated on our main laptop.
One pitfall to avoid is using 2 different lan on the main laptop as it would confuse the G-Live.
The good practice to achieve that is using a 3G/4G Gateway connected to your local network so every devices can connect to a central hub and get Internet Access. Every device is working with the same network address range like 192.168.1.x e.g..
For our own timing we use this 4G Gateway from D-link. But it is not the only device that can do the job. The good points about this one:
There are 4 lan ports so you can connect your laptop directly and the RFID hardware with ethernet cables.
You can insert a sim card to get an internet connexion for your network.
It has also a wifi access point so you can connect a tablet for the commentator to display G-Live.
Starting to give a flavour of the new features already implemented, but not yet in a public release. So that you can wait for them, and give us a feedback in between.
Focusing this one today: if you are a user of Australian RFID Timing systems as we do, you will soon enjoy this new layout for your acquisitions. Not taking more place, the row will show up with the device's battery level, the visualization of the active antennas, the readers current mode, the power of each reader and the reading ON/OFF status.
Classic race week-end: you're having to deal with multiple races spread across Saturday and Sunday. Each of them holds its own bib number range, but eventually you discover lately that the organizer made two of them overlap.
You want to avoid any perturbation in a simple way. For example some runners hanging around your mats/antennas with their bib for next day's race. Or other kinds of interference like clothing chips holding a plausible id (note: this is a good reason among others that makes filtering also useful in a single race configuration).
At the same time you want to make your chips encoding as easy as possible. Though the software can deal with chip-bib correspondence tables, it's always a waste of time to feed them and a non-necessary source of errors.
Here's what you'll use: chip filters in the software and a prefixing of your chip ids at encoding.
Chip encoding policy
Your chip ids will be made of 2 parts:
a unique number identifying the race - for example 0147. This number will be simply incremented after each race
the actual bib number
Giving for example this chip id for bib #4356: 01470004356
Chip filters in Wiclax
Open the acquisitions form, and look for the interference filter panel in the status bar:
Check the Filter active option. Enter the prefix that will identify the only chips you want to see read, and the number of trailing digits that will compose the actual bib number. In our sample case: 0147 is the prefix and 7 is the number of digits to care about.
Close the panel. The status bar now indicates that there's a filter active:
And that's it!
In case you're in doubt after that, seeing a chip discarded and wondering why, remember you can check the acquisition log. All filtered readings land there:
In 2016, we can't think of timing an event in a manual way. So we have to make our favorite hardware talk to Wiclax. This is possible in a very simple way. Wiclax can interface with many systems on the market and the list is not closed.
Below is a quick video to show you how it can be done. It does not show all the possibilities as your timing configuration can be much more complex, with multiple readers/decoders or loops that can be either local or distant, and with multiple passings on some of them, etc... But it does make a short introduction.