Akkor viszont valami hiányzik a rajzról! Vagy én nem látom?

USB GND1 közős az aksi GND-vel, Ha ezt megszakítod?
Minden áramkőr a GND2-re van kötve. Honan kap GND-t az egész cucc?


85mA egyértelműen kevés lehet ennek a cuccnak!

Hmm, ténylegesen hány volt a feszültség a GND2 és a VCC között? A sok dióda és egyéb tükrözés miatt szerintem 5V-nál jóval kevesebb (Az USB-ből is általában inkább 4V5 jön, az ATMEGA32-nek pedig 4V5 a minimum az adatlap szerint). A DC-DC konverter jelét is megnézném szkóppal milyen (kiegészítő LC szűrés csodákra képes). Inkább 8MHz-es kristályt használtam volna (akkor talán elmegy az alacsonyabb feszültségről).

Miért lenne kevés a 85mA? Építettem már olyan áramkört, ami elment akár 4V-ról is (pici módosítással ez akár 3V alá is csökkenthető lenne) , tartalmazott mikrokontrollert, műveleti erősítőt fesz/áram átalakítóval és mellette hőmérsékletet mért és beérte kevesebb mint 3mA-el (muszáj volt, lévén 4-20mA-es szenzor a drága ).

A GND2 a T1 tranzisztoron (nyitva van, mert az R20 kinyitja) és R22-n keresztül kapcsolódik a GND1-hez.
Egyébként úgy működik, hogy alaphelyzetben a T2 tranzisztor zárva van, mivel az R22-n eső feszültség nem éri el a T2 bázis emitter diódájának a nyitófeszültségét (kb. 0,6 V). Amikor az áram meghalad egy bizonyos értéket (ezért állítható az R22, 7Ohm környékén lesz majd). A T2 elkezd kinyitni. Ettől picit megnő az árama az R20 ellenállásnak (viszont a T1-nek kevesebb jut belőle, mivel a T2 felé halad). A T1 tehát elkezd záródni, ezzel növeli a rajta eső feszültséget. Mivel a "hasznos" áramkörön magán kevesebb feszültség esik, így csökken a felvett árama is.

A gond inkább ott van, hogy még a hasznos tartományban is viszonylag nagy a védelmen eső feszültség. Viszont a kolléga véleményem szerint rossz mikrokontrollert választott a feladathoz, mivel a sima ATMEGA32-ben nincs ekkora tartalék. Az ATMEGA32L viszont sokkal kevésbé érzékeny a feszültségesésre, igaz az csak 8MHz-en működik.

Meg van a hiba, hardveres volt. Figyelmetlenségemnek köszönhetően kihagytam a keypad hardveres bekötését a breadboardon. Illesztés után a hiba elhárult. A kód szerint a keypadot nem szükségszerű használnom, ugyan hardveresen mégis jelen kell lennie. Köszönöm mindenkinek a hasznos kommentet!

Sziasztok!
Egy kis segítségre lenne szükségem, megépítettem ezt a kapcsolást de nem működik, valaki tudna segíteni mi lehet a probléma? Milyen TSOP kell bele? Miért nem futhat a progi?
Előre is köszönöm.
Bővebben: Link

Egyáltalán nem megy ?

Az első bekapcsoláskor sorban villogniuk kell a LED-eknek. Ez sem megy? Mert akkor valószínűleg nem sikerült rendesen felprogramozni a kontrollert (fuse bitek?).

Ha viszont ez jó, akkor érdemes lehet szkóppal rámérni az infra vevő kimenetére, hogy valóban van-e ott jel, amikor a távirányítóval rávilágítasz (lábkiosztás stimmel-e, nem-e nyitott kollektoros véletlenül, stb). Ha ez is jó, akkor előfordulhat-e, hogy a távirányítód adatformátuma nem felel meg a remote.h-ban definiáltnak (NEC szabvány)?

Jó topicban vagyunk?

Ez a helyes sorrend.Vártam volna a visszajelzést , hogy meg mukkan e a készüléke de hát kilépett.Igy nehéz reagálni , hogy mi is lehet a gond.De a működés az ahogy leírtad.Annyival egészíteném ki , hogy amikor villognak a ledek egymás után a nyomógombbal kell beállítani , hogy melyik legyen a következő bekapcsoláskor mindig az első aktív kimenet.Ezt csak egyszer kell megcsinálni.

Bocsi, de el kellett mennem!
Nos az avr-t sikerült a megadott hex-el felprogramozni meg a fuse biteket is . De nem villognak a ledek bekapcsoláskor a feszültségek megvannak mértem. A fórumon az oldal alján is panaszkodtak az után építők, hogy valami nem jó. Amúgy milyen TSOP kellene bele mert azt nem írja a cikk?

A TSOP lehetőleg 38 kHz-es legyen (NEC szabványban ez van az internet szerint), és ne legyen nyitott kollektoros kimenetű (mondjuk én még nem is láttam olyat). Hogy a tiéd jó-e, arról szkóppal tudsz a legkönnyebben meggyőződni.

De ha meg sem mukkan a készülék, akkor nyilván nem ez a baj. Vagy a felprogramozással lesz gond, vagy nem lép be a konfigurációs rutinba a program. Ez például akkor fordulhat elő, ha valami okból a futás megakad a

ciklusnál. Ezt debugolással lehetne kideríteni, de úgy látom, a nyákon nincs JTAG. A másik lehetőség még az lehet, hogy az EEPROM memória nem üres, ugyanis a program akkor lép be a konfigurációs ciklusba, ha a 0x0000 címről kiolvasott adat 0xFF. Szóval ha korábban már használva volt az ATmega8, akkor próbáld meg törölni az EEPROM-ot.

