RC5 decoder in C met AVR

Hallo,

Ik ben bezig een RC5 decoder te bouwen in CodeVisionAVR, dit is mijn code, voorzien van commentaar:


while (1){
 // RC5 structure:
 // | S | S | T | A4 | A3 | A2 | A1 | A0 | C5 | C4 | C3 | C2 | C1 | C0 |
 // Manchester/biphase encoding

 // Wait until first half of first startbit is received
 // When first startbit is received, check for validity
 // by waiting for second startbit, which will be 895us
 // after falling edge of first startbit. Conclusion: 
 // bit detection will be 180 deg out of phase with TX

 while(IR_IN) #asm("nop");
 delay_us(895);

  if(IR_IN)                    //Second startbit detected, let's go!
  {
  delay_us(1778);              //Wait one bitlength to detect togglebit
  toggle=IR_IN;                //Store togglebit

  for(i=0;i<6;i++){            //Read address byte, which is 5 bits long
   delay_us(1778);
   address=address|IR_IN;      //Store MSB bit as LSB
   address<<1;                 //Shift left to make room for the next bit, repeat
   }
  for(i=0;i<7;i++){            //Read command byte, which is 6 bits long
   delay_us(1778);
   command=command|IR_IN;      //Store MSB bit as LSB
   command<<1;                 //Shift left to make room for the next bit, repeat
   }
  }
  // Transmistter will pause here for 114ms before sending next command.
  // We can use this time to transmit characters over RS232 without messing
  // up RC5 decoding timing. 
 };

IR_IN is gedefinieerd als:


#define IR_IN PIND.6

Op PD6 is een TSOP1738 aangesloten, via een 10K pullup naar 5V (dus in idle logisch 1).

Toggle, address en command zijn unsigned chars.

Wat is nu het probleem? De toggle bit komt niet goed aan.
Persoonlijk denk ik dat ik een redelijk goed algoritme bedacht had ( ;) ) maar ik kan er naast zitten. Heeft iemand hier ervaring mee?


