Slik brukte vi O-total på Sørlandsgaloppen 2025

Lurer du på om O-total kan brukes i et stort flerdagersløp? Det korte svaret er «ja.» Et mye lengre svar følger her, en lang beskrivelse av hvordan vi forberedte og gjennomførte Sørlandsgaloppen 2025 med O-total.

Begynnelsen

Det var en mørk og stormfull oktoberkveld i Kristiansand i 2024. Bak et enslig opplyst vindu i en kontorbygning i sentrum møttes klubbene i vestlige Agder for å planlegge Sørlandsgaloppen året etter. Jeg var også invitert. Hvordan havnet jeg der?

«Vi har hatt glede av å benytte O-total i flere nær/K-løp i kretsen. Jeg har sett hvor enkelt det kan gjøres. Vi i Sørlandsgaloppen må utvikle oss, og ikke lengre være avhengige av enkeltpersoner. For at tilbudet til løperne skal være så fleksibelt som mulig, må vi få flere personer til å være med å bidra. Selv uten spesiell kompetanse på løpssystemet. Kan du utvikle O-total til å bli et slit system for flerdagers løp?»

– mail fra Sørlandsgaloppens leder Svein Roar Jonsmyr.

Så på agendaen til møtet sto det:

• Vi får en demonstrasjon av O-Total
• Kan/vil/ønsker vi å benytte dette systemet?

Det ville de, så ni måneder senere var det O-total på alle skjermer da vi ønsket deltakerne velkommen til sommer, Sørland og orientering. (Og fire dager senere pustet jeg lettet ut: Det gikk bra. Flerdagersfunksjonaliteten virket fint, og serveren tok belastningen så å si på tomgang.)

En liten oppsummering:

• 17679 brikkeavlesinger
• 25 brukere pålogget
• 72 løyper
• 247 poster
• 1589 deltakere
• 24,8 mm nedbør

Folk og utstyr

Det var mange PC-er i bruk under arrangementet, men ingen server og ikke noe lokalt nettverk. Siden alt med nettleser kan brukes og ingenting må installeres, var det en blanding av utrangerte, personlige og jobbmaskiner i bruk. De fleste kjørte Windows, men det var også Mac, Chromebook og Linux i miksen.  Og mange folk som brukte dem.

• Løpskontor: 4 maskiner, rundt 10 brukere, en 4G-ruter
• Mål: 4 maskiner, 4 brikkelesere, 5-10 brukere, en 4G-ruter
• Rød sone: 2 maskiner, 5-10 brukere
• Brikkesjekk: 4 maskiner, 4 brikkelesere, 5-10 brukere, en 4G-ruter
• Start: 1 skjerm, 1 Raspberry pi
• Resultatriggen: 6 skjermer, 6 Raspberry Pi, en 4G-ruter
• Tidtakingskontoret: 2 maskiner, 2 brukere

Brikkesjekk

Brikkesjekk er nyttig for å få bekreftet at riktig person har riktig brikke hver dag. Dette er jo et ferieløp, og de glade orienteringsfamiliene som kommer har noen ganger fordelt feil brikker fra haugen de har av brikker. Så får vi også sjekket at brikka virker, og vi får en bekreftelse på at deltakeren befinner seg på arena. Funksjonen er en del av liveresultatene, så der trenger man ikke logge inn. Bare gå til o-total.live -> Arena -> Brikkesjekk og velg riktig brikkeleser.

Vi rigget opp fire maskiner: tre PC-er og en Chromebook. De ble koblet til tre eScan2 og en MTR4. Det er lurt å bruke eScan2 på brikkesjekk for klassiske emit EKT brikker, fordi eScan2 er mindre følsom enn MTR4. Da får man luket ut de dårlige brikkene i brikkesjekken, siden de dårlige brikkene slutter å virke på en eScan2 før de gir opp på MTR4.

Brikkesjekken henter komplett startliste en gang i minuttet hvis nettet er oppe, sånn at det skal gå fort å sjekke brikka. Det virket, de fire brikkeleserne klarte å ta unna folk på vei til start uten å lage kø.

Bortsett fra på dag 1 da. Der var vi litt optimistiske med wifi-dekningen. Med mange mennesker mellom brikkesjekk og wifi-ruteren mistet vi forbindelsen, så brikkesjekken opererte med gamle data. Dermed ble noen av dem som nettopp hadde meldt seg på avvist som «ukjent brikke.» Da ble det litt dårlig stemning, men det løste seg med å plassere en egen 4G-ruter på brikkesjekken. Brikkesjekken ble bemannet av 1-2 mennesker fra Kristiansand OK. Deres oppgave var å be folk om å legge på brikka, og enten ønske god tur (riktig påmelding kom opp) eller be dem gå tilbake til løpskontoret (feil påmelding, ukjent brikke eller død brikke).

