Hallo zusammen,

auch wenn der Thread schon etwas älter ist, hat er mir gerade dieser Tage sehr geholfen und mich motiviert meinen RLX-1201 zu reparieren.
Gerne teile ich meine Erfolgserlebnisse hier in diesem Forum.

Bei mir brannte die Leuchte ständig. Ging also nicht mehr aus. 

» Wie schon mehrfach in diesem Threat erwähnt, Immer schön vorsichtig beim Messen. «

An der Spule des Relais liegt quasi keine Spannung an. Daher vermutete ich ein Verkleben der Kontakte. Die Ohmsche Messung an spannungsloser Schaltung hat meinen Anfangsverdacht erhärtet.
Also ein neues Relais bei ebay bestellt (Omron Signal Relais G6E-134P-US 24 VDC, SPDT, 2 A) und siehe da die Leuchte arbeitet wieder wie gewünscht.

Viele Grüße Jürgen

anstatt PIC-Ausgang ist D-Latch Ausgang (SN74LS373) angeschlossen. OE (Output-Enable) ist aber immer gesetzt.

ich habe das gleiche Problem, ich habe vom PIC-Ausgang einen 2,2KOhm Widerstand zur Basis. Emitter ist mit Masse verbunden.  (NPN Transistor BC237 o.Ä.) Am Kollektor habe ich die Beleuchtung LED einer Anzeige angeschlossen, diese hat einen internen Vorwiderstand. Wenn ich die Beleuchtung ausschalte, dann leuchtet ganz schwach die LED-Bel. Ich hatte auch schon mit einem Widerstand die Basis gegen Masse verbunden. Leider ohne Erfolg. Ich meine ich hatte damals eine Spannung an der LED von ca. 0,8V gemessen.em14028_1.pdf

In meinem Auto sitzt eine von mir erstellte Doppelschaltung. Ein PIC ist für die Anzeige der Öltemperatur zuständig, ein zweiter für die Anzeige des Beginns der Regeneration des Diesel-Partikelfilters. Dieser Beginn wird durch einen schrecklich lauten Pfeiton nicht überhörbar zur Kenntnis gebracht. So weit, so gut. Aber leider gibt das Gerät auch "unter der Hand" Geräusche von sich. Das ist ein eher schwacher, aber immerhin im Hintergrund vernehmbarer hoher Ton. Der kommt recht unregemäßig zustande, wird auch gerne mal unterbrochen, lange ist's stumm, dann singt es für viele Minuten und nervt einfach.
"Eigentlich" dürfte nur der niedliche Piezo-Töner die Geräuschquelle sein. Mir ist nur im Ansatz nicht klar, wie das möglich ist.

Im Programm wird laufend - so ca. alle 2 sec - der Wert der Temperatur des Sensors abgelesen und angezeigt. Die beträgt normalerweise irgendwas zwischen 150° C und 350° C. Wenn die Temp erstmals über 400° C steigt, beginnt die Regeneration und der Piff ertönt. Das Prog arbeitet so, dass es nach jeder Messung erneut quasi bei Null beginnt und fix von unten nach oben hochzählt, bis die Temp passt. Das Piepsen ist nur ein einziges Mal dabei vorgesehen, eine extra Variable merkt sich, ob es das erste Mal eine Überschreitung gab oder ob schon häufiger.
Die schlichte Hardware ergibt für mich keinen Grund, warum es piepsen sollte. Wenn der PIC nicht gerade in seiner Pfeif-Routine ist, dann liegt der Port-Ausgang auf "0".
Was könnte der Grund für dieses leise, unterbrochene, aber nervige hohe Singen sein?
Grüße, picass

Zitat von: pic18 in 23.07.2026, 23:06:25 CESTWillst Du den Taupunkt in Assembler berechnen? Das stelle ich mir schwierig vor.

Stimmt Beides! Leider! Da sitzen die KI und ich nun im zweiten Anlauf dran. Der erste Anlauf war vor ca. 3 Wochen und der war in der Theorie und den ersten Rechen-Strampel-Übungen auch gelungen. Leider hatten wir das nicht konsequent zu einem überprüfbaren Extra-Programm-Teil ausentwickelt. So entstand kein ausführbares .asm-File. Nach dem theoretischen Erfolg hatten wir uns den anderen Programmblöcken zugewandt. Das war nicht grundsätzlich schlecht, nur war meine Erfahrung im Umgang mit der KI zu der Zeit noch nicht vorhanden. Da musste ich erst lernen, dass die erstens fast nichts speichert, wenn man eine Sitzung beendet und zum Zweiten auch alles, vor allem und besonders gerne das ganz Wichtige komplett vergisst.
Nachdem wir nun die anderen, wichtigen Blöcke geschafft haben, ging es zurück an die Wurzeln der Berechnung der Magnus-Formel. Um allerdings 32-Bit-Rechen-Routinen möglichst aus dem Weg zu gehen, schlug die KI vor, rum zu tricksen. Gaaaaanz viel mit Tabellen. Das wird auch klappen, nur ist mir jetzt die Zeit davon gerannt. Musste diese Arbeit leider vorläufig abbrechen, weil der Sommerurlaub mit Langfahrt im Auto nach Italien ansteht. Dessen Vorbereitung belegen z.Z. alles mit Beschlag, weswegen es frühestens in 3 Wochen weiter gehen wird. Schade, ich hätte das fertige Prog gerne im Schlepptopp mit genommen, um die Teile zu durch-ackern, die sich bei erstem Lesen noch als geheimnisvoll darstellen.
Grüße, picass

Anstatt die Magnusformel zu verwenden, würde ich den einfacheren Weg wählen, nämlich über das Auslesen einer Dampfdrucktabelle, über den in Betracht komenden Temperaturbereich hinweg z.B.

https://www.internetchemie.info/chemie-lexikon/daten/w/wasser-dampfdruck.php

Ich stimme pic18 zu, dass es ein erheblicher Aufwand sein könnte, die Formel in Assembler nachzubilden.

Willst Du den Taupunkt in Assembler berechnen? Das stelle ich mir schwierig vor. Vielleicht kann es ja die KI

Es gibt einen ersten, zumindest für mich ganz großen Erfolg zu verkünden:
die vierstellige LCD-Anzeige übermittelt die Innen- wie Außen-Temperatur und entsprechnd die Werte für Luffeuchtigkeit.
Vor 30 min war es so weit und dieser Erfolg ist hart, sehr hart erkämpft. Und das ist noch zurückhaltend formuliert. Was nun noch fehlt ist das Implementieren der Berechnung der Magnus-Formel. Das entsprechende File war schon entwickelt worden, ist allerdings noch nicht im ruppigen Alltag getestet. Aber es gibt berechtigte Gründe zur Annahme, dass dies auch noch gelingen wird.
Meine Frau..... ach..... die hat so gar nichts mit Technik am Hut. Es sei denn, sie nützt ihr konkret was. Aber ansonsten will sie damit nichts zu tun haben. Versuche ich, eine Erfolgsmeldung bei ihr anzubringen, kann sie grundsätzlich nichts hören. Deshalb müsst ihr hier dafür herhalten, dass ich meine Riesen-Freude über das bisherige Gelingen irgendwo auch mal loswerden kann.
Danke fürs Zuhören, picass

Mit deinem zweiten Beitrag hast du es deutlich dargestellt, pic18. Da ist aus irgendeinem Versehen heraus eine Variable falsch benannt worden. Der hauptsächliche Grund dürfte auf das häufige Umstruktrurieren des Programmes und damit einher gehend das Kopieren von Programm-Teilen in andere Bereiche sein - verbunden mit einer Konzentrationslücke.
Ich hatte das mal als durchaus typisches Beispiel eingestellt, um aufzuzeigen, aus welchen Gründen Assembler-Programmierung so langwierig werden kann. Da kämpft man seit vielen Tagen nicht nur mit Bytes, sondern ganz oft um jedes einzelne Bit. Wenn das nur lange genug anhält und sich mal wieder eine "ganze Winzigkeit" - wie man hinterher feststellt - quer gestellt und man sich schon wieder einen Wolf gesucht hatte, dann wird man irgendwann matschig und dann kulminiert das auch noch. Ist aber nur einer von vielen Gründen, warum der Kampf mit und gegen der/die KI so lange anhält. Nach groben Schätzungen könnte gegen Ende dieser Woche aber der Zieleinlauf gelingen.
Grüße, picass

sollte die 3. Zeile

movff DHT_TEMP_INT,DHT1_RH_INT

nicht so heißen?

movff DHT_TEMP_INT,DHT1_TEMP_INT