Emulare telecomanda IR

[louis]

Bun, cum in ultimul thread am esuat in problema abordata, mi-am gasit altceva de lucru, in incercarile mele de a descoperi lumea micrcontrollerelor cat mai aplicat cu putinta.

 

Tema proiectului este constructia unui circuit cu care sa controlez aerul conditionat Samsung din camera. De ce? Simplu, nu-mi place ca are unele hibe software. De exemplu, modelul nu opreste baleiajul de directionare a aerului in pozitii prestabilite. Cand ii dau drumul, se pune la 45 grade si imi sufla in cap. Trebuie sa fac manevre suplimentare pe telecomanda respectiv, apas butonul de swing, si pandesc cand aerul bate in podea, si apoi mai apas odata swing sa ramana asa. De asemenea nu-mi place ca dupa ce aduce la temperatura camera ventilatia ramane. As prefera sa se inchida si sa pornesca in jumate de ora sa zicem, sau mai usor, cand un circuit diy detecteaza o temperatura intr-un anumit loc din camera.

 

Bun, pentru asta avem nevoie de un pic..si eu lucrez pe 16f88. Mai avem nevoie de studiul semnalului telecomenzii. Pentru asta am cumparat un senzr IR shf5110 pe care il hranesc la 5v iar iesirea o bag in 2 rezistente cu care fac un divizor de tensiune. Intre rezistente plec cu 2 fire catre placa audio. Datorita faptului ca frecventa e pe undeva la 36kHz se captureaza bine mersi pe audio-in-ul placii de sunet folosind Zelscope (software google it).

 

Telecomanda este modelul Samsung ARH-1363 ce seamana cu ARH-1362 care se gaseste mai usor gugalind. Cautand informatii despre protocoalele telecomenzilor IR am ajuns si la LIRC unde se gaseste o baza de date cu multe telecomenzi si protocoalele lor. Din pacate n-am gasit decat o versiune de samsung ce are initiale ARH care s-a dovedit a nu semana cu ceea ce aveam eu.

 

Un site frumos de protocoale se gaseste si aici, dar sunt protocoale generale si nu se pupa cu cazurile individuale.

 

Bun, acum sa revin la analiza protocolului care mi-a luat vreo 2 zile. Telecomanda transmite la o simpla apasare de buton, 3 sau 2 rafale de date, una dupa alta, marcate fiecare printr-un header cu o pauza corespunzatoare. Bitii sunt codati cu 0 daca pulsul e urmat de o pauza scurta si cu 1 daca e urmat de o pauza lunga.

Lungimea rafalelor este de 12+8+32+4 deci vreo 56 de biti.

Hackingul e un calvar. Ganditi-va ca trebuie sa faci sute de capturi de frecventa pe apasat de butoane, sa le bagi intr-un editor grafic, sa decupezi zonele si sa le pui langa alte bucati si sa studiezi zonele unde apar modificari ale bitilor. Se ia usor cu apasatul butonului de cresterea temperaturii, se creste cu 1 grad, se face captura, si se compara cu captura precedenta, descoperind astfel unde s-au modificat, si acolo e zona de temperaturi. Cu timpul zonele se reveleaza. trebuie testate toate butoanele.

 

In principiu am descoperit ca la pornire, prima rafala de 56biti e de initializare, nefiind transmise date. Apoi urmeaza inca o rafala care transmite date legate de timer-ul de pornit/oprit programabil.. ultima rafala contine datele importante, de la temperatura setata, la modul (frig, cald fan etc) pana la viteza motorului si swing-ul. Dupa ce AC-ul e pornit, sunt transmise doar 2 rafale, daca se fac manevre care nu implica timerul (cel din rafala 2).

 

