MTR Debug Tool
Thierry Matthey
Jeg har skrevet et lite MTR-debug-program i perl (finnes ogsaa som
Windows exe) til fritt bruk for aa hacke, konfigurere eller utlese MTR'er:
http://www.matthey.org/ttime/
http://www.matthey.org/ttime/tkmtr.exe.zip
http://www.matthey.org/ttime/tkmtr.pl
... fungerer og paa Linux.
-Thierry
PS: tTiMe med online-kodesjekk er rundt hjoernet ...
Terje Mathisen
> Hei,
>
> Jeg har skrevet et lite MTR-debug-program i perl (finnes ogsaa som
> Windows exe) til fritt bruk for aa hacke, konfigurere eller utlese MTR'er:
>
> http://www.matthey.org/ttime/
> http://www.matthey.org/ttime/tkmtr.exe.zip
> http://www.matthey.org/ttime/tkmtr.pl
Fint!
Jeg regner med at du har lagt merke til at EMIT ikke har lagt ut USB
driver for MTR-4, jeg fant den ved å plugge inn, enheten, sjekke ut USB
id, og deretter søke på Google.
På denne måten fant jeg en Win2K driver for den innebygde USB-Serial
enheten som sitter i MTR-4.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Sindre Jansson Haverstad
> Hei,
>
> Jeg har skrevet et lite MTR-debug-program i perl (finnes ogsaa som
> Windows exe) til fritt bruk for aa hacke, konfigurere eller utlese MTR'er:
>
> http://www.matthey.org/ttime/
> http://www.matthey.org/ttime/tkmtr.exe.zip
> http://www.matthey.org/ttime/tkmtr.pl
>
> ... fungerer og paa Linux.
Flott, Linux liker vi!
--
SIndre
Thierry Matthey
Jeg pleier aa bruke tTiMe eller tkmtr for aa finne riktig port, searlig
naar en bruker USB-Serial-Port. Jeg har lastet ned en del drivere med
har ikke klart aa faa bundlet alt i en pakke ...
exe/bin-Linux-versjon faas via email siden jeg ikke har lisens paa
perl2exe ;-) ... ellers kan man ja bruker selve perl-skripte, men da
trenger man en del pakker, SerialPort, Tk.
Jeg skrev tkmtr.pl siden jeg fikk en del MTR'er jeg maatte "debugge" ...
og det er ikke altid lett aa finne ut naar noe feiler naar det snakkes
med en MTR. Bare tenkt som hack'er tool ;-)
-Thierry
Terje Mathisen
:-)
Jeg var i en lignende situasjon for tre år siden da vi innførte EMIT på
bedriftsløp i Oslo: Jeg hadde klart å få det inn via ett benkeforslag på
årsmøtet høsten før, så kom vi til det første løpet og skulle dumpe
resultatene fra MTR-2 via EMITs programvare.
Ingeting virket!
Jeg prøvde også ett program utviklet på Veritas, men uten hell (min
teori er at dett var fordi våre MTR-2 enheter var helt nye, og derfor
ikke inneholdt minst 8 løp i hukommelsen).
Resultatet var at jeg på kvelden etter det første løpet måtte starte
febrilsk prorammering:
Først skrev jeg ett absolutt minimalt C program som bare gjør en ting:
Åpner COMx porten og dumper hele lageret fra MTR. Disse dataene skrives
til en disk-fil i hex-format.
Resten av kvelden gikk med til perl kode som leste inn disse dataene, og
tolket dem sammen med flate (komma-separerte) filer med post-koder,
klasser, løyper og brikke/navn oversikt.
Din versjon som bruker Tk til å gi ett bruker-grensesnitt er helt klart
mye mere bruker-vennlig. :-)
Thierry Matthey
> bedriftsløp i Oslo: Jeg hadde klart å få det inn via ett benkeforslag på
> årsmøtet høsten før, så kom vi til det første løpet og skulle dumpe
> resultatene fra MTR-2 via EMITs programvare.
>
> Ingeting virket!
>
> Jeg prøvde også ett program utviklet på Veritas, men uten hell (min
> teori er at dett var fordi våre MTR-2 enheter var helt nye, og derfor
> ikke inneholdt minst 8 løp i hukommelsen).
>
> Resultatet var at jeg på kvelden etter det første løpet måtte starte
> febrilsk prorammering:
>
> Først skrev jeg ett absolutt minimalt C program som bare gjør en ting:
>
> Åpner COMx porten og dumper hele lageret fra MTR. Disse dataene skrives
> til en disk-fil i hex-format.
>
> Resten av kvelden gikk med til perl kode som leste inn disse dataene, og
> tolket dem sammen med flate (komma-separerte) filer med post-koder,
> klasser, løyper og brikke/navn oversikt.
>
> Din versjon som bruker Tk til å gi ett bruker-grensesnitt er helt klart
> mye mere bruker-vennlig. :-)
Tk maatte neste til for at folk utenfor Unix/Linux-verden ville/kunne
bruke det :-), men tTiMe startet som et enkelt kommandobasert skript for
parsing av epttest/etiming loggfiler og lage resultater/strekktider.
Det med utlesing klarte jeg aa faa til takket ditt lille C program ...
etterpaa fant jeg og noen litt mer portable maater aa snake med MTR'er,
men begge stoettes under under Windows.
Det som jeg ser som en virklig svakhet i etiming er en database som
blander statisk loeperinformasjon og dynamisk data (MTR'er) ... gaar
databasen i vasken (har oppleved selv) blir det meget vanskelig aa huske
alle manuelle endringene. Jeg mener at det er bedre aa skille statisk,
MTR-datane og maaten man lager resultater, da kan du lage dem omigjen
senere.
-Thierry
Terje Mathisen
> Det som jeg ser som en virklig svakhet i etiming er en database som
> blander statisk loeperinformasjon og dynamisk data (MTR'er) ... gaar
> databasen i vasken (har oppleved selv) blir det meget vanskelig aa huske
> alle manuelle endringene. Jeg mener at det er bedre aa skille statisk,
> MTR-datane og maaten man lager resultater, da kan du lage dem omigjen
> senere.
Ja!
Jeg lager med vilje slike systemer som dette (også i jobb-sammenheng!)
med uavhengige input-filer for forskjellige typer data, i
orienterings-sammenheng så laget jeg ett skript for å generere
sammenlagt-lister for bedrifts-løpene i Oslo.
I stedet for å gå inn og rett opp de enkelte resultat-filene (som alle
er i html) ved en manuell korreksjon, så lagde jeg i stedet en separat
korreksjons-fil som kun inneholder tillegg/endringer til det som de
enkelte resultat-filene viser.
På ett generelt O-system så ville jeg i dag starte med en (My)SQL
database, med generelle tabeller over løpere/klubber/brikker osv.
PÅ hvert enkelt løp lages en ny DB, med tabeller over klasser, løyper,
starttider og påmeldte (ref tilbake til løper-DB).
Alle EMIT/MTR data lagres rått i en egen tabell, og alle manuelle
endringer/korreksjoner gjøres på en egen endrings-tabell.
På denne måten blir aldri noe slettet, og det er alltid mulig å kjøre om
igjen etter en vilkårlig oppdatering av basis-tabellene.
Det eneste jeg lurer litt på er om det er riktig å bruke EMIT brikke-nr
som primær nøkkel for å binde tabellene sammen, da det har vist seg at
relativt mange løpere kommer til å bruke mer enn en brikke i løpet av en
sesong (glemt brikke, stafett, byttet brikke), og bruk av brikke som
nøkkel vil gjøre det umulig å kjøre gamle resultater om igjen når
løperen har byttet brikke i mellomtiden.
Thierry Matthey
> med uavhengige input-filer for forskjellige typer data, i
> orienterings-sammenheng så laget jeg ett skript for å generere
> sammenlagt-lister for bedrifts-løpene i Oslo.
... da har du nok og lest "The Pragmatic Programmer" Hunt & Thomas :-)
> I stedet for å gå inn og rett opp de enkelte resultat-filene (som alle
> er i html) ved en manuell korreksjon, så lagde jeg i stedet en separat
> korreksjons-fil som kun inneholder tillegg/endringer til det som de
> enkelte resultat-filene viser.
Da blir det akkurat som min config-fil i tTiMe som anviser korreksjoner
eller gir instrukser hvordan resultater skal lages ... SOA ...
http://www.matthey.org/bilder/ttimeflow.png
> På ett generelt O-system så ville jeg i dag starte med en (My)SQL
> database, med generelle tabeller over løpere/klubber/brikker osv.
... eller kanskje XML, men da maa det bli en del fiks i IOF-XML
standarden. Kjell Soenniken som er en av paadriverene har det paa sin
to-do-list ...
> PÅ hvert enkelt løp lages en ny DB, med tabeller over klasser, løyper,
> starttider og påmeldte (ref tilbake til løper-DB).
>
> Alle EMIT/MTR data lagres rått i en egen tabell, og alle manuelle
> endringer/korreksjoner gjøres på en egen endrings-tabell.
... eller ren tekstfil.
> På denne måten blir aldri noe slettet, og det er alltid mulig å kjøre om
> igjen etter en vilkårlig oppdatering av basis-tabellene.
Helt enig!
> Det eneste jeg lurer litt på er om det er riktig å bruke EMIT brikke-nr
> som primær nøkkel for å binde tabellene sammen, da det har vist seg at
> relativt mange løpere kommer til å bruke mer enn en brikke i løpet av en
> sesong (glemt brikke, stafett, byttet brikke), og bruk av brikke som
> nøkkel vil gjøre det umulig å kjøre gamle resultater om igjen når
> løperen har byttet brikke i mellomtiden.
Jeg selv bruker en int som hovedindeks. Brikkenummer er nok ikke godt
nok, searlig naar du bruker leiebrikker og noen oensker aa "igjenbruke"
brikker paa samme loep ... og de som bytter brikke mellom registrering
og start. Det med navn gaar og ut, da maa du ta i tillegg klasse og
klubb ... men under "flere"-dagesloep blir det og et problem, noen kan
bytte klubb, f.e. ved aarskiftet, etc.
Det jeg kunne tenkt meg er aa laget noen ekte OO-perl-moduler s.a. man
kan skrive etiming-apps med noen faa linjer + litt GUI. Da aapner seg og
muligheter for loep med SportIdent.
-Thierry
Haavard Tveite
Et lite problem jeg observerte da jeg skulle stille klokka
i en MTR3:
Jeg startet tmktr mot MTR3. Første gang jeg stilte klokka
så alt ut til å fungere, og tida ble satt korrekt. Etter at
jeg hadde rota litt rundt og bl.a. stilt klokka en rekke
ganger begynte det å blir et ganske stort (et par minutter!)
avvik mellom det jeg satte klokka til og det som status
rapporterte.
Neste gang jeg kjørte tkmtr klarte jeg først ikke å reprodusere
problemet, samme hva jeg forsøkte. Etter ei stund kjørte jeg
en "Spool all" og "Get range", og plutselig fikk jeg et par
minutters feil igjen ved stilling av klokka. Forsøkte derfor
å starte opp på nytt og kjøre "Spool all" - ingen effekt.
Nok debugging for i dag. Problemet kan vel ligg både i MTR3
og i tmktr?
Jeg er på MS Windows plattform...
Håvard
--
Håvard Tveite
Department of Mathematical Sciences and Technology, UMB
Drøbakveien 14, POBox 5003, N-1432 Ås, NORWAY
Phone: +47 64965483 Fax: +47 64965401 http://www.umb.no/imt
Haavard Tveite
Det viser seg at feltene der en kan sette tida ikke var
begrenset til 2 siffer, så dersom en skriver inn tall uten
å slette de gamle kan f.eks. antall sekunder bli ganske
stort...
Håvard
Thierry Matthey
takk!
> Det ble litt mer debugging...
>
> Det viser seg at feltene der en kan sette tida ikke var
> begrenset til 2 siffer, så dersom en skriver inn tall uten
> å slette de gamle kan f.eks. antall sekunder bli ganske
> stort...
... ok, jeg medgir at jeg ikke har lagt til alt for mange user input
checks, det er det som "koster" tid & nerver. Det skal komme en fiks paa
dette at du ikke faar lov aa skrive bokstaver og heller ikke mer enn 2
tall for dato & tid. I tillegg har jeg lagt til en knapp for aa
aktualisere feltene med aktuell datatid.
... ideen er/var at tkmtr skal bare brukes kun for debugging ... du faar
gjoere alt, men alt paa eget ansvar ;-) ... MEN jeg vet at MTR'er har en
nok saa lei tendens til aa gaa for sakte, vet ikke helt, men det kan gaa
opp til 1s/dag!
-Thierry
Thierry Matthey
akkurat som paa Linux/Unix med "rm -rf *"