ESP8266 instabil / schickt UART obwohl nicht vorgesehen?

[Max M. (maxmicr)]

Hallo,

Mein Testboard mit dem ESP8266 (Schaltplan siehe Anhang) scheint nun 
halbwegs zu funktionieren, immerhin kann ich den Controller mit eigenem 
Code flashen. Der da sieht z.B. aktuell so aus:

#include <ets_sys.h>
#include <osapi.h>
#include <gpio.h>

#define DELAY 50000 /* microseconds */

void user_init(void)
{
  // Configure pin as a GPIO
  PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12);
  for(;;)
  {
    GPIO_OUTPUT_SET(12, 1);
    os_delay_us(DELAY);
    GPIO_OUTPUT_SET(12, 0);
    os_delay_us(DELAY);
  }
}

Es wird einfach der Pin "GPIO12" ein und ausgeschalten, also ein 
klassisches LED-Blink Testprogramm.

Zum Flashen benutze ich einen klassischen USB / UART Konverter mit einem 
CH340G.

Neben dem LED blinken beobachte ich nun auf der Konsole auch 
UART-Ausgaben, die ja eigentlich nicht Teil des Programms sind. Der 
Controller wird mit einer BAUD-Rate von 115200 geflasht, auf der selben 
BAUD-Rate empfange ich aber bei den UART-Sendungen nur kryptische 
Symbole. Weiterhin blinkt die blaue LED auf dem Modul im Takt mit dem 
UART, zudem wird das LED-Blinken kurz von dem UART unterbrochen (die LED 
bleibt länger aus als gewöhnlich).

Nach einiger Zeit geht das Modul kurz aus (kein UART mehr und auch die 
LED blinkt nicht) und dann wieder an. Nachdem das ein paar mal passiert, 
geht das Modul ganz aus und auch nach 5 Minuten warten nicht wieder an.

Ein Flashen ist nun auch nicht mehr möglich (auch nach Strom ab und 
wieder an nicht).

Lötstellen hab ich schon alle überprüft. Womit lässt sich das seltsame 
Verhalten erklären?

[Werner P. (Gast)]

Max M. schrieb:
> void user_init(void)
> {
>   // Configure pin as a GPIO
>   PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12);
>   for(;;)
>   {
>     GPIO_OUTPUT_SET(12, 1);
>     os_delay_us(DELAY);
>     GPIO_OUTPUT_SET(12, 0);
>     os_delay_us(DELAY);
>   }
> }

die for(;;) in der user_init. tödlich.

[Max M. (maxmicr)]

Werner P. schrieb:
> die for(;;) in der user_init. tödlich.

Danke für deine Antwort,

Jetzt lässt sich das Modul erstmal wieder programmieren, wer weis, 
warum...
Okay, ich habs mal mit einem Timer probiert:

#include <ets_sys.h>
#include <osapi.h>
#include <gpio.h>
#include <os_type.h>

#define DELAY 1000

LOCAL void ICACHE_FLASH_ATTR fctTimer(void *arg){
  GPIO_OUTPUT_SET(12, 1);
  os_delay_us(DELAY);
  GPIO_OUTPUT_SET(12, 0);
  os_delay_us(DELAY);
}
void user_init(void)
{
  os_timer_t functionTimer;
  // Configure pin as a GPIO
  PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12);
  os_timer_disarm(&functionTimer);
  os_timer_setfn(&functionTimer, (os_timer_func_t *)fctTimer, (void *)0);
  os_timer_arm(&functionTimer, DELAY, 1);
}

Jetzt blinkt allerdings nicht die GPIO12-LED sondern die auf dem Modul 
selber und UART-Daten werden immer noch übertragen:

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

 16 
tail 4
chksum 0x7a
load 0x3ffe8000, len 884, room 4 
tail 0
chksum 0xf8
load 0x3ffe8380, len 168, room 8 
tail 0
chksum 0xab
csum 0xab

