Hur synca en tid? (trådlöst mellan två arduinosar)

[FormerMazda]

Har dock läst om att "mina" går längre med lite antennjobb.
Men dina lockar då allt sånt är fixat redan.

Men det jag funderar på nu är hur fort saker sker med en sån här lösning med seriell via radio.
Som sagt så kanske det bara är att labba sig fram som ger svar.

[Nerre]

Så även om GPS-idén skulle fungera så kan jag ju bara vara säker på att dom är syncade på en sekund. Inte vilken sekund. Vilket gör det svårt att räkna ut ET, alltså hur lång tid hela sträckan tog att köra. Skulle tro att den tiden är allt mellan .. inte en aning, men runt 10 sekunder kanske.

Det borde väl inte vara så svårt att gå igenom koden och ersätta anropen av den där millis()-funktionen med anrop av en egen funktion som returnerar millisekunder sen en specifik tidpunkt?

Med den faslåsta räknare som räknar millisekunder så får du millisekunderna, sen får du då addera ett sekund-värde till det. Med GPS så får du ju utöver sekund-pulserna även UTC-tid, om du helt enkelt plockar ut sekundvärdet från den tiden så borde det väl räcka? (Du får lov att lägga in lite kontroll för att hantera om sekunderna wrappar under körningen.)

[Swech]

Den största felkällan är radiolänken, den tid det tar bidrar mest till ostabila värden.
Gps i all ära, men man vill nog gå över ån i detta fallet....

sedan är det sällan någon ifrågasätter ett sådant tidtagarsystem....

Swech

[FormerMazda]

Nerre > Så sant. millis() är ju lätt att ersätta med egen funktion som är justerad efter UTC + sekundtick från GPS. En tanke är planterad.

Swech > "den tid det tar bidrar mest till ostabila värden." Jag förstår inte? Förklara så jag fattar. (För en en femåring tydligen )

[Icecap]

En radiolänk har en viss latency, alltså tid från det att data skickas in till de kommer ut. Utgår man ifrån t.ex. den typ som Swech säljer samlas det ihop en block bytes och när nog är samlat ihop - eller det blir ett uppehåll på en viss tid - skickas de data som sedan börjar ramla ut i andra ändan.

Det är mycket svårt att veta exakt vilken latency som gäller, det beror på den interna timers upplösning, antal bytes osv.

Kommunicerar man t.ex. med 9600 baud och ska sända 10 bytes tar det 10,4166667ms att skicka data in i radion. Sedan ska det väntas en viss tid för att det ska detekteras att "nu är det slut på data för denna gång". ER400-serien använder 3 bytes tid vilket alltså motsvarar 3,125ms. Men exakt när räknas tiden ifrån? Och hur exakt är denna tidmätning?

Om timern t.ex. kör med 1ms i upplösningen kommer latency alltid att variera med minst 1ms.

Sedan är det avståndet mellan sändare och mottagaren, det har också betydelse även om ljusets hastighet är hög.

Men det går att lösa om man tänker till, det blir dock mycket svårt att få ms-noggrannhet på denna synkronisering.

Om t.ex. det skickas ett paket med en tid från A till B. I paketet ingår det en "skicka tillbaka direkt"-flagga och B skickar då tillbaka till A omedelbums. Då kan A kolla "vad är tiden nu kontra då jag skickade den?" och med några paket fram och tillbaka på det vik kan det räknas ut en kompensering och man kan då få det hela ganska hyggligt noga.

Men det måste finnas en TCXO i vardera ända för att man ska ha chans för att det ska fungera.

[ronnylov]

Om man ska synka två klockor mot varandra bör man nog göra det två gånger - dels före och dels efter tidmätningen. Då kan man förutom offset även få med hur mycket de har dragit sig mot varandra och kan sedan kompensera mot deras olika hastigheter. Men för att mäta rätt så behöver man ändå en kalibrerad referens att jämföra mot (den ena man jämför mot kan man förstås kalla referens om man vill). Referensen är alltså den som mäter "rätt" som de övriga ska rätta sig efter. Denna referens skulle kunna vara GPS-baserad.

RTC kan väl (och bör väl) ha batteribackup så att den inte påverkas av omstarter. Om de då har varsin RTC så borde man kalla en av dem referens och så kopplar man ihop dem före tävlingen och efter tävlingen och jämför dem mot referensen. Fast då får man inte veta resultaten förrän efteråt och det kanske inte riktigt var meningen? Man skulle ju kunna kalibrera upp klockorna i förväg också så att man har koll på hur mycket de diffar i hastighet och ha någon förinställd kompensation. Men så kanske saker som temperaturskillnader, slumpen och annat börjar påverka.

Om klockorna är väl synkade så gör det väl inte så mycket om det är tidsfördröjning i överföringen så länge som korrekt tid vid tidpunkterna för start och stopp överförs som data i den trådlösa länken mellan enheterna. Alltså man skickar inte enbart över start och stoppkommandon utan man skickar "start inträffade klockan x", "stopp inträffade klockan y" och så räknar man ut skillnaden y-x helt enkelt. Vid behov korrigerar man tiderna vid den slutgiltiga tidsynken efter tävlingen då man vet hur mycket fel realtidsklockorna har visat under tävlingen.

