Ein Prob bei der "Weiternutzung" der Kaltluft ist mir noch eingefallen: während auf der Heißseite der Luftstrom möglichst groß sein sollte, um eine wirksamere Hitzeabfuhr zu erreichen, ist auf der anderen Seite - wie mein Test gestern s.o. ergeben hat - ein virulenter Luftstrom kontraproduktiv: der trocknet!
Also sollte auf der Kaltseite die Luft "freiwillig" ran- und nachströmen. Die runterfallende Luft ließe sich sicher unten in einem großen Behälter auffangen. Aber wenn dann aus dem nachhaltig abgesaugt wird, gerät doch wieder ein Teil des Luftstromes auf die Kalt-Kühler. Da müsste man erst mal ordentlich in Sachen Thermik investieren....!

Bei diesen Überlegungen fiel mir ein, dass es noch ein weiteres, wirksames Konzept gibt, die in der Luft enthaltene Feuchtigkeit raus zu fischen: Flechten !
Gesehen auf den Kanarischen Inseln, z.B. auf La Palma und Teneriffa, sicher auch auf Gran Canaria. Dort jeweils auf der Nordseite kommt von Norden her, was die überwiegende Windrichtung dort ist, der Passat an und schiebt die über dem Meer eingesammelte Feuchtigkeit die jeweiligen Hänge der Berge hoch. Die sind hoch - 2 km Höhe ist da fix erreicht. Is klar, die Luft kühlt ab und die Wolken treiben einen Haufen feinster Wassertröpfen mit sich. In diesem Luftstrom stehen Bäume und Büsche und viele davon tragen als Symbiose Flechten in ihrem Laub- rsp. Astwerk. Die Flechten mit ihren vielen, feinen Fäden bilden eine ideale Möglichkeit, Kondenswasser zu generieren. Das tropft dann runter und der jeweilige Wirt - also Baum - freut sich.
Nicht gefreut hatten meine Frau und ich uns während einer Wanderung auf Teneriffa. Da gerieten wir in ca. 1 km Höhe auf dem Wanderweg in ein solches Wolkenfeld. Eine halbe Stunde darin gelaufen und wir waren quatschnass und es hatte nicht geregnet!


 Entsprechend wäre ein Geflecht aus vielen dünnen Drähten - nach Möglichkeit noch gekühlt - 'ne feine Sache.
Die Natur macht es vor, ganz ohne elektrische Energie und - ach ja - auch ohne µC's.
Grüße, picass

Die o.g. zweite Auflage der "Kühlmaschine" ist heute in Betrieb gegangen, allerdings nur für wenige Minuten, weil ich aus dem alten Haus wieder weg musste und alleine wollte ich sie noch nicht laufen lassen. Die zweite Version hat wie beschrieben auf jeder Seite große Kühlkörper, zwischen beiden Seiten zur Trennung der Luftströme und zur Isolierung zwei große Platinen bekommen - Bild später - und der Kühler auf der Hitzeseite wird von einem 12 cm-PC-Gehäuselüfter bepustet. Soweit so gut, vorne wirds auch schön kalt, aber wenige Minuten reichen nicht, ein sichtbares Ergebnis zu produzieren. Vielleicht ab morgen weiter.