Das Modul geht nun schon nach ~10 Sekunden aus.

Okay, gerade gings wieder an, sehr seltsam.

Edit: Und wieder aus.

Edit_2: Wieder an???

[Werner P. (Gast)]

Max M. schrieb:

mach mal den functionTimer global.

#include <ets_sys.h>
#include <osapi.h>
#include <gpio.h>
#include <os_type.h>

#define DELAY 1000

os_timer_t functionTimer;

LOCAL void ICACHE_FLASH_ATTR fctTimer(void *arg){
  GPIO_OUTPUT_SET(12, 1);
  os_delay_us(DELAY);
  GPIO_OUTPUT_SET(12, 0);
  os_delay_us(DELAY);
}
void user_init(void)
{
  // Configure pin as a GPIO
  PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12);
  os_timer_disarm(&functionTimer);
  os_timer_setfn(&functionTimer, (os_timer_func_t *)fctTimer, (void *)0);
  os_timer_arm(&functionTimer, DELAY, 1);
}

[Stefan F. (Gast)]

Was hast du für einen Spannungsregler verwendet und wie viel Strom kann 
das Netzteil liefern?

Unabhängig davon würde ich C2 auf 100µF oder 220µF vergrößern. Ist ein 
Erfahrungswert aus (nicht nur meiner) der Praxis. Manche Leute empfehlen 
noch mehr.

Vermutlich benötigt der Spannungsregler außerdem noch 1 oder 2 viel 
kleinere Kondensatoren im Nanofarat Bereich.

Ist dein UART Adapter für 3,3V geeignet? Liefert er an TxD auch 3,3V 
Pegel, oder 5V?

[Max M. (maxmicr)]

Stefan U. schrieb:
> Was hast du für einen Spannungsregler verwendet und wie viel Strom kann
> das Netzteil liefern?

Ich benutze die 5V vom UART Adapter:

http://www.haoyuelectronics.com/Attachment/CP2102_module/CP2102_2.jpg

Stefan U. schrieb:
> Unabhängig davon würde ich C2 auf 100µF oder 220µF vergrößern. Ist ein
> Erfahrungswert aus (nicht nur meiner) der Praxis. Manche Leute empfehlen
> noch mehr.

Hatte ich vergessen zu erwähnen. Ich hab den 22uF inzwischen durch einen 
100uF getauscht. Was größeres hab ich leider nicht da (und gibt es glaub 
ich auch gar nicht für SMD, oder?).

Stefan U. schrieb:
> Vermutlich benötigt der Spannungsregler außerdem noch 1 oder 2 viel
> kleinere Kondensatoren im Nanofarat Bereich.

Hm, das ist schlecht :(
Ich benutze einen HT7333, ich finde allerdings gerade kein Datenblatt, 
wo beschrieben ist, wie der verschaltet wird.

Stefan U. schrieb:
> Ist dein UART Adapter für 3,3V geeignet? Liefert er an TxD auch 3,3V
> Pegel, oder 5V?

An RX/TX liegen 3.5 - 3.6V an.


Gerade ist der ESP wie tot...

Edit:

Okay, jetzt kann ich wieder flashen. Das Programm funktioniert nun:

#include <ets_sys.h>
#include <osapi.h>
#include <gpio.h>
#include <os_type.h>

#define DELAY 1000

os_timer_t functionTimer;

LOCAL void ICACHE_FLASH_ATTR fctTimer(void *arg){
  GPIO_OUTPUT_SET(12, 1);
  os_delay_us(DELAY);
  GPIO_OUTPUT_SET(12, 0);
  os_delay_us(DELAY);
}
void user_init(void)
{
  // Configure pin as a GPIO
  PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U, FUNC_GPIO12);
  os_timer_disarm(&functionTimer);
  os_timer_setfn(&functionTimer, (os_timer_func_t *)fctTimer, (void *)0);
  os_timer_arm(&functionTimer, DELAY, 1);
}

Aber das kann doch nicht sein, dass die lokale Deklaration einer 
Variablen solche Probleme auslöst? Die UART Übertragungen sind jetzt 
auch weg.

Edit: Okay, zu früh gefreut, jetzt ist das Ding wieder aus :(

[Michael U. (amiga)]

Hallo,

wenn Dein Terminal es kann setze die Baudrate mal auf 74800.
Das ist die Baudrate des Bootloaders (warum auch immer...). Dann siehst 
Du auch Deine Absturzgründe etwas besser.

Eigentlich gibt es 2 Hauptproblemursachen: Betriebsspannung unstabil und 
Programmierfehler.
Man hat den ESP8266 nicht allein. Es laufen immer systembedingte Sachen, 
laufen die nicht (weil man die stört oder weil man sie vergessen hat, 
wenn man wie Du auf SDK-Ebene anfängt), schlägt spätestens nach 6 
Sekunden der Watchdog zu und löst einen Neustart aus.
Den kann man auch nicht abschalten!

Gruß aus Berlin
Michael

[Stefan F. (Gast)]

Die Spannungsversorgung kommt also vom USB kabel, dass du an den PC 
gesteckt hast. Wir müssen hier damit rechnen, dass die Spannung unter 
Last erheblich einbricht, vielleicht auf 4 bis 4,5 Volt.

Wir können mangels Datenblatt nicht feststellen, ob der Spannungsregler 
richtig mit den erforderlichen Kondensatoren beschaltet ist und ob er 
überhaupt genug Strom liefern kann. Und wir wissen nicht, ob er bei der 
oben genannten Eingangsspannung (die man prüfen sollte) überhaupt 
korrekt funktioniert.

Tausche ihn durch einen anderen aus, von dem du auch ein Datenblatt 
hast. Du brauchst einen Spannungsregler, der bei 4V Eingangsspannung 
mindestens 500mA liefern kann. Und vergesse die Kondensatoren gemäß 
Datenblatt nicht!

Ich habe in meinem letzten Aufbau einen LF33CV im TO220 Gehäuse (ohne 
Kühlkörper) verwendet. Der würde nicht auf deine Platine passen, aber so 
hast du schonmal einen Anhaltspunkt, welche Regler elektrisch geeignet 
wäre.

[Stefan F. (Gast)]

Ich habe noch einen Tip:

Um festzustellen, ob dein primäres Probelm wirklich die 
Spannungsversorgung ist, verwende mal Testweise drei NiMh Akkus (3,6V) 
statt der geregelten 3,3V.

[Werner P. (Gast)]

Max M. schrieb:
> Aber das kann doch nicht sein, dass die lokale Deklaration einer
> Variablen solche Probleme auslöst?

Ja mei. Eine Variable, welche in einer Funktion deklariert wird, ist 
halt nur in dieser Funktion gültig.

[Max M. (maxmicr)]

Stefan U. schrieb:
> Tausche ihn durch einen anderen aus, von dem du auch ein Datenblatt
> hast. Du brauchst einen Spannungsregler, der bei 4V Eingangsspannung
> mindestens 500mA liefern kann. Und vergesse die Kondensatoren gemäß
> Datenblatt nicht!

Ich hab noch einen LM1117 hier, der dürfte auch mit 10µF und 100µF 
klarkommen, bei dem ist nur leider der Vin und Vout Pin gegenüber dem 
HT7333 vertauscht. Aber der wäre sowieso zu groß.

Stefan U. schrieb:
> Um festzustellen, ob dein primäres Probelm wirklich die
> Spannungsversorgung ist, verwende mal Testweise drei NiMh Akkus (3,6V)
> statt der geregelten 3,3V.

Ich hab nun 3 NiCd Akkus an das Board angeschlossen (im Schaltplan an 
den 3.3V und GND Ausgang / Eingang rechts oben).

Die blaue LED blinkt kurz (sieht also erstmal okay aus), allerdings 
lässt sich der Controller nicht flashen, es liegen ~3.67V an VDD, GPIO2 
und CH_PD, an GPIO15 liegen 0V an und an GPIO0 liegen 0.24V an (dürfte 
passen um das als 'LOW' zu erkennen, oder?).

[Max M. (maxmicr)]

Eine Frage zum os_timer:

Was passiert, wenn der Timer eigentlich schon wieder aufgerufen werden 
müsste aber der letzte Aufruf noch in der Funktion hängt da dort ein 
os_delay drin ist, der größer ist, als die Wiederholzeit des Timers?

[Michael U. (amiga)]

Hallo,

ich habe mir bisher weder os_delay noch den genauen Timer-IRQ angeschaut 
(ja, ich nehme die Arduino-IDE und direkte os-Aufrufe nur, wenn nötig 
und sinnvoll). Ansonsten 2 Möglichkeiten: der Timer-IRQ wird ignoriert 
(evtl. gespeichert, hängt von der Hardware ab, vom Verhalten der 
Interrupts überhaupt usw.). Der Interrupt ist zu der Zeit freigegeben 
und ruft die Routine eben nochmal auf. Ist die nicht dafür ausgelegt 
(reentrant) crasht er irgendwann wegen Speichermangel oder nicht 
eigeplanten Rekationen des Programmteils.
Prinzipiell gehört kein delay in eine Interruptroutine, dann ist der 
Programmauufbau schon falsch. Die soll prinzipiell so schnell wie 
möglich bearbeitet werden. Für den Rest setzt man Flags und macht es in 
main().

Wie oben schon geschriben: man ist nie allein auf einem ESP mit seinem 
Programm, es laufen immernoch Firmwaresachen für WLAN usw., egal, ob man 
die gerade nutzt oder nicht.
Setz das Terminal auf 74800 und schau Dir die Bootmessage an, falls er 
crasht. Hilft oft schon weiter.
Für die Arduino-IDE gibt es einen netten ExeptionDecoder, der decodiert 
den Stacktrace, daß hilft mir auch öfter mal weiter, wenn ich dem ESP 
mal wieder auf die Füße getreten bin.

Der HT7333 sollte den ESP eigentlich noch schaffen, allerdings dürften 
100-220µ am Ausgang fällig sein. Meine MCP1703 brechen ohne Elko sonst 
auch gern mal kurz ein wenn WLAN aktiv wird. Dann können auch 350mA 
Spitzen kommen und es hängt vom Verhalten des Regler ab, was der ESP 
macht.

CP2102 ist ansonsten kein Problem als USB-Adapter am ESP.

Gruß aus Berlin
Michael

[Max M. (maxmicr)]

Michael U. schrieb:
> Der HT7333 sollte den ESP eigentlich noch schaffen, allerdings dürften
> 100-220µ am Ausgang fällig sein.

100uF benutze ich zur Zeit, was größeres gibts in SMD-Bauform, soweit 
ich weiß, nicht. Aktuell klappt auch seltsamerweise wieder alles (mit 
der Stromversorgung über den USB / UART Konverter), ich habs sogar 
hinbekommen, einen Analogwert auszulesen.

Ich finde es nur etwas schade, dass einem die SDK-Beschreibung nur 
Funktionen hinwirft, aber man keinerlei Einblick in Register oder 
ähnliches erhält, man ist also gezwungen, diese Funktionen zu benutzen.

Angenehm ist allerdings, dass es eingebaute C-Funktionen wie strcat 
und sprintf gibt.

Was ich allerdings im API-Guide nicht verstehe (Punkt 
"system_adc_read"):

>The 107th byte in esp_init_data_default.bin(0〜～127byte) is named as 
>"vdd33_const",
>and when wire TOUT pin to external circuitry, the vdd33_const must be set as 
>real power
>voltage of VDD3P3 pin 3 and 4.

Ab was ist nun 'real power'? Vielleicht hängt das damit zusammen, das 
mein Temperaturwert des LM35 nicht stimmt. Mit dieser Formel:

adcVal = adcVal * (3.3/1024) * 100;

bekomme ich Werte um die 90 zurück (also 90°C).

[Michael U. (amiga)]

Hallo,

ich bin eigentlich ein Freund von hardwarenahen Programmierungen und 
Datenblättern. Ich gabe aber zu, daß ich mit mit den 
Espressif-Unterlagen und dem Xtensia-Kram nicht freiwillig 
auseinandergesetzt habe.

Ich wollte mit den ESP nur etwas rumspielen auf meine alten Tage.
Vermutlich könnte man sich auch die Wrapper-Sachend er Arduino-IDE zu 
Gemüte führen, die setzen ja auch nur auf dem SDK auf.
Dort liefert analogRead() die Betriebsspannung in mV ab, wenn man auf 
den externen Anschluß umschaltet, gibt es 0...1023 für 0V...1V am Pin.
Die Werte sind auch recht nah an der Wirklichkeit, ich habe nur sehr 
wenig in der Umrechnung korrigiert um die Akkuspannung bei meinen 
Sensor/PIR-Modulen zu messen. Andere Gründe, den ADC zu nutzen, hatte 
ich da noch nicht.

Aus core_esp8266_phy.c

    // vdd33_const
    // the voltage of PA_VDD
    // x=0xff: it can measure VDD33,
    // 18<=x<=36: use input voltage,
    // the value is voltage*10, 33 is 3.3V, 30 is 3.0V,
    // x<18 or x>36: default voltage is 3.3V
    //
    // the value of this byte depend from the TOUT pin usage (1 or 2):
    // 1)
    // analogRead function (system_adc_read()):
    // is only available when wire TOUT pin17 to external circuitry, Input Voltage Range restricted to 0 ~ 1.0V.
    // For this function the vdd33_const must be set as real power voltage of VDD3P3 pin 3 and 4
    // The range of operating voltage of ESP8266 is 1.8V~3.6V，the unit of vdd33_const is 0.1V，so effective value range of vdd33_const is [18,36]
    // 2)
    // getVcc function (system_get_vdd33):
    // is only available when TOUT pin17 is suspended (floating), this function measure the power voltage of VDD3P3 pin 3 and 4
    // For this function the vdd33_const must be set to 255 (0xFF).
    [107] = 33,

 Copyright (c) 2015 Ivan Grokhotkov. All rights reserved.
 This file is part of the esp8266 core for Arduino environment.

Ich kann da den Ivan nur bewundern...

Gruß aus Berlin
Michael

[Max M. (maxmicr)]

Michael U. schrieb:
> analogRead function (system_adc_read()):
> is only available when wire TOUT pin17 to external circuitry,
> Input Voltage Range restricted to 0 ~ 1.0V.

Genau diese Funktion benutze ich:

  uint16 adcVal = system_adc_read();
  adcVal = adcVal * (3.3/1024) * 100;
  char str[40];
  os_sprintf(str,"%d",adcVal);
  os_strcat(str,"\n");
  ets_uart_printf(str);

Der LM35 liefert ~0.2V (nachgemessen), mit der Formel müsste also 
irgendwas um die 20 rauskommen, stattdessen bekomme ich Werte über 90 
als Wert.

[TestX (Gast)]

3.3/1024 geht schief bei einem uint16!

[Michael U. (amiga)]

Hallo,

adcVal = adcVal * (3.3/1024) * 100;

Wieso (3,3/1024)?
1023 ADC-Wert sind 1V, mehr kann der ja nicht.

PS: (ADC * 100) / 1024 dürfte eher passen.

Gruß aus Berlin
Michael

[Max M. (maxmicr)]

Michael U. schrieb:
> PS: (ADC * 100) / 1024 dürfte eher passen.

Ja, das stimmt, aber nicht ganz (29°C). Ich hatte diese Formel genommen:

Beitrag "Digitalwert des ADC in Spg-Wert umrechnen"

Warum stimmt die nun nicht?

Was ich mich gerade frage: Muss der LM35 keinen Offset haben, da er bis 
-50°C misst und 10mV/°C? Negative Spannungen kann er ja schlecht 
liefern.

TestX schrieb:
> 3.3/1024 geht schief bei einem uint16!

So besser?

  uint16 adcVal = system_adc_read();
  float realVal = adcVal * (3.3/1024.0) * 100.0;
  char str[40];
  os_sprintf(str,"%d",(uint16)realVal);
  os_strcat(str,"\n");
  ets_uart_printf(str);

[Michael U. (amiga)]

Hallo,

ja, Temperaturen munter 0 erfordern eine negative Hilfsspannung und 
entsprechende Potenzialverschiebeung.

Ich habe damals den LM335 genommen, der gibt die Werte auf 0 Grad Kelvin 
bezogen aus, also 0 Grad sind ca. 2,73V. Passte so schön zum AVR, müßte 
man am ESP in einen Spannungsteiler investieren.

Ist aber schon ein paar Jahre her, inzwischen sind mir digitale Sensoren 
lieber, gibt ja genug als 1-Wire oder I2C, meist noch Feuchte oder/und 
Luftdruck als Zugabe.

Ich habe nicht überprüft oder nachgelesen, wie genau die interne 
Referenz des ESP ist und wie genau damit die ADC-Werte sind.
Bei 1k/3,9k als Teiler an meinen Li-IO-Zellen passte es ziemlich gut.

String((analogRead(0) * 5.09F /1000) ,2); passt zumindest ganz gut zu 
meiner Multimetermessung am Akku, ich will ja nur wissen, wann der 
ziemlich leer ist...
Die (Arduino-)Stringaufbereitung nur, weil mir der ESP das sowieso per 
MQTT als Spannung mit 2 Stellen nach dem Komma schickt.

Ja, die 2 Stellen sind auch etwas Augenwischerei, allerdings sind die 
Werte sehr stabil und reproduzierbar, die Tendenz also gut zu erkennen.

Gruß aus Berlin
Michael

[Max M. (maxmicr)]

Ich hab das ganze jetzt mit einem Thermometer "kalibriert". Wenn man von 
einer Referenzspannung von 1.03V ausgeht (laut dem ESP8266 IRC-Webchat) 
kommt man auch auf 28°C (was allerdings um 3°C nicht stimmt).

Leider fällt mir beim Punkt WLAN-Konnektivität das miserable Design 
meines Boards auf die Füße. Zu einem ~8m Luftlinie entfernten Access 
Point kann sich der ESP8266 nicht mehr verbinden "<SSID-Name> not 
found", wenn ich mit meinem Smartphone einen Hotspot aufmache und das 
neben das PCB lege funktioniert es.

Naja, dann wirds wohl irgendwann mal Zeit für eine Version 2.0 des 
Boards.

[Stefan F. (Gast)]

Das ist echt mies. Ich komme mit meinem ESP-01 Modul locker durch drei 
Wände und 15m Distanz.

[Max M. (maxmicr)]

Stefan U. schrieb:
> Das ist echt mies. Ich komme mit meinem ESP-01 Modul locker durch drei
> Wände und 15m Distanz.

Bei mir wurde in einem anderen Beitrag angesprochen, dass es (sehr) 
schlecht ist, wenn das Modul auf Kupfer (in diesem Fall die GND-Fläche) 
liegt, das stört anscheinend die Antennenfunktion ziemlich. Deswegen ist 
bei allen anderen ESP8266-Träger-Boards, die ich bis jetzt gesehen habe, 
entweder kein Kupfer darunter oder die Fläche mit der Antenne ragt über 
das eigentliche PCB hinaus.

Zur Zeit versuche ich, einen HTTP Request zu erstellen, aber das 
Datenblatt ist alles andere als hilfreich, hier wird von einem Struct 
gesprochen, aber nirgendwo steht erklärt, wie der aussieht?

sint8 espconn_send(
struct espconn *espconn,
uint8 *psent,
uint16 length
)
Parameters:
struct espconn *espconn : corresponding connected control block structure
uint8 *psent : pointer of data

[Michael U. (amiga)]

Hallo,

ich drücke es mal diplomatisch aus: das ESP-Modul mitten auf eine 
Leiterplatte packen, so daß es genügend dämpfende Bauteile um die 
Antenne gibt und noch eine Kupferfläche darunter...
Ich packe die Module ja ganz gern auf Lochraster, dann aber so, daß die 
Antenne am Rand liegt und die Lötaugen darunter weggefräst werden.

Ich habe auch den Zweck der Platine noch nicht so ganz begriffen.
Zum Testen macht sich ein NodeMCU sehr praktisch und die fertigen Sachen 
bekommen sowieso nur das Notwendige an das ESP-Modul.

Gruß aus Berlin
Michael

[Stefan F. (Gast)]

Irgendwo habe ich bezüglich des ESP-01 Moduls die Empfehlung gelesen, es 
über ein Stück Flachkabel mit der Hauptplatine zu verbinden, damit man 
es HF technisch vorteilhaft im Gehäuse platzieren kann.

[Max M. (maxmicr)]

Seltsamerweise verbindet sich das Modul mit dem HotSpot des Smartphones 
(das die gleiche SSID und das gleiche Passwort hat wie mein WLAN) aber 
nicht mit dem WLAN, auch wenn es direkt neben dem Router liegt.

Kennt jemand das Problem?

[Sven B. (mainframeosx)]

Ich Arbeite seit ca. 1 Jahr mit diesen ESP 8266 Modulen.

Also dann mal die Aufzählung:

Spannungsversorgung vom USB Serial Wandler muß 3,3 Volt betragen, sonnst 
schiest du den ESP.

Stromversorgung darf nicht vom USB Serial Wandler kommen. Zu Schwach!!!!
Das kann zu Fehlfuntionen führen.

Ich nutze eine LM7833 oder baugleich, die Beschaltung des 
Spannungsreglers sind zu beachten.

Wenn du ein USB Netzteil verwendest , kann das die Übertragung der RS232 
Schnitstelle massiv stören. Kann man mit einem Oszi messen. Habe hiervon 
auch 5 Stück in die Tonne getreten, weil diese von Haus aus schon 
schlecht waren. Hier sollte ein sauberes Schaltnetzteil verwendet 
werden.

WLan SSID niemals die gleiche SSID und Passwort eines anderen WLan 
Routers verwenden.

Ich nutze nun seit 4 Wochen ein ESP8266 HUZZAH mit einem, Arduino und 
einer Wetterstation.
Den ESP hänge ich an mein WLan Router und kann von dort aus per UDP die 
Aktuellen Sensordaten auslesen.
Es gab bisher keine Unterbrechung. Die Daten werden auch nur vom Client 
Abgefragt. Ein automatischen verbinden bei Stromausfall ist auch 
eingebunden.

[Stefan F. (Gast)]

Ich kann das bestätigen. Eine gute Stromversorgung ist Allerwichtigste 
bei dem Chip.

Du brauchst einen Spannungsregler, der mindestens 500mA liefern kann - 
auch wenn die durchschnittliche Stromaufnahme viel geringer ist. Viele 
Schaltnetzteile versagen an der sehr stark sprunghaft wechselnden 
Stromaufnahme. Gewöhnliche Linear-Regler hingegen sind (so weit ich 
weis) alle geeignet.

Ich verwende den LF33CV in Kombination mit Handy Ladegeräten, wobei auch 
ich bemerkt habe dass nicht jeden Handy-Ladegerät geeignet ist.

Ich empfehle, einen 100µF Elko ganz nahe zu den VCC/GND Anschlüssen des 
ESP Moduls zu löten. Damit konnte ich die letzten Instabilitäten 
beheben. Mein Prototyp lief danach zwei Wochen am Stück im Dauer-Test 
ohne Hänger und ohne Reset durch.

[Michael U. (amiga)]

Hallo,

Stromversorgung wurde ja ausreichend auseinandergenommen.
Die China AMS1117 und die MCP1703 machen bei mir keine Probleme, weder 
an LiIo-Zelle noch an nahezu beliebigen USN-Ladern oder 5V 
Steckernetzteilen.
Der 100-220µ Elko gehört bei mir zum Pflichtprogramm, weitere Maßnahmen 
waren noch nicht nötig. Mit 20cm Leitung zum FTDI-USB-Adapter macheen 
hohe Baudraten dann schon Probleme, 921000 gehen meist nur mit dem 
NodeMCU stabil, 512kBit und 256kBit gehen eigentlich immer. Ich habe 
keine Lust, ewig zu warten...

Wenn man die Arduino-IDE nutzt, sollte man den Exeptiondecoder 
installeiren, der kann recht brauchbar dem Stacktrace die Funtionen 
zuordnen.
Serielle Baudrate beim Experimentieren auf 76400 setzen, dann kann man 
auch die Meldungen des Bootloaders lesen, hilft manchmal auch weiter.
Hier laufen mehr als 6 ESP eigentlich ständig seit mehreren Wochen.
Probleme machen definitv meine WLAN-Verhältnisse, wenn die Antwortzeiten 
sehr lang werden verliert der ESP etwas unmotiviert die Verbindung und 
ich habe noch nicht auf allen Modulen die Firmware so sauber drauf, daß 
er den Reconnect mit WLAN und MQTT immer sauber wieder hinbekommt.
Im neusteten SDK soll da was geändert worden sein, das habe ich mir aber 
noch nicht zusammengesucht, da muß ich meinen Bekannten mal fragen, der 
hat sich die Änderungen auch für die Arduino-IDE auf github 
zusammengesucht.

Ich werde da wohl eher warten, bis das halbwegs offiziell ist...

Gruß aus Berlin
Michael

[Max M. (maxmicr)]

Stromversorgung ist kein Problem. Ich hab nun das WLAN vom Speedport 
abgeschaltet und durch einen TP-Link (für 15€) ersetzt, jetzt schafft 
der ESP8266 sogar ein Stockwerk höher (Luftlinie 8 Meter) noch einen 
Connect (wohlgemerkt: mit dem Speedport kam gar kein Connect zustande, 
nicht mal, als ich mit dem Modul direkt davor stand). Wenn ich meinen 
Prototypen in Version 2 in Auftrag gebe (mit korrigierter GND-Fläche) 
klappts vielleicht noch weiter.

[Stefan F. (Gast)]

Das bestätigt meine Meinung dass diese ESP Module noch nicht reif für 
kommerziellen Einsatz sind.

Apropos WLAN Router: Ich habe in 10 jahren 4 Router kaufen müssen, weil 
immer irgendein Gerät nicht funktionierte.

Bei meinem letzten Router konnte niemand mehr eine IP Verbindung 
aufbauen, nachdem mein Sohn sein Smartphone einschaltet. Er hat aber 
kein Problem, und mit der neuen Fritzbox klappt alles.

Ich liebe und hasse WLAN.

[Klaus (Gast)]

Stefan U. schrieb:
> Das bestätigt meine Meinung dass diese ESP Module noch nicht reif für
> kommerziellen Einsatz sind.

Die letzten ESP-12, die ich bekommen habe, waren ein Abschnitt von einer 
Filmrolle. Es muß sich für den Hersteller also lohnen, sie auf Rollen zu 
verpacken und so zu verkaufen.

MfG Klaus

[Max M. (maxmicr)]

Wenn sie funktionieren, sind sie ja super, die kleinen Biester :D