Go Down

Topic: DS18b20 mit ESP32 wird durch Wifi gestört (Read 3515 times) previous topic - next topic

postmaster-ino

Hi

Hattest Du schon probiert, die DS18B20 auf einen anderen Pin/anderes Port zu setzen?
Wenn Das auch nicht hilft, spucken sich diese beiden Funktionen gegenseitig in die Suppe!
Nicht mehr, aber auch nicht weniger.
Wie viele DS18B20 musst Du in welcher Zeit abfragen?
Kann man der Dallas-Lib auch sagen, daß ALLE DS18B20 die Temperatur konvertieren sollen?
(also per SkipRom, convertTemp)
Hätte den Vorteil, daß man EIN MAL diese 750ms warten muß, da alle Sensoren gleichzeitig die Generierung vornehmen - möglich, daß hier dann im parasitären Modus ein Leitungslängenproblem auftritt, da die Sensoren dafür halt etwas Strom brauchen - äh, Stichwort: wird das Port ggf. vom Wifi-Teil abgeschaltet? Dadurch würden die Sensoren keinen Strom mehr haben und somit nicht mehr fähig, die Temperatur herzuleiten - das anschließende Auslesen liefert dann -> Müll.

Alternativ:
Man kann das ganze Gelump auch zu Fuß machen (wobei mir nocht bekannt ist, wie genau man in C selber zeitkritische Abläufe steuern kann) - eben mit der Möglichkeit, per SkipRom, ConvertTemp der ganzen Bargage gleichzeitig zu Befehlen, die Temperatur herzuleiten.
Das Auslesen ist dann nur noch abhängig vom 1-wire-Bus und sollte vernachlässigbar kurz ausfallen.

Zumindest den Convertierungsbefehl könnte man als Inline-Assembler raus hauen - dann kann man beim Auslesen auf jegliche Pause verzichten.

MfG

Wiki_

Moin,

jo, mehrere Ports ausprobiert. Ergebnis immer dasselbe: ohne Wifi prächtig, mit Wifi Zufall.

Ich frage zZt. vier Dallas ab, dafür dient die Schleife

Code: [Select]

  for(int i=0;i<numberOfDevices; i++)     // Schleife zum Auslesen der Temperaturen
  {
    if(sensors.getAddress(tempDeviceAddress, i))
    {
      float tempC = sensors.getTempC(tempDeviceAddress);
      temp[i]=tempC;
      delay(30);
    }
  }


Dabei wird die im setup ermittelte Anzahl der Sensoren nacheinander abgefragt. Wieviele Sensoren dran sind hab ich nicht fest auf die schon vorhandenen Sensoren verdrahtet sondern offen gelassen, da vllt. Umgebungstemperatur und solch profane Infos wie Vorlauftemperatur der Heizung später mal dazukommen könnten. Dann brauch ich nur in der Webseite weitere im Array gespeicherten Daten ausgeben, ohne die Auslesefunktion zu ändern.

Zeitlich ist die Messung in diesem Anwendungsfall völlig unkritisch. Die Sensoren kleben an vier 12V Bleiakkus. Was ich wissen will ist, ob einer der Blöcke in der Volladungs- oder Ausgleichsphase temperaturmässig aus dem Ruder läuft. Oder bei tieferen Entladungen zu weit einbricht. Und Bleiakkus ändern ihren Zustand nicht im Millisekunden- sondern im Minutenbereich. Genauso mit der Spannung, auch da hab ich eigentlich alle Zeit der Welt. Von daher hab ich absolut kein Problem, auf die Antwort der lib zu warten, in diesem Fall sind das drei Sekunden.

Der Dallas Lib sage ich mit requestTemperatures(), sie möge alle ihr erreichbaren Sensoren anstossen, funzt auch prächtig. Die lib blockiert derweil - abhängig von der eingestellten Genauigkeit - den Fortlauf vom Programm. Das ist gut so, denn ich muss mich dann nicht ums Timing kümmern - ist schon smart.

