Go Down

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

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

#37
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)

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

#40
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.


Whandall

Welchen Pullup benutzt du auf der Datenleitung?
Ah, this is obviously some strange usage of the word 'safe' that I wasn't previously aware of. (D.Adams)

ElEspanol

#43
Dec 08, 2017, 08:04 pm Last Edit: Dec 08, 2017, 08:51 pm by ElEspanol
Ich meinte 5V über Pullup 1-2k auf den Datenpin und dann mit Level shifter zum ESP

in etwa so:

Addi2438

Hast du ein BitScope zu Hand?

Da die Arduino Bibs für den ESP32 auf die Original ESP IDF aufsetzen läuft auf dem ESP ein RTOs. Um genau zu sein freeRTOs.

Wenn die Bibliothek die du verwendest dumm programmiert wurde kann es passieren das während der Abfrage des Sensors die Abfrage durch z.B. eine höherpriorisierte Task unterbrochen wird oder der Code für die Abfrage auf Grund von Delays und oder synchroner Programmierung Rechenzeit für andere Tasks frei gibt.
Den resultierenden Taskwechsel bekommt man spürbar mit und das Ganze kann soweit gehen, dass es dir dein gesamtes Timing zerschießt. Ich hatte das Problem bei einem SPI Treiber für ein TFT Display den ich zur Zeit schreibe. Am Anfang war das alles schön synchron programmiert und das Display hat sich extrem langsam aktualisiert eben genau desswegen weil bei jedem Verschicken gewartet wurde bis die SPI Einheit fertig war und es dadurch zu einem Taskwechsel kam.


Mittlerweile wickle ich das alles über DMA ab.

Im ESP Forum hatte ich mal einen Thread aufgemacht weil ich selbst über DMA noch Probleme hatte.
Da ist ein Bild mit einem gescoptem Signalverlauf dabei wo man sehr schön sieht wann ein Taskwechsel auf Grund von synchronen Befehlen hervorgerufen wurde.

Bild kann ich später mal hier rein stellen.


Ich würde mal mitm BitScope das Signal verfolgen.
Wenn dir soetwas in die Quere kommt kann man das deutlich sehen.


Du könntest mal versuchen deine Routine in eine freeRTOS task zu packen und diese mit einer höheren Priorität laufen zu lassen oder auf einem anderen Kern. Vlt hilft dir das bereits.

Wie das mit der Arduino IDE geht kann ich später verlinken.
Baby Kiwi, what else? :D

Go Up