Mål

 I mål var det også fire maskiner og fire brikkelesere, her var det PC-er og MTR4. Hver brikkeleser hadde den vanlige EPR-3 printeren fra emit som skrev ut strekktidslappene. Siden den kom fra brikkeleseren inneholdt den bare poster og tider, ingenting om plassering eller disk/godkjent.

I utgangspunktet skulle mål bemannes av voksne folk fra Kristiansand OK, men ble raskt veldig populært blant ungdommen, så her satt etter hvert ungdom fra både arrangørklubbene og andre og rev av strekktidslappene og annonserte status og plassering.

PC-ene i mål var i utgangspunktet koblet til nettverk med kabel, til en 4G-ruter, siden sjefstidtaker Rune Kittelsen var litt bekymret for forstyrrelser på wifi. Men på dag 2-4 ved Høvåg Skole var Telias dekning så usikker at han gikk over til å bruke skolens wifi, før han flyttet ruteren til taket av skolen og fant god dekning der.

Bortsett fra en liten periode med manglende mobilnett tok mål også greit unna alle som leste av.

Rød sone

Alle som ikke ble godkjent skulle innom rød sone, hadde vi tenkt, sånn at vi kunne merke dem som «verifisert» i O-total hvis de var enige i å ikke bli godkjent. Men i praksis var det mange som gikk skuffet rett forbi. Og det er jo forståelig.

På rød sone satt to personer som rullerte ofte med hver sin PC, en med windows og en gammel som hadde fått nytt liv med Ubuntu Linux. De hadde siden for målpasseringer oppe, som viste alle målpasseringene etter hvert som løperne stemplet i mål. Der kunne de se hvilke poster løperne hadde bommet på, og hvordan backuplappen skulle se ut.

Der kom det alle slags problemer, som døde brikker, brikker som ikke var nulla, folk som hadde løpt feil løype, og de første som ble utsatt for en post som døde midt i arrangementet. Dette er jo et ferieløp, så vi var greie med å endre klasse, og godkjente riktige backuplapper med en anslått tid hvis brikka var helt død. De jobbet effektivt i systemet, det køet aldri.

«Veldig mange fornøyde løpere fikk sitt løp godkjent med en rask og effektiv behandling» sier målleder Rune Kittelsen.

For å gjøre det lett for nye å rullere inn, hadde jeg laget korte og konsise bruksanvisninger på ett eller to ark for hver funksjon, og laminert dem. De som satt i rød sone var jo dyktige orienteringsløpere, så når de vurderte at noen skulle godkjennes i en annen klasse kunne de slå opp på punktet «Godkjenn løper i annen klasse» og følge oppskriften. Det avlastet oss på support veldig. Den ideen fikk jeg fra Pål Kittilsen (nei ikke Rune) som gjorde det på et av sine arrangement. Arkene finner du i hjelpesenteret.

Løpskontoret

Løpskontoret var et travelt sted, særlig i begynnelsen, som delte ut lagsposer og leiebrikker og tok i mot etteranmeldinger og endringer. De hadde fire datamaskiner og fire personer som betjente dem, mye rullering her også, med påmeldingssiden oppe og en egen 4G-ruter som fikk dem på nett.

«Fire personer, tre personer som ikke var eksperter på O-total, det kunne ikke gått bedre»

– Sjef Jonsmyr

De var utstyrt med en kort bruksanvisning og mye velvilje, og de sa etterpå at dette hadde vært veldig lettvint, også for de som ikke hadde gjort det før. Bortsett fra at det var litt tungvint å gjøre en endring på tvers av løp, for eksempel brikkenummer, fordi de måtte skifte løp mellom hver endring. Det er notert, det skal endres til å bli enklere.

Tidtakerkontoret

Rett ved mål satt tidtakersjef Rune med sin MacBook og to eksterne skjermer og fulgte med på hvordan løpet skred fram. Med dashbord på en skjerm fulgte han med på statistikk og etter hvert løpere ute. Startdisplayet, den samme som vises på start, var også på en skjerm for å følge med på hvordan starten forløp. Også liveresultater selvfølgelig.

I tillegg hadde han installert programvare på mål-PC-ene som speilet skjermen, så på en skjerm kunne han følge med på alle som kom i mål. Dette er ikke standard i O-total, men det var ganske snedig. Programmene han brukte var TightVNC på PC og Remote Ripple for Mac.