Dupa ce am descoperit zonele din biti asociate butoanelor, am dat de o belea. O zona de 2-3biti care aparent se modifica random. Am realizat ca e vreo treaba de CRC si-mi venea sa-mi dau palme ca muncisem degeaba Va dati seama ca un CRC, si cel mai simplu, se calculeaza in cip-ul telecomenzii, si n-ai cum sa-ti dai seama ce face ala. Dupa vreo 2h de incercari, am descoperit ca introducerea cate unui "1" in plus/minus intr-o rafala, modifica linear bitii din zona crc. Spre exemplu, 16 grade in binar 10000 contine un 1. Daca setam 20 grade (10100 binar) si faceam captura semnalului , aveam inca un UNU in rafala si constatam ca si CRC-ul crestea/scadea cu 1 fata de precedentul. Initial nu stiam de cati biti e zona CRC-ului, incercand cu 3 biti sa fie vreun rest de impartire, apoi cu 4. Dupa care am vazut ca din cei 8 biti din zona, in diverse combinatii erau atinsi vreo 5 din 8. la final am ajuns la concluzia ca e o diferenta. CRC-ul era de fapt, 0xFF (8 biti) minus suma bitilor "1" din rafala. De aia cand erau putine date (1) cei mai multi biti din CRC erau "1", in special cei din capatul din dreapta.

 

Mai sunt cateva zone de biti care nu am descoperit ce fac. Aparent nu se modifica din butoane. Testarea lor va avea loc cand voi construi modulul de emitere si voi putea trimite efectiv semnalul. Momentan sunt la stadiul de captura in PIC a semnalului telecomenzii si afisarea lui pe portul serial in calculator. Dar despre asta vom vorbi intr-un episod viitor.

 

Aveti aici si protocolul "pictat" in graba in timpul cercetarilor.

[Liviu M]

In poza de la imageshack ai, la good sleep, bitii marcati 1 1 1 0 = 7; in functie de cum se transmite (msb first sau lsb first) asta poate fi si E.Presupun ca ai avut in vedere aspectul asta cand ai "decodat".

[louis]

n-am stiut niciodata care-i msb lsb big endian si astea. adica le-oi fi stiut odata, dar daca nu te lovesti de ele zilnic le uiti. deci, bitii cei mai reprezentativi (msb) se citesc de la dreapta la stanga in acest proiect. cred ca asta ar insemna little-endian system, adica lsb sunt stocati in memoria mai mica adica la stanga.

[Liviu M]

Tinand cont ca faci inginerie inversa (cum suna ), e mai putin important; important e sa fii consecvent. Altfel trebuie sa te uiti prin documentatii la ce conventie foloseste producatorul cipului.

[louis]

nu cred ca tine de cip ci de softul din el, mai bine spus de protocol, ala stabileste cum sunt trimise semnalele. am desfacut telecomanda ieri, cand era sa ma dau batut din cauza CRC-ului, am zis sa vad ce cip are. din pacate era ceva super mic, acoperit de o paleasca de picatura de rasina din aia sau ce-o fi, de nu se vedea nimic. mai era si sub lcd-ul care parea ca nu se poate demonta.

[Liviu M]

Ma rog, la toate circuitele cu care am comunicat se specifica cine-i primul, msb sau lsb. Da' cum spuneam, atata timp cat esti consecvent, ar trebui sa n-ai probleme.Uite de exemplu citat din data-sheetul senzorului DS1631 (de care tocmai am pomenit intr-un alt topic):

GENERAL 2-WIRE INFORMATION- All data is transmitted MSb first over the 2-wire bus.

[louis]