for(i=0;i<6;i++){            //Read address byte, which is 5 bits long

Je leest hier 6 bits in ipv. 5, namelijk: 0, 1, 2, 3, 4 en 5!
Kijk ook naar de tweede for()-lus, waar je 8 bits ipv. 7 inleest.

Nog iets: je wijzigt telkens bit 0, en vervolgens ja je alle bits opschuiven. Het resultaat is, dat het laatste ingelezen bit uiteindelijk als bit 1 eindigt.
Wil je dat vermijden, dan moet je telkenmale eerst alle bits naar links schuiven en pas dan bit 0 aanpassen. Zo komt het laatst-ingelezen bit netjes op bit 0 te staan.

Moest het niet een TSOP1736 zijn. RC5 werkt met een modulatie van 36Khz.

Op 8 maart 2008 08:26:49 schreef pros:


for(i=0;i<6;i++){            //Read address byte, which is 5 bits long

Je leest hier 6 bits in ipv. 5, namelijk: 0, 1, 2, 3, 4 en 5!
Kijk ook naar de tweede for()-lus, waar je 8 bits ipv. 7 inleest.

Nog iets: je wijzigt telkens bit 0, en vervolgens ja je alle bits opschuiven. Het resultaat is, dat het laatste ingelezen bit uiteindelijk als bit 1 eindigt.
Wil je dat vermijden, dan moet je telkenmale eerst alle bits naar links schuiven en pas dan bit 0 aanpassen. Zo komt het laatst-ingelezen bit netjes op bit 0 te staan.

Ai, daar zeg je wat! Zal dit zo eens aanpassen en kijken wat er gebeurt. Enig idee waarom de toggle bit niet goed aankomt? Deze blijft altijd nul.

Op 8 maart 2008 10:29:14 schreef 2N3055:
Moest het niet een TSOP1736 zijn. RC5 werkt met een modulatie van 36Khz.

I know, maar een 1736 hadden ze niet bij de winkel en deze had ik nog liggen. Volgens de datasheet is hij dan 15% minder effectief. Ik test het nu door de afstandsbediening vrij dichtbij de ontvanger te houden.

Op 8 maart 2008 13:03:39 schreef smsmonster:
Enig idee waarom de toggle bit niet goed aankomt? Deze blijft altijd nul.

Een timing-probleem, misschien?
Hoe heb je "IR_IN" gedefinieerd?

Het is in deze code erg makkelijk om dingen verkeerd te laten gaan. Als de delay_us bijvoorbeeld iets verkeerde timing heeft (heb je de juiste clock freq opgegeven?)...

Maar Als ie nooit veranderd, zou ik eerst even botweg proberen of ie ooit wel veranderd. Dus:


   while (1) {
       if (IR_IN) {
          portb.6 = 1; // Ene ledje aan
          portb.5 = 0;
          delay_ms (500); // Zeker weten dat je hem ziet. 
          while (IR_IN);
       } else {
          portb.5 = 1;  // andere ledje aan. 
          portb.6 = 0;
          delay_ms (500);
          while (!IR_IN);
       } 
   }

Volgens mij krijg je dan duidelijk te zien dat er uberhaupt iets veranderd....

Ik heb 20 jaar geleden ooit zo'n IR ontvanger ding gekocht, maar nog nooit aan de praat gekregen. Nooit veel aan gewerkt. Maar duurt het inderdaad echt 1.7 milliseconde per bitje?

Heeft de delay_us functie echt een int als argument en niet een char? Dan heb je ineens hele andere timing...

Op 8 maart 2008 13:28:15 schreef pros:
[...]
Een timing-probleem, misschien?
Hoe heb je "IR_IN" gedefinieerd?

IR_IN is gedefinieerd als PIND.6, heb in de startpost de code staan.

Op 8 maart 2008 13:49:37 schreef rew:
Het is in deze code erg makkelijk om dingen verkeerd te laten gaan. Als de delay_us bijvoorbeeld iets verkeerde timing heeft (heb je de juiste clock freq opgegeven?)...

Maar Als ie nooit veranderd, zou ik eerst even botweg proberen of ie ooit wel veranderd. Dus:


   while (1) {
       if (IR_IN) {
          portb.6 = 1; // Ene ledje aan
          portb.5 = 0;
          delay_ms (500); // Zeker weten dat je hem ziet. 
          while (IR_IN);
       } else {
          portb.5 = 1;  // andere ledje aan. 
          portb.6 = 0;
          delay_ms (500);
          while (!IR_IN);
       } 
   }

Volgens mij krijg je dan duidelijk te zien dat er uberhaupt iets veranderd....

Ik heb 20 jaar geleden ooit zo'n IR ontvanger ding gekocht, maar nog nooit aan de praat gekregen. Nooit veel aan gewerkt. Maar duurt het inderdaad echt 1.7 milliseconde per bitje?

Heeft de delay_us functie echt een int als argument en niet een char? Dan heb je ineens hele andere timing...

IR_IN wordt wel gepulst aangestuurd, ledje knippert als ik dat doe. Dit heb ik daarna gedaan voor de toggle bit en dan verandert er nooit iets. Heb de goede timing, als ik met delay_ms(1000) een ledje laat knipperen duurt het ook echt 1 seconde. Ik laat nu de 3 variabelen echo'en over de RS232 en daar komt dit uit:
toggle: [null]
address: 0x01
command: 0x01

Voor de volledigheid, ik doe dit zo:


    putchar('t');
    putchar(toggle);
    putchar('a');
    putchar(address);
    putchar('c');
    putchar(command);      
    putchar('\n');
    putchar('\r');

Gevolg:
http://www.smsmonster.nl/files/hyperterm.jpg
Voordat iemand vraagt waarom ik niet gewoon printf gebruik: die neemt onwijs veel geheugen in beslag :)

Je zou van dat laatste

putchar(toggle + '0');
putchar(address + '0');
putchar(command + '0');

kunnen maken. Dan zie je een '0' verschijnen als "toggle" 0 is, of anders een '1'.

Als de andere bits wel goed gededecteerd worden, kan ik eigenlijk geen reden bedenken waarom het toggle-bit steeds als 0 wordt gezien - tenzij het steeds 0 is, uiteraard.

Ik dacht dat ik misschien op de grens zat met het detecteren van de toggle bit (en dus ook de rest) dus ik controleer de togglebit nu op 3/4 van de periode ipv net na de helft. Nu krijg ik gewoon op alle chars de waarde 1. Zou ik verkeerd schuiven? Bij RC5 komt de MSB als eerste.

Als MSB eerst komt, schuif je goed (wel eerst schuiven en dan bit 0 aanpassen).

Nu krijg ik gewoon op alle chars de waarde 1

Bedoel je 00001 of 11111? Misschien de huidige code even tonen?

Vooruit ;) Volledige listing:


#include <stdio.h>
#include <tiny2313.h>
#include <delay.h>      
#define IR_IN PIND.6

void main(void)
{
unsigned char i, address, command, toggle;
address=0;
command=0;
toggle=0;

// Crystal Oscillator division factor: 1
CLKPR=0x80;
CLKPR=0x00;

// Input/Output Ports initialization
// Port A initialization
// Func2=Out Func1=Out Func0=Out 
// State2=0 State1=0 State0=0 
PORTA=0x00;
DDRA=0x07;

// Port B initialization
// Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In 
// State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T 
PORTB=0x00;
DDRB=0x00;

// Port D initialization
// Func6=In Func5=Out Func4=Out Func3=Out Func2=Out Func1=Out Func0=Out 
// State6=T State5=0 State4=0 State3=0 State2=0 State1=0 State0=0 
PORTD=0x00;
DDRD=0x3F;

// Timer/Counter 0 initialization
// Clock source: System Clock
// Clock value: Timer 0 Stopped
// Mode: Normal top=FFh
// OC0A output: Disconnected
// OC0B output: Disconnected
TCCR0A=0x00;
TCCR0B=0x00;
TCNT0=0x00;
OCR0A=0x00;
OCR0B=0x00;

// Timer/Counter 1 initialization
// Clock source: System Clock
// Clock value: Timer 1 Stopped
// Mode: Normal top=FFFFh
// OC1A output: Discon.
// OC1B output: Discon.
// Noise Canceler: Off
// Input Capture on Falling Edge
TCCR1A=0x00;
TCCR1B=0x00;
TCNT1H=0x00;
TCNT1L=0x00;
ICR1H=0x00;
ICR1L=0x00;
OCR1AH=0x00;
OCR1AL=0x00;
OCR1BH=0x00;
OCR1BL=0x00;

// External Interrupt(s) initialization
// INT0: Off
// INT1: Off
// Interrupt on any change on pins PCINT0-7: Off
GIMSK=0x00;
MCUCR=0x00;

// Timer(s)/Counter(s) Interrupt(s) initialization
TIMSK=0x00;

// Universal Serial Interface initialization
// Mode: Disabled
// Clock source: Register & Counter=no clk.
// USI Counter Overflow Interrupt: Off
USICR=0x00;

// USART initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART Receiver: Off
// USART Transmitter: On
// USART Mode: Asynchronous
// USART Baud rate: 9600
UCSRA=0x00;
UCSRB=0x08;
UCSRC=0x06;
UBRRH=0x00;
UBRRL=0x33;

// Analog Comparator initialization
// Analog Comparator: Off
// Analog Comparator Input Capture by Timer/Counter 1: Off
ACSR=0x80;

while (1){
 // RC5 structure:
 // | S | S | T | A4 | A3 | A2 | A1 | A0 | C5 | C4 | C3 | C2 | C1 | C0 |    
 // Manchester/biphase encoding

 // Wait until first half of first startbit is received
 // When first startbit is received, check for validity
 // by waiting for second startbit, which will be 895us
 // after falling edge of first startbit. Conclusion: 
 // bit detection will be 180 deg out of phase with TX

 while(IR_IN) #asm("nop");
 delay_us(1333);

  if(IR_IN)                     //First half of second startbit detected
  {
  delay_us(889);  
  if(!IR_IN)                    //Second half of second startbit detected, let's go!
  {
   PORTA.0=1;
   delay_us(1778);              //Wait one bitlength to detect togglebit
   toggle=IR_IN;                //Store togglebit

   for(i=0;i<5;i++){            //Read address byte, which is 5 bits long
    delay_us(1778);
    address<<1;                 //Shift left to make room for the next bit
    address=address|IR_IN;      //Store MSB bit as LSB
    }
   for(i=0;i<6;i++){            //Read command byte, which is 6 bits long
    delay_us(1778);
    command<<1;                 //Shift left to make room for the next bit
    command=command|IR_IN;      //Store MSB bit as LSB              
    }
    putchar('t');
    putchar(toggle);
    putchar('a');
    putchar(address);
    putchar('c');
    putchar(command);      
    putchar('\n');
    putchar('\r'); 
    PORTA.0=0;
   }
  }
  // Transmitter will pause here for 114ms before sending next command.
  // We can use this time to transmit characters over RS232 without messing
  // up RC5 decoding timing. 

 };
}