Med O-total var jobben til tidtakersjefen bare å følge med, siden all punching i systemet ble gjort av løpskontoret og rød sone. På slutten av dagen kom jo spørsmålet fra løpsleder Svein Roar Jonsmyr: Er det mange ute? Og en dag manglet vi fire: to var merket som startet for tre timer siden, og to hadde vært innom brikkesjekk men var ikke sett siden. Noen dro ut for å se etter de to som hadde startet men ikke kommet i mål. Løpsleder Svein Roar prøvde å finne telefonnummer til de to som hadde brikkesjekket. Det gikk bra, de to som var ute fant hverandre og veien til mål, og de to som var brikkesjekket hadde skadet seg på vei til starten og gått hjem. (Og etterpå beklaget at de ikke ga beskjed.)

Start

Det var ti løyper med starttider i år, og dermed ti startbåser og opptil ti som startet samtidig. Birkenes IL rigget starten og hadde emit startklokker med oppropstider, men startregistreringen skjedde elektronisk. Alle 0- bukkene var gule, altså meldeposter som kringkastet brikkenummeret når noen la på. For å fange opp 0-stemplingene brukte vi O-total emitLinker. En enhet fanger opp stemplinger i en radius på 15 meter, så det hadde holdt med en, men siden vi ennå ikke har fått dem 100% pålitelige så brukte vi to enheter, en på hver side av feltet. De sender brikkenummer og tidspunkt til O-total, sånn at de blir merket som startet, og tiden begynner å løpe i liveresultatene. (Og bare så det er nevnt, du kan bruke Emits ETS med O-total også, og de er mer pålitelige enn så lenge.)

Vi rigget også et startdisplay, en skjerm, på start. Starten var jo langt unna både strøm og nett, så vi hadde med et blybatteri («fritidsbatteri») og en inverter for å drive den. Startdisplayet er bare en nettside på liveresultatene det også, og den laster inn hele startlista først, også viser den de som skal starte i hver bås etter hvert som starten går framover. Jeg delte nett på telefonen når vi gikk til nettsiden (live -> arena -> startdisplay), deretter klarte den seg selv uten nett.

Skjermen er en spesielt lyssterk skjerm beregnet for offentlige steder (en «public display» skjerm), det er nødvendig for at den skal være leselig i solen. Det kunne vært en hvilken som helst maskin som viste nettsiden, men jeg har brukt en liten ettkorts-maskin (Raspberry PI) som henger bakpå og får strøm fra en USB-port på selve skjermen. På denne skjermen kunne løperne sjekke starttiden sin. Funksjonærene på start brukte den også til å se når det var en glipe der de kunne slippe inn noen som var sent ute, siden den viste 5 startende fram i tid.

Liveresultater og speaker

O-total har alltid liveresultater, som viser plassering og tid til de som har kommet i mål. Vi hadde også automatisk startregistrering, så da begynte tiden å gå på liveresultatene med en gang løperen nulla brikka. Rekkefølgen på live er først de som har kommet i mål, deretter de som er ute, så de som ikke har startet. Veldig oversiktlig og fint.

Vi hadde også en eller to meldeposter i hver løype. Det fungerte sånn passe, vi mistet en del stemplinger, og de som hadde vært innom en meldepost havnet nederst på liveresultatene inntil de kom i mål, da havnet de øverst der de skulle være. Det er to beklagelige feil vi er nødt til å fikse.

Våre to speakere Jan Blandkjenn og Jack Bjørnsen brukte bare liveresultatene, med flere vinduer oppe og fokus på ungdomsklassene. Det gjorde jobben deres litt vanskeligere at mellomtidene og forvarselet ikke var til å stole på, men de gjorde likevel en formidabel jobb i bua.

Resultatriggen

Liveresultater ble også vist på seks skjermer på arena. Det var bare nettsider det også, som ligger under arenaknappen på liveresultatene. Forskjellen fra de vanlige live-sidene er at disse er delt opp i fire spalter, og man kan forhåndsdefinere fordeling av klasser på skjermer på løpsdefinisjonen. På et løp av denne størrelsen var det ikke plass til alle på seks skjermer, så vi valgte å ikke vise de urangerte, og droppet 80+ til fordel for de yngste. Sorry, svigermor. Selve konstruksjonen er en sekskant av OSB-plater, med public display-skjermer med veggfester, og en Raspberry Pi minidatamaskin bakpå hver skjerm. De gikk på wifi fra en 4G-ruter i midten av ringen. Den gikk på Telenor og hadde god 4G+ dekning også på Høvåg. Riggen er laget slik at den bare kan skrus på, så går den til den nettsiden som er definert i en egen resultatrigg-applikasjon. Ikke en del av O-total foreløpig. Det er jeg som har bygget den, men Hisøy OK som eier den.