A .hex fájl nem tartalmazza a kontroller típusát, sem a fuse biteket, ezeket biztosan jól beállítottad programozáskor? Én ilyen problémáknál azt szoktam csinálni, hogy az eredeti program helyett debug céllal egy egyszerű LED villogtató programot égetek be, így rögtön kiderül, hogy nincs-e baj a kontrollerrel, jár-e az oszcillátor, stb.

Hardveres hiba biztosan ki van zárva? Az ULN2003 is megkapja a tápot?

A panel az olyan mint az oldalon azt már átnéztem. Nekem most TSOP1736 van benne az volt kéznél. Ha nincs benne akkor is el kellene indulni a programnak? azaz villogni a ledeknek, gondolom. Most keresek egy másik kvarcot hátha amiatt nem megy, jártam már úgy!

Összedobtam egy próbanyákos verziót, de meg sem mukkan. Van benne TSOP1738 is de azzal sem megy és nélküle sem. Igaz nekem csak 4Mhz-ről jár a mega8-am.

Ennek nagyon örülök! Mármint, hogy kipróbáltad Te is, talán valaki rájön a hibára!!!

Olvasgattam a kommenteket az eredeti oldalon, és úgy tűnik, hogy senkinek sem működik. Szerintem a remote.c-ben van baj, és megakad a futás annál a sornál, amit írtam.

TSOP nélkül csak úgy érdemes megpróbálni, ha földre vagy tápra van kötve a bemenet, mert lebegő lábbal össze-vissza hívódhat meg az INT0.

Még egy dolog: ha esetleg ATmega8L kontrollered van, akkor az csak 8MHz-cel tud menni, 16-tal nem. Bár ha Gerrynek 4-gyel sem megy, akkor nem hiszem, hogy ez a baj.

Szerinted megoldható egy működő program? Én sajna nem nagyon értek hozzá.

mega8L-em van csak sajna.

Hát, a hardver megvan hozzá, úgyhogy persze, megoldható, legfeljebb nulláról meg kell írni. Ha megmondod, hogy pontosan milyen kontrollered van (minden számmal és betűvel együtt), akkor küldök egy .hex fájlt, ami az egyik LED-et (és a hozzá tartozó relét) kapcsolgatja. Így legalább megtudod, hogy nálad van-e a hiba, vagy az eredeti programban.

Gerry: De Te 4MHz-cel hajtod, akkor nem is baj. Ha Lajosnak is L-je van, az már baj...

Atmega8-16PU az áldozat!
Köszönöm ha meg tudod csinálni!
Kár lenne így hagyni, csak jó lenne ha tudnám valamire használni!
A fusebit az marad úgy ahogy a cikkben? Low 0xFF, High 0xC9?

Na, ennek a programnak másodpercenként villogtatnia kell az egyik LED-et. Mellékeltem a beégetendő hex fájlt. A fuse bitek maradhatnak.

Kipróbáltam tökéletesen működik!

Ez a rosszabbik eset. Lehet keresni a hibát az eredeti programban... Újrafordítottam az eredeti forrást, néhány helyen belejavítottam, ahol warningot dobott, próbáld ki ezzel. Egyébként szép lett a panel!

Köszi! Próbálom!

Beégettem, most gyorsan kapcsolgatja az egyik relét. Azt amelyiket az előbb.
Most hagyjuk mert reggel megyek dolgozni majd holnap jelentkezem! Vagy jelezd ha rájöttél valamire. Előre is köszönöm!

Ezt is kipróbálhatod, ha van philips tv távod.
Ez RC5-ös. Bekapcsolgatja a reléket ha megnyomod, ha megint megnyomod kikapcsolja.
Elmenteni nem ment, mert csak próbának csináltam.



A fusebitek, mint az eredetin!

Azt is kell neki csinálnia, nem? Villog az első LED, amíg meg nem nyomod a kívánt gombot a távirányítón. Aztán villog a második és így tovább...

Ez működik URC22B távirányítóval, elég bizonytalanul kapcsol de működik mind az öt csatorna!
TSOP 1736 van benne. Az jó?

Kipróbáltam az előzőt, úgy működik ahogy mondod amíg villog nyomni kell egy gombot s utána a következő villog stb... Csak nagyon nehezen sikerül neki venni a jelet ez mitől lehet?
No mindegy majd holnap kereslek megyek aludni .
Jó éjt Neked!

Nekem 1738 van a kapcsolásban azzal tökéletesen kapcsolgat.
Nem olvastam el a működését az eredeti programnak, csak azt tudja hogy felkapcsolja, majd le az összes ledet és utána átvált távirányító módba. De ez csak próba. Ha Balázs kijavítja az eredeti programot, akkor megyen az majd rendesen!

A remote.c -ben 1738-at ír a szerző

Kipróbáltam ATmega128-cal a módosított kódot, működik. Az volt a gond, hogy amikor egy char típusú változót -1-gyel hasonlított össze, akkor a -1 intként volt értelmezve, így sosem teljesült az egyenlőség, és a program megakadt abban a végtelen ciklusban, amit korábban mondtam. Átírtam a QFront és a QEnd változók típusát intre, és így már jó.

Lajos: Mivel Gerry megoldásával is ilyen problémád volt, arra tippelnék, hogy nem nem lesz jó a 36kHz-es vevő. Próbáld ki 1738-assal, nekem is az van.