Closed Kater432 closed 1 year ago
Do you also have some log of the measured battery voltage?
No, i don't. But at night (it is dark ;-) ) there is a cut at around midnight, and then the next hours, no problem. if the battery had a problem, must it the hole night, or ?
next day i will try a ip over dhcp, not a static one. i also tried the "sleep awake time" to increase, but it doesn't help.
first i have an old version from may 2018 on the esp, there was the problem much more, then i read a solved issue here and upgrade it. now it is much better, but also there
No, the thing I'm thinking about is the RF calibration made when starting WiFi. This RF calibration is internally using the voltage supplied to the node. So if you're performing a successful RF calibration, you could also try to connect the next time and skipping the RF calibration. When running on battery power, this means it will start to fail (when skipping RF calibration) to connect to WiFi after a number of wake-ups due to the fact the battery will have a lower voltage as it is being emptied.
Turn this given fact around and you'll see the RF calibration may give incorrect results as soon as the voltage is not constant during this calibration. This can happen if your power supply is not stable or not powerful enough. So if you're running on a battery being charged by a solar panel, the supplied voltage may be fluctuating more during the day.
Not saying this is the problem, but it is something I was thinking about. Maybe I should add a setting to disable RF calibration on some occasions. (e.g. after successful reconnect + deepsleep) It will also save energy used during the awake time since RF calibration takes time and also has a short but high current peak.
Maybe also a shorter sleep after an unsuccessful connect attempt would help here.
i will try another esp8266 with espeasy with a local power supply (without a HC-SR04) and send only sys Data per UDP, but with the same deep sleep config.
but why, when the rc calibartion fail, i can see the arp request from the device. is the calibration not before the send of data over wlan ?
it the rc calibration after deep sleep necessary ?
I think the RC calibration is not needed so often, but at least every now and then and after a reconnect failure. It is however the default when trying to connect to WiFi.
I am not entirely sure what it does during this RC calibration, but I can imagine it may also affect RX capability, so it may still send an ARP request, but that doesn't mean it is receiving the answer. It is also possible this not receiving the answer is caused by something else.
What version of the arduino core is this based on ? Best would be to try again with git head or 2.5.0-beta2. Espressif firmware has beenupgraded since may 2018. You may find it useful to follow up this discussion on arduino core issue tracker.
@d-a-v Build ESP_Easy_mega-20190109_normal_ESP8266_4096.bin is based on core 2.4.2 Most likely ESP82xx Core 2_4_2, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3
maybe it is a problem with the power supply (akku). perhaps it is a problem with the temperature and the peak current at calibration at start. last night is was colder and there was much more problems.
in the wireshark i can see the DHCP discover (first request at dhcp process to catch a ip), but a long time no answer from the fritzbox (wireshark ist on a raspberry) why no answer, i dont know.
at 3:17 the discover and the answer from fritzbox is there, but not the next "gratuitous arp". this is to check if the ip is free.
at 3:32 is the normal phase, dhcpdiscover, request and then the arsp und the udp data
my other esp8266 (this is a nodemcu) with power supply (not battery) ist since yesterday afternoon without problems. but it is much closer to the wlan fritz box.
i will check the battery problem when it is a little bit cozy outside. then i will put a 5v battery pack with 10000mA there or i test a capacitor parallel to the battery / 3,3V input ath the esp8266 to puffer the peaks at start
Espressif has a reference design to use their modules. They advice to have a 10 uF + 100 nF capacitor as close as possible to the 3V3 pin(s) of the ESP. On the NodeMCU you can see the 10uF quite easy, since it is a yellow block. The 100 nF is hard to distinguish among other SMD parts. If you've made your own PCB using an ESP12F for example, you should check if it is there. In my own projects I also have a 470 uF capacitor on the 5V leading to the NodeMCU or Wemos d1 mini, whichever one I use. This allows to overcome the peaks. Still if the PCB traces carrying the power are too thin, they may introduce a significant voltage drop proportional to the current being used.
One other thing could be the antenna. The design of the antenna is rather critical and anything near it may affect the resonant frequency. For example the thickness of the PCB does affect the shape/dimensions of the PCB antenna trace. If there is ice on the enclosure, it may also have an effect on the antenna's performance.
it is a wemos d1 mini with the ultrasonic modul and the solar powered battery 3,7v. the 3,7v battery is direkt connected to the 3,3v and gnd of the wemos. the other one is a NodeMCU ESP8266 ESP-12E
How do you prevent the voltage to the ESP to get over 3.6V? I thought that was the max. of the ESP8266. Or do you use a Wemos d1 mini pro, the new one with a "Lipo" input plug?
No, the Battery with 3,7V ist direct at the 3.3V Input at the Wemos. It ist not the NewOne. I read this somewhere, that it is possible to connect it direct.
It looked like a power problem AND i think the wemos has now a malfunktion.
i use 1000uF capacitor on the 5v to ground and it works much better with the solar powered Lion Battery. With a USB Power Bank ist works fine. I ordered also a ne Li-Ion and a charged TP4054. Then i only use the solar panel from the solar LED lamp.
since the 4.2V on the 3.3V Input the Wemos had now 10mA Current in DeepSleep. My first testing of the current, was about < 0.5mA. i think i 'grilled' the Wemos with that. It works, but with to much current. Now i receive a new one, i put the PowerBank and the Ultrasonic Modul on that ohne an in DeepSleep now 0,1mA.
I experimented with the HC-SR04 Ultrasonic and powering it over a GPIO Pin. Because with direct 3.3V the current was 2mA more. Now the Ultrasonic direct connected on D5 (Output High), D6 Output Low as trigger, D7 Input as Echo and Ground. The Ultrasonic Modul is a new one with 3.3V - 5V, so i don't need the tow restistors an i can connect it direct.
How much current does the HC-SR04 take? (startup may be higher) You may want to add a FET to switch the power to that sensor and then trigger that FET via a GPIO pin.
And the charging of the Li-Ion battery may have some peaks which are higher than 4.2V I guess adding one or two germanium diodes in series with the ESP will help getting it in range of 3.3 - 3.7V
for charging i bougth the TP4054 Board, it had a Input for the solar panel and a connection for the battery and a connection for the output. i connect the output to the 5v input on the wemos. there is the Me6211 regulator for a input range from x to x V. DropOutVoltage by 100mA is about 100mV, that means round about input 3.5V is enought.
the HC-SR04 had a max of 15mA in the specs i read. when it is connected the current of the wemos dont increases. i know that the gpio max 12mA had, but i try it with this one. i think the other wemos hat a problem with the 4.2V on the 3.3V input for the long time.
That Me6211 is a nice one to know :) Did you happen to make a board for these, or are you just combining standard boards from Ali Express using these components?
i bought excatly this board version over ebay from china. https://www.ebay.de/itm/Wemos-D1-Mini-V3-0-0-WIFI-Internet-of-Things-ESP8266-CH340-4MB-Development-Board/232741420953?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
this wemos V3 Version had the ME6211 regulator. before i had another version with another regulator.
This issue is no longer relevant, and can be closed.
Hello,
i have a Wemos D1 Mini ESP8266, with a HC-SR04+ Ultrasonic Modul (3,3V Version) The ESP8266 works with a solar powered 3,7V Batterie and works almost fine. Deepsleep is activated (900sec Sleeptime, and 5sec until it goes to DeepSleep. the ESP8266 wake up every 15minutes and send the data UDP to my loxone (and parallel to a Raspberry for wireshark Trace).
The Problem is, that sometimes no Data a registered at the Loxone. Until 31minutes no Data receive, it activate Default Value and the error output in the Loxone.
In the wireshark Trace i see allways, that the ESP make a "Gratuitous ARP", then ask ARP the two IPs and then receive the MAC from the device per ARP answer. (Time 6:58) Then they send per UDP the Data, in the wrong case, no data are send, only more ARP request are send. and then after 6sec they go to deepsleep. (time 6:43)
What ist the Problem ? Sometimes 10h without problem, sometimes more often. First time i think, that the ESP8266 cannot connect to the WLAN, but witj the wireshark trace, that can not the problem.