Zu Fuß könnte ich den Klumpatsch schon abfackeln. Dafür gibts das Keyword waitForConversion() in der lib. Wenn auf false, blockiert die lib nicht und ich hätte das Timing selbst in der Hand. Will ich nicht, ich lass der lib gern die Kontrolle.

Imho gibt es hier kein Timing-Problem, das Auslesen der Dallas ist popelig einfach und die Abfrage eines A/D Wandler profan. Die Dallas-Sensoren sind völlig unschuldig an meinem Problem. Dass selbst espressif für ihre eigene IDE eine Lib zum "Kalibrieren" der A/D-Wanlder zur Verfügung stellt deutet für mich darauf hin, dass in der Hardware selber diverse Probleme mit eingebaut sind. So kann zB niemand genau sagen, in welcher Hertsellungs-Charge welche Referenzspannung intern vorhanden ist - in meinen Augen ein absolutes Unding. Dazu noch die Tatsache, dass die Ausgabe der A/D-Wandler nicht linear ist, ich muss eine umfangreiche Tabelle zurate ziehen, um lineare Werte zu generieren. In meinen 30 Jahren Handling von A/D Wandlern ist mir soetwas noch nicht untergekommen. Und ja, ich weiss, Dallas wird nicht analog abgefragt ;-).

Ich gehe mittlerweile davon aus, dass die I/O Ports des mC keinerlei Dämpfung enthalten und somit das Protokoll des 1Wire durch die ständige Präsenz des Wifi zerschossen wird.

Eine Weiterverfolgung dieses Themas ist wohl müßig. Es scheint keine Erfahrung damit zu geben, einen ESP32 als Webserver mit DS18B20 zu betreiben.

postmaster-ino

Hi

Schade - hätte ja sein können, daß das Wifi-Zeug nur an einem Pin/einem Port stört.
Dann denke ich, geht die Sache eher in Richtung Timer - eine andere 1-wire-Lib versucht?
Zu Deinen Spannungsmessungen - wenn 1-wire klappt, könntest Du Das auch per 1-wire erschlagen (DS2834z, erster eBay-Treffer).
Habe die Hoffnung, daß bei einer anderen Lib ein anderer Timer benutzt wird - habe bisher aber auch nur zu Anfang die DS18B20 händisch auf einem ATtiny45 mit 1MHz gesucht und ausgelesen.(in Assembler, Routinen in tagelanger Fleißarbeit nach Datenblatt/WWW zusammen geschraubt - halt nicht sonderlich portierbar, der Kram)

MfG

Wiki_

Dann denke ich, geht die Sache eher in Richtung Timer - eine andere 1-wire-Lib versucht?
Zu Deinen Spannungsmessungen - wenn 1-wire klappt, könntest Du Das auch per 1-wire erschlagen (DS2834z, erster eBay-Treffer).
Moin,

nö, hab bis jetzt für den ESP32 keine andere 1-wire-lib gefunden. Bitte zu beachten: ESP32 ist (noch) nicht direkt in Arduino implementiert, muss extern über github gezogen werden und ist immernoch in der Übersetzungsphase.

Aber bitte: warum Richtung Timer? Wenn ich Wifi abschalte funzt es gnadenlos gut....versteh ich nicht.

Für die Batterieüberwachung meinst Du aber eher den DS2438z, oder? ;-)

postmaster-ino

Hi

Hmm, hatte gerade einen 'Gedankenblitz' - leider wohl erfolglos.
Mein Gedanke war:
Setze den Wifi-Include Mal an das Ende der ganzen Includes - klappt jetzt das 1-wire und Wifi nicht mehr?

Wieso includierst Du eigentlich Dallas, 1-wire, Adafruid-Sensor ? Ist Das nicht Alles irgendwie für 1-wire?
Kannst Du davon was auskommentieren, OHNE, daß der Compiler meckert? Wobei unbenutzte Includes -glaube- als Warnung ausgegeben werden.