Het ledje op PA0 gaat aan tijdens het ontvangen van een code van een RC5 afstandsbediening. Bij een andere afstandsbediening niet, dus de startbits worden goed herkend.

Ik krijg via de RS232 een smiley terug, das 0x01 in ASCII.

Voor de volledigheid:
http://www.sbprojects.com/knowledge/ir/rc5modulation.gif
http://www.sbprojects.com/knowledge/ir/rc5train.gif

Elke bit is een burst van 64 pulsen op 36Khz > 1778us per bit

Misschien loopt het mis bij het dedecteren van de startbits, en is een meer uitgebreide controle noodzakelijk. Zo, misschien:


while (1) {
    toggle = 0;				// We misbruiken toggle maar even
    while (!IR_IN) {			// Wachten tot IR_IN hoog wordt
	delay_us(100);
	if (toggle < 20) {		// Overflow vermijden
	    toggle++;
	}
    }
    if (toggle == 20) {			// Minstens 2000µS geen signaal ontvangen?
	// Dan is dit het eerste startbit
	delay_us(2222);			// 1.25 priodetijd wachten
	if (IR_IN)			// IR_IN hoog?
	{				// Dan zitten we nu halfweg het 2e startbit
	    PORTA .0 = 1;
	    delay_us(1778);		//Wait one bitlength to detect togglebit
	    toggle = IR_IN;		//Store togglebit

	    for (i = 0; i < 5; i++) {	//Read address byte, which is 5 bits long
		// enz...
	    }
	}
    }
}

Op die manier vermijdt je, dat je een willekeurige opvolging van 2 hoge bits als startbits gaat beschouwen.

Inderdaad, daarom heb controleer ik in mijn code na de eerste helft van de tweede startbit ook of de tweede helft van de tweede startbit laag is (want bi-phase). Zie if(!IR_IN). Dit blijkt te werken, als ik een niet-RC5 afstandsbediening gebruik wordt het decode gedeelte niet aangeroepen.

In uiterste nood kan je nog steeds om de 889µS IR_IN testen en controleren of je bij elk "paar" wel degelijk "01" of "10" ontvangt. Bij "11" of "00" weet je dat de ontvangen bitreeks waardeloos is.
Probeer ook na te gaan, hoeveel tijd eea. in beslag neemt. Die tijd (bv. 2µS) kan je dan van de wachttijd aftrekken (bv. 889 - 2 = 887µS).

Misschien is dit een handig hulpmiddel:


unsigned long bits;

while (1) {

    bits = 0;

    while (!IR_IN) {		// Wachten tot IR_IN hoog wordt
    }
    delay_us(444);		// 1/4 bittijd wachten
    bits |= IR_IN;
    for (i = 0; i < 26; i++) {	// Nog 13 *2 samples te nemen
	delay_us(889);
	bits = ((bits << 1) | IR_IN);
    }
    // bits is nu 0000 0101 tTaA aAaA aAaA cCcC cCcC cCcC
    for (i = 0; i < 32; i++) {
	if (bits & 0x8000) {
	    putchar('1');
	} else {
	    putchar('0');
	}
        bits = (bits << 1);    // <<<Toegevoegd
    }
}

Zo zie je voor elk bit (als het goed is) telkens "01" of "10" verschijnen. Komt er een "00" of "11" op het scherm, dan is er duidelijk iets loos met de timing.

Edit: regeltje bijgevoegd in laatste lus.

Briljant idee. Ik laat nu in een grote for lus 32 keer de status van IR_IN zien, en dat wordt dus dit:

Telkens de powerknop:


00101001000010110000010111111111;
00101000100010110000010111111111;
00101001000010110000010111111111;
00101000100010110000010111111111;
00101001000010110000010111111111;
00101000100010110000010111111111;
00101001000010100000010111111111;
00101000100010110000010111111111;
00101001000010110000010111111111;
00101000100010110000010111111111;
00101001000010100000010111111111;
00101000100010110000010111111111;

Random knoppen:


00101001000010110010110111111111;
00101000100010110001110111111111;
00101000100010110001110111111111;
00101001000010110001100111111111;
00101000100010110001100111111111;
00101001000010110001101111111111;
00101000100010110001100111111111;
00101000100010110001100111111111;
00101001000110110000000111111111;
00101001000010110000000111111111;
00101000100010110000001111111111;
00101000100010110000001111111111;
00101001000110110000000111111111;
00101001000010110000000111111111;
00101000100010110010000111111111;
00101001000110110011000111111111;
00101000100010110000110111111111;
00101000100010110000110111111111;
00101001000010110010001111111111;
00101001000010110010001111111111;

Er staat een aantal enen teveel aan het einde, dat komt doordat ik 32 tekens inlees ipv 26. We zien dus mooi de togglebit veranderen in de eerste reeks en ik zie dat er af en toe een bitje omvalt in de adresbyte.

Aan de uitdraai te zien, had je al opgemerkt dat er een instructie ontbrak in de laatste lus. :-)

Verder zie ik daar op elke regel verschillende nullen na mekaar, hetgeen niet kan als ik je uitleg over de code hierboven goed begrijp. Dus toch een timing-probleem?

Ik denk het wel. Ik heb vannacht tot half drie van alles geprobeerd qua timing maar krijg het niet helemaal goed. Als ik ga schuiven met de timing krijg ik telkens andere bitreeksen binnen. Wellicht is het een goed idee om elke keer als ik de status van de bit poll een puls op een andere pin te zetten en deze signalen met de scoop te vergelijken. Heb alleen geen scoop :P

Hier zou een scoop --of beter: een logic analiser-- zeker van pas komen.

Wat je zou kunnen doen, is de AVR zelf de pulsbreedten laten meten. IR_IN is immers ofwel 889, ofwel 1778µS hoog. In principe, dan. De IR-zender kan afwijken, maar ook de timing van je AVR kan verlopen. Zo, dus:


void pulsbreedtemeting(void)
{
    unsigned int lang[8], kort[8];
    unsigned int cnt, tmp;

    for (cnt = 0; cnt < 8; cnt++) {
	tmp = 0;
	while (!IR_IN) {		// Wachten tot IR_IN hoog wordt
	}
	while (IR_IN) {			// Tellen tot IR_IN terug laag wordt
	    tmp++;
	    delay_us(1);
	}
	if (tmp > 1300) {		// Lange puls?
	    lang[cnt] = tmp;
	} else {			// Korte puls
	    kort[cnt] = tmp;
	}
    }
}

Daar heb je uiteraard niets aan, tenzij je beide arrays na verloop van de meting ook kan uitlezen. Als je geen ruimte hebt voor printf() kan je misschien iets als dit gebruiken:


void puthex(unsigned char x)
{
    if (x < 10) {			// 0 ... 9
	putchar(x + '0');
    } else {				// A ... F
	putchar(x + 55);
    }
}

void hex2uart(unsigned int d)
{
    puthex((unsigned char) (d & 0xF000) >> 12);
    puthex((unsigned char) (d & 0x0F00) >> 8);
    puthex((unsigned char) (d & 0x00F0) >> 4);
    puthex((unsigned char) (d & 0x000F));
    putchar('\n');
    putchar('\r');
}

Hou er wel rekening mee, dat doorlopen van 1 tel-lus in de praktijk meer dan 1µS zal duren. Zowel het aanroepen van delay_us(1) als het verhogen van tmp en het doorlopen van de lus zelf nemen tijd in beslag. Maar op een pulstijd van bijna 1 mS is dat peanuts.

Ik kom er niet uit. Ik heb gemeten hoe lang de eerste lage sectie duurt volgens de uC, dit blijkt 960us te zijn (ipv 889 dus). Vervolgens wacht ik totdat IR_IN laag wordt, dan wacht ik 480us (1/4 periode) zodat ik in het midden van de puls zit en dan meet ik elke 960us wat de waarde is. Ik zou verwachten dat ik dan dus om en om 0'en en 1'en zie, met maximaal twee 1'en of 0'en achter elkaar. Toch gebeurt dit niet. 


0011100101101000100101111111
0011100101101000100111111111
0011100101101000100111111111
0001100101101000100111111111
0011100101101000100111111111
0001100101101000100111111111
0011100101101000100111111111
0011100101101000100111111111
0001100101101000100101111111
0011100101101000100101111111
0001100101101000100101111111
0011100101101000100111111111

