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?
> 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)
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...
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
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
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.
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.
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
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.
IMG_20181108_1017569.jpg
(250 KB)