Sammenlagt og premier

Man vil jo gjerne ha en sammenlagtpremiering på et flerdagers løp. Det kunne vært i form av en jaktstart, men galoppen valgte en rangering basert på poeng. Tradisjonell rangering i Agder er 1000 poeng til vinner, deretter 9 poeng trekk pr prosent av vinnertiden man kom etter vinneren. Minimum er 100 poeng. Vi strøk det dårligste, altså at de 3 høyeste poengene teller. Denne formelen kan man definere på arrangementet i løpsoppsettet, under rangering. I tillegg må man angi rangering på hver klasse som skal ha det.

Rangeringen vises på liveresultatene den også, og er alltid oppdatert. (Du må oppfriske siden, den oppdateres ikke hvert 10.sekund av seg selv slik som liveresultatene.) På den måten fikk vi startet premieutdeling så raskt som mulig, det var ingen egen beregning å kjøre.

Forberedelser

Det krever en del av arrangørklubbene og løpsleder å arrangere et så stort løp. For meg var det mest å utvikle flerdagersfunksjonalitet som ikke var på plass ennå, men når det var gjort var det ikke så mye som måtte gjøres i systemet.

Opprette løpet

For å opprette arrangementet i O-total er det bare å trykke «Opprett dette løpet» som vanlig. Da opprettes arrangementet, alle løpene, alle klassene og eksisterende påmeldinger hentes inn.

Så, når løypeleggerne er klare er det bare å mase noen ganger, få løypefilene og lese dem inn. Vi hadde kartsnu på sprinten på dag 1, og det kommer litt forskjellig avhengig av tegneprogram og hvordan man gjør det, så det er greit å sjekke at kartsnu-posten kommer riktig. I dette tilfellet het de RES1 og RES2, og jeg fjernet dem fra løypa i O-total for sikkerhets skyld. De skulle jo ikke stemples på.

Løypesjefen hadde finregnet og sett på statistikker og bestilt kart som han håpet skulle være nok. Antallene la vi inn på løypedefinisjonene i O-total, så kunne vi se på dashbordet om antall påmeldinger og antall kart i hver løype kunne gi problemer. Løypesjefen var flittig bruker av dashbordet etter hvert som påmeldingene kom inn.

«Det å tilby etteranmelding, klassebytte på arena er en service som krever ekstra god kontroll på antall kart. På et løp var det fire løyper med kun ett kart igjen i boksen. Takk for en utrolig flott funksjon»

– løypesjef Stein Erik Scheie.

Trekning og ønsker

Da siste påmeldingsfrist gikk ut, og noen timer før startnummerfila skulle til trykkeriet, var det på tide å tildele starttider.

Vi hadde som mål at starten ikke skulle bli for lang, at den skulle bli omtrent like lang for hver løype, og at rekkefølgen på klassene skulle variere mellom dagene.

Trekningen gjøres i påmeldinger -> avansert -> tildel starttider. Her var de ordinære klassene med alder over 10 krysset av som standard, og det var greit. Systemet foreslo 60 sekunder intervall på sprinten og 120 på mellom og lang, men det endret vi til 60 for alle. Det er jo et ferieløp, folk vil jo på stranda, starten kan ikke være for lang.

Så trykket vi «oppdater» for å se på grafen hvordan det så ut. Deretter endret vi litt på noen klasser. H21 og D21 fikk 120 sekunder intervall, rekkefølgen på klassene ble snudd rundt på annenhvert løp, og vi la inn mange ledige før enkelte klasser for å dra starten ut i tid og få jevnere belastning på start. Så tok vi ut en foreløpig startliste, det så bra ut. I ettertid skulle det vise seg at vi skulle studert de foreløpige startlistene litt mer nøyaktig. I løpet av en time var vi ferdige med fire løp og trykket «bruk dette.»

Da manglet det bare å endre starttider på de som hadde sendt mail med ønsker, noen kom med fly og måtte starte sent, og et foreldrepar måtte starte med mye tid mellom for å kunne ta seg av barna. Vi er på tilbudssiden, det er jo et ferieløp, så det ordnet vi. Alt klart! Da trykket vi på knappen for startnummer, fikk en pdf vi sendte til trykkeriet, lastet ned startlister på xml og lastet den opp igjen til Eventor.

Sinte engasjerte e-poster

Det tok ikke lang tid før vi innså at ikke alle var like fornøyde med trekningen. Det viste seg nemlig at rekkefølgen av klubber innen en klasse var lik hver dag, og dermed var også rekkefølgen av løpere ganske lik hver dag. Og det er jo ikke bra.

