Entwicklung eines Innenraumsensors /Steuerung mit ESP32 und Nextion Display 7"

[PeMue]

... ist doch schön, das auf Umwegen dasselbe rauskommt 

Aber mal im Ernst: ich habe diese Schaltung glatt übersehen. Würde aber trotzdem kein Poti einbauen wollen, da diese sich ganz anders über der Temperatur verhalten, als Festwiderstände. Ich denke, wenn das mit dem Offset funktioniert, sollten wir schauen, wie wir einen Referenzwert bei höherer CO2 Konzentration hinbekommen. Gut ist, dass der Grenzwert sowieso im Bereich zwischen 1000 und 1500 ppm liegen sollte, da haben wir eine akzeptable Genauigkeit.

Gruß Peter

[Tobias]

Also lass und mal sehen wie die aktuelle Schaltung funktioniert und was an Ergebnissen herauskommt. Danach machen wir auf Grundlage der Ergebnisse eine optimierte Schaltung
Ich versuche heute abend die ersten SMD-Widerstände drauf zu löten...

[stgeran]

Ich erinnere mich aber, daß Du danach aber mit einer "abgespeckten" Schaltung ankamst. Und auf der haben wir wieder aufgebaut.

[Tobias]

Ich erinnere mich aber, daß Du danach aber mit einer "abgespeckten" Schaltung ankamst. Und auf der haben wir wieder aufgebaut.

Ja korrekt Nur als du den Poti erwähnt hast ist mir dieses Beispiel sofort wieder eingefallen

[PeMue]

Hallo Tobias,

wo läßt Du eigentlich Deine Leiterplatten fertigen? Ich denke, ich werde demnächste auch was brauchen ...

Danke + Gruß

Peter

[Tobias]

unterschiedlioch, zurZeit hier: http://www.dfrobot.com/index.php?route=product/product&path=135_134&product_id=718

[justme1968]

ich schaue mir gerade deine formel an....

kann es sein das du mit 8 bit auflösung bzw. werten des a/d wandlers zwischen 0 und 255 rechnest? jedenfalls bekomme ich jeweils etwas in der nähe von 0 bzw. 255 wenn ich 350ppm bzw 3500ppm in die funktion stecke und rückwärts rechne.



wir haben aber 10 bit Auflösung. d.h. werte zwischen 0 und 1023.

gruss
  andre

[PeMue]

Hallo Andre,

nein, passt schon. Der ausgenützte Bereich ist im Mittel 778 mV Differenz zwischen 350 und 3500 ppm. Sprich wir bewegen uns im Bereich von 800 mV bei einem max. Bereich von 3,3 V. Dies entspricht in etwa dem Faktor 4 und somit dem von Dir beobachteten 8 versus 10 bit.
Da die Sensoren aber bei 350 ppm eine starke Streuung haben, liegt der Wert irgendwo. Daher muss ja auch der Nullpunkt (350 ppm) bei jedem Sensor extra festgelegt werden.

Gruß Peter

[justme1968]

ok.

wenn die korrektur/kalibrierung nur linear als offset ins ergebnis eingeht ist ziemlich sicher eine lookuptable die platzsparendste lösung.
selbst wenn ich nicht auf jedes bit achte und einfach 8 bit  auf 16 mappe brauche ich 512 byte. die kann ich ohne probleme ins eeprom stecken und mit flashen.

da braucht die berechnung sicher mehr speicher. egal wie sehr optimiert. und langsamer wäre es auch.

gruss
  andre

[PeMue]

Hallo André,

habe mal die Lookuptable hier eingefügt. Das mit den 512 Bytes könnte hinkommen. Allerdings könnte man auch bei Werten über 2000 ppm linearisieren, da stimmt dann der Sensor sowieso nicht mehr ...

Tobias ist gerade so schweigsam, vermutlich funktionieren die Verstärker noch nicht 

Gruß Peter

[justme1968]

perfekt. das hatte ich eigentlich heute vor

zum platz sparen könnte man auch 12bit fürs ergebnis verwenden und die nibble packen. das spart 1/4. wie viel das linear interpolieren spart probiere ich mal aus.

beides führt aber wieder zu größerem code. könnte also unterm strich nach hinten los gehen. zumal der eeprom platz noch völlig unkritisch ist. der flash ist der engpass. also die code größe.

ich könnte auch das nvsram verwenden. da ist noch viel mehr luft. da kann ich aber nur über einen laufenden sketch hin schreiben. nicht beim flashen. das würde dann auf einen zusätzlichen sketch zum initialisieren der lookup table hinauslaufen. das ist zwar kein problem aber unpraktisch. also erst etwas wenn es noch enger wird.

gruss
  andre

[justme1968]

hier eine erste vor alpha version der software.

- indoorsensor.tar.gz: alle (ich hoffe ) quelltexte für den sketch
- devices.xml das aktualisierte devcices file -> nach .../FHEM/lib/SWAP
- indoorsensor.xml -> das device description file für das sensor board -> nach .../FHEM/lib/SWAP/justme
- 35_SWAP_0000002200000008.pm das fhem modul -> nach .../FHEM

kompilieren zur zeit nur per ino tool.

wichtig: in src/config.h jeweils alle pins anpassen. zur zeit ist meine breadboard config drin. die ist anders als die auf dem board

in src/sketch.ino in zeile 39ff lassen sich einige defaults konfigurieren. die beschreibung steht in src/config.h

das fhem modul kann zur zeit nur 'set desired' und 'set text'. der text ist nur einzeilig. also nur 7 Buchstaben.

noch ein paar anmerkungen:
- die große loop soll noch auf eine state machine umgestellt werden. das macht das erweitern später einfacher
- bei den libs lässt sich vermutlich noch etwas platz sparen. da hab ich nicht nicht geschaut
- die helligkeit wird noch nicht in lux übertragen. mit dem temt6000 ging das ja nicht. mit dem TSL2561 schon.
- das senden von messwerten sobald eine bestimmte änderung erreicht ist ist noch nicht eingebaut

gruss
  andre

[Tobias]

So, heute abend wieder 1h dazu gekommen. Ihr wisst ja, Feiertage, Family usw...

So sieht das Board jetzt aus, der Panstamp ist noch nicht programmiert...

Edit: CY14x101I.h fehlt.....
Und damit ich sketch.ino in der IDE laden kann muss ich es auf indoorsensor.ino umbenennen sowie src/ auch in "indoorsensor" umbenennen

[PeMue]

... und wo ist der CO2 Sensor? Und der OP ist auch noch nicht bestückt? 
Ich bin echt gespannt auf die Spannungswerte 

Gruß und schöne Ostern

Peter

[Tobias]

Will erst sehen ob es grundsätzlich läuft. Der Sensor ist zu teuer um sofort in Rauch aufzugehen

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk