[Ant-l] ANT version 12 issues
Libor Forst
forst at ms.mff.cuni.cz
Mon Nov 4 08:45:44 CET 2024
Hi all,
Here are some features that are candidates for removal and issues
to be slightly discussed. Please, comment on them - whether you've
ever used them or think that you might use them in the future.
1. Start, Finish and Punch devices
This was, in fact a forerunner of the ToePunch system. Mobile phones
with ANT were placed along the path like Toe units nowadays and used
for punching. Compared to the ToePunch, this was less user-friendly,
more expensive and theft-riskier solution. A nice evolutionary step
but overdone, IMHO.
2. Identifying competitors by chips
In order to identify competitors in the punching device mode, ANT
can use NFC chips. The same function was added for marshals at timed
controls as well. A competitor can approach to the station, touch
the marshal's phone and ANT selects the competitor instead of the
marshal. Especially for international competitions, it's easier than
understanding a foreign name spoken by the competitor. Nowadays,
however, it is a common practice to use startnumbers - etiher on
numbers bibs, backup cards, or simply told to the marshal by the
competitor. The marshal can choose competitors long before they
arrive at the station.
3. Writing results to Toe chips
The TC result of a competitor can be written to the ToePunch chip.
If your TC is deep in the forest with a poor or none signal, the
marshals attach competitors' SFI chip when the station is done and
the result is written there. When the competitor reads the chip,
the TC results are uploaded to the server together with the course
answers and the results can be published much earlier.
4. Publishing results in the forest
If your competiton center is out of a signal, you can use ANT to
make an HTML page with preliminary result and share it using a WiFi
hotspot in the CC.
5. Assigning chips
If a competitor uses an unknown chip for identification, the marshal
can assign the new chip to the competitor from a startlist, or to add
a new person name. This is especially useful when publishing results
in the forest - otherwise, the chip assignment should be done in
the result IS long before any data with the new chips comes into
the IS. The assignment itself is not that complicated, the problem
arises when the startlist needs to be reloaded - whether to keep the
saved assignments, or forget them and simply use the new startlist.
Reloading the startlist typically means that we have a new, fresh
data which should include the new chips...
6. E-card mode
This is another mode that exists longer than the ToePunch. In this
mode, competitors carry a mobile phone and punches answers on it.
The advantage is that an organizer does not have to buy or rent
ToePunch, but just asks competitors to bring their Android phones
and to have some devices to lend to people who don't have their own.
The use of this mode is not possible at big international events
as competitors have a communication device during the race, but it
is suitable for smaller local events. AFAIK this mode has been used
in Italy in the past so I would like to know their experience.
7. E-card mode menu locking
There is another aspect associated to the e-card mode: if competitors
share devices (e.g. from organizers), they can see answers of other
competitors who used the same device before. That's why there is
an option to lock the menu so that users cannot open the results.
Has this been used in elsewhere?
8. ANT Master Server
Application running in the ANT Master Server mode acts as an HTTP
server and other ANT devices can be configured to download INI and
upload results to AMS instead of a real server. This is especially
useful if you don't have a signal at some TCs and solve uploading
using an extra mobile with ANT as AMS - results are saved to AMS,
carried to a better place and sent to the real server. We thought
about this mode on Day2 of WTOC 2023 in the deep valleys. At the end
we succeeded to get the signal directly but it was really difficult.
9. Multistages event
Originally, it was possible (and sometimes used) to configure one
app for multiple stages of an event using different Classes for
different categories in different stages. Nowadays, I assume that
nobody uses this and only configures the app for a single race at
a time (which does not mean that you cannot download configuration
for more races separately, save them and recall them later from the
internal disk without connecting the real server, but in a single
moment, you have only one race actively set). This is not a real
implementation problem, rather a question of manuals, samples etc.
10. Terminology
The TOP system came up with a slightly different terminology: there
is an Event that has one or more Races. In ANT, the term Event has
historically been used for Race (slightly influenced by the idea
of multi-stage events - see the previous paragraph). I am thinking
about changing the teminology in ANT as well. And maybe change Class
to Category, too. Is there a strong argument against it?
Thank you for any comment.
Sincerely, L
More information about the Ant-l
mailing list