azi urmeaza episodul 2: partea de software de pic cu care capturam semnalul telecomenzii samsung.desi n-ar trebui sa ne intereseza, strict urmarind sa producem un IR sender, e interesant de capturat cu un pic, semnalul unei telecomenzi, pentru utilizari in proiecte viitoare.pentru asta am folosit ca parte hardware, un pic16f88 montat cum se vede pe breadboard. se observa senzorul infrared si cele 2 rezistente cu care scad voltajul la iesire si trimit semnalul in placa de sunet pentru captura cu Zelscope. in poza, o rezistenta e in aer pentru ca semnalul mergea catre pinul pic-ului cu care faceam deja teste de captura. pinii Rx si Tx ai pic-ului merg spre un MAX3232 (coltul dreapta sus pe breadboard) de unde ajung pe serial in calculator, asa fiind usor de monitorizat ce capturam. e un fel de output bun la debugging. alimentarea are + ul pe exteriorul celor 2 coloane din stanga si dreapta pic-ului. se mai vede si un rezistor >10K pe + la MCLR si pinii la 90grade la care leg programatorul (coltul stanga jos).bun. acum sa vorbim de software. pentru captura folosim o functie de captura a PIC-ului. functia CCP (capture, compate, PWM) mai precis functia de captura. ce face aceasta? pur si simplu apeleaza o functie a noastra in momentul in care simte o variatie de voltaj pe pinii predestinati (CCP1). sunt mai multe tipuri de variatii la care ne poate notifica. pe noi ne intereseaza sa ne anunte cand creste voltajul si cand scade. asa putem urmari "zimtii" semnalului. de fiecare data cand functia noastra va fi notificata, noi vom cere procesorului ca data viitoare sa ne anunte o scadere daca in prezent e o crestere si invers, daca acum suntem pe scadere il punem sa ne anunte o crestere. in momentul semnalarii, avem in 2 registri si timpul unui timer. dar de timpul asta trebuie sa ne ocupam si sa-l resetam la 0 la fiecare eveniment, asa incat la urmatorul sa stim exact durata dintre o urcare si o coborare a semnalului.ce se intampla daca nu mai vin "zimti" pe teava la un moment dat in timp ce adunam "zimtii" in niste buffere? functia noastra nu va mai fi notificata si ramanem "in aer". pentru asta trebuie sa folosim un timer si sa definim o periaoda de timeout oarecum mai mare de cel mai mare interval care reprezinta ceva in semnalul nostru. la fiecare intrerupere pe captura, cand functia noastra e apelata, resetam acel timer si ne asiguram ca nu expira. daca nu mai vin date, timerul expira, iar cand expira ne notifica pe un intrerupt, ca si pinul de captura. atunci noi fiind "in aer" putem face o verificare a bufferului sa vedem daca e plin cu date, si daca nu e, il dam invalid si resetam programul sa astepte o noua rafala de biti.functia in care capturam bitii, fiind pe intrerupt tebuie sa n-o lungim extraordinar de mult. trebuie sa ne uitam la delta t-ul unui puls, care in cazul nostru e de aprox. 500us. ea va fi notificata de fiecare data la acel interval, dar daca executia in interiorul ei dureaza mai mult de atat, vom pierde evident date.o alta chestie e ca semnalul nostru ajuns in pic e inversat. deci ce vedem in Zeloscope trebuie pus pe INV ca sa arate cum "vede" picul, pentru ca senzorul tine constant 4-5V si scade la 0 cand primeste lumina. de aia daca un 1 insemna un maxim de 500ms urmat de o pauza de 3x mai mare, noi vom cauta pe semnal un "gap" de 500ms si o creasta de 3x mai mare.mai mult, fiecare "rafala" e anuntata printr-un Header (puls dar noi il vedem ca gap) de 3ms, si o pauza 3x3ms. in functia noastra de captura trebuie sa sarim peste intreruperile astea, dar verificand ca intervalele de timp sunt corecte. tinand cont de semnalul inversat, cand vom da start la intreruperi, captura trebuie pusa pe "Capture mode, every falling edge" pentru ca asteptam gap-ul reprezentat de header.trebuie sa tiem cont telecomanda trimite 2 sau 3 rafale de cate 56biti legate despre care am mai vorbit (in principiu daca se seteaza ceva legat de timer-ul telecomenzii, apare inserata o rafala la mijloc; aceasta apare constant si la start sau la stop; ultima rafala contine mereu temperatura, viteza, modul, in timp ce prima e una de forma). din cauza asta nu avem timp sa le aratam la terminal pe fiecare in parte facand o functie care sa captureze doar o rafala. ele trebuiesc capturate toate 2/3 odata atfel le pierdem in intervalul dintre afisari. deci ne trebuie un buffer in care sa stocam cele 3 rafale.