Weiter geht es aber jetzt schon mit der installierten Entfeuchtungs-Anlage, die zugekauft wurde, die mit dem Arduino drinnen. Die beiden Fühler - also innen und außen - sind ganz sicher gut und fachgemäß installiert, aber was sich die Anlage da zusammen rechnet nach dieser Taupunktformel, passt nicht auf die berühmte Kuhhaut. Erst zeigt mein Betriebsstundenzähler eine verschwindend geringe Stundenanzahl des Betriebes auf, dann ist die Feuchte im Keller von durchschnittlich gut 92% mit der Pust-Hilfe auf irgendwas zwischen 86 und 90 % "gesunken". Und dann lief sie heute Vormittag nicht bei besten Bedingungen, also draußen Sonnenschein, es war weitestgehend trocken draußen, die Außentemp nur 3 bis 4° C über der im Keller, aber da rührte sich kein Lüfter und kein Lüftchen.
Jetzt gerade um 19 Uhr lief dat Ding, fast alle Werte gleich, aber draußen regnete es!!!
Was genau rechnet dieser Ardu-Zwerg sich da zusammen?! Trockenheit und Sonne draußen straft er mit Missachtung, aber Kühle und Regen draußen, das findet er, müsse gefördert werden und fördert so ganz sicher Feuchtes von draußen nach drinnen.
Ich habe den Verkäufer heute angemailt und ihn gebeten, die Einstellungsmöglichkeit für die Feuchtedifferenz um zwei Grad zu ändern, damit die Anlage mehr, rsp. überhaupt läuft. Für die Änderung habe ich auch Entlohnung angeboten, mal sehen, ob und wie er reagiert. So wie die Anlage jetzt mit ihren Parametern ist, ist sie unbrauchbar.

Es wird sich nicht vermeiden lassen, dass wir bei diesem Thema selbst Hand anlegen. Das kann nur besser werden und für mich wäre es selbstverständlich, außer so komischen Sensoren auch einen schlichten Regenfühler zu installieren, der dann ein No-Go sendet.
Grüße, picass

Es ist ein wenig undankbar, über die Funktion der o.g. beschriebenen, fertig gekauften Anlage so was wie ein entgültiges Urteil zu sprechen. Klar ist allerdings eines: im serienmäßigen Zustand und der damit verbunden, teils eingeschränkten Einstellbarkeit der Parameter ist die Anlage nur teilweise nützlich, ganz häufig leider gar nicht. Es gibt viel zu viele Fälle, in denen sie nicht oder falsch oder gar nicht nachvollziebar arbeitet. So ist sie bei bestens trockener und warmer, teils heißer Luft im Dauerstreik: tagelang rührt sich nichts und lässt diese Chance komplett verstreichen. Sobald es kalt draußen wird und damit meine ich Temps unterhalb von 18° C, erweckt sie zum Leben und besonders häufig, rsp. dauernd arbeitet sie, wenn es echt kalt draußen ist. Dann kühlt sie den bis dahin warmen Keller deutlich runter auf kalt. Am störensten ist sie aber, wenn sie Luft von draußen nach innen befördert, wenn es draußen regnet. Nach meinem Geschmack ist es dann draußen nicht nur feucht, sondern nass, was sich gänzlich ohne hoch präzise Sensoren verifizieren lässt, wenn man - ausgestattet mit der von der Natur auf dem Kopf plazierten Glatze - ein paar Schritte nach draußen tritt. Ebenso wenig sinnvoll finde ich, wenn das LCD-Display vermeldet, dass draußen eine Luftfeutigkeit von 88 % herrrscht, im Keller nur 80%, und dann die deutlich feuchtere Luft von draußen nach drinnen gepumpt wird. Die Formel ist aus meiner Sicht schon recht krude, wenn sie so was für gut hält.
Das Gerät und seinen Preis würde ich für gut halten, wenn es mehr oder überhaupt Möglichkeiten bieten könnte, an den Parameter-Schrauben zu drehen. Und wenn es in der Lage wäre, draußen Regen zu erkennen.

Wiederhole: es wird sich nicht vermeiden lassen, da tatsächlich selbst Hand anzulegen.

Dabei - und u.a. deswegen schreibe ich diesen Beitrag - brauche ich aber eure Hilfe. Das eigentliche Steuerprog würde ich wohl selbst schaffen. Wo es bei meinen µC-"Künsten" hakt, ist sowohl das Nutzen eines LCD-Displays unter Assembler als auch das Auslesen von Sensoren, welche digitale Formate für die Datenübertragung nutzen.