MfG

Whandall

Bitte zu beachten: ESP32 ist (noch) nicht direkt in Arduino implementiert, muss extern über github gezogen werden und ist immernoch in der Übersetzungsphase.
Was bitte soll das denn heißen?

Es gibt nichts was "in Arduino implementiert ist".

Was ist dein Problem mit github? Zu unbequem?
Fand ich erträglich, auch wenn Boardmanager schöner wäre.

Von was in was soll das ESP32 Subsystem übersetzt werden?
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Wiki_

Was bitte soll das denn heißen?

Es gibt nichts was "in Arduino implementiert ist".

Was ist dein Problem mit github? Zu unbequem?
Fand ich erträglich, auch wenn Boardmanager schöner wäre.

Von was in was soll das ESP32 Subsystem übersetzt werden?
Moin,

[OT on]
nö, mit github hab ich überhaupt kein Problem. Im Gegenteil, ich achte und schätze die Arbeit derjenigen, die viel eigenen Aufwand dort veröffentlichen und solchen Noobs wie mir die Möglichkeit geben, mit den Geräten zu arbeiten. Ich fand das Einbinden in Arduino nicht nur erträglich, sondern absolut hervorragend - Kompliment und Hut ab an die Verwirklicher sowohl von Arduino als auch von den espressif-Komponenten.

Was ich meinte ist, daß libs für AVR-Plattform nicht unbedingt für den ESP32 funktionieren und die Anpassungen noch weiterhin in Arbeit sind. Damit gibts noch keine große Auswahl an Alternativen für funktionierende libs, obwohl schon einige schon auf github zu finden sind. Ist verständlich und von mir voll und ganz akzeptiert.

Das "von was in was" beantworten die in den Headern der angepassten libs integrierten Abfragen nach der jeweiligen Plattform und die dann folgenden Verlinkungen und Verzweigungen. Gibt da ne Menge Lesestoff.

[/OT off]

Whandall

[OT]
Alles das keine prozessorspezifischen Dinge enthält, sollte auf allen Plattformen laufen,
(u.U. mit kleinen Änderungen) auch wenn in der Library als Ziel nur AVR angegeben ist.

Die Standard Libraries die zum Arduino Kernsystem gehören, sind alle portiert.

Die Ersteller anderer Libraries können nicht erwarten, dass Espressif das für sie tut, oder?

Durch Open Source kann ja auch jeder Libraries selbst portieren.

Zu jammern, dass es die Anderen nicht für einen machen, ist nicht zielführend,
und ganz sicher kein Makel eines ESP32/ESP8266.
[/OT]

Ich glaube nicht dass dein Problem ein WiFi Übersprechen ist, sondern eher dass die Spannung für parasitäre DS bei 3.3V und WiFi-Strombelastung einfach nicht ausreicht.
Kleine Spannungseinbrüche kann der ESP32 vielleicht noch wegstecken, die DS nicht.

Funktioniert dein System wenn du testweise die DS nicht parasitär betreibst?
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Wiki_

Moin,

[OT on]
ich fühl mich ein wenig missverstanden: ich will nicht über die fehlende Arbeit Anderer jammern, sondern fühle mich pudelwohl mit der Arbeit Anderer, die bis jetzt geleistet worden ist. Alles gut, so, wie es ist - was die Softwareseite anbelangt. Die Hardware ist ein anderes Thema.
[/OT off]

hhmmm, an dem laufenden System kann ich ohne großen (Haus-)baulichen Aufwand so gut wie nix mehr ändern. Ich werd wohl mit den minutenwiese zufälligen Antworten der Dallas wohl oder überl leben müssen und wohl auch können.

Um dem Thema aber auf den Grund zu gehen, werd ich mal schaun, ob ich morgen (öhm, heute) einen anderen ESP32 nicht-parasitär aufbauen kann. Der Verdacht der nicht ausreichenden Versorgung auf der 3,3V-Seite scheint mir nicht verkehrt zu sein. Zumal weil Wifi in Relation zu allen anderen Komponenten ein rechter Energievernichter ist.

