Nedokonale vynulovaný čip? / Příliš rychlý check?

[petrsv]

Ahoj.
QE2.6.26 1.5.2024 M oblasti, Petrohrad - narazili jsme na takto vyčtený čip. Závodník tvrdil, že dal nulování a "check" správně. Při kontrolním vyčtení v "SI-config" měl odpovídající čas nulování zaznamenán (navíc naprosto stejný čas byl uveden hned pod tím v check).
Na trati čip evidentně zaplnil, zbytek kontrol razil kleštěmi, takže jsme mu výsledek uznali. S tím, že zřejmě nedokonale vymazal čip, nebo už ho má vadný.
Každopádně podobný problém se potom objevil ještě u 2 dalších závodníků. V "check time" na lístku 0:00:00, ve vyčítání SI čipů - Čas-K prázdné pole a v ražení několik dalších kontrol s číslem 494 - všechny v čase 16:59:26.

Setkali jste se s tím někdy, nedokonalé nulování, nebo snad něco jiného?

Mezičasy a data čipu:


QE soubor zde.
petr1.zip

[fvacek]

Musim priznat, ze jsem toto jeste nevidel. Odhaduji ale, ze zavodnik keca a ze nerazil check ani jednou.

Pokud ovsem check v SI configu je, mohlo by jit take o chybu implementace SI protokolu v QE. Na overeni teto hypotezy bych ale potreboval ten cip.

[petrsv]

Udál se nám podobný případ teď o víkendu na oblasťáku. Věříme, že se jedná o nedostatečně (příliš rychle) oražený check, při čemž nedošlo k propsání času do čipu (ale k nastartování SIAC funkce ano), popřípadě jinou závadu SI systému.

Závodník startoval v 11:22:00 a měl v poli check zapsánu hodnotu 11:19:06 (což byl čas jeho nulování, kterou SI zapisuje do obou polí (clear a check), následný check má potom pole check přepsat novým časem, což se nestalo. Čili byl disk za ulitý start. Vyčtení krabiček ukázalo u jeho čipu korektní zápis clear (11:19:06) a check (11:20:06) bez jakéhokoli kódu chyby, tedy rehabilitaci.

Přijde mi nefér penalizovat závodníka za nepředpisově krátké ražení, když mu check nastartuje funkci SIAC (a těžko rozliší potvrzovací signály čipu a krabičky)....

Asi spíše otázka na Sportident - Neměl by proběhnout nejdříve zápis času do čipu a až pak start SIAC funkce?
Popřípadě nemůže zde docházet k nějakému rušení - viz další poměrně častá zkušenost, kdy nedochází k zápisu času startu z krabičky, pokud je tato ražena bezprostředně (v řádu sekund) po oražení check...

Postřehy, řešení? Pokud má SI systém takovouto limitaci, pak asi nepoužívat v QE check kontrolu, resp. nastavit ji tedy ne na 2 ale 3 minuty...

[xkenia]

Popřípadě nemůže zde docházet k nějakému rušení - viz další poměrně častá zkušenost, kdy nedochází k zápisu času startu z krabičky, pokud je tato ražena bezprostředně (v řádu sekund) po oražení check...

A nebude to spis tim, ze cip jeste pipa, kdyz se razi Start? Pokud je v cipu nastaveno dlouhe pipani, tak je myslim nejakych 6 sekund.

[petrsv]

Ano, máš pravdu. "Neražení" startu bývá v čase po který SIAC čip vytažený z checku ještě pípá.
Netuším zda toto pípání nějak systémově vylučuje, blokuje či ruší zapisování času na čip.
Ale pokud opravdu ano a - jak vidno z případu výše - krabička check úspěšně spustila (nejprve) v čipu funkci siac (čip začal pípat) a zřejmě teprve poté? chtěla zapsat do čipu čas checku (což se nezdařilo) - pak by tam nějaká souvislost být mohla?

[xkenia]

Je to tak, ze pokud SIAC pipa/blika, tak nerazi jakoukoli dalsi kontrolu. Pocitam, ze v tu chvili neprijima zadny signal. Ted me napada, zda celou tu dobu vysila do eteru informace o svem orazeni, pokud mu tento prikaz prisel z krabicky (send last/all punches), nebo zda to posle jen jednou?
Ohledne zapisu checku a clearu ale netusim, proc by to mohlo delat binec.