Eigentlich möchte ich nicht wirklich unbedingt eine neue Programmiersprache - egal, wie sie heißt - lernen müssen, nur um diese beiden genannten Techniken verwenden zu können. In Hochsprachen gibt es doch - wenn ich das richtig verstehe - sogenannte Bibliotheken, welche zugeschnitten auf z.B. einen Sensor es ermöglichen, das Gewusel der Zeitprotokolle und der Impulszählung und all' solchem Schweinskram der Biblio zu überlassen und "nur" ein paar Bedien-Parameter anzupassen. So was müsste es doch unter Assembler auch geben. Oder wenn nicht: da müssten doch irdenwo im Inet fertige Programmteile existieren, in denen das beispielhaft vorgestrampelt ist. Bei Microchip gabs doch früher mal unendlich viele Programm-Sammlungen - deren Namen begann in der Regel mit AN... - für bestimmte Techniken.

Habe aber eben bei Reichel geschaut: es gibt auch für Feuchtemessungen Sensoren mit analogem Ausgang. Das wäre zwecks der von mir geschilderten noch nicht vorhandenen Fähigkeit, Digitales im Sensorenbereich zu nutzen, doch eine gute Empfehlung?! Oder übersehe ich da was?
Also verblieben als drängenste Prob-Felder das Ansteuern von LCD-Displays und diese vermaledeite Formel, welche mathematische Klimmzüge erfordert. Na, was meint ihr? Wäre jemand in Stimmung, da mit helfender Hand einzusteigen? Oder gibt es Hinweise auf nutzbare Beispiele?
Grüße, picass

Was ASM für das LC-Display betrifft:
https://www.sprut.de/electronic/pic/programm/lcd.htm

Ist für 16F84, sollte sich aber ohne große Probleme an andere PICs anpassen lassen.

Gruß
PICkel

Wie kann man nur NICHT an den guten, alten Sprut denken!    Tsssss!
Danke, PICkel. Dieses File habe ich runter geladen und werde versuchen, es in "meine" Assembler-Version - also die mit dem "X" und v.5.20 - zu übersetzen. Anzeigen habe ich noch irgendwo im Regal versteckt. Das wäre schon mal 'ne Menge weiter.
Um dem digitalen Wirrwar zu entgehen, hatte ich ja schon den analogen Datenübertragungsweg für Sensoren genannt. Der nächste Punkt wäre nun, eine Tabelle oder wieder 'ne Formel für solchen Sensor wie den HIH 5031-001 von Honeywell zu finden. Aber bitte: das soll keine Aufforderung darstellen, das Suchen für einen zu Faulen zu übernehmen. Ist nur mein Gedanke an die nächste Baustelle....
Nochmal danke...., einmal mehr kann nicht schaden!
Grüße, picass

Ich würde einen digitalen Sensor vorziehen. Sonst hast du evtl. wieder Umrechnungsprobleme.
Hier http://www.stefan-buchgeher.info/elektronik/feuchtemodul2/feuchtemodul2_kap04.html habe ich ein älteres Projekt mit RS232 Schnittstelle gefunden. Es ist zwar in C geschrieben, aber der ASM-Code ist unter download http://www.stefan-buchgeher.info/elektronik/feuchtemodul2/feuchtemodul2.zip auch da. Vielleicht kannst Du damit was anfangen.

Schreibs mal ganz kurz und ganz unauffällig hier rein: die nachfolgend kurze Notiz bedeutet für mich einen irren Durchbruch, enthält diese Notiz doch dasjenige Programm, welches die Berechnung der Taupunkt-Temperatur hier unter Python liefert.

import math
h = 6.1078   #konstante
s = 237.3   #konstante
t = 25      #gemessene temp
f = 60      #gemessene feuchte
t1 = h*10**((7.5*t)/(s+t))
t2 = f/100*t1
t3 = math.log10(t2/h)
t4 = (s*t3)/(7.5-t3)
print (t4)

