[Ant-l] ANT version 12 issues

[Ján Furucz]

Hi,
short comments from me in text

po 4. 11. 2024 o 8:45 Libor Forst <forst at ms.mff.cuni.cz> napísal(a):

> 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.

I don't use it and I don't plan to use it

>
>
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.
>
We used it about 1-2x in Slovenia. But it could be useful when not using
start numbers, but this is usually done if there are few competitors, but
then I have no problem with identification.

>
> 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.
>
We used it about 1-2x in Slovenia. It's useful if I don't use (as an
organizer) backup (paper) recording of times and answers (= I'm a
masochist), or if I don't use paper cards (for a competitor). Personally, I
would suggest keeping it.

>
> 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.
>
I don't use it and I don't plan to use it. If I have problem I use 8.
Competition centre out from Internet is untypically, now.

>
> 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...
>
I don't use it and I don't plan to use it. It looks difficult from the
referee's point of view, he has to reload the data, he has to do it at
every station (TC, TempO). Typically the referees are not that Ant
proficient I think.

>
> 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.
>
Nice history :-) I remember. Maybe ok for local competitions.

>
> 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?
>
See 6.

>
> 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.
>
We used it and it was helpful. It is suitable for countries where there is
not good internet coverage in competition area (the race takes place in
rugged terrain, deep valleys, ...) and cannot be replaced otherwise, e.g.
local wifis, starlink, ...

>
> 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.
>
I don't use it and I don't plan to use it.

>
> 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?
>
Your app, your terminology :-)

>
> Thank you for any comment.
>
> Sincerely, L
> --
> Ant-l mailing list
> Ant-l at ms.mff.cuni.cz
> http://mbox.ms.mff.cuni.cz/listserv/listinfo/ant-l
>
-------------- next part --------------
HTML attachment scrubbed and removed