Ik ga hem morgen maar eens aan een scoop hangen denk ik :) Er gebeuren vreemde dingen.

Bestel nou gewoon een TSOP1736 dan ben je klaar ;-)
Een 1738 gaat echt niet werken.

Daar zeg je wat.. Zou het demoduleren gewoon fout gaan? Donderdag zal ik wel een TSOP1736 halen..

Guys... Ik geloof dat we met z'n allen ergens overheen gelezen hebben.

Bij een AVR werkt het over het algemeen als volgt: 


if (PIND & (1 << 6))

De syntax PIND.6 o.i.d. heb ik op de AVR nog niet zien werken. Kennelijk doet je compiler er wel iets mee, want hij geeft geen foutmelding... Normaal definieer je dan IR_IN als PIND6, en dat is gedefinieerd naar 6. dus krijg je "PIND & (1<< IR_IN)" ...

Op 12 maart 2008 15:22:39 schreef rew:
Guys... Ik geloof dat we met z'n allen ergens overheen gelezen hebben.

Bij een AVR werkt het over het algemeen als volgt: 


if (PIND & (1 << 6))

De syntax PIND.6 o.i.d. heb ik op de AVR nog niet zien werken. Kennelijk doet je compiler er wel iets mee, want hij geeft geen foutmelding... Normaal definieer je dan IR_IN als PIND6, en dat is gedefinieerd naar 6. dus krijg je "PIND & (1<< IR_IN)" ...

Leuk geprobeerd, geen punten.

Ten eerste zien we toch duidelijk dat het bitje wel degelijk veranderd in die mooie blokken binaire data van de TS, en bij mijn weten is de waarde van 6 niet echt veranderd de laatste tijd.

Daarbij zou het wel heel vreemd zijn dat een C compiler daar niet over zou vallen. Ik neem aan dat jij een andere compiler (en headers) gebruikt dan de TS, want sommige definiëren dit gewoon. PIND.6 is dan hetzelfde als ( PIND & 0x40 ) >> 5.

@TS: wat me verbaast, is dat je vaste bit tijden gebruikt. Manchester codering is juist bedoelt voor goede clock recovery, daarvoor zijn ook de 2 start bits. Ik ben hier in het verleden ook wel eens mee bezig geweest, en als ik me goed herinner zat er nogal wat verschil in de bit tijden van verschillende afstandsbedieningen. Ik kon destijds ook nergens waarden vinden voor die bit tijden.

Manchester codering is leuk als je het hardwarematig moet decoderen; een PLL met tweedeler voor de clock recovery, en een schuifregister voor de data, veel meer is het niet.
Het schuifregister is gemakkelijk te maken in software, maar de PLL is best lastig.

Wat ik toen gedaan heb, is een timer vrij laten lopen, met een input capture en overflow interrupt. Deze timer laat je lopen een snelheid rond de 16x de verwachtte bitrate.
De overflow interrupt gebruik je om de timer softwarematig te vergroten (16 of 32 bit erbij, ophogen bij interrupt).
Bij elke input capture lees je de huidige waarde van de timer, en bepaal je de delta. Van het tweede startbit sla je deze delta op, voor alle andere pulsen vergelijk je deze met 1.5 keer de lengte van het startbit, om te kijken of het een kort of een lang bit was.

Op 12 maart 2008 16:07:49 schreef SparkyGSX:
[...]
Ik ben hier in het verleden ook wel eens mee bezig geweest, en als ik me goed herinner zat er nogal wat verschil in de bit tijden van verschillende afstandsbedieningen. Ik kon destijds ook nergens waarden vinden voor die bit tijden.

Die waarden staan in het geval van RC5/RC6 toch wel degelijk vast. Ik heb op basis van vrijwel hetzelfde principe als smsmonster hier laat zien een RC5X decoder gemaakt. Dat werkt tot op heden stabiel. Ik doe alleen niets met het toggle bit.

OK, tijdje geleden dat ik voor het laatst gereageerd heb. Ik heb een TSOP1736 gekocht maar deze geeft dezelfde problemen. Ik ben nu bang dat er toch iets mis loopt met de timing. Ik zal een extern kristal aanknopen en kijken of dat iets oplevert. Mocht zelfs dit niet werken, dan moet ik toch met een scoop aan de gang.