Mäta dutycycle med PIC12F683 (hinner inte med)

[ToPNoTCH]

Behöver lite hjälp med att tänka rätt här.

Mål:
Mäta dutycycle på en puls med 31.5 KHz.
Det är för att mäta signalstyrkan (RSSI) på en RC mottagare vilken ges i detta format.

Då mycket utrustning vill ha en analog signal, så fixade jag en dutycycle till analog konverterare
med en SPI Potentiometer som reglerades utifrån dutycycle.

Problem:
Jag hade allt fungerande, men sedan ändrades koden för mottagaren (opensource projekt) så
att signalen kommer i 31.5KHz istället för tidigare 440Hz.
Det visar sig att min CCPM bara klarar att hänga med till 640Hz

Symptomet är att med kortare dutycycle så hänger den med i högre frekvens, så jag misstänker att
det hela har att göra med min timer inställning (TMR1) att göra.

Timer1 har en prescaler 1:1 (T1CON = 00000101), och jag hanterar mätning mellan stig och fall med interupt.

Nuvarande prescale är satt med trial'n error och jag ger mig fan på att timern rullar runt, men att jag har haft "tur" och kommit i synk, för nog fan borde man hinna med att sampla mer än 1KHz signal tycker jag.

Innan jag håller på att posta kod och greja tänkte jag kolla hur man BORDE tänka när det gäller timern.
Bara för att se om jag tänker rätt:
- MCU'n går i 8 MHz på intern OSC.
- TMR1 har en default prescale 1/4 från MCU klockan = 2MHz
- Med min satta prescale på 1:1 så borde TMR1 rulla om varje 32.7675 millisekund
- Med en signal på 31.5 KHz så blir pulslängden 31.5 uS.

Jag får det till att det borde funka

[TomasL]

Nja pulslängden blir väl inte 31 us utan hela perioden, vid 50% duty, så blir pulslängden 15,9 us.

[ToPNoTCH]

Kanske jag som kastar om begreppen lite.

Jag tänkte som så att duty 50% = 50% av pulslängden, vilken då blir det dubbla.

[Marta]

Det finns alternativa sätt att mäta. Om Du inte kan använda CCP-modulen för att få en perfekt mätning på varje puls, så använd en statistisk metod istället. Sampla ett stort antal gånger med en frekvens som inte är jämnt delbar med pulsernas frekvens. Kvoten mellan antalet gånger Du läser en etta och antalet gånger det läses en nolla är samma som pulskvoten. Ju fler pulser som räknas, ju bättre blir resultatet.

Med CCP och de tider som gäller får Du bara ungefär 63 klockor att räkna på en pulsperiod, men den noggranheten borde ju räcka för detta ändamål. Så lite justering av koden borde även det kunna lösa problemet. Eller nu när det är opensource, kommunicera signalstyrkan på ett vettigare sätt än som pulskvot. Allt är en fråga om hur mycket krångel som är acceptabelt i förhållande till önskat resultat.