Hallo allerseits, Habe einen Verstärker(NAD) der das Signal der Fernbedienung nur sehr selten akzeptiert. Ausgewertet wird das RC-5 Signal von einem Microchip(????FJ128GB106) am Pin46. Der Anhang zeigt das Signal das direkt am Pin anliegt. Meine erste Farge ist, ob das Signal wegen der auftretenden Spitzen nicht ausgewertet werden kann, oder ob ich ein anders Problem habe? Bis jetzt habe ich ohne Erfolg folgendes getestet: -eine andere Fernbedienung die bei anderen Geräten funktioniert -einen neuen IR-Empfänger (baugleich)
Moin, Christoph H. schrieb: > Meine erste Farge ist, ob das Signal wegen der auftretenden Spitzen > nicht ausgewertet werden kann, oder ob ich ein anders Problem habe? Das mit den Spitzen wuerd' ich nicht so eng sehen. Es koennte evtl. daran liegen, dass der Quarz oder keramische Resonator, der den Takt fuer die das Signal auswertende CPU erzeugt, ein bisschen daneben liegt. Hast du einen Frequenzzaehler, um da mal zu gucken? Gruss WK
Christoph H. schrieb: > Meine erste Farge ist, ob das Signal wegen der auftretenden Spitzen Die können auch ein Artefakt Deines Messaufbaus sein - verwendest Du einen Tastkopf, wenn ja, 1:10 oder 1:1, wo ist das Signal und wo die Signalmasse an den Tastkopf angeschlossen, und ist der Tastkopf abgeglichen?
Christoph H. schrieb: > Bis jetzt habe ich ohne Erfolg folgendes getestet: > -eine andere Fernbedienung die bei anderen Geräten funktioniert Hat es bei der anderen Fernbedienung auch nur teilweise mit diesem Verstärker funktioniert oder gar nicht?
So einen Signaldreck habe ich aus einem IR-Receiver jedenfalls noch nicht gesehen. Der sollte u.a. eine gut gesiebte VB haben.
> Hat es bei der anderen Fernbedienung auch nur teilweise mit diesem > Verstärker funktioniert oder gar nicht? Auch nur teilweise, so wie bei der originalen. > Die können auch ein Artefakt Deines Messaufbaus sein - verwendest Du > einen Tastkopf, wenn ja, 1:10 oder 1:1, wo ist das Signal und wo die > Signalmasse an den Tastkopf angeschlossen, und ist der Tastkopf > abgeglichen? Messaufbau mit Tastkopf 1:10 Hab keine besonderen Maßnahmen getroffen um Störungen zu vermeiden. Hab das Signal aber mit einem anderen verglichen (CD-Player). Hatte bei gleichen Einstellungen am Oszi und ähnlich liegenden Abgriffen deutlich weniger Spitzen.
> So einen Signaldreck habe ich aus einem IR-Receiver jedenfalls noch > nicht gesehen. Der sollte u.a. eine gut gesiebte VB haben. VB ist in OK > Hast du einen Frequenzzaehler, um da mal zu gucken? Bin noch am suchen...(nach dem richtigen Pin nicht nach dem dem Frequenzzähler)
zu Testzwecken kriegst du die Spitzen vmtl. mit einem kleinen C weg.
Christoph H. schrieb: > Ausgewertet wird das RC-5 Signal von einem Microchip(????FJ128GB106) am > Pin46 Wie kommst Du auf die Idee, dass dies RC5 sein soll? RC5 verwendet Manchester-Codierung, ist also ein Biphase-Code. Auszug von https://www.mikrocontroller.net/articles/IRMP#Biphase "Damit erkennt man ein Biphase-Coding an folgendem Kriterium: es kommen genau eine Pausen- und eine Pulslänge, sowie jeweils die doppelten Puls-/Pausenlängen vor." Das passt überhaupt nicht zu Deinem Bild. Hier sind die Pulslängen (bis auf das Start-Bit) immer gleich lang, lediglich die Pausen sind verschieden. Es handelt sich hier also um ein Pulse-Distance-Protokoll. Eine solche Kodierung ist sehr weit verbreitet und wird in zig IR-Protokollen eingesetzt, die aber alle zueinander verschieden und damit inkompatibel sind. Nach dem Timing des Start-Bits (9ms Puls, 4,5ms Pause) zu urteilen, könnte es sich um das weitverbeitete NEC- oder auch Extended-NEC-Protokoll handeln: https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC Leider sieht man den Frame nicht vollständig, man sieht nur die ersten 27 von (vermutlich) insgesamt 32 Bits. Beim NEC-Protokoll gibt es 256 mögiche verschiedene Geräteadressen und bis zu 256 mögliche Codes. Damit wird es richtig schwierig, irgendeine andere FB an diesem Gerät zum Laufen zu bewegen - selbst wenn diese auch NEC spricht. Beim moderneren abwärtskompatiblen Extended-NEC-Protokoll sind es sogar 65536 verschiedene Adressen. Die Wahrscheinlichkeit, mit irgendeiner anderen - willkürlich gewählten - Fernbedienung ausgerechnet Dein Gerät (vollständig) bedienen zu können, ist hier also sehr sehr klein.
Dergute W. schrieb: > Es koennte evtl. daran liegen, dass der Quarz oder keramische Resonator, > der den Takt fuer die das Signal auswertende CPU erzeugt, ein bisschen > daneben liegt. Es könnte auch daran liegen, dass der IR-Sender etwas aus dem Takt ist, da der TO bereits einen anderen baugleichen Empfänger getestet hat. Das spricht eher dafür, dass die Ursache beim Sender zu suchen ist. @Christoph: Kann es sein, dass die Fernbedienung mal hingefallen ist? Eventuell hat der Quarz dabei Schaden genommen. Den könnte man ersetzen.
Sieht ziemlich genau (Frank M. schrieb es schon), wie das NEC-Protokol aus: Die hat einen Grundtakt von ca. 38 kHz, der für die Tastung der IR-LED und für das Puls-Timing genutzt wird. Die Einleitung sind ~ 9,0 ms ON (LOW am Empfänger) gefolgt von ~ 4,5 ms OFF (HIGH am Empfänger) Jedes Bit startet mit ~ 0,55 ms ON (LOW am Empfänger) Sie unterscheiden sich durch die Dauer der nachfolgenden Pause (OFF): Entweder ~= 0,55 ms, oder ~ 1,7 ms. Kein Bi-Phase RC-5. Das sieht alles wunderbar aus! Runterfallen und verstimmter Taktgeber ist auch unwahrscheinlich: IR-Tastfrequenz und Pulszeiten stehen fast immer in einem festen Verhältnis, also würden die Zeiten nicht stimmen. Und dass davon NUR der RC-Code kaputt geht, ist schwer vorstellbar... Fazit: Falsche Fernbedienung, oder falsches Gerät.
> Leider sieht man den Frame nicht vollständig, man sieht nur die ersten > 27 von (vermutlich) insgesamt 32 Bits. Habe mal versucht alle Bits auf ein Foto zu bannen. Ist jetzt die originale FB, die beim Gerät dabei war. Die andern FB (habe jetzt noch eine dritte getestet) sind alle vom selben Hersteller wie das Gerät (MultifunktionsFB) und dafür ausgelegt (lt. Hersteller) alle Geräte der Firma zu steueren. Die original FB vom Gerät und die Multifunktions FB haben auch das selbe Bitmuster / Zeitmuster.
> Es koennte evtl. daran liegen, dass der Quarz oder keramische Resonator, > der den Takt fuer die das Signal auswertende CPU erzeugt, ein bisschen > daneben liegt. Kann es sein dass der Takt intern generiert wird? Und wäre es dann trotzdem möglich das der Takt daneben liegt, bzw. wie könnte ich das überprüfen...
Warm und kalt machen. Hab schon Pferde kotzen sehen - aber noch keine Quarzuhr, die plötzlich "ein bischen daneben" lief. :)
> zu Testzwecken kriegst du die Spitzen vmtl. mit einem kleinen C weg
Spitzen sind weg, funktioniert aber auch nicht... noch eine Idee?
Je nachdem, wo diese Störungen eingespiesen werden. Im IR-Receiver oder im Controller? Ein Symptom ist beseitigt aber vielleicht nicht die Ursache. Hat das Ganze denn jemals richtig funktioniert?
Moin, Christoph H. schrieb: > Kann es sein dass der Takt intern generiert wird? Prinzipiell waer's vielleicht nicht ausgeschlossen, aber eben aus Genauigkeitsgruenden wuerd' ich sowas als Verstaerker-µC-HW-Designer nicht machen. > Und wäre es dann > trotzdem möglich das der Takt daneben liegt, bzw. wie könnte ich das > überprüfen... Man kann natuerlich auch in der Fernbedienung eingreifen, und da mal testweise einen etwas erhoehten oder erniedrigten Takt am Resonator einspeisen. Aber das ist schon aufwendig. Mach doch mal ein Foddo von dem Kaefer und seiner Umgebung, wo das Signal aus dem IR-Empfaenger hingeht. batman schrieb: > Hab schon Pferde kotzen sehen - aber noch keine > Quarzuhr, die plötzlich "ein bischen daneben" lief. :) Ja, fuer besonders naheliegend und wahrscheinlich halt' ich meine Vermutung auch nicht, aber das Signal anundpfirsich sieht ja gut aus - also die ueblichen Verdaechtigen (Bier/Chips in der Fernbedienung, Aufgeloeste Tastaturgummis, Energiesparlampen, etc.) scheinen's ja nicht zu sein... Gruss WK
Ich habe das Teil gebraucht gekauft. Den Fehler hat es, seit dem ich es habe.
Signalverlauf von IR-Empfänger zum Microchip: IR-Empfänger - 100R - Flachbandkabel - Ferrit Chip - Schmitt/Trigger(NC7WZ17) - 100R - Microchip Pin46 Der ST Eingang hängt eingangsseitig über 100k auf VCC und über eine Schutzdiode auf Masse
Oha, was wurde da schon alles gebastetlt. Da wird wohl das ganze Programm fällig werden, angefangen mit der Versorgung von allet.
Kann ja auch sein, dass der einfach sporadisch abschmiert, wenn er ein Kommando verarbeiten soll.
Nochmal: Das empfangene Fernsteuersignal sieht sehr gut aus. Die paar Spitzen sind sowieso mehr vom Messen, als dass sie stören würden. Es ist einwandfrei übertragener NEC-Code mit richtigem Timing. Da er empfangen wurde, stimmt auch die Pulsfrequenz der IR-Diode. Der NEC-Code besteht aus 4 Byte in 2 Varianten: 1) 8-Bit-Adresse: Adresse - 1er-Komplement der Adresse - Befehl - 1er-Komplement des Befehls 2) 16-Bit-Adresse: Adress-Byte-A - Adress-Byte-B - Befehl - 1er-Komplement des Befehls Nach den 9 ms Low und 4,5 ms High kommen immer kurze Low-Pulse, gefolgt von unterschiedlich langen Pausen. Für lange Pausen nehmen wir L und für kurze Pausen K. So sehen wir Adresse: LLLKKKKL-KKLLLLLK Gruppieren wir die ersten 16 Bit (Adresse), sieht man, dass das zweite Byte nicht das 1er-Komplement (bitweise Invertierung) des ersten Bytes ist. Also 16-Bit-Adresse. Ob die stimmt, wissen wir nicht... Befehl auf dem ersten Bild: LKLKKLKK-KL????? Gruppieren wir die 16 Befehls-Bits, können wir sie gleich mit dem 1er-Komplement ergänzen: LKLKKLKK-KLKLLKLL Das zweite Bild bestätigt dies. Halten wir fest: Die Fernbedienung ist grundsätzlich OK, spricht aber das Gerät nicht an. - Entweder spricht die Fernbedienung die falsche Sprache (RC-Code, Geräteadresse, ...) - oder das empfangende Gerät ist defekt, bzw. vermurkst, also "taub". Der Anblick spricht dafür.
Dagegen spricht, dass es manchmal funktioniert.
> Dagegen spricht...
Wogegen, gegen vermurkst?
Vorschlag:
Oszillogramme von 2..3 (zufällig) funktionierenden Befehlen.
Moin, Hm, ja so ganz taufrisch schauts auf der Platine tatsaechlich nicht mehr aus; aber funktionieren sollt's trotzdem noch. Irgendwas taktgeneratormaessiges hat mich da jetzt auch nicht angesprungen, aber das sollte schon zu finden sein. Der µC scheint mir nicht zu exotisch zu sein, da wird man schon rauskriegen koennen, was das fuer einer ist und wo der seinen Takt herbekommt. Auch wenn da irgendwer draufrumgeschliffen/geschmiert hat. Gruss WK
> Hm, ja so ganz taufrisch schauts auf der Platine tatsaechlich nicht mehr > aus; aber funktionieren sollt's trotzdem noch. Das Gerät hatte - wie ich es bekommen habe - außerdem das Problem dass weder die Lautstärkenregelung noch die Quellenauswahl funktioniert hat (Beides über Encoder). Musste deswegen schon 2 Widerstandsarrays und ein Ferritarray tauschen. Def. war nur das Ferritarray - war jedoch das letzte was ich getauscht habe... Durch das Herumlöten hat sich aber die Funktion der FB weder verbessert noch verschlechtert. > Der µC scheint mir nicht zu exotisch zu sein, da wird man schon > rauskriegen koennen, was das fuer einer ist und wo der seinen Takt > herbekommt. Auch wenn da irgendwer draufrumgeschliffen/geschmiert hat. Hab mir mal die Datenblätter durchgesehen... und soweit ich das Verstanden habe (habe bis jetzt noch kaum Erfahrung mit µC) kommt es auf die Programmierung an, wie welcher Pin verwendet wird und eben auch ob der Takt intern generiert wird oder von extern eingespeist wird. > Vorschlag: > Oszillogramme von 2..3 (zufällig) funktionierenden Befehlen. Mal sehen ob ich das hin bekomme... Fotos folgen sobald ich Erfolg hatte.
Habe da noch eine Frage Drück ich die Taste der FB nur einmal kurz bekomme ich das Signal wie in diesem Bild
Bleibe ich jedoch auf der Taste länger oben, sieht das dann so aus.
Im zweiten Bild ist, soweit ich das verstanden habe, keine Info über Geräteadresse oder Befehl, sonder nur das der Befehl wiederholt werden soll. Wenn ich die Taste jetzt schon sagen wir mal 15 sec. halte und dann erst beginnt sich die Lautstärke zu ändern, muss das Gerät ja den Befehl bekommen haben. Nur aus irgend einen Grund führt sie ihn erst aus wenn es dafür lustig ist - oder auch gar nicht. Oder liege ich da falsch?
Moin, Christoph H. schrieb: > Hab mir mal die Datenblätter durchgesehen... Weisst du was das fuer ein µC ist? Wenn ja, koennt' eine Erwaehnung hier nicht schaden :-) > und soweit ich das > Verstanden habe (habe bis jetzt noch kaum Erfahrung mit µC) kommt es auf > die Programmierung an, wie welcher Pin verwendet wird und eben auch ob > der Takt intern generiert wird oder von extern eingespeist wird. Ja. Prinzipiell kann es natuerlich auch sein, dass der Prozessor mit einem intern generierten Takt laeuft. Dann kannst du da nix machen. Aber der interne Taktgenerator ist eigentlich immer ungenau, also so ungenau, dass sogar die Baudrate von seriellen Schnittstellen eine Herausforderung ist. Deshalb wuerde ich mir als Entwickler einer µControllerschaltung im Rahmen eines groesseren Geraets mit ein paar Watt Leistungsaufnahme nicht antun, mit dem internen Oszillator zu arbeiten. Und wenn man mit externem Takt arbeitet, gibts ueblicherweise nicht soviele verschiedene Pins, wo der Takt in den Prozessor kommt oder ein Quarz/Resonator angeschlossen wird. Bei einem Quarz/Resonator kann man ueblicherweise die Frequenz noch ein bisschen durch die beiden Cs gleich neben dran ziehen - oder eben mal testweise dort einen selbst generierten Takt einspeisen und so den Oszillator auf eine andere Frequenz zwingen. Gruss WK
Hier noch ein Foto von dem guten Stück. Sorry, dachte die Info hätte ich längst gegeben...
Der Verstärker ist übrigens ein NAD D7050. Man findet so ziemlich alles im Netz darüber... bin mir noch nicht sicher, was ich linken oder als Foto einstellen darf...
Moin, Christoph H. schrieb: > Der Verstärker ist übrigens ein NAD D7050. Man findet so ziemlich alles > im Netz darüber... Ja. Wenn man's weiss, dann schon. > bin mir noch nicht sicher, was ich linken oder als > Foto einstellen darf... Kann mir nicht vorstellen, dass alleine die Erwaehnung des genauen Typs schon irgendwelche Urheberrechte verletzt. Tja, dann kann ich mir die Raterei auch sparen. Sieht tatsaechlich so aus, als wuerde der µC vom internen Oszillator getaktet. Da wirds natuerlich nix mit mal schnell die Taktfrequenz aendern. Also entweder irgendwas anderes annehmen, als den Taktversatz, an dem's liegen koennte, dass die Fernbedienung nicht tut - oder testhalber an der Fernbedienung anderen Takt einspeisen oder statt Fernbedienung mit LIRC oder sowas arbeiten und dann am Timing der Impulse drehen... Gruss WK
Einen RC-Oszillator kann man ja schon mittels kleiner Temperatur- und Spannungsänderungen in der Frequenz beeinflussen. Das sollte reichen, um da einen ursächlichen Zusammenhang zu erkennen oder auszuschließen.
>Kann mir nicht vorstellen, dass alleine die Erwaehnung des >genauen Typs schon irgendwelche Urheberrechte verletzt. Dachte da jetzt eher an einen Link von einen Schaltplan oder Service Manual. >Einen RC-Oszillator kann man ja schon mittels kleiner >Temperatur- und Spannungsänderungen in der Frequenz >beeinflussen Das mit der Temp. Hab ich probiert. Hat leider nichts gebracht. Muss mal noch schauen wie ich die Spannungsänderungen hinbekomme. Was mir noch aufgefallen ist, wenn ich es mit der FB EIN- oder AUSschalten möchte wird die Led, die den Betriebszustand angibt, etwas Dunkler und es dauert dann ein paar Sekunden bis sie wieder die volle Helligkeit hat.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.