Hallo.
Ich hätte da gerne mal ein Problem. Nämlich das folgende:
Ich habe gerade versucht mit der Software von Peter Danegger (in einem
anderen post hier irgendwo ^^) wenn ein Mega8 irgendein Signal empfängt
eine LED zu toggeln.
Blöd nur, dass er anscheinend mit den Signalen, die er bekommt nichts
anfangen kann. (Definitiv sind hier RC5 Fernbedienungen unter denen, die
ich hier grad probiere).
Der uC läuft mit 4MHz internem Takt. Ich würde gerne einen 4MHz Quarz
anschließen, hab aber keine Ahnung, auf welchen von den geschätzen 20
Werten der Fusebits ich selbige setzen muss (Slow, Middle, Fast, ...)
Im Anhang der für die aktuelle GCC version angepasste code.
Danke Schonmal! Gruß M.
Kannst ja mal zum Test die LED Toggeln, wenn der Empfangspin was
empfängt, also ein Test, ob die Schaltung ok ist.
Hast du einen richtigen Fernbedienungsempfänger am Pin (z.B. TSOP1736),
richtig geschaltet?
Hey Tobi,
Also die Beschaltung sieht folgendermaßen aus:
GND an GND
V+ an +5V
die Datenleitung an PD2 und über 10kOhm an +5V
Ich hab jetzt mal ne LED mit der kathode an die Datenleitung vom TSOP
geschaltet und man sieht wie das teil flackert, wenn ich ne Taste auf
einer Fernbedienung drücke.
Oder meinst du den Port-Toggle befehl an einer anderen Stelle einfügen,
wenn ja an welcher?
Aja, dann funktioniert die hardware ja schonmal.
Die RC5 software von P-Dannegger sollte ja auch funktionieren, vllt hat
er einen anderen Takt benutzt, nicht 4 MHz, oder von deinen
Fernbedienungen ist keine RC5. Ich hab 3 zuhause, und keine davon ist
RC5.
Ich geh jetzt schlafen. Gute Nacht
am tsop liegts nicht. wenn du einen 1738 anstatt einen 1736 nimmst
klappt das trotzdem - nur mit geringerer reichweite. hast du schon die
timer pulsezeiten angepasst auf deine taktfrequenz??
da du ja "TCNT0 = -2", "PULSE_MIN (uchar)(XTAL / 512 RC5TIME 0.4 +
0.5)" etc. nicht an deine taktfrequenz von 4mhz angepasst hast. scheinst
du den code nur kopiert zu haben. versuch ihn doch einfach mal zu
vertsehen. dann wirst du feststellen, dass peter die ganze sache für
eine anderen taktfrequenz geschrieben hat. ich glaube er hatte 16mhz.
das heisst, dass du den timer/prescaler neu berechnen und die "512"
anpassen musst.
Hallo!
Das mit der 512 kann schon bleiben; lediglich der XTAL sollte an den
Quartz angepaßt werden. Ich habe diese Routine schon mit diversen
Quartz-Frequenzen ausprobiert und es klappte immer. Es gibt lediglich
Probleme, wenn die Fernbedienung nicht die passenden Sequenzen sendet;
das ist bei Universalfernbedienungen halt auszuprobieren, bei welchen
Einstellungen das funktioniert. Der TSOP selbst ist da relativ
entspannt, was die Frequenz angeht; 36 - 40 khz decken die Teile schon
ab (mit leichten Einbußen in der Empfindlichkeit). Probier mal ein
bißchen rum
>Das mit der 512 kann schon bleiben; lediglich der XTAL sollte an den>Quartz angepaßt werden. Ich habe diese Routine schon mit diversen>Quartz-Frequenzen ausprobiert und es klappte immer. Es gibt lediglich>Probleme, wenn die Fernbedienung nicht die passenden Sequenzen sendet;>das ist bei Universalfernbedienungen halt auszuprobieren, bei welchen>Einstellungen das funktioniert. Der TSOP selbst ist da relativ>entspannt, was die Frequenz angeht; 36 - 40 khz decken die Teile schon>ab (mit leichten Einbußen in der Empfindlichkeit). Probier mal ein>bißchen rum
Dann hast du immer Glück gehabt das sich der Wert nicht groß geändert
hat. Er muss auf jeden Fall neu berechnet werden. Schon alleine weil
TCNT0 bei 4MHz und 256 Prescaler auf -5 angepasst werden muss um die
32µs einzuhalten. Versucht doch bitter erst einmal den Kode zu
verstehen.
Hallo ihr,
also ich werde mir demnächst mal ein oszi beschaffen und mir angucken,
was der TSOP da so produziert, so langsam fange ich an an den
Fernbedienungen zu zweifeln.
Ja gast, so ganz verstanden hab ich den Code noch nicht, hier allerdings
mal ein zitat aus der beiligenden index.htm:
"Der Timerinerrupt wurde so eingestellt, daß er alle 512 Zyklen
aufgerufen wird. Damit ergeben sich bei 4MHz je Bitzeit
4e6/512*1.778e-3=14 Aufrufe des Timerinterrupts. Das ist ausreichend
fein gestaffelt, um die verschiedenen Zeitbedingungen testen zu können.
Bei höheren Quarzfrequenzen kann man die Zyklenzahl entsprechend
erhöhen."
Gruß
Naja; bei Frequenzen von 3,8xxx bis 8 Mhz funktioniert die Routine; alle
Werte der Fernbedienung werden bei mirsauber erkannt. Poste doch mal
Deine main.c und Deine Schaltung
Den Code findest du im 1. Post im Anhang, die Schaltung habe ich im 3.
Post beschrieben
Habe jetzt einen externen Quarz mit 4MHz angeschlossen mit folgenden
FUSE settings: CKSEL=1111 und SUT=11, falls das irgendwie weiterhilft
So, Oszi ist da, sogar gleich ein Rolls Royce unter den Oszis, hab ich
von dem Vater meiner Freundin ausgeliehen bekommen.
Nach ein bisschen rumtüfteln an der Signalerfassung klappt das sogar
ganz prima ... Ich brauch auch so ein Teil :D
Also hier mal ein paar Bilder die ich von dem Signal gemacht hab:
Das gesamte Signal: http://marcelk.info/ir/tek0006.png
Der Afnang des SIgnals: http://marcelk.info/ir/tek0005.png
Wenn eine Taste gedrückt ist, wird dieses SIgnal wiederhohlt:
http://marcelk.info/ir/tek0004.png
Das mit den Bildern vom Oszi hat leider nicht so geklappt, falls ihr
euch die anderen in dem Verzeichnis noch anguckt. Ich hab da mit den
Cursorn noch die Länge der Pulse vermessen, aber da wo diese
Informationen normalerweise stehen, ist leider der "Datei Speichern"
Dialog vom Oszi ^^
Naja, ich hoffe ihr schlachtet mich jetzt nicht, aber das ganze sieht
nach dem JVC Protokoll aus, doch kein RC5 ... argh
Sorry, ich habe wirklich fest daran geglaubt, das wäre RC5, weil ich mal
einen IR-Empfänger für den PC gebaut habe (Serieller Port) und ich
dachte die Software dafür kann nur RC5, die ist nämlich mit allen FBs
die ich hatte klar gekommen. Die Software konnte aber anscheinend noch
ein paar mehr Protokolle!
Aber vielen Dank und ein dickes Sorry für alle die versucht haben mir zu
helfen, super Community hier ;)
Gruß Masl
Hallo Masl,
der aufgezeichnete Code ist sicher kein JVC, da der nur 16-bit lang ist.
Ich würde auf extended-NEC tippen. Also 16-bit Adresse, 8-bit Befehl und
8-bit negierter Befehl. Demnach wäre das deine Sequenz:
00001000 10110111 11010010 00101101
Schau mal hier für die Beschreibung:
http://www.sbprojects.com/knowledge/ir/nec.htm
Gruß
Rolf
Oh stimmt, auf die gesamt länge hab ich garnich geachtet, dämlich von
mir ^^
Danke dir, mal schauen ob ich demnächst mal zeit finde dafür nen Code zu
schreiben.
Danke dir
Masl schrieb:
> Oh stimmt, auf die gesamt länge hab ich garnich geachtet, dämlich von> mir ^^>> Danke dir, mal schauen ob ich demnächst mal zeit finde dafür nen Code zu> schreiben.>
Ich habe den Code von Peter umgeschrieben (d.h. das Prinzip
beibehalten), so daß der NEC code dekodiert wird. Allerdings nicht der
extended (mit 16 bit Adresse), sondern nur der Standard mit 8 bit
Adresse (d.h. das 2. Adressbyte ist das negierte 1. Adressbyte); das
kann man aber leicht ändern.
Ich kann ja den Code heute abend mal posten, wenn Interesse besteht....
Gruß,
Boregard
Hi Bernhard,
ja, das wäre super.
Ich hab zwar gestern auch schon bisschen rumgetüftelt und einen halbwegs
funktionierenden code gebaut aber deiner ist bestimmt eleganter
Gruß
Halli hallo,
hier mal der Code den ich gebastelt hab.
Ich komme aber partout nicht drauf, warum mit das ding auf dem LCD (is
ein 40x4 Zeichen LCD) nur 16 bit anzeigt.
Auf dem oszi sehe ich schön wie bei jeder 1, also bei nem langen low
puls PD6 toggelt, aber irgendwie scheint da noch der wurm bzw käfer drin
zu sein ;)
Vielleicht sieht von euch einer spontan, woran es liegt.
Gruß
Ok, hab jetzt einen Code der funktioniert.
Vielleicht kann mir trotzdem einer erklären warum der im vorigen Post
nicht funktioniert hat, hab den Fehler nämlich nicht gefunden, sondern
schreibe jetzt die 16 Bit Adresse und die jeweils 8 Bit Commands in
einzelne Register.
Der Code ist noch nicht wirklich fertig, will alles noch mit
Präprozessor-Intelligenz versehen um den code leicht auf die aktuelle
Umgebung anpassbar zu machen.
Wer verbesserungsvorschläge hat - immer her damit ;)
Gruß Marcel
So,
nach Problemen mit Rechner und USB-Stick...
Jetzt der versprochene NEC Decoder von mir.
Aufgerufen wir sie im 125usec interrupt, dies findet sich im
IRQS_PER_SECOND wieder.
Der empfangene 32 bit code besteht:
nec_data & 0xff000000 : invertiertes Datenbyte
nec_data & 0x00ff0000 : Datenbyte
nec_data & 0x0000ff00 : invertiertes (oder erweitertes) Adressbyte
nec_data & 0x000000ff : Adressbyte
Man kann noch eine erweiterte Konsistenzprüfung machen, über Datenbyte
oder auch über Adressbyte (wenn man keine erweiterten Adressen zulässt).
(Der repeat ist auskommentiert, man sollte da nicht tmp nehmen, sondern
einen gespeicherten gültigen Wert...).
Gruß,
Boregard
Bevor die ersten Beschwerden kommen, daß etwas fehlt...
Hier mein Testprogramm für Mega 8 mit 2*16 Display, auf dieses Display
wird der empfangene Code ausgegeben, und zwar in die obere Zeile NEC, in
die untere RC5 (mit Peter Code decodiert).
Gruß,
Boregard
Hallo Bernhard!
Vorweg: vielen Dank für deine "Erweiterung" um den NEC-Code.
Allerdings krieg ichs nicht hin, das Teil mit einer bestimmten
Fernbedienung zum Laufen zu bringen :-(
Mit meiner Yamaha-FB klappt alles bestens. Mit der hier allerdings
nicht: http://www.ltt-versand.de/product_info.php/info/p36217.html
Ich dann mit dem LA von einem Kumpel mal die Zeiten gemessen:
1
A B C D E
2
¯¯\_______/¯¯¯¯\_/¯\_/¯¯\
3
| start | 0 | 1 |
4
5
smarites: (µs)
6
A: 9075 .. 9130
7
B: 4420 .. 4490
8
C: 485 .. 550
9
D: 480 .. 550
10
E: 1615 .. 1645
11
12
yamaha: (µs)
13
A: 9040
14
B: 4370
15
C: 655
16
D: 460
17
E: 1580
Ich verstehe allerdings anhand dieser Zeiten nicht mal, warum die
yamaha-FB funktioniert. Die haben irgendwie nichts mit den Zeiten in den
defines zu tun.
An deinem Code hab ich nur die Ausgabe angepasst und als printf über die
UART geschrieben. Hier kommt bei der "smaries"-FB meisten nur Fehler
oder sinnlose Sequenzen an.
Hilfe :-)
Grüße,
Max
Max schrieb:> Mit meiner Yamaha-FB klappt alles bestens. Mit der hier allerdings> nicht: http://www.ltt-versand.de/product_info.php/info/p36217.html
Das Ding macht auch das NEC-Protokoll.
> smarites: (µs)> A: 9075 .. 9130> B: 4420 .. 4490> C: 485 .. 550> D: 480 .. 550> E: 1615 .. 1645>> yamaha: (µs)> A: 9040> B: 4370> C: 655> D: 460> E: 1580> [/pre]
Das korrekte Timing beim NEC-Protokoll ist:
A = 9000µs
B = 4500µs
C = 560µs
D = 560µs
E = 1690µs
Da ist die Smarties-Fernbedienung sogar näher dran als die Yamaha.
IR-Fernbedienungen haben vom Timing her oft bis zu 40% Abweichungen vom
Idealwert, siehe auch
http://www.mikrocontroller.net/articles/IRMP
Dort findest Du auch einen IR-Decoder, der beide Fernbedienungen (Yamaha
als auch die Smarties-FB) durch Berücksichtigung gewisser Toleranzen
(40% beim NEC-Protokoll) ohne Probleme "versteht".
Gruß,
Frank
Frank M. schrieb:
Hallo Frank,
danke für deine Antwort!
Um Missverständnissen vorzubeugen: ich weiß, dass das NEC-Code ist und
dass es im Thread eigentlich um RC5 geht, aber ich hab mich an der
NEV-Variante von Bernhard Michler versucht.
> Dort findest Du auch einen IR-Decoder, der beide Fernbedienungen (Yamaha> als auch die Smarties-FB) durch Berücksichtigung gewisser Toleranzen> (40% beim NEC-Protokoll) ohne Probleme "versteht".
Ich hab mir deinen IRMP auch schon angesehen, bin aber nicht richtig
warm damit geworden, weil dieses riesige Stück Software für mich
Overkill ist.
Ich will auch nicht verschiedene Codes oder Timing-Varianten eines Codes
erkennen, sondern nur diese eine bunte FB :-)
Darum hab ichs zuerst mit diesem Dekoder versucht und ihn ja eigentlich
auch zum Funktionieren gebracht. Nur nicht mit der richtigen FB :-(
Wenn ich hier wirklich nicht zum Ziel komme, kommt der IRMP zum Einsatz.
Gut zu wissen, dass die Smarties-FB damit funktioniert!
Nochmal danke,
Grüße,
Max
