I samband med den frekvensgenerator jag har tillverkat uppstod problemet at mäta frekvenser mellan 125mHz och 50kHz.
Har en frekvensräknare (GW Universal Counter GUC-2010G) som fungerar hyggligt och verkar ganska precis. Den har längste gatetid på 10 sek, det är en dryg tid att vänta, speciellt när upplösningen bara kan bli i 0,1Hz.
Satt därför och funderade lite på att hitta ett snabbare och enklare sätt här till kvällen.
Praktik: på långsamma frekvenser kan man räkna pulstiden (stigande flank till stigande flank) med en timer i rätt läge, på en PIC kallas det "Capture" och det har jag sett andra ställe också så den tar vi. Det betyder att jag kan få ut mHz-frekvenserna med trevlig upplösning och att jag kan få en utläsning för varje puls.
Men högre upp i frekvenserna då? Ska jag visa på ett display kan det kvitta att ha en slukt snabb uppdatering av utläsningen, 3 gg/sek är allt som behövs.
Så jag tuggade lite på det och kom på en lösning. Den lösning kräver en capture-enhet + ytterligare en timer ställd som pulsräknare samt en aning logik.
Man har ett ingångssteg som tål det mesta, tänker att jag skulle hitta på nätet och "tjuva lite".
Signalen från ingångssteget går då till Clock-ingången på en D-flipflop MED Set & Reset-pinnar också, signalen går även till en AND-gate's ena ingång.
D-flipflop'ens Q-utgång går dels till Capture-ingången och dels till andra ingången på AND-gaten. Utgången från AND-gaten går till en Timer-ingång som är ställd i pulsräknare-läge.
D-flipflop'ens D, Set & Reset-ingångar styrs av µC'n.
Funktion:
* Frekvensmätning:
--- D sätt till '0', FF'en resets, Capture-enhetem nollas och sätt till att fånga BÅDA flanker och pulsräknaren nollas.
--- När µC'n är klar skickar den en '1' till D-ingången på FF'en.
--- Vid första stigande flank "flippar" Q-utgången till '1', det kommer en startpuls på Capture-enheten och pulsräknaren börjar räkna antal pulser.
--- Efter ett lagom tag skickar µC'n '0' till D-ingången på FF'en, förstkommande stigande flank skickar igenom den '0' och får Capture-enheten att ge ytterligare en interrupt, '0'-an stoppar ytterligare räkning av antalet pulser också.
Nu vet man alltså antalet pulser som har kommit och tiden som dessa har tagit, sedan kan lite matte räkna ut detta väldigt enkelt med mycket bra upplösning.
Vill man kan man ha en valfri prescaler direkt efter införstärkaren, kan man växla den som t.ex. 1:1 eller 1:256 ville detta medge att man kan spänna över ett mycket brett frekvensområde med bra upplösning + snabb utläsning.
Mätningspulsens längd är inte kritisk då man likaväl får rätt tal att räkna på, en vanlig timer duger alltså fint, t.o.m. ett mjukvarustyrd delay skulle duga.
Om man sedan väljer 1:1 i prescaler (om man bygger på det), ställer Set på FF'en till '1' kan man i lägre frekvenser ställa pulsräknaretimern till Capture-mode, fånga båda flanker och då få ut pulsbredd på endera nivå, duty-cycle och vad man annars ids räkna ut. Vill man kan man samla ihop data över ett antal cyklar och ta ett snitt, allt detta styrs av mjukvaran.
Hårdvaran är alltså "hur enkel som helst": ett input-steg (kan ju bli lite knepigt, speciellt vid höga frekvenser), en D-flipflop (kanske 7474), en AND-gate (kanske 74AHC1G08) samt en µC (jag väljer nog Renesas M16C28). Till det kan man lägga en prescaler och logiken för att välja "med eller utan nerdelning".
MEN... noggranheten beror självklart på µC's klocka, där duger det inte med vad som helst. Jag har ett par DS8000 liggande, de finns inte mer men det är TCXO'er på 8MHz med ett antal nollor efter. Ju bättre den klocka är ju bättre mätinstrument har man och jag vill påstå att en TCXO är ett MÅSTE för detta.
Jag har lyckats mäta frekvens på 3 kanaler på nästan detta vis med en 20MHz M16C och upp i närheten av 45kHz på båda kanalerna började det bli lite hackigt... fast jag hade inte D-FF'en med, för varje stigande flank kom det en interrupt då men mjukvaran såg till att mäta över längre tid.
Jag tror därför att detta system borde räcka upp till 8MHz utan prescaler på (eg. bara begränsat av hur snabbt pulsräknaren kan räkna), antal pulser kan ju lätt expanderas från räknarens 16 till 32 bit via overflow-interrupten.
På det vis skulle jag kunde bygga en frekvensmätare som kan klara av kanske 2 kanaler och ha ett frekvensspan från .... ja, riktigt lågt till ett par hundra MHz med fin upplösning hela vägen och snabb utläsning, självklart byter den mätområde automatisk osv.
Frekvensmätning
Det hade varit trevligt om du valde någon processor i PIC-familjen eftersom så många har utrustning för just PIC.
Du har "återuppfunnit" den reciproka frekvensmätningsprincipen! 
Får mig att tänka på ett byggprojekt i Allt om Elektronik (nr. 3 / 1985) - "Processorstyrd frekvensräknare 0.01 Hz - 1.2 GHz".
Finns också ett annat projekt i Elektor Electronics (januari 1991) som bygger på samma princip. Den artikeln heter "Multifunctional Measurement Card for PC". Allt om Elektronik (nr. 11 / 1992) innehåller projektet "1.2 GHz multifunktions frekvensmätare".
Har forfarande kvar artiklarna i min "bra att ha-pärm".
Reciproka principen = räknar hur många perioder av en referensklocka (t.ex. 10 MHz -> 100 ns/period) som ryms inom en period av den signal man vill mäta. Sedan kan man, som du också nämner, fixa till det så att man kan mäta tiden som insignalen är "HÖG" respektive "LÅG" och därefter beräkna duty cycle m.m.
En frekvensdelare på ingången för att mäta högre frekvenser gör att du förlorar duty cycle-informationen...om du nu inte också har kommit på ett sätt att behålla även denna information...
Jag håller på med ett liknande frekvensräknarprojekt men baserar min lösning på MCU'n 68HC908QY4.
Den reciproka frekvensmätningstekniken är intressant tycker jag!
Får mig att tänka på ett byggprojekt i Allt om Elektronik (nr. 3 / 1985) - "Processorstyrd frekvensräknare 0.01 Hz - 1.2 GHz".
Finns också ett annat projekt i Elektor Electronics (januari 1991) som bygger på samma princip. Den artikeln heter "Multifunctional Measurement Card for PC". Allt om Elektronik (nr. 11 / 1992) innehåller projektet "1.2 GHz multifunktions frekvensmätare".
Har forfarande kvar artiklarna i min "bra att ha-pärm".
Reciproka principen = räknar hur många perioder av en referensklocka (t.ex. 10 MHz -> 100 ns/period) som ryms inom en period av den signal man vill mäta. Sedan kan man, som du också nämner, fixa till det så att man kan mäta tiden som insignalen är "HÖG" respektive "LÅG" och därefter beräkna duty cycle m.m.
En frekvensdelare på ingången för att mäta högre frekvenser gör att du förlorar duty cycle-informationen...om du nu inte också har kommit på ett sätt att behålla även denna information...
Jag håller på med ett liknande frekvensräknarprojekt men baserar min lösning på MCU'n 68HC908QY4.
Den reciproka frekvensmätningstekniken är intressant tycker jag!
Väljer man periodtid så kan man ju få väldigt precis, men man måste räkna själv om det var frekvensen man ville veta...PeterH: efter vad jag vet är det lite taskigt med PIC med BÅDA en 16-bitars Capture-enhet igång OCH en 16 bitars event-counter på samma gång.
Väljer jag Renesas finns de i överflöde.
Ronny: jahopp... precis som då vi lärde oss om AD-omvandlare under min utbildning i 1981, vi lärde om ramp-omvandlare men på kvällen fick jag en idé som jag ritade ner och visade min lärare nästa dag, samma dag fick jag lära mig att den heter "Succescive Approximation Register"...
Men skit samma, den ska bara fungera och jag är nog mest förvånat över att det egentligen är så enkelt räknat i hårdvara.
Har AoE's eller EE's projekt bra ingångssteg? Och om det är så, har du möjlighet att scanna av dom?
Och nej, jag har ingen magisk lösning på duty-cycle vid allt för höga frekvenser tyvärr, enda sättet jag rent omedelbart kan komma år att ha en oscillator och räkna hur många pulser signalen är '1' och '0'.
Väljer jag Renesas finns de i överflöde.
Ronny: jahopp... precis som då vi lärde oss om AD-omvandlare under min utbildning i 1981, vi lärde om ramp-omvandlare men på kvällen fick jag en idé som jag ritade ner och visade min lärare nästa dag, samma dag fick jag lära mig att den heter "Succescive Approximation Register"...
Men skit samma, den ska bara fungera och jag är nog mest förvånat över att det egentligen är så enkelt räknat i hårdvara.
Har AoE's eller EE's projekt bra ingångssteg? Och om det är så, har du möjlighet att scanna av dom?
Och nej, jag har ingen magisk lösning på duty-cycle vid allt för höga frekvenser tyvärr, enda sättet jag rent omedelbart kan komma år att ha en oscillator och räkna hur många pulser signalen är '1' och '0'.
skall du ha en stabil referenskristall så skall oscillatorn inte vara av pierce-modell (den modellen med 2 kondingar på var sida om kristallen och inveterare som 'alla' mcu-kretsar använder idag)
skall det vara stabilt bör kristallen jobba serieresonans-mode.
vanliga processorkristaller kan också köra i serieresonans - men dess frekvensmärkning kommer inte att stämma utan är något tiotal till hundratal kHz fel
skall det vara stabilt bör kristallen jobba serieresonans-mode.
vanliga processorkristaller kan också köra i serieresonans - men dess frekvensmärkning kommer inte att stämma utan är något tiotal till hundratal kHz fel
Senast redigerad av xxargs 26 oktober 2008, 10:31:48, redigerad totalt 1 gång.
Nu skrev jag ju "TCXO" om oscillatorn, det betyder "Temperature Compensated X-tal Oscillator" och Dallas har t.ex DS32KHZ som är tänkt som en RTC-frekvens, använder man den är det ±1 minut/år som gäller.
Jag vet om att det finns lite olika TCXO att köpa, Dallas har även en med högre frekvens men tyvärr då bara 3,3V matning som mest.
Jag vet om att det finns lite olika TCXO att köpa, Dallas har även en med högre frekvens men tyvärr då bara 3,3V matning som mest.
Icecap:
Ingångssteget till "Processorstyrd frekvensräknare 0.01 Hz - 1.2 GHz" är ganska omfattande. Det har tre olika ingångar som används beroende på vilken signaltyp/signalnivå och frekvens man vill mäta.
Tillbaka till reciproka principen...
Jag håller med dig om att det blir enkelt räknat i hårdvara...det blir också enkelt räknat i mjukvara
I fallet med 10 MHz referensklocka (100 ns/period) och t.ex. ett 32-bitars räknarregister kan det bli något i stil med följande för att visa periodtiden:
1. Omvandla innehållet i 32-bitarsregistret till motsvarande BCD-siffror (BIN2BCD-rutin eller motsvarande).
2. Anpassa BCD-siffrorna till teckenkoder för t.ex. en LCD-modul.
3. Överför till LCD-modul och placera kommatecken på lämpligt ställe och lägg till texten "us", "ms", "s" eller vad man nu tycker passar bäst.
Med enkla medel har man nu fått ett, för låga frekvenser, noggrannt och mycket användbart mätinstrument.
Besvärligare blir det om man mäter med den reciproka principen och vill presentera resultatet som frekvens i enheten Hz.
I mjukvaran måste man då invertera periodtiden. Jag programmerar enbart i assembler och detta är ingen enkel uppgift om man ska göra allt helt själv. Jag har ett antal äldre matematikpaket med subrutiner för beräkning av trigonometriska funktioner, logaritmer m.m. Dessa subrutiner är skrivna helt i assembler för Motorolas processorer. Jag ska undersöka om jag kan använda någon av subrutinerna i de programbiblioteken.
Jag kan inget om vilka möjligheter man har att lösa en sådan programmeringsuppgift med ett "högnivåprogrammeringsspråk" och en bra kompilator för MCU'er (8-bitars PIC eller AVR av "enklare typen").
Varje LSB i det 32-bitar breda binära räknarregistret motsvarar tiden 100 ns i mitt exempel ovan. Den totala periodtiden ska alltså omvandlas till motsvarande frekvens utan att förlora i noggrannhet under omvandlingsproceduren, dvs. den frekvens som man till slut räknat fram och visar på LCD-displayen ska "värdesiffermässigt" motsvara det som gäller för den uppmätta periodtiden...
Vilket programmeringsspråk använder du?
Ingångssteget till "Processorstyrd frekvensräknare 0.01 Hz - 1.2 GHz" är ganska omfattande. Det har tre olika ingångar som används beroende på vilken signaltyp/signalnivå och frekvens man vill mäta.
Tillbaka till reciproka principen...
Jag håller med dig om att det blir enkelt räknat i hårdvara...det blir också enkelt räknat i mjukvara
I fallet med 10 MHz referensklocka (100 ns/period) och t.ex. ett 32-bitars räknarregister kan det bli något i stil med följande för att visa periodtiden:
1. Omvandla innehållet i 32-bitarsregistret till motsvarande BCD-siffror (BIN2BCD-rutin eller motsvarande).
2. Anpassa BCD-siffrorna till teckenkoder för t.ex. en LCD-modul.
3. Överför till LCD-modul och placera kommatecken på lämpligt ställe och lägg till texten "us", "ms", "s" eller vad man nu tycker passar bäst.
Med enkla medel har man nu fått ett, för låga frekvenser, noggrannt och mycket användbart mätinstrument.
Besvärligare blir det om man mäter med den reciproka principen och vill presentera resultatet som frekvens i enheten Hz.
I mjukvaran måste man då invertera periodtiden. Jag programmerar enbart i assembler och detta är ingen enkel uppgift om man ska göra allt helt själv. Jag har ett antal äldre matematikpaket med subrutiner för beräkning av trigonometriska funktioner, logaritmer m.m. Dessa subrutiner är skrivna helt i assembler för Motorolas processorer. Jag ska undersöka om jag kan använda någon av subrutinerna i de programbiblioteken.
Jag kan inget om vilka möjligheter man har att lösa en sådan programmeringsuppgift med ett "högnivåprogrammeringsspråk" och en bra kompilator för MCU'er (8-bitars PIC eller AVR av "enklare typen").
Varje LSB i det 32-bitar breda binära räknarregistret motsvarar tiden 100 ns i mitt exempel ovan. Den totala periodtiden ska alltså omvandlas till motsvarande frekvens utan att förlora i noggrannhet under omvandlingsproceduren, dvs. den frekvens som man till slut räknat fram och visar på LCD-displayen ska "värdesiffermässigt" motsvara det som gäller för den uppmätta periodtiden...
Vilket programmeringsspråk använder du?
Jag använder C och att räkna med "stora tal" är knappast ett problem, det beror ju självklart på vilken upplösning man behöver. I HEW som jag använder till Renesas processorerna finns det en "long long" som, om jag deklarerar den som "unsigned long long" kan ge mig en 64-bit variabel utan förtecken, det borde räcka en bit på väg
Vill jag mäta t.ex. 125mHz som mitt senaste projekt kräver och jag kör med 16MHz i klocka kan dessa 8 sekunders antal klocks lätt rymmas inom dessa 64 bitar och inget hindrar att jag minskar klockan för att enklare räkna på det hela. Exakt vilken klockfrekvens jag kommer att välja beror på vad jag kan hitta av stabil TCXO eller liknande, sedan får man ju räkna "lite".
Jag har ju som sagt redan löst den bit fast då utan hårdvara-assistans men att deras ingångssteg är delat i 3 delar är ju inget bra, då måste jag likaväl fixa en automatisk omkopplare då jag vill ha ett fullautomatisk system med bara en ingång från lägsta till högsta frekvens.
Min idé är att jag ska kunde använda enheten i en automatisk test som jag har planerat, därför kommer det att finnas en serieport på också men viktigast är att jag vill ha en bättre frekvensräknare än den jag har nu, den fungerar bra men har inte upplösning nog vid låga frekvenser.
Vill jag mäta t.ex. 125mHz som mitt senaste projekt kräver och jag kör med 16MHz i klocka kan dessa 8 sekunders antal klocks lätt rymmas inom dessa 64 bitar och inget hindrar att jag minskar klockan för att enklare räkna på det hela. Exakt vilken klockfrekvens jag kommer att välja beror på vad jag kan hitta av stabil TCXO eller liknande, sedan får man ju räkna "lite".
Jag har ju som sagt redan löst den bit fast då utan hårdvara-assistans men att deras ingångssteg är delat i 3 delar är ju inget bra, då måste jag likaväl fixa en automatisk omkopplare då jag vill ha ett fullautomatisk system med bara en ingång från lägsta till högsta frekvens.
Min idé är att jag ska kunde använda enheten i en automatisk test som jag har planerat, därför kommer det att finnas en serieport på också men viktigast är att jag vill ha en bättre frekvensräknare än den jag har nu, den fungerar bra men har inte upplösning nog vid låga frekvenser.
Jag inser inte riktigt hur du tänker att beräkningen ska gå till men det kanske beror mest på att jag inte känner till vad en C-kompilator är kapabel till.
"long long" eller "unsigned long long" antar jag betyder att man deklarerar en heltalsvariabel.
Den frekvensräknarvariant jag skissar på behöver kunna hantera flyttalsberäkningar/flyttalsresultat.
Här är ett räkneexempel som får illustrera det:
Den reciproka frekvensräknarprincipen används med referensklockan 10 MHz (100 ns/period).
Ingen frekvensdelare används på ingången.
Ett 32 bitar brett register används för att räkna hur många referensklockperioder som ryms inom en period av "mätsignalen".
Man startar en mätning och efter mätningens slut innehåller räknarregistret det binära talet som motsvarar det decimala talet 8100052.
Vilken frekvens motsvarar detta?
"long long" eller "unsigned long long" antar jag betyder att man deklarerar en heltalsvariabel.
Den frekvensräknarvariant jag skissar på behöver kunna hantera flyttalsberäkningar/flyttalsresultat.
Här är ett räkneexempel som får illustrera det:
Den reciproka frekvensräknarprincipen används med referensklockan 10 MHz (100 ns/period).
Ingen frekvensdelare används på ingången.
Ett 32 bitar brett register används för att räkna hur många referensklockperioder som ryms inom en period av "mätsignalen".
Man startar en mätning och efter mätningens slut innehåller räknarregistret det binära talet som motsvarar det decimala talet 8100052.
Vilken frekvens motsvarar detta?
10 000 000 / 8 100 052 blir det väl? 1,2346Hz typ...
Vill man slippa flyttal kan man ju byta 10*10^6 mot 10*10^9 för att få svaret i mHz. 10*10^9 är ju iofs längre än 32 bitar men kan man räkna med 64 bitar så är det ju inget problem... Då kan man ju förlänga ännu mer och få svaret i µHz eller nåt sånt om man vill
Kan processorerna det rör sig om dividera i hårdvara? Iofs gör det ju inte jättemycket om de inte kan det, det är ju inte jättemånga gånger per sekund divisionen måste utföras för att ge en display med snabbt svar.
Vill man slippa flyttal kan man ju byta 10*10^6 mot 10*10^9 för att få svaret i mHz. 10*10^9 är ju iofs längre än 32 bitar men kan man räkna med 64 bitar så är det ju inget problem... Då kan man ju förlänga ännu mer och få svaret i µHz eller nåt sånt om man vill
Kan processorerna det rör sig om dividera i hårdvara? Iofs gör det ju inte jättemycket om de inte kan det, det är ju inte jättemånga gånger per sekund divisionen måste utföras för att ge en display med snabbt svar.
Ronny:
10MHz (mätfrekvens) * 100 = 1.000.000.000 / 8.100.052 = 123mHz
eller
10MHz * 10000 = 100.000.000.000 / 8.100.052 = 12345 = 123,45mHz
OBS. att det är heltalsmatematik enbart...
Men vill man använda flyttal kan man göra det, det är bara att deklarera som "float" eller "double" eller vad man nu vill men jag har aldrig under mina 10 år som "professionell" programmör behövt flyttal.
10MHz (mätfrekvens) * 100 = 1.000.000.000 / 8.100.052 = 123mHz
eller
10MHz * 10000 = 100.000.000.000 / 8.100.052 = 12345 = 123,45mHz
OBS. att det är heltalsmatematik enbart...
Men vill man använda flyttal kan man göra det, det är bara att deklarera som "float" eller "double" eller vad man nu vill men jag har aldrig under mina 10 år som "professionell" programmör behövt flyttal.
)Icecap och kimmen: OK, jag förstår principen. Vaska fram fler siffror genom att höja med en tiopotens.
Jag hittade Gordon Doughmans applikationsnot AN974 "MC68HC11 Floating-Point Package" som är ett beräkningspaket skrivet helt i assembler.
Ska börja titta nämare på det. Här är en länk till AN974
Jag kommer använda en OCVCXO som tidbas i min frekvensräknare.
Tycker det är ett intressant projekt du håller på med. Rapportera gärna hur det går med din konstruktion!
Jag hittade Gordon Doughmans applikationsnot AN974 "MC68HC11 Floating-Point Package" som är ett beräkningspaket skrivet helt i assembler.
Ska börja titta nämare på det. Här är en länk till AN974
Jag kommer använda en OCVCXO som tidbas i min frekvensräknare.
Tycker det är ett intressant projekt du håller på med. Rapportera gärna hur det går med din konstruktion!
