Left here for archival purposes.

User avatar
By epsoc
#10294
GeoNomad wrote:
GeoNomad wrote:I will add a pullup on GPIO0 and try again. But GPIO0 low would normally enter flash programming mode, not zombie mode


I can confirm that awaking from sleep, GPIO0 low causes zombie mode and not UART flash mode, which is what happens on a power reset. Interesting that it is different and makes me wonder what else is different between a full power reset and a reset from sleep mode.

So, recommendation is now that both GPIO0 and GPIO2 MUST have pullups on them to reliably awake from node.dsleep(). 2K to 12K seem to be advised by different sources.

it is possible that UOTXD and MTD0 also require being pulled up or down for total reliability. I don't believe MTD0 has a connection on the ESP-01, but then the ESP-01 is not designed for sleep as there is no jumper for pin 8 to 32...



In an RF environment I'd like to keep the pins pulled pretty good. 10k+ seems to me to be on the high side. I mostly use 4k7 (or close to that) on the ESP8266 to be reasonably safe. 2k only if I consider it critical (e.g. exposed long pcb trace or wire on pin etc).
I have no problems anymore.Attached a screenshot of an ESP8266-03 recording its own battery voltage (LiPo w/ small solar cell). 1 min sampling and upload to server w/ deepsleep. (subtract approx. 0.2V because of GPIO for GND).
Attachments
Screen Shot 2015-02-20 at 4.30.00 PM.png
ESP8266-03 recording its own battery voltage (LiPo w/ small solar cell)
User avatar
By GeoNomad
#10295
epsoc wrote:
GeoNomad wrote:
GeoNomad wrote:In an RF environment I'd like to keep the pins pulled pretty good. 10k+ seems to me to be on the high side. I mostly use 4k7 (or close to that) on the ESP8266 to be reasonably safe. 2k only if I consider it critical (e.g. exposed long pcb trace or wire on pin etc).
I have no problems anymore.Attached a screenshot of an ESP8266-03 recording its own battery voltage (LiPo w/ small solar cell). 1 min sampling and upload to server w/ deepsleep. (subtract approx. 0.2V because of GPIO for GND).


There is sense in what you say. Although I would hope the radio doesn't turn on until after the pins have been tested...

So what values do you have on GPIO2 and GPIO0 for this test?
User avatar
By epsoc
#10301
GeoNomad wrote:There is sense in what you say. Although I would hope the radio doesn't turn on until after the pins have been tested...



I agree, you would think so. But we don't really know when the radio kicks in and when pins are evaluated. But in general, regarding pin states in an RF environment (including after startup) I'd like safe pulls. With all the tests I did (touching parts of your test circuit in operation with your fingers are still a great way to test it), it was my very strong impression that RF did have an influence on the initial state of the GPIOs.
IIRC, the datasheet states 3V minimum for the radio power supply and down to 1.7V for digital power supply, which seems to imply that the radio shouldn't have an impact on the pin states at that time. Although that doesn't mean too much as to when pin states are evaluated in the process.

As for my current pull-ups (just for this test circuit, whatever I had flying around):
GPIO0 - none (the final design will definitely get a 4k7)
GPIO2 - 5k6
RST/GPIO16 - 5k6
CH_PD - 2k2 (I use it right now for reset)

In my final design I plan on using 4k7's for the 5k6's

Derk
User avatar
By epsoc
#10303 I also record the uploaded sample interval. Attached a graph of sampling periods over time corresponding to the Voltage graph above. The few misses are multiples of the 60 s sampling interval, so are most likely short network reachability problems (I am on Frontier, brief network 'outages' during the day are common).
The one very short interval at 8 in the morning is due to briefly shorting the power supply while adjusting the little solar cell w/ associated reboot and immediate upload. So I guess I cheated and didn't run continuously.

Derk
Attachments
Screen Shot 2015-02-20 at 6.21.46 PM.png