GPS-signalen kanske man kan använda som referens vid kalibreringen av klockorna. Man låter klockorna gå i flera dagar eller veckor och loggar hur mycket de driver mot referensen. Kanske kan man ha något smart system som kontinuerligt räknar ut kompensationsvärden för klockornas kristaller så att de hela tiden håller sig välsynkade mot GPS på lång sikt (och därmed bör de mäta hyfsat bra även på kort sikt). Då gör det inte så mycket om de råkar tappa GPS-signalen tillfälligt eftersom de mäter så pass bra på egen hand. Sedan får man väl studera statistiken, räkna på standardavvikelser och sådant för att få fram en felbudget och en uppskattad mätosäkerhet. Eller så nöjer man sig med databladet på RTC-klockan och räknar på vad det blir för felvisning i värsta fall.

[FormerMazda]

Ju mer jag funderar på saken så inser jag att det blir bara knöligare och knöligare att lösa för att få nåt som är nåt om nåt exakt.
Men sen när jag googlar på riktiga system för tidtagning och startgran och grejer, så inser jag att ingen av dom jag hittat kör trådlöst. Alla kör trådat. Det borde finnas en anledning..

Så det kanske blir trådat trots allt. Finns ju billig "telefontråd" på biltema: http://biltema.se/sv/Kontor---Teknik/Da ... bel-44276/

Det löser ju egentligen alla problem jag har.

[superx]

Borde det inte finnas någon analog radiolösning som kan funka? Den enda informationen som behöver föras över synkroniserat är väl egentligen precis när själva starten går (sedan kan ju enheten vid målet mäta hela loppets tid själv)?

Jag tänker mig någon grej som skickar toner och byter frekvens på tonen när starten går, eller något annat superenkelt protokoll som kan detekteras mer eller mindre analogt.

Äh, kabel är väl enklare såklart, men radio är roligare!

[Hedis]

En sak till att tänka på när ni pratar om att köra med direkt signalering (alltså tex., NU! kom bana 1 i mål o då låta startenheten ut ET) är att radiostörningar från tex. taskiga tändsystem mm förstör detta helt.
Så enda rätta är nog som du redan är inne på att använda en synkad klocka och då i lugn och ro kunna skicka över måltiden, hastigheten och så vidare med både ack på paketen och möjlighet till omsändning om datan uteblir eller blir korrupt.

Många bilklubbar har ju sina egna system för mätning av tider vid acc-körning och även konbanor osv. och iaf i STCS (SaabTurboClubSweden) så har största felkällan och orsaken till avbrott och panik innan start varit att kabeln glappat/gått sönder/blivit avkörd osv. Så försök i möjligaste mån att undvika den. Med dagens priser på GPS-moduler och radiolänkar så ser jag ingen direkt anledning till att inte köra med något sådant när det ska vara smidigt att hantera och driftsäkert.

[Josasp]

Vet inte om exaktheten på GPS klockan mellan enheter.

Men vill minnas att Ubiquiti använder GPSer i sina RocketStations för att synca datatransmissioner i samma mast.
För att minska störningar mellan enheter i samma mast. Jag tänker mig att om GPS duger till att synca datapaket i TDMA så borde det duga till en klocka med

[Nerre]

Ja, GPS-klockan är väldigt exakt, eftersom mottagaren baserar klockan på input från flera satelliter (som var och en har ett eget atomur).

GPS-tid brukar räknas som stratum-0.

Så det enda "problemet" här blir att synka mikrocontrollerns "klocka" mot GPS:ens signal.

[Andax]

Många gpsmottagare brukar speca jittret på 1 PPS pulsen till ca 50-100 ns. Och det är ju väldigt enkelt att bygga mot en mikrokontroller. Man får en seriesträng via RS232 med absolut tiden i sekunder för 1PPS pulsen. Vid varje 1PPS puls läser man av milli_pps = millis() och vid varje start stop puls läser man också av milli_stop = millis(). absoluttiden är ju sedan bara att ta sekund-tiden + milli_stop-milli_pps.

Man kommer ju inte ifrån att man måste skicka start tidens absolutvärde till målgången för att räkna ut körtiden.

[LaRdA]

Jag har tittat på att göra en liknande tidtagningslösning som då ska användas vid en backtävling.
I dagsläget så används en gammal tidtagningsutrustning för skidåkning, med nackdelen att man måste dra en kabel flera hundra meter igenom skogen till målgången.
Den lösningen jag har fastnat för främst är samma som ni har diskuterat här, att köra med en GPS mottagare för att synkronisera tiden mellan enheterna och sedan skicka start/stop tiderna mellan enheterna antingen via radiolänk eller genom att man kopplar dom till en dator med internetuppkoppling.
Fördelen är att om man vill så är man är helt okänslig för fördröjningar i överföringen, lösningen kan tom fås att fungera genom att skriva ner tiderna på ett papper och springa emellan start och mål.
Samt att om man låter programmet logga alla tider så kan man i värsta fall sammanställa tiderna i efterhand även om radiolänken/internetuppkopplingen skulle lägga ner.