When a competitor at our recent event finished and went to download, I accidentally put their SI into the Clear box for an instant. It did not beep nor give an indication that it cleared, but neither was it able to download successfully. Anyone know if there is a way to restore the result and split times? Thanks in advance!
I believe if they can't be retrieved from the stick you could query each box on that person's course and rebuild them that way (provided that data is still present)... kind of a pain, though.
I'd settle for a result, which i guess would require checking the start and finish units. How do you query them?
I've only done this a time or two under instruction and my memory is a bit foggy, so hopefully one of the epunch gurus can come along and explain more thoroughly. I believe the box was coupled with the download station using the black coupling stick, and then in the software (in this case OE2010) was an option along the lines of "Evaluate SI Station"
If you have SI Config+, you should be able to use the "Backup" icon top row to read the info from any control unit, including START and FINISH. There is also a way to print out on a miniprinter, but have not done that in a while, though, so don't remember how to do it.
Using Or as the timing program it is possible with the coupler stick to read the START and FINISH units as described above then manually go through each list to find the SI number and compare. And each SI unit to get the splits, too but that would be a pain above and beyond.
I'm guessing MEOS and other programs would be the same, too.
MEOS doesn't have a way to read the finish unit directly, but can import the files exported from SI Config[+] after reading a units backup - usually used to cross-check who actually started and who took a walk in the woods and never come back
You should be able open such files in a text editor (maybe excel too) and search for the SI number.
What results program are you using, Boris?
In OE 2010, like Furlong49 said, there is a "Evaluate SI station", I think it is under "competiton day". You need to use a connecting rod and place the SI station on the master station as if you were configuring it. Cedarcreek could walk you thru it, surprised that he has not weighed in yet.
I think also as Andreais said, you can do it under SI Config.
This is all assuming that they punched old style (inserting the card) and were not using a SIAC with the controls in beacon mode.
Based on my knowledge of how flash memory works, I'd say the chances of recovering anything useful from the stick itself are very low.
I avoid having a Clear unit anywhere near the download area for this very reason.
SI Config+ will display the unit's backup memory as well as export it to a CSV file. As undy says, MeOS can import the CSV and adjust its information accordingly. I usually read the Check punches, import the file(s), and MeOS will mark the runners who didn't punch. Handy when you have preregistration and people don't show.
I think it will do the same for the Start and Finish.
Yes I've often seen registration setup where there are clear and check bricks on the table with the download (typically for mass start events where there's no start brick). It's asking for trouble. Usually the rego person packs it up before finishers come in but it's best to avoid the situation altogether.
Perhaps if the person recorded their run on a GPS or watch then you could maybe trust them for their actual time.
Thanks everyone. Using SI Config+ worked perfectly for this purpose.
A little late to this thread, but just a quick thought @BorisGr: if you have the possibility to contact the athlete and if their chip is an SIcard5, please ask them to plan for the small possibility that the chip has become "locked up" by the partial clearing process. There is a very small time-window when a write-protection bit is set and can then not be cleared again if the clearing process is interrupted. (Well, strictly speaking it is possible with some low-level SI-commands sent to the download station, but that's not something users can normally do). Only SIcard5 is affected by this.
@jSh: Thanks! This is a rental SI card, and it's an SI6, so I think we are in the clear. But how do I check for sure?
* "we're in the clear"
* topic we're talking about
-> well done, massive grin here!
You check by simply trying to clear again. If it were an SI5 and the extremely unlikely lockup had happened, the Clear station would never give you feedback and the chip would not be cleared. Therefore you wouldn't be able to use Check or Start anymore, normal controls would work until the card was full (30+6 punches), then they would deny further punches too.
But: your SI6 will be just fine, it'll take the seeming etenity to clear as always (as 192 words of data are being scrubbed) and then will be as good as new.
I am glad to know, officially, the SI6 clear time is really long. I thought it was just me!
You should see how long it takes for the rather rare SI6*. (It also had compatibility issues, I was told to stop using mine.)
JJ, actually the clear time for SI6 and SI6* will be exactly the same since station-firmware 5.74 and 6.18, so roughly March 2015. The reason being that since then, SI6 are handled exactly like the SI6* always had been. You may also remember that since v.0.9 (April 2016), SI-Config+ started hiding the checkbox "SI-Card6 with 192 punches" for the "Clear"-mode, because it always clears all blocks of an SI6.
These changes were some of the steps taken trying to work around the infamous SI6 punch-pointer corruption bug. I won't bore you with the details, but since then, SI6 and SI6* are equal wrt Clear-time. The recommendation to not use SI6* came from some event-software not knowing how to interpret the special number range of those chips.
By the way, any news on that corruption bug? Still see it happening here, many years after it was officially acknowledged.
It's surely been at least since 2016 that my SI6* has been sitting on the shelf. It was a long time ago that a friend who does a lot of results presented me with a newer SI stick as a gift and told me to never show up with that annoying SI6* again. And I've since moved on from that one as well.
Pi, I'm really sorry, I'm not in a position to give any statements on that...
I can discuss some technical details, but I can't get into political stuff between a company and a country representation and an o-federation...
jj - you've moved on from the friend???
She's still a dear friend, although it is true that I haven't seen her in a while. I'm looking forward to sometime this year, though. I hope.
I'm not interested in politics. Was just curious if there had been any progress on solving the problem, from a technical point of view.
Understood. Well, the statement a while back was the acknowledgement of the problem with SI6 (and SI6* too, same internals) due to a bit-shift in the punch pointer (PP), used to index into the punch data on where to write next. Fairly quickly, at least a partial fix was implemented that identifies a corruption when it has happened (next control) and tries to rescue the PP.
Sadly, during really extensive testing, no specific bug in the firmware was found, rather it seems there are (very unlikely, but non-zero) chances that the induction field that is powering the punch process "collapses" due to (again very unlikely, but non-zero) movement of the chip in the hole - for example an athlete continuing to run around the station while keeping the chip inserted, or even just twisting his finger hoping to see the station feedback better.
Even worse, it turns out this situation can happen (much less likely, but again non-zero) even with all other chips in "classic" punching. And statistically, the longer the punch process the more likely the problem - hence SI10,11,AC least likely.
So far, so good/bad. The problem is, to protect from all this, a read-after-write strategy would need to be added. This would increase the punch duration, mandating a change of athlete punch-habits learnt and stored in "muscle-memory" for... years. The fear is this would cause more problems than it solves, plus there is the perceived solution of contactless punching, and thus this is where we cross into the land of politics, and I must remain silent.
Another finding was, by the way, that the "active feedback" chips (SI11 and SIAC) in "classic" punching are problematic specifically for radio controls. These chips process the punch-process internally in one step and then register "success" with the station while already giving feedback (blink/beep). It turns out there is a (much more likely than punch pointer corruption!) chance that the chip successfully stores the punch, starts feedback and is removed from the station before that station picks up the "success" response - and this leads to the station failing to send the AutoSend datagram, thus the radio control looks like it failed. At TioMila 2018 and 2019 this was rather a depressing situation for me because the leading athletes, many equipped with shiny new SIACs, push the limits extremely hard on when to remove the chip - and thus it seemed my radios were failing badly - while in fact the SI-stations weren't giving my radios the decisive punches.
Very interesting. Thank you for sharing.
You're very welcome! Now if you could please direct your attention at this little gadget I have here - it's called a Neuralyzer... :-)
@jSh: So... let's say I am doing the English-language commentary for the Tiomila webcast again this year. Would you come by our booth for an interview on this?
Well... currently I have not been asked to provide any radio services for this year yet. If I'm there, and time permits, I'll come for a chat, but I'll check what I'm allowed to say in advance, OK?
Since what firmware version is the partial fix included that tries to rescue the PP? I'm pretty sure our SI team is running the latest firmware and still we see the corruption bug, usually one or two cases in an event with 1000+ participants. I assume the rescue attempt itself does not always work?
There's your problem, you have too many people at your events. If you only have as many as a typical Aus or US event those one or two with SI issues aren't likely to turn up.
Since firmware 5.74 in the old stream and 6.18 (March 2015) in the new stream (the latter supporting the contactless punching modes). So there's a very high chance the partial fix is in the stations you are working with, but you are right, the rescue doesn't always work.
Regarding statistics: if you speak of 1 to 2 cases per 1000+ participants and assume 20 controls on an average course, that's ~2 of ~20.000 punches, so 0.01% fails, or 99.99% successes per punch. I'm honestly not trying to downplay the criticality of each single case, just trying to put it into perspective: it is still really rare, your disadvantage is you have so many participants at your events ;-)
I don't think they have average courses in Sweden. Everything is World Standard.
Certainly they are longer than the IOF winning time rules prescribe...
Oh, I certainly don't think it's a big deal anymore, now that the problem is acknowledged, organizers are aware of it and rules permit to query units as they come back from the forest after the event. As a software/firmware engineer myself I was just really interested what has happened with the issue.
At trainings and local events no one cares at all and just reinstates runners if they are adamant they visited the control. At regional/national events the organizers will reinstate mispunched runners if they protest and the unit in the forest confirms they were there. At the very important events with TV (WOC, World Cup, Swedish Champs etc) the athletes must carry 2 units to avoid the problem.
What wasn't great was to stick the head in the sand for years and years, stubbornly insisting that the system was 100% correct, keeping totally inflexible rules and disqualifying countless runners incorrectly, including at WOC, national champs and 10-mila, Jukola and so on.
It's easy to say afterwards, but it would have been nice with a softer approach from an earlier stage. After all, we all know that no man-made system is ever 100% correct.
100% agree. I'm glad you mention inflexible rules, because apart from the technical impossibility of 0% error-rate there were also many years when o-rules forbade pragmatic solutions, and sometimes even forbade them on a vendor-specific basis. That made flexible approaches more difficult, because orienteering is not just fun and games, it also has commercial aspects, for athletes, organisers, control hardware vendors, etc.
I like living in a country where it is just fun and games.
Do you 100% agree though or is there a 0.01% margin for error?
This discussion thread is closed.