Tidtagningssystem

[cjonash]

Då är det dags för min första projekttråd...

Här kommer det handla om utvecklingen och bygget av ett tidtagningssystem, som skall användas som en del i ett mycket större projekt, nämligen grafik- och spelsystem till en stor gameshow för en nordisk tv-kanal.

Det har ju funnits en del trådar om tidtagning tidigare, och förhoppningsvis finns det någon som kan ha intresse av den här tråden i andra sammanhang också.

Själva tidtagningssystemet består av ett antal givare (fotoceller och tryckknappar för deltagarna), en klocka med ingångar för dessa och sen så klart en del mjukvara. Detta kopplas sedan ihop med resten av spelsystemet (som bl.a. består av 7 st grafikmaskiner, 6 st Windows 8 Tablets, kopplingar till ljusstyrning och en del annat roligt).

Hjärtat i tidtagningen är den klocka som den här tråden kommer handla om. Den har egentligen bara en, men en viktig, funktion: att kunna tidsstämpla allt som händer på dess ingång med en hög noggranhet. Den informationen ska skickas till den anslutna datorn, som sedan räknar ut tiderna genom att helt enkelt subtrahera starttiden från sluttiden. För att kunna visa en "rullande" klocka skickar den också ut en kontinuerlig tidskod. Liknande system finns att köpa färdiga från t.ex. Alge Timing, och används på allt från bilsport till alpin slalom. Men dessa system är allt annat än billiga, och heller inte lika roligt som att bygga själv...

I det här fallet handlar det både om att kunna ta tid på en händelse, där fotoceller genererar start och stoppulser, dels om att kunna avgöra t.ex. vem som tryckte först på sin knapp i en frågesport.

Som utgångspunkt för konstruktionen gällde att det behövdes minst 8 ingångar, den behöver ha en noggranhet på misn 1/100 sekund, ingångarna måste vara avstudsade för att undvika flera triggers på en knapptryckning, och den skall kopplas till PC:n med RS-232. Slutligen fanns det ungefär 2 veckor från beslut tills den måste vara färdig...

Så långt om förutsättningarna, som dom såg ut när jag startade projektet för ca 2 veckor sedan. Den uppmärksamme noterar att det innebär att det ska snart vara färdigt, och så är också fallet. Så det kommer gå relativt kort tid innan den här tråden kommit betydligt längre i processen!

[Lennart Aspenryd]

Är lite nördig på autonoma TS (TimeStamp) system så detta skall bli riktig kul att följa, och snabbt!

[cjonash]

Utifrån förutsättningarna var det då dags att komma igång. Eftersom jag i modern tid främst sysslat med programmering på PC (jobbar ju med tvproduktion egentligen), och det gått ett antal år sedan jag höll på med elektronikkonstruktion, så fanns det en del att ta ställning till:

- Plattform (val av mikroprocessor)
- Kretskort (göra själv eller lämna bort)
- Låda / inkapsling
- Tid (som i att det måste gå snabbt)

Eftersom jag, i samband med ett tv-jobb i Norge, tvingats lära mig en del om Arduino, så föll valet rätt snabbt på den utvecklingsmiljön. Dessutom hade jag kvar en Arduino Uno som blev över från det jobbet, så det kändes som en bra start.

Eftersom det handlar om att tidsstämpla events, om man därmed måste ha någon form av referensklocka, så kändes det som att Time-of-day är det bästa sättet - även om det inte är nödvändigt (det är ju skillnaden mellan två tider som egentligen är intressant). För att slippa tvingas ställa klockan varje gång man startar systemet ville jag ha någon form av RTC med batteri i systemet. Valet föll på en ChronoDot http://www.adafruit.com/products/255, bl.a. för att jag har extremt liten erfarenhet av ytmontering och här fick jag en färdig modul.

Tanken var (och är) att time-of-day laddas från RTC när systemet startar. Sedan körs på intern klocka (eftersom högre nogrannhet krävs) som startar på den laddade tiden. Det ska också gå att ställa klockan från PC-interfacet (samt synka flera enheter genom att förladda en tid från PC'n till alla enheter och sedan ge dem en gemensam startsignal genom att parallellkoppla en ingång från varje enhet).

Ett par ChronoDot beställdes från Lawicel, och redan nästa dag kunde den första prototypen byggas:

prototyp.jpg

Några timmars kodning senare, så hade jag en fungerande klocka, om än bara med en ingång. Den använder en upplösning på 1/1000 sekund, och skickar varje tiondel ut på serieporten (12:01:02.1 - 12:01:02.2 osv). För varje event skickas ingångsnummer och exakt tid (C1 12:01:02.214). Proof of concept klart - nu återstår resten...

En intressant frågeställning, som saknar betydelse i mitt sammanhang men kan vara aktuellt för andra, är hur pass bra den håller sin tid över en längre tid. Detta har jag inte testat ännu - ej heller hur bra två enheter står sig mot varandra. Det senare kommer dock att testas, eftersom jag bygger totalt 4 enheter. Med hjälp av synk-funktionen och en lämplig testmjukvara på PC:n blir det lätt att se diffen mellan två eller flera enheter.

[Lennart Aspenryd]

Häpp, häpp, Jättebra
Där ser man vad en av världens snabbaste mellanhänder kan åstadkomma.
Lite kod och exempel som du kör i PC miljö emotses tacksamt!

Hur identifierar du de enskilda enheterna?

[Nerre]

Är det kollat så koden hinner med och gör rätt om t.ex. alla ingångar aktiveras samtidigt? Eliminerat eventuella race conditions?

[cjonash]

Med en fungerande prototyp så blev nästa steg att ta fram ett komplett schema, och så klart en kretskortslayout.
Efter att ha läst en del här på forumet, men också på andra ställen, blev valet att använda Eagle för att göra båda delarna. Kom ihåg att det som sagt var länge sedan jag höll på med liknande projekt, så inga val är självklara för mig i det här läget, utan jag försöker sätta mig in i de olika alternativen och ta ett välavägt beslut...

Ett beslut som togs tidigt var att inte bygga systemet på ett arduino kort (även om jag ett kort tag övervägde det av tidsskäl), utan det skulle tas fram ett kort som innehöll all elektronik.

Det tog ett tag, och rent ritningsmässigt blev det kanske inte perfekt, men ett schema lyckades jag i alla fall få fram:

mainboard.pdf

För att göra layouten så placerade jag komponenterna i vad jag tyckte var en bra placering, och lät Eagle autorouta kortet. Jag blev positivt förvånad efter första försöket! Med lite flyttande och roterande av komponenter, så fick jag till slut en layout jag kände mig ok med:

pcb.jpg

Sedan gällde det att ta ett beslut om hur kortet skulle tillverkas. Ganska tidigt valde jag att inte göra det själv. Även om jag gjort det tidigare så ville jag inte göra något som i bästa fall skulle fungera men inte se så fint ut (och kanske heller inte fungera efter ett tag). Eftersom EuroCircuits http://www.eurocircuits.com/ kan ta Eagle filer direkt, och desstom kan leverera snabbt, så föll valet på dem.

Jag skickade filerna till dem på natten mellan den 6 och 7 maj, och på morgonen den 10 maj kommer 6 st kort med UPS (beställde 5 kort men fick tydligen 1 extra):

kort.jpg

[cjonash]

Hur identifierar du de enskilda enheterna?

Varje ingång har ett nummer (0 - 7), och det "kanal"-numret skickas med i dataströmmen. protokollet som skickas till PC'n är faktiskt det samma som i Alge Timings eftersom jag redan gjort ett interface till deras klockor för alpin-tävlingar i samband med en tidigare tv-sändning. Har man flera klockor, så är de ju kopplade till olika serieportar, och kan på så sätt skiljas åt i programmet.

Exakt ser protokollet ut så här:

Löpande tid (skickas 10 ggr per sekund):
HH:MM:SS.T<CR>

Event (skickas direkt på event):
b####bCXbHH:MM:SS.TTTTTb00<CR>

där b = space, #### = löpnummer, X = kanelnummer, TTTTT = 1/10000 sekunder och de två sista 00 vet jag faktiskt inte varför de är där... Eftersom jag använder deras protokoll så måste jag skicka tiden som 1/10000, men i mitt fall är alltid sista siffran 0 (och så är det även i många av deras egna klockor, beroende på vilken sport de är inställda på).

I datorn är det sedan lätt att skilja event från löpande tid redan på att det första tecknet är ett mellanslag om det är ett event.

[cjonash]

Är det kollat så koden hinner med och gör rätt om t.ex. alla ingångar aktiveras samtidigt? Eliminerat eventuella race conditions?

Ingångarna kollas i en loop som är ett fåtal instruktioner lång (har inte mätt hur lång tid den tar, men det kan inte handla om någon lång tid). Om en ingång är aktiverad skickas direkt den aktuella tiden. Om flera ingångar hunnit aktiveras samtidigt sedan senaste koll, skickas förvisso alla efter varandra (med ingång 0 först), men eftersom det i såfall gått mindre än 1 ms mellan dem så skulle de ändå få samma tid. Så länge det går minst looptiden mellan eventen, så kommer de oavsett att komma i rätt ordning till PC:n.

Utöver detta ligger all logik i den mottagande mjukvaran (pc). Klockan skickar bara eventen, race logiken ligger helt i databas och PC. Skulle kanske göra en projekttråd om detta också när jag får tid - finns en del att tänka på när man gör den mjukvaran också...

[Icecap]

Dallas har ju en RTC som är "rimligt noga". DS3231/DS3232 (I²C), DS3234 (SPI). Där är allt inbyggd och temperaturkompenserat.

[cjonash]

Med korten beställda, så var det hög tid att fundera på inbyggnaden.
Eftersom systemet skall användas i en tv-studio, så är det en fördel om det ser något sånär proffsigt ut - även om det inte syns i bild så skall det ju få medarbetare och (framför allt) deltagarna att "lita på" att det fungerar felfritt.

Redan från början hade jag bestämt att alla ingångar till klockan skall vara med banankontakter (väldigt vanligt i tidtagningssammanhang) och med en parallellkopplad D-Sub för anslutning av en break-out box. Serieporten så klart en D-Sub, och ström in med en 4-pol XLR för 12VDC (vanligt i TV-sammanhang).

Med i princip ingen erfarenhet av metallarbete, och ännu mindre lust att göra om lägenheten, där jag också har mitt kontor, till metallverkstad så fick det även här bli externa leverantörer. Till saken hör att jag inte heller är så erfaren med CAD program. Jag behövde en låda där mitt kort får plats, och med hål för alla kontakter. Och gärna med gravering eller tryck av text till anslutningarna. Efter lite research så hittade jag tre företag som verkade kunna göra vad jag behövde - och inom den tid som fanns till förfogande:

- Schaeffer AG (Tyskland) http://www.schaeffer-ag.de
- Protocase (Kanada) http://www.protocase.com/
- Panel Print (England) http://www.panel-print.com/

De två första har gjort egna (enkla) CAD-program anpassade till deras produktion, så av det skälet föll Panel Print bort ganska tidigt. Shaeffer och Protocase har ganska olika typ av lådor, och jag fastnade för Protocase. På bara några få timmar ritade jag upp lådorna (en till klockan, och en till break-out boxen). Priset ser man direkt i programmet, och man skickar även beställningen direkt därifrån.

Så här såg klockan ut i programmet när jag skickade iväg den:

klocka.jpg

Och så här såg break-out boxen ut:

breakout.jpg

Detta skickade jag in den 7:e maj, och den 8:e fick jag en PDF med riktiga cad-ritiningar gjorda av dem för godkännande. I skrivande stund ligger paketen i DHL's bil någonstans i Göteborg på väg hit...

[cjonash]

Dallas har ju en RTC som är "rimligt noga". DS3231/DS3232 (I²C), DS3234 (SPI). Där är allt inbyggd och temperaturkompenserat.

Det är den som sitter på ChronoDot (DS3231), och som jag använder för att "spara" tiden när systemet är avstängt. Dock har jag inte hittat ett sätt att få ut tider med 1/100 sekunds nogrannhet ur den - annars hade jag låtit hela tidshanteringen göras i den.

[Nerre]

Hur funkar det om en ingång triggas innan meddelandet om dess förra triggning hunnit skickas klart? Buffras alla meddelanden och hur mycket klarar då bufferten? Och hur hanteras buffer overflow?

[cjonash]

Hur funkar det om en ingång triggas innan meddelandet om dess förra triggning hunnit skickas klart? Buffras alla meddelanden och hur mycket klarar då bufferten? Och hur hanteras buffer overflow?

Efter att en ingång har triggats, måste den vara "oaktiv" i minst 50 ms innan den kan triggas igen. Dvs, den triggar direkt men sedan är den låst tills den dels gått tillbaka till otriggad status och dels stannat där i minst 50 ms. Därmed kan inte en trigg skickas innen den föregående skickats klart. I den mottagande PC'n buffras alla inkommande event, i en (åtminstone praktiskt) oändlig buffer.

Nu kan nog en del undra över den här 50 ms blockeringen - men i praktiken har den inga nackdelar men en del fördelar. En fördel (den avgörande för mig) är så klart att den tar bort kontaktstuds från strömbrytare.
Faktum är att de flesta klockor jag kommit i kontakt med fungerar på samma sätt - flera med ännu längre blockeringar (jag har sett upp till 3 sekunder).

Anledningen är att de applikationer man använder dessa system i inte kan få korrekta mätdata snabbare än så. Här är två exempel:

I en skidtävling (där man använder fotoceller och inte transponder-tidtagning) kan bara en deltagare passera mållinjen åt gången. Dvs det kommer gå långt mer än någon sekund mellan triggers.

I fallet med deltagare som skall trycka på knappar skall dom ju bara kunna trycka en gång. Sen dröjer det lång tid innan nästa tävling där dom skall kunna trycka igen.

Ofta ligger det medvetna blockeringar i den mottagande mjukvaran som är betydligt längre, för att undvika falska event och att komma "fel" i racet.

[Nerre]

Ja det var inte mottagande sidan jag funderade över buffring på utan den sändande.

Just för de typer av applikationer du nämner så funkar det ju antagligen bra med blockering, jag var mer inne på generella tankegångar:)

[Icecap]

cjonash: OK, då är tidbasen helt OK. Men OM det är möjligt kan man ju skapa en "kickstart" vid att använda larm-utgången. När allt initieras kan man läsa RTC'n, ställa in ett larm 2 sekunder fram efter att ha ställt allt klart och när larmet kommer (extern interrupt eller wait-loop som kollar pinne) Startar man den interna 1/1000-del timer och de är synkroniserat.

Man kan synkronisera t.ex. var 10 sekund på det vis och då "trimma" den interna klocka till att synka med RTC'n. Lite pilligt till en börja men synnerligt exakt sedan.