Die Werte für Temperatur und Luftfeuchte stammen ,,normal" natürlich von entsprechenden Sensoren. Hier sind sie nur zur Veranschaulichung schlicht ,,händisch" eingefügt. Das Prog lässt sich noch bei Bedarf deutlich verkürzen. Wahrscheinlich könnte man mit einer Variablen und allen Berechnungen in einer einzigen Zeile auskommen.

Das ist nun in dürren Zeilen das, was mir in 3 Jahren unter Assembler nicht gegeben war. Heuer hats ein paar Minuten gebraucht. Kann ich aber nix für, das sind die Kombi aus dem µC ,,Raspberry Pi Pico" und Python.
Grüße, picass

Zitat von: picass in 18.11.2024, 15:38:58 CETdas sind die Kombi aus dem µC ,,Raspberry Pi Pico" und Python.

"C" für einen 14K22 hätte kaum anders ausgesehen

oder für einen 25K22
(Ich hoffe der C Compiler rechnet nicht schlechter als der Python)

welchen C-Compiler hast Du da genommen? Ich habe irgendwie in Erinnerung, das meiner (c18) mit "float" Probleme hatte.

XC8 v2.46

Danke, muss ich mal ausprobieren, ich arbeite noch mit dem c18, der ist offenbar noch ANSI 89 kompatibel.

Zitat von: vloki in 19.11.2024, 10:57:02 CET"C" für einen 14K22 hätte kaum anders ausgesehen

Was die "richtige" Programmiersprache anbelangt, bin ich ganz sicher nicht im Besitz der reinen Lehre, sondern schlichtweg ein Suchender.
Hatte mich jahrelang um eine Entscheidung, Assembler zu verlassen und endlich eine Hochsprache zu erlernen versuchen, rum gedrückt. Mal ehrlich: bei dieser Suche hatte ich mich immer wieder an Beiträgen in der von mir hoch geschätzen "c't" und verschiedentlich auch der Schwester-Zeitschrift aus dem Heise-Verlag, der "make:" orientiert. Deren Redakteure propagierten seit Jahren schon MicroPhyton. Aber - wie schon erwähnt - waren das unterm Strich immer nur so Schnupper-Proben und aus meiner Sicht nichts Handfestes.
Nach Jahren des Zweifelns habe ich nun mit Gewalt den Knoten zu durchschlagen versucht. Die Anfänge lassen es für mich sinnvoll erscheinen, den Faden auch weiter zu verfolgen. Ich bitte um Verständnis, dass ich diesen Versuch auch fortführe, um nicht wieder in die Phase der Zweifel zurück zu fallen.
Wenn es denn mit MicroPhyton - oder wie im Moment eher mit Phyton - doch in die Nähe von "C" rückt, kann das ja keine schlechte Sache sein. Immerhin sind die vielen Klammern erst mal nicht nötig. Ihr seht, ich versuche, der Lage Positives abzugewinnen und endlich mal zu wissen, in welcher Richtung es weiter gehen könnte. Und wenn Phyton und C viele Gemeinsamkeiten aufweisen sollten, dann kann ja auch dein Script plötzlich wieder zu unerwarteten Ehren kommen, Volker.
Grüße, picass

Zitat von: picass in Gestern um 10:42:04 CETUnd wenn Phyton und C viele Gemeinsamkeiten aufweisen sollten...

Viele Hochsprachen werden in der Syntax oberflächlich viele Ähnlichkeiten aufweisen.

Solange man vom Bauraum und dem Energieverbrauch nicht eingeschränkt ist, kommt man
mit Raspi, ESP32, ItzyBitzy, Arduino ... aufgrund der vielen fertig vorhandenen
Bibliotheken und Beispiele sicher schnell und ohne große Einarbeitung voran.

Wenn ich mal wieder länger Zeit habe, werde ich mich auch nochmal in CircuitPython vertiefen ;-)
https://circuitpython.org/