/* * SAMSUNG ARH 1363 * header 3080us pause 9000us * 1 : 500us pause 1440us * zero 500us pause 500us */

acum sa vorbim putin de clock si frecventa de oscilatie. am folosit Timer1 al pic-ului pus sa genereze time-outul cu care sa prindem daca am ramas "atarnati" sau am terminat captura. din comoditate am pus PIC-ul sa foloseasca oscilatorul intern (fiind dotat cu asa ceva), nemaidorind sa incarc montajul cu inca un cristal si 2 caps-uri. asta se defineste in __CONFIG(INTIO... si mai departe OSCCON = 0x62 care seteaza oscilatorul-ul intern la 4Mhz. la frecventa asta, instructiunile sunt executate cu FOSC/4. de asemenea setand TMR1CS = 0; timer 1 va rula si el tot la FOSC/4 adica 1Mhz. ce inseamna asta? un tick de Timer1 va dura o microsecunda 1us. el "se va da peste cap" la 0xFFFF adica dupa 65535 ticaieli care dureaza 1us adica 65ms. se observa va e suficient timp fiind mult mai mare decat lungimea pauzei headerului (9ms), ca sa zicem ca poate timeout-a in mijlocul ei. cand intreruperea pe captura are loc, 2 registre de 2bytes fiecare ne dau timpul clock-ului din momentul intreruperii: CCPR1H si CCPR1L; din cmoditate si din faptul ca nu necesitam precizie extraordinara am folosit numai partea cea mai semnificativa - HIGH; spre exemplu, vrem sa vedem daca intervalul capturat corespunde pauzei headerului (9ms); 9ms inseamna in cazul nostru 9000tick-uri. dca ne uitam doar la partea high, impartim la 256 si avem ~35. acum trebuie sa ne alegem un interval in care sa fie facuta comparatia. eu am ales [32,38] (see ir2.h)

if (CCPR1H < SAMS_HEADP_MIN ||CCPR1H > SAMS_HEADP_MAX) {			sams.flags.invalid = 1;

libraria de care m-am folosit pentru a intelege cum se fac capturile este de aici Multi protocol IR decoder. am adaptat-o pentru pic16f88 si pentru frecventa cristalului meu; nu m-am atins de timingurile celorlalte telecomenzi suportate de autor, dar el mentioneaza ca are frecventa la timer de 4MHz (are FOSC 16Mhz), adica de 4x mai mare ca a mea, asa incat, intervalele alea ar trebui micsorate de 4x ca sa mearga in proiectul meu.am atasat si codul sursa (c-mplab HI-TECH)o poza cu terminalul aratand Tx din PIC cu rafalele capturate

[fratello]

Astept cu mare interes si partea despre transmiterea codurilor in IR. M-am chinuit si eu sa 'clonez' o telecomanda in infrarosu, protocol RC10, pentru aparatele audio (casetofon, radio-card, etc) modele Blaupunkt, folosite in auto. Rezultatul a fost bun...si nu prea :(. Nu am reusit sa scriu un cod care sa fie bun pentru toate PIC-urile tip 12F675 folosite; timpii trebuia configurati manual, datorita ne-preciziei oscilatorului intern. Teoretic eu setam osc_int pe 4 MHz, in realitate insa cred ca erau (mici ?) variatii de la aceasta frecventa, a.i. timmingul trenurilor de impulsuri necesita corectie sofware...M-a disperat, ce sa mai vorbim...De aceea urmaresc cu interes acest subiect, iar prezentarea este SUPER ! Iti doresc succes in continuare !

[louis]

aici m-am impotmolit si eu am probleme legate de partea hardware. cred. in sensul ca trimit semnal digital ON/OFF in baza unui tranzistor la care e legat LED-ul IR. ei, daca tin semnalul ON pentru intervalul necesar de vreo 500us, nu vrea sa stea mai mult de 100ms, si nu stiu daca e de la receiver sau de la sender, pisicii ma sii. asa ca trebuie ca in intervalul ala sa trimit de multe ori 1 si 0 asa incat sa iasa un fel de pwm cu duty. numai asa il fac sa fie vazut de receiver ON pe durata cat am nevoie.mai mult, m-am chinuit sa scriu 2 functii, una pentru trimiterea lui "1" si una pentru "0"; avand in vedere ca la 4MHz FOSC, o instructiune ruleaza la 1us (FOSC/4) si ca eu am nevoie sa trimit semnal la fiecare 500us (sau multipli de valoarea asta), codul executat in functiile alea oarecum poate fi lungit//scurtat (numarand efectiv instructiunile asm) sa se invarta in jurul a 500us prin numaratul instructiunilor, introdusul unei bucle "for" (de care oricum am nevoie pentru pwm fake) si niste nop-uri. nu e de ajuns numai asta pentru ca atunci cand trimitem bitii pe teava, codul acela (un for(..) are cateva zeci de instructiuni asm deci us) papa si el timp si va mari timpul de trimitere din functiile cele 2 (ptr 1 si 0). trimitand 32 biti de "0"in modul asta am constatat ca intervalele de "0" se labarteaza spre final si nu au o valoare constanta. si nu stiu de ce. cred ca se cere o alta metoda, mai putin empirica. dar n-am gasit exemple. la viteza de 1us/instructiune e cam greu sa scrii cod cu care sa manevrezi intervale de 500us asa cum am inceput eu.

[Liviu M]

Timer + intreruperi.Adica folosesti un timer care sa numere pana la 250, pui prescaler 2 si iata, ai obtinut 500us.Ca sa ai timp sa mai faci una-alta, o sa numere de fapt pana la 245..250 (calculezi sau tatonezi). Numai asa o sa ai cat de cat siguranta ca face ce vrei tu.LE Sorry, am citit de jos in sus si acum am ajuns si la partea cu timeri; se pare ca stii sa-i folosesti, asa ca uita de raspunsul asta.

[louis]

intrebare:

1.dupa cum spuneam, cand pun pinul in 5v si las 500us sa aprinda led-ul IR, acesta nu trimite semnal decat pentru o fractiune din alea 500us dupa care pauza, receptorul vede pauza pana la 500us. e problema de hardware, sau asa trebuie sa faca led-urile IR. adaug aici ca led-ul ia curent dintr-un tranzistor pentru ca are nevoie de 100mA si din pic ies doar 20mA.

2. am vazut asocierea telecomanda IR - frecv de modulare 38KHz. ce reprezinta asta? - pentru ca eu am perioadele alea multipli de 500us, care ar corespunde unei frecvente mult mai mici.

 

le:

cred ca e "by design" iar senzorii trebuiesc folositi la frecventa aia. "An IR remote works by turning the LED on and off in a particular pattern. However, to prevent inteference from IR sources such as sunlight or lights, the LED is not turned on steadily, but is turned on and off at a modulation frequency (typically 36, 38, or 40KHz). "

 

am mai povestit ca "pulsurile" se labarteaza in timp (spre exemplu daca trimit 32 biti de "0", intervalele se maresc constat spre final), pentru ca folosesc delay software; in acelasi timp in pic ruleaza si functia de detectie, pentru ca am lasat montat in circuit si receptorul IR cu care fac captura (evident, pentru a verifica ce trimit); iar asta merge pe intreruperi, care pot cauza modificarea delay-iului din functiile cu care trimit bitii; cel putin cred ca asta ar fi o explicatie; n-am stat sa verific.

 

spre exemplu, cum transmit bitul "1" = un puls + 3 pauze:

void SendOne(void){	for(int i=0; i<15; i++)	{		IR_LED_SEND = HIGH;		NOP		IR_LED_SEND = LOW;	}	for(int i=0; i<20*3; i++)	{			NOP NOP		IR_LED_SEND = LOW;	}}

si cum arata in asm primul for:

185:               void SendOne(void)186:               {187:               	for(int i=0; i<15; i++)   FA1    3000     MOVLW 0   FA2    1283     BCF 0x3, 0x5   FA3    1303     BCF 0x3, 0x6   FA4    00A4     MOVWF 0x24   FA5    3000     MOVLW 0   FA6    00A5     MOVWF 0x25   FA7    0825     MOVF 0x25, W   FA8    3A80     XORLW 0x80   FA9    00FF     MOVWF 0x7f   FAA    3080     MOVLW 0x80   FAB    027F     SUBWF 0x7f, W   FAC    1D03     BTFSS 0x3, 0x2   FAD    2FB0     GOTO 0x7b0   FAE    300F     MOVLW 0xf   FAF    0224     SUBWF 0x24, W   FB0    1C03     BTFSS 0x3, 0   FB1    2FB3     GOTO 0x7b3   FB2    2FB4     GOTO 0x7b4   FB3    2FB6     GOTO 0x7b6   FB4    2FD1     GOTO 0x7d1   FB5    2FD1     GOTO 0x7d1   FBD    3001     MOVLW 0x1   FBE    07A4     ADDWF 0x24, F   FBF    1803     BTFSC 0x3, 0   FC0    0AA5     INCF 0x25, F   FC1    3000     MOVLW 0   FC2    07A5     ADDWF 0x25, F   FC3    0825     MOVF 0x25, W   FC4    3A80     XORLW 0x80   FC5    00FF     MOVWF 0x7f   FC6    3080     MOVLW 0x80   FC7    027F     SUBWF 0x7f, W   FC8    1D03     BTFSS 0x3, 0x2   FC9    2FCC     GOTO 0x7cc   FCA    300F     MOVLW 0xf   FCB    0224     SUBWF 0x24, W   FCC    1C03     BTFSS 0x3, 0   FCD    2FCF     GOTO 0x7cf   FCE    2FD0     GOTO 0x7d0   FCF    2FB6     GOTO 0x7b6   FD0    2FD1     GOTO 0x7d1188:               	{189:               		IR_LED_SEND = HIGH;   FB6    1283     BCF 0x3, 0x5   FB7    1303     BCF 0x3, 0x6   FB8    1606     BSF 0x6, 0x4190:               		NOP   FB9    0000     NOP191:               		IR_LED_SEND = LOW;   FBA    1283     BCF 0x3, 0x5   FBB    1303     BCF 0x3, 0x6   FBC    1206     BCF 0x6, 0x4192:               	}

avem vreo 27 de instructiuni executate de 15x =~ 405. fiecare papa cate 1us rezulta ca ne putem juca cu ele sa aproximam pulsul in valoare de 500us. ce am omis este ca in acelasi timp ruleaza si codul de detectie a semnalului pentru receiverul IR fiind pus pe intreruperi. si ala papa timp si incurca. cele 3 pauze le-am mai lungit (tot incercand ajustari disperate) fata de puls..3x20 de bucle fata de 15 la puls. probabil ca pe "puls" intra si interruptul de captura si de aia cele 400us de aici apar in final lungite.

 

deci asta ar fi un fel de pwm software. e totul la voia intamplarii, depinde de ce mai ruleaza in sistem. la frecvente mai mari de clock, probabil codul de pe intreruperi incurca mai putin fiind executat mai repede. totodata trebuiesc marite for-urile pentru respectarea duratelor, instructiunile executandu-se mai rapid. dar tot e la voia intamplarii

[fratello]

Poate e de ajutor : http://home.citycable.ch/flotulopex/REM ... ames_e.htm

[louis]

pana la urma i-am dat de cap cat de cat. azi aerul conditionat a primit prima comanda valida din led-ul IR montat pe breadboard

 

am descoperit ce-mi "labartza" sirul de 32 de bit "0"

 

for( uint8_t i = 0; i < 32; i++){		sendBit((uint8_t)((cmd.data1>>i)&0x1));	}

sa analizam. aveam de transmis un integer pe 32 biti. pentru asta, luam fiecate bit si-l bagam in functia SendBit care transmitea o perioada T 5v si o prioada T 0v daca bit-ul era null. T fiind 500us, adica exact cat vreo 500 de instructiuni de pic cu FOSC 4mhz. trebuie sa remarcam ca si for(..) are si el un numar de instructiuni (destul de multe) iar shifting-ul ala pe biti e dezastruos. am impresia ca shift >> n, ocupa de n ori mai mult timp decat shift>>1. asa incat, desi functia SendBit ramanea constanta ca valoare de timp, timp suplimentar era papat aici in rutina asta, pentru furnizarea argumentului. am rezolvat-o print-o variabila temporara pe care o shiftuiesc la fiecare for, si asa ramane.

 

mai departe, am lasat la o parte bit banging-ul prin care emulam pwm ca sa tin ledul IR high, nereusind sa ajustez cat de cat delay-urile la modularea semnalului. neavand nici osciloscop si facand doar comparatii pe captura audio e greu de potrivit intervalele intre ce scoate lelecomanda si ce scot eu.. asa incat am setat un pin pe pwm la frecv de 38khz cu duty 50% si folosesc delay-ul din librariile compilatorului.

 

metoda asta nu mi-a mai lasat posibilitatea sa folosesc in acelasi timp si senzorul cu care am facut captura la episodul 2, deoarece modulul capture/compare-pwm este unul singur la pic16f88, si eu il foloseam si la captura semnalului, si acum la transmitere prin pwm.

 

iar o treaba nasoala. tot codand si adaugand functii noi in programel, terminand partea de trasnsimtere, am zis, hai sa ma-ntorc la captura sa mai notez niste comenzi de telecomanda, sa le intoduc in softul de transmitere. am constatat cu stupefactie ca nu mai capturam nimic. atunci am pus intre niste #define toate chestiile noi adaugate la transmisie si in final, eliminate de la compilare, au lasat iar partea de captura sa mearga dar nu cum era initial (tot da niste rateuri). ideea e ca nu rulau in while ci doar erau compilate si probabil umpleau memoria pic-ului. ciudat rau.

[louis]

iar o treaba nasoala. tot codand si adaugand functii noi in programel, terminand partea de trasnsimtere, am zis, hai sa ma-ntorc la captura sa mai notez niste comenzi de telecomanda, sa le intoduc in softul de transmitere. am constatat cu stupefactie ca nu mai capturam nimic.

am descoperit de ce nu apareau comenzile din telecomanda originala prinse de functia de captura..in Terminal de com1. nu era de vina pic-ul vinovat era max3232. alimentat la 5v necesita niste capacitoare mai mari decat aveam puse. daca trimiteam multe caractere la terminal, probabil ca n-avea suficient curent sa le trimita pe toate si trimitea si el random, cand toate, cand nimic cand doar 1-2 randuri. cu ocazia asta am mai adus un fix si functiei de captura.acum am toate jucariile ca sa fac ce vreau cu aerul conditionat

[Liviu M]

Captura o poti face si pe RBx (x=0, 4..7 sau cati RB sunt la picul tau), care functioneaza cam ca modulul compare, numai ca trebuie sa numeri de unul singur delay-ul intre flancuri. Pentru asta e bun tmr0.Cu RB0 trebuie sa ai tu grija sa schimbi flancul de detectie, la RB4..RB7 ar trebui sa faca singur schimbarea.