"spela in pulståg" och utvärdera?
"spela in pulståg" och utvärdera?
Hej!
Har en anemometer som sprutar ut data enligt ett icke standard protokoll.. Den skickar ut 37 bitar med en viss startsekvens, och varje bit kommer med ca 1.2 ms mellanrum.
Jag vill "spela in" pulståget med en PIC och sedan använda datan.
Min intuitiva lösningsmetodik säger:
Använd någon timer som kollar en pinne var 1.2 ms, lägg de första värdena i någon form av temporär bit-variabel och kolla om startsekvensen har kommit och sedan spara nästkommande bitar i någon vektor som kan behandlas när hela sekvensen är mottagen.
Alternativt trigga ett interrupt när något händer på pinnen, (men vad händer då om två efterkommande bitar är 0-or?
Är detta en vettig lösning eller har någon ett bättre förslag?
/ Christian
Har en anemometer som sprutar ut data enligt ett icke standard protokoll.. Den skickar ut 37 bitar med en viss startsekvens, och varje bit kommer med ca 1.2 ms mellanrum.
Jag vill "spela in" pulståget med en PIC och sedan använda datan.
Min intuitiva lösningsmetodik säger:
Använd någon timer som kollar en pinne var 1.2 ms, lägg de första värdena i någon form av temporär bit-variabel och kolla om startsekvensen har kommit och sedan spara nästkommande bitar i någon vektor som kan behandlas när hela sekvensen är mottagen.
Alternativt trigga ett interrupt när något händer på pinnen, (men vad händer då om två efterkommande bitar är 0-or?
Är detta en vettig lösning eller har någon ett bättre förslag?
/ Christian
Re: "spela in pulståg" och utvärdera?
Sätt igång en räknare som inkrementerar för varje klockpuls. Ställ sedan in hårdvaran i MCU:n så att ingången triggar när det kommer flanken (edge) och att detta resulterar i att hårdvaran sparar det räknevärde som den råkar ha i just den stunden.
Om det går eller hur är en annan sak. Men det finns andra här som kan reda ut det
Sedan kan din programkod i lugn och ro hantera räknarvärdet mellan bitpulserna. 1,2 ms är lång tid i sammanhanget. Du lär få max 37 räknarvärden att hantera. Med en 4 MHz processor har du 4800 instruktioner på dig att spara.
Efterföljande värden som är av samma nivå kan hanteras genom att mäta upp det kortaste intervallet. Som sedan används för att dela in resten av sekvensen i bitpositioner.
Om det går eller hur är en annan sak. Men det finns andra här som kan reda ut det

Sedan kan din programkod i lugn och ro hantera räknarvärdet mellan bitpulserna. 1,2 ms är lång tid i sammanhanget. Du lär få max 37 räknarvärden att hantera. Med en 4 MHz processor har du 4800 instruktioner på dig att spara.
Efterföljande värden som är av samma nivå kan hanteras genom att mäta upp det kortaste intervallet. Som sedan används för att dela in resten av sekvensen i bitpositioner.
Re: "spela in pulståg" och utvärdera?
Kan inte vara helt lätt om databitarna inte kommer med konstant
tidsmellanrum. Men om de nu gör det så borde det gå att ta reda
på när den okända dataströmmen börjar och när den borde vara
avslutad.
Hårdvarumässigt skulle jag nog bygga något i den här stilen.
Statemaskin som detekterar en viss startsekvens och ger en S-signal
till en S-R-vippa. Vippan kopplad till en AND som släpper fram
klockpulser. AND-utgången kopplad till en räknare och räknarens
utgångar kopplade till ett logiknät som detekterar 37 minus antal bitar
i startsekvens och då ger en R-signal till S-R-vippan som blockerar
klockpulserna.
Varje klockpuls kopplad till en AND som släpper fram aneometer-
pulserna till inspelnings-prylen. Varje klockpuls skiftar inspelnings-
prylens adress för lagringsplats.
tidsmellanrum. Men om de nu gör det så borde det gå att ta reda
på när den okända dataströmmen börjar och när den borde vara
avslutad.
Hårdvarumässigt skulle jag nog bygga något i den här stilen.
Statemaskin som detekterar en viss startsekvens och ger en S-signal
till en S-R-vippa. Vippan kopplad till en AND som släpper fram
klockpulser. AND-utgången kopplad till en räknare och räknarens
utgångar kopplade till ett logiknät som detekterar 37 minus antal bitar
i startsekvens och då ger en R-signal till S-R-vippan som blockerar
klockpulserna.
Varje klockpuls kopplad till en AND som släpper fram aneometer-
pulserna till inspelnings-prylen. Varje klockpuls skiftar inspelnings-
prylens adress för lagringsplats.
Re: "spela in pulståg" och utvärdera?
Hur ser starfrekvensen ut? Ingår den i de 37 bitar?
Tiden mellan datapaketen?
Tiden mellan datapaketen?
Re: "spela in pulståg" och utvärdera?
Att sampla med samma frekvens som bitsen är, enl. Nykvist, fullständigt värdelöst! Som sämst skulle jag sampla 4 gg/bit minimala bredd men helst mer.
Dessa data hade jag sedan buffrat med en tidinformation och skickat snabbast möjligt via serieporten till en PC som sparar datan som text som kan behandlas i t.ex. Excel.
Det som är intressant är vilken tid som vilken flank hände på, resten kan man räkna ut.
Dessa data hade jag sedan buffrat med en tidinformation och skickat snabbast möjligt via serieporten till en PC som sparar datan som text som kan behandlas i t.ex. Excel.
Det som är intressant är vilken tid som vilken flank hände på, resten kan man räkna ut.
Re: "spela in pulståg" och utvärdera?
När saker och ting inte är synkroniserade verkar det ju nästan som
säkrast att spela in signalen med samples och sedan analysera nivåerna
i efterhand. Som att titta på en kurvform inspelad med tex Wavosaur.
http://www.wavosaur.com/
Datanivån som släpps fram av klockpulsen i mitt exempel kan
med viss risk ändra sig under klockpulsens längd om nu databitarna
inte visar sig helt i synk med klockan. Där kanske det vore lämpligt
att sampla säg 100ggr och låta datainsamlings-prylen
ta reda på om nivån är 1 eller 0 största delen av tiden.
säkrast att spela in signalen med samples och sedan analysera nivåerna
i efterhand. Som att titta på en kurvform inspelad med tex Wavosaur.
http://www.wavosaur.com/
Datanivån som släpps fram av klockpulsen i mitt exempel kan
med viss risk ändra sig under klockpulsens längd om nu databitarna
inte visar sig helt i synk med klockan. Där kanske det vore lämpligt
att sampla säg 100ggr och låta datainsamlings-prylen
ta reda på om nivån är 1 eller 0 största delen av tiden.
Re: "spela in pulståg" och utvärdera?
> Den skickar ut 37 bitar med en viss startsekvens, och varje bit kommer med ca 1.2 ms mellanrum.
Om du fixar än specifikation på protokollet så går det att svara på det specifika fallet.
Annars blir det enbart ett generellt svar att du får spela in det ungefär som en vanlig
logikanalysator gör, sen om du gör det med ett instrument eller med en PIC spelar
kanske mindre roll (men ett instrument verkar enklare).
Men om du inte är 100% säkert på hur protokollet ser ut så blir
det lite svårt att skriva kod som ska koda av ett gissat format.
Notera att om det är 37 pulser utan någon synkning under tiden så
får du inte ligga speciellt fel i timingen, någon enstaka %, förutsatt att
din timing hamnar "mitt i" från start...
Om du fixar än specifikation på protokollet så går det att svara på det specifika fallet.
Annars blir det enbart ett generellt svar att du får spela in det ungefär som en vanlig
logikanalysator gör, sen om du gör det med ett instrument eller med en PIC spelar
kanske mindre roll (men ett instrument verkar enklare).
Men om du inte är 100% säkert på hur protokollet ser ut så blir
det lite svårt att skriva kod som ska koda av ett gissat format.
Notera att om det är 37 pulser utan någon synkning under tiden så
får du inte ligga speciellt fel i timingen, någon enstaka %, förutsatt att
din timing hamnar "mitt i" från start...
Re: "spela in pulståg" och utvärdera?
Där finns ingen synkronisering, bara 37 bitar där startsekvensen (5bitar) ingår i dem 37.
Så sekvensen börjar med 5 bitar start 11011
Följt av 4 bitar vindriktning och 12 bitar vindhastighet.
De resterande är sedan en repetition av riktningen och hastigheten.
Har tittat på pulserna med en logikanalysator..
Så då får jag väl trigga ett interrupt och starta en timer, sampla med 1.2 ms mellanrum. Kolla om jag får startsekvensen och sedan sampla 32 bitar..
Så sekvensen börjar med 5 bitar start 11011
Följt av 4 bitar vindriktning och 12 bitar vindhastighet.
De resterande är sedan en repetition av riktningen och hastigheten.
Har tittat på pulserna med en logikanalysator..
Så då får jag väl trigga ett interrupt och starta en timer, sampla med 1.2 ms mellanrum. Kolla om jag får startsekvensen och sedan sampla 32 bitar..
Re: "spela in pulståg" och utvärdera?
Vad ska du trigga interruptet på ?
Alltså, vad använder du för att identifiera start på ett 37-teckens paket ?
Eller, hur vet du att dina 1.2 ms samples hamnar mitt i bitarna ?
Ska du trigga om/synka om inför varje nytt 37-teckens paket ?
Sänder den kontinuerligt ? Hur ser det ut innan startsekvensen 11011 ?
Hur ser dataformatet ut efter 11011 ? Är det gjort så att 11011 inte kan förekomma ?
Alltså, vad använder du för att identifiera start på ett 37-teckens paket ?
Eller, hur vet du att dina 1.2 ms samples hamnar mitt i bitarna ?
Ska du trigga om/synka om inför varje nytt 37-teckens paket ?
Sänder den kontinuerligt ? Hur ser det ut innan startsekvensen 11011 ?
Hur ser dataformatet ut efter 11011 ? Är det gjort så att 11011 inte kan förekomma ?
Re: "spela in pulståg" och utvärdera?
Du säger cirka 1.2 ms.... är det alltid lika lång tid mellan bitarna?
Hur ser det ut på "linan" innan de fem startbitarna? Är det en lång tidsperiod med bara etta eller nolla? Man bör ju kunna avgöra när de fem bitarna kommer, för det finns väl en risk att samma sekvens råkar uppstå bland de övriga 32 bitarna?
Det säkraste är ju att man synkroniserar vid varje omslag - och sedan samplar man efter 0.6 ms samt följande + 1.2 ms ända tills nästa omslag då man synkroniserar om igen.... sedan kan man försöka leta upp startbitarna i detta och plocka ut resten.
UART-läsare samplar ofta tre gånger i varje bit - nånstans i mitten efter ca. 3/8, 4/8 och 5/8 av tiden. om inte alla tre är samma så sätts felflagga och så tar man majoriteten.
Hur ser det ut på "linan" innan de fem startbitarna? Är det en lång tidsperiod med bara etta eller nolla? Man bör ju kunna avgöra när de fem bitarna kommer, för det finns väl en risk att samma sekvens råkar uppstå bland de övriga 32 bitarna?
Det säkraste är ju att man synkroniserar vid varje omslag - och sedan samplar man efter 0.6 ms samt följande + 1.2 ms ända tills nästa omslag då man synkroniserar om igen.... sedan kan man försöka leta upp startbitarna i detta och plocka ut resten.
UART-läsare samplar ofta tre gånger i varje bit - nånstans i mitten efter ca. 3/8, 4/8 och 5/8 av tiden. om inte alla tre är samma så sätts felflagga och så tar man majoriteten.
Re: "spela in pulståg" och utvärdera?
En metod för att sampla/spela in signaler för senare analys, te.x vid protokoll analys, är att använda sig av ljudkortet i en dator.
Jag har använt den metoden ett flertal gånger med lyckat resultat, men det kräver att ljudkortet faktiskt klarar den frekvens du försöker mäta dock.
Vid relativt låga överföringshastigheter som t.ex. trådlösa NEXA strömbrytare, så har jag både spelat in, analyserat, reproducerat signaler till och från dessa med lyckat resultat. Det finns ett antal verktyg framtagna för just detta att spela in och analysera signaler genom ljudkortet, som t.ex. oscilloscop mm.
När det gäller att avkoda det modulerade "datat" i en transmission så måste du nog ha någon form av processor som gör arbetet, de i tråden föreslagna funkar nog bra, men alla kräver en genomtänkt och bra mottagningsrutin. Detta kräver att man exakt vet hur mottaget data har för format är modulerat (det sk. protokollet), är det t.ex. manchesterkodat eller inte, binärt eller trinärt osv. , jag brukar oftast köra med timers och interrupt när jag gör mottagare, men som sagt, sända data är inga problem, ta emot å andra sidan kräver lite mer.
Jag har använt den metoden ett flertal gånger med lyckat resultat, men det kräver att ljudkortet faktiskt klarar den frekvens du försöker mäta dock.
Vid relativt låga överföringshastigheter som t.ex. trådlösa NEXA strömbrytare, så har jag både spelat in, analyserat, reproducerat signaler till och från dessa med lyckat resultat. Det finns ett antal verktyg framtagna för just detta att spela in och analysera signaler genom ljudkortet, som t.ex. oscilloscop mm.
När det gäller att avkoda det modulerade "datat" i en transmission så måste du nog ha någon form av processor som gör arbetet, de i tråden föreslagna funkar nog bra, men alla kräver en genomtänkt och bra mottagningsrutin. Detta kräver att man exakt vet hur mottaget data har för format är modulerat (det sk. protokollet), är det t.ex. manchesterkodat eller inte, binärt eller trinärt osv. , jag brukar oftast köra med timers och interrupt när jag gör mottagare, men som sagt, sända data är inga problem, ta emot å andra sidan kräver lite mer.
Re: "spela in pulståg" och utvärdera?
Atmels AVR mikrokontrollers har ett läge som kallas "capture register" som innebär att värdet i en timer kopieras av när en yttre signal triggar. Låter man timern drivas av klockpulser från en oscillator så kan man genom att spara dessa timervärden räkna ut med stor precision hur signalen ser ut.
Test att söka på: +"capture register" timer +AVR
Ljudkort brukar ha problem med DC-nivåer pga filter på ingången.
Test att söka på: +"capture register" timer +AVR
Ljudkort brukar ha problem med DC-nivåer pga filter på ingången.
Re: "spela in pulståg" och utvärdera?
Det är väl det enda sättet att lösa sånt? Det gör man ju både vid asynkron och synkron överföring (med skillnaden att vid asynkron synkar man vid varje tecken medans vid synkron synkar man vid varje paket).sodjan skrev: Ska du trigga om/synka om inför varje nytt 37-teckens paket ?
Re: "spela in pulståg" och utvärdera?
Och nästan alla mikroprocessorer (inte bara AVR) har en Capture-funktion!
Re: "spela in pulståg" och utvärdera?
>>Ljudkort brukar ha problem med DC-nivåer pga filter på ingången.
nja... men i det här fallet handlar det ju om millisekunder - och det är ju flankerna som ska kollas upp - de är inte "DC", så det funkar bra med ljudkortet. Vill man inte ha en DC-offset på ljudkortets ingång kan man filtrera själv först med en kondensator och ett motstånd mot jord, så kommer signalen att hålla sig kring ett medelvärde på 0V.
nja... men i det här fallet handlar det ju om millisekunder - och det är ju flankerna som ska kollas upp - de är inte "DC", så det funkar bra med ljudkortet. Vill man inte ha en DC-offset på ljudkortets ingång kan man filtrera själv först med en kondensator och ett motstånd mot jord, så kommer signalen att hålla sig kring ett medelvärde på 0V.