Det skyldes en kombinasjon av hvordan O-total virker, hvilke parametere vi brukte, og litt overfladisk kvalitetssjekk. Nå er O-total endret slik at det ikke skjer, men for dette arrangementet landet vi på at det var for sent. Startnummer var trykket og lagsposer pakket. Vi skrev en beklagelse i eventor og sto i det. Det er jo bare et ferieløp.

«Som leder av Sørlandsgaloppen, var det ikke noe annen løsning enn å legge seg flat. Vi tok et «teamsmøte», vurderte fordeler og ulemper. Beslutningen ble å følge oppsatt plan. Vi er takknemlige for at ledere/løpere i klubbene tok dette på en fin måte, men det gav ingen god magefølelse»

– Svein Roar Jonsmyr.

Startnummer

I O-total kan man laste opp en egen mal for startnummeret, som er et Microsoft Word-dokument med spesielle {tags} der data skal plasseres. Layouten var det løpsleder Svein Roar som tok seg av, og plasserte sponsorlogoer og overskrifter der de skulle være. En generell mal hentes på hjelpesenteret, så kan man endre den og laste den opp på løpsdefinisjonen på arrangementet.

På startnummeret kan man også legge til en tekst som hentes fra klassen. Vi plasserte en * på de klassene der alle skulle ha premie (stort sett 12 år og under), sånn at de startnumrene fikk en stjerne til høyre. Dermed var det superenkelt for de som delte ut premier i mål å se hvem som skulle ha.

«Helt utrolig bra løsning med merke på startnummeret»

– Kjell Arne Håland, som ledet premieutdelingene.

Pdf-fila produseres fra siden for rapporter. Velg noen klasser eller alle, og velg sortering. For pakking i lagsposer valgte vi sortering på klubb; da er det enkelt å dele bunken.

I genereringen av startnummer oppdaget vi også at O-total viste feilmelding fordi det tok for lang tid med over 1000 sider, det skal også rettes. I mellomtiden delte vi jobben i to, med halvparten av klassene i hver pdf.

Vi skrev også ut en bunke ledige numre, det er startnumre som ikke er tildelt noen deltaker, med utfylt nummer, men blankt navn, klubb og starttid som kunne brukes med tusj på etteranmeldte. O-total kan tildele startnummer pr klasse eller i en lang sekvens, vi valgte å ha en lang sekvens der første påmeldte fikk nr, 100, og så telte det bare opp i påmeldingsrekkefølge.

Lagsposer

Lagsposene skulle fylles med leiebrikker, startnummer, sikkerhetsnåler og en påmeldingsliste. Rapporten «Lagspose» viser alle påmeldingene for en klubb, med starttider og klasse for hver dag under hver deltaker, og denne ble brukt som pakkeliste og til å identifisere leiebrikker. Den ble også brukt for å sjekke påmeldingene på tvers av dager etter endringer, siden det ikke var så lett å se i påmeldingsbildet.

Etterarbeid

Det er lite etterarbeid for hver dag, egentlig bare å laste opp resultatene til Eventor. Da vi pakket sammen etter dag 1 var det noen som spurte om jeg nå måtte hjem og overføre til ny dag, men det er ikke noe slikt i O-total. Neste dag er det bare å åpne neste løp,

For resultatriggen gikk jeg inn i resultatrigg-appen og la inn nye nettadresser, så den viste riktig løp når vi satte på strømmen neste dag.

Fakturering

For etteranmeldte velges kontingent automatisk basert på klasse og alder, men det var ikke alltid alder ble angitt, så de ble stående uten kontingent. De fant vi ved å filtrere påmeldingene på blank kontingent, så vi fikk lagt dem inn. Sørlandsgaloppen var definert med kontingenter pr dag, og ble fakturert pr. dag. I O-total kan man velge mellom å få fakturagrunnlag og fakturere gjennom et økonomisystem, eller å sende ut fakturaene med e-post rett fra O-total. Galoppen valgte det siste, og da vi trykket «Send» gikk det ut over 400 e-poster til klubbene og like mange i kopi til kasserer. Lett å sende ut, ikke like lett å følge opp i etterkant. O-total er ikke et økonomisystem, egentlig.

Alt i alt

… gikk det smud, arrangementet ble avviklet uten store feil, med god informasjon til løpere og publikum, og god oversikt for arrangørene. O-total skal finpusses for at det skal gå enda lettere for de neste som kjører et stort flerdagers løp, men det er klart til bruk allerede.