Quick-Event
Nedokonale vynulovaný čip? / Příliš rychlý check?
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
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.
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...
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.
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?
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.