[Ant-l] ANT version 12 issues

[Renato Bettin]

Hi Libor,
these are my comments:

On 04/11/2024 08:45, Libor Forst wrote:
> 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've never organized a PreO competition using ANT in this way, also 
because it is
difficult to provide all the required devices, as you pointed out. I 
don't think
I might use it in the future.

>
> 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.
I agree with your comments: it is important to identify the competitor 
in advance,
before he reaches the marshal, so the NFC identification is not very 
practical.

>
> 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.
This can be very useful, also because:
1. the marshal can even use a tablet with no mobile connectivity
2. you have two copy of the records.

>
> 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.
Very useful. I wish I had this feature in Cansiglio some years ago...

> 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...
Every additional option to make changes in the entry list during the 
competition is welcome.

>
> 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.
This mode has been used extensively in Italy both in official 
competitions and in the trainings,
because is very practical. As far as I know, we had just one or two 
cases of accidental reset of devices
during the race, with data loss (I don't know the details, I was not in 
the organization);
in a case the control card backup helped the organizers to recover the 
answers.

>
> 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?
As organizer, I've never used this option. Actually, I've never opted to 
share a device
in a competition.

>
> 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.
This mode can be very useful. If I understand correctly, I can pass the 
TC stations
with my device configured as hotspot and Ant Master Server,
  and pick up the result from the devices of the marshals. This, together
with 4., provide a  a complete solution in case there is no mobile 
connectivity.

> 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.
Ok for me, so far I don't see any drawback.

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

For me this change is ok.

>
> Thank you for any comment.
>
> Sincerely, L

Regards,

Renato Bettin


-------------- next part --------------
HTML attachment scrubbed and removed