Gib mir nen paar Stunden, ich werde berichten.

Whandall

#39
Dec 08, 2017, 12:44 am Last Edit: Dec 08, 2017, 12:55 am by Whandall
Der AD Wandler des ESP32 ist sinnvoll innerhalb gewisser Grenzen nutzbar,
am unteren und oberen Ende des Bereichs ist er stark nichtlinear (zumindestens war das mal so),
dagegen hilft nur algorithmische Korrektur, keine Mittelwertbildung.

Quelle: https://github.com/espressif/esp-idf/issues/164

Alternativ könnte man die Messgröße in den linearen Bereich abbilden (mit Auflösungsverlust),
oder einen externen ADC verwenden.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

kulturbereicherer

Quote
Durch Open Source kann ja auch jeder Libraries selbst portieren.
Wirklich jeder?  ;) Ich kann es nicht  :D

Whandall

Wirklich jeder?  ;) Ich kann es nicht  :D
Immerhin muss man nur noch die Fehler finden, falls es überhaupt welche gibt.

Wenn man es selbst nicht kann (oder will) kann man immer noch nach den öffentlichen Lösungen
Anderer suchen, auf GITHUB finde ich für "ds18b20 esp32" 9 Einträge.

Aber das hilft alles nichts wenn (wie schon in #1 erwähnt) parasitärer Betrieb mit 3.3V nicht zuverlässig funktioniert.
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

Wiki_

Der AD Wandler des ESP32 ist sinnvoll innerhalb gewisser Grenzen nutzbar,
am unteren und oberen Ende des Bereichs ist er stark nichtlinear (zumindestens war das mal so),
dagegen hilft nur algorithmische Korrektur, keine Mittelwertbildung.
Quelle: https://github.com/espressif/esp-idf/issues/164
Alternativ könnte man die Messgröße in den linearen Bereich abbilden (mit Auflösungsverlust),
oder einen externen ADC verwenden.
Moin,

[wieder OT]
jo, hast Recht, menno, ich weiss an der Stelle wirklich, wovon ich rede.

Haste mal versucht, ne Spannungs- und Strommessung einer in einem Fahrzeug befindlichen Energieverorgung über welchen A/D Wandler auch immer korrekt umzusetzen, wennste mit dem Fahrzeug, in dem sich die Messeinrichtung befindet, an dem Mittelwellensender im Bereich Linnich vorbeifährt? Wenn nicht, probiers mal, und dann viel Erfolg. Hört sich harsch an, ist aber bei Weitem so nicht gemeint. Ich empfinde Deine Kommentare als durchaus sinnvoll und anregend.

Die Mittelwertbildung ist bei mir drin zur Eliminierung äusserer Störgrößen (sowas profanes wie 50Hz oder sowas), nicht zur Korrektur der nicht-Linearität. Allerdings sind die A/D-Wandler des ESP32 arg empfindlich, wenn ich mal meine Erfahrungen mit anderer Hardware mit hinzuziehe. In meinem Code kannste den Aufruf von ADCKorrektur sehen, da setze ich die analogen Werte in die erwarteten um - Korrektur der nicht-Linearität.

Espressif hat für das mehr als merkwürdige Verhalten desw ADC schon "Kalibrirungs"-libs veröffentlicht, die bei mir allerdings vom Compiler unter Arduino nicht so recht akzeptiert werden. Von daher meine hakelige - für mich funktionierende - Lösung (ist q&d per Script aus Excel-Tabelle generiert, man kann sie wesentlich eleganter schreiben, klar, für Vorschläge immer offen):

Code: [Select]

float ADCKorrektur(float Reading)
{
  if (Reading < 1863)
  {
    Reading=Reading/219;
  }
  else if (Reading < 1980)
  {
    Reading=Reading/219.5;
  }
  else if (Reading < 2055)
  {
    Reading=Reading/220;
  }
  else if (Reading < 2127)
  {
    Reading=Reading/221;
  }
  else if (Reading < 2220)
  {
    Reading=Reading/221.5;
  }
  else if (Reading < 2337)
  {
    Reading=Reading/222;
  }
  else if (Reading < 2410)
  {
    Reading=Reading/222.5;
  }
  else if (Reading < 2482)
  {
    Reading=Reading/223;
  }
  else if (Reading < 2580)
  {
    Reading=Reading/223.5;
  }
  else if (Reading < 2610)
  {
    Reading=Reading/224;
  }
  else if (Reading < 2750)
  {
    Reading=Reading/225;
  }
  else if (Reading < 2850)
  {
    Reading=Reading/226;
  }
  else if (Reading < 2910)
  {
    Reading=Reading/227;
  }
  else if (Reading < 3000)
  {
    Reading=Reading/228;
  }
  else if (Reading < 3050)
  {
    Reading=Reading/229;
  }
  else if (Reading < 3100)
  {
    Reading=Reading/230;
  }
  else if (Reading < 3200)
  {
    Reading=Reading/231;
  }
  else if (Reading < 3250)
  {
    Reading=Reading/233;
  }
  else if (Reading < 3300)
  {
    Reading=Reading/235;
  }
  else if (Reading < 3350)
  {
    Reading=Reading/236;
  }
  else if (Reading < 3400)
  {
    Reading=Reading/237;
  }
  else if (Reading < 3440)
  {
    Reading=Reading/238;
  }
  else if (Reading < 3480)
  {
    Reading=Reading/239;
  }
  else if (Reading < 3510)
  {
    Reading=Reading/240;
  }
  else if (Reading < 3550)
  {
    Reading=Reading/241;
  }
  else if (Reading < 3590)
  {
    Reading=Reading/242;
  }
  else if (Reading < 3630)
  {
    Reading=Reading/243;
  }
  else if (Reading < 3655)
  {
    Reading=Reading/244;
  }
  else if (Reading < 3700)
  {
    Reading=Reading/245;
  }
  else if (Reading < 3725)
  {
    Reading=Reading/246;
  }
  else if (Reading < 3760)
  {
    Reading=Reading/247;
  }
  else if (Reading < 3800)
  {
    Reading=Reading/248;
  }
  else if (Reading < 3840)
  {
    Reading=Reading/249;
  }
  else if (Reading < 3870)
  {
    Reading=Reading/250;
  }
  else if (Reading < 3900)
  {
    Reading=Reading/251;
  }
  else if (Reading < 3940)
  {
    Reading=Reading/252;
  }
  else if (Reading < 3970)
  {
    Reading=Reading/253;
  }
  else if (Reading < 4000)
  {
    Reading=Reading/254;
  }
  else
  {
    Reading=Reading/255;
  }

return Reading;
}


Man mag daraus ersehen, ich war in dieser Angelegenheit nicht ganz untätig.
[/mal wieder OT off]

ElEspanol

#43
Dec 08, 2017, 05:31 pm Last Edit: Dec 08, 2017, 05:37 pm by ElEspanol
Anstatt Mitterwertbildung bietet sich bei Störeinflüssen doch eher ein (Running) Median an. Der lässt Ausreisser einfach aussen vor.

DS18B20: Hab noch etwas rumgespielt. Mit einem Levelshifter und 5V Versorgung der Datenleitung mit Widerstand. Klappt perfekt, je nach Anzahl der Sensoren muss man mit dem Pullup runtergehen. bei 1K hab ich mit 3 Sensoren parasitär keine Fehlmessungen. Allerdings Kabellänge praktisch null, da auf dem Breadboard.

Du kannst ja auch testweise eine Strippe mit 3,3V Versorgung zu den Sensoren ziehen. Dann siehst du sofort, ob es die Versorgung ist. Auch eine Batterie an den Sensoren könnte ein guter Test sein, wenn du keine Strippe durchs Haus ziehen willst.

Wiki_

Moin,

Danke für Deine Unterstützung, weiss ich zu schätzen.

Hhmmm, wenn ich aber in der parasitären Schaltung eine höhere Vup anlege, dann steht am I/O Pin doch im worst case über den Pullup die Spannung an. Und es wird davor gewarnt, dass die I/O Pins des ESP32 nicht 5v-tolerant wären. Ich werd aber mal eine zusätzliche Versorgung von 3,3V generieren und berichten.

Ich hab jetzt mal auf nem anderen Breadboard mit nem anderen ESP32 zwei andere Dallas nicht parasitär aufgebaut, allerdings mit Versorgung der 3,3V vom DevBoard. Mehr Dallas hab ich zZt hier nicht rumfliegen. Auch das OLED musste ich mir sparen, hab zZt nur noch nen I2C parat und wollte am Sketch nix ändern. Aber wenns die Versorgung sein sollte wäre das ja nur von Vorteil. Dazwischen gemogelt hab ich nen bissl logging.

Selber Sketch, einmal mit Wifi Server an, einmal mit Wifi Server aus.

Ergebnis:

Wifi Server an: (fast)Schweigen im Walde, dasselbe Spiel wie mit parasitärer Schaltung der vier Sensoren meines aktiven Systemes:

Code: [Select]

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:956
load:0x40078000,len:0
load:0x40078000,len:11856
entry 0x40078a34
2
Initialmessung vor Anschalten Wifi
Temp holen
Sensor: 0
20.44
Sensor: 1
20.44
Wifi anschalten
Vergangene Sekunden: 12
Temp holen
Vergangene Sekunden: 18
Temp holen
Vergangene Sekunden: 23
Temp holen
Vergangene Sekunden: 29
Temp holen
Sensor: 0
20.44
Vergangene Sekunden: 35
Temp holen
Vergangene Sekunden: 41
Temp holen
Sensor: 0
20.44
Vergangene Sekunden: 47
Temp holen
Vergangene Sekunden: 52
Temp holen
Vergangene Sekunden: 58
Temp holen
Sensor: 1
-127.00
Vergangene Sekunden: 64
Temp holen
Vergangene Sekunden: 70
Temp holen
Vergangene Sekunden: 76
Temp holen
Vergangene Sekunden: 81
Temp holen
Vergangene Sekunden: 87
Temp holen


Wifi Server aus: wie zu erwarten prächtige Temperaturanzeigen

Code: [Select]

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:956
load:0x40078000,len:0
load:0x40078000,len:11856
entry 0x40078a34
Initialmessung
Temp holen
Sensor: 0
20.75
Sensor: 1
20.81
Vergangene Sekunden: 7
Temp holen
Sensor: 0
20.75
Sensor: 1
20.81
Vergangene Sekunden: 13
Temp holen
Sensor: 0
20.75
Sensor: 1
20.81
Vergangene Sekunden: 19
Temp holen
Sensor: 0
20.75
Sensor: 1
20.81
Vergangene Sekunden: 25
Temp holen
Sensor: 0
20.81
Sensor: 1
20.81
Vergangene Sekunden: 31
Temp holen
Sensor: 0
20.81
Sensor: 1
20.81
Vergangene Sekunden: 37
Temp holen
Sensor: 0
20.81
Sensor: 1
20.81
Vergangene Sekunden: 43
Temp holen
Sensor: 0
20.81
Sensor: 1
20.81
Vergangene Sekunden: 49
Temp holen
Sensor: 0
20.81
Sensor: 1
20.81
Vergangene Sekunden: 55
Temp holen
Sensor: 0
20.81
Sensor: 1
20.81


Erklärung für die höheren Temperaturen: Hab grad den Kamin angworfen, die Werte stimmen also und die Dallas sind alive ;-)

Ist also egal, ob parasitär oder nicht, der Wifi Server raucht mir dazwischen.


Go Up