-
Notifications
You must be signed in to change notification settings - Fork 13.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP.deepSleep(xxxx, WAKE_NO_RFCAL) not working since 2.0.0 #3408
Comments
Also tried 2.4.0-rc1, same issue. |
why didn't you post your results on espressif ESP8266 NON_OS_SDK github? Or make a thread on their BBS |
Because it works fine on the NON_OS_SDK. It's an Arduino lib issue. Their tree but it appears abandoned at this point. We've now moved onto NON_OS_SDK thanks for your interest |
but using the system_ ... calls accesses the sdk libs directly. Especially when using system_deep_sleep_instant(); I can't think of which arduino lib should interfere with the correct execution of deepsleep with wake_no_rfcal ... edit: did you try to read the rf_cal byte before the deepsleep call and after bootup? |
I wasn't reporting a issue with the SDK libs being used directly, I was reporting a change in behavior with: ESP.deepSleep(6000000, WAKE_NO_RFCAL) Between Arduino 2.0.0 and later versions The system calls noted were commented out and just my earlier experimenting. The code posted behaved differently between 2.0.0 and 2.3.0 in that you couldn't during off RF Calibration after a wake from a deep sleep, using arduino calls, after 2.0.0 |
according to the starting post
you say that the direct use of system_... has the same problem, this is why I suggested to report to espressif directly. |
I'm not quite sure why you don't understand me This is the Github site for reporting issues with the Arduino port. The issue is with the Arduino command ESP.deepSleep(6000000, WAKE_NO_RFCAL) NOT the system calls even though I had issues calling them from the arduino code. That could just as easily be operator error on my part and I wasn't reporting those. Howver I have confirmed the system call's (i.e. system_deep_sleep_instant(6000000);) work fine directly under the NON_OS_SDK. There is nothing to report to espressif because the SDK is doing what it is supposed to. Sometime after 2.0.0 ESP.deepSleep(xxxxx, WAKE_NO_RFCAL) stop turning off the RF calibration on wake. If you like I can go back and remove all the commented code out of my example. I had just been trying to test various things. |
with the parts I quoted from your OP you say that the same problem exists calling the system_ ... functions (not having problems calling them) leading to the assumption that this might be the root cause. |
For not "couldn't caring less" you sure seemed to want to argue this None-the-less it's a real issue and my testing is solid. That it persisted through a few versions before being reported is irrelevant. Hook your scope up and confirm it yourself if you doubt me |
I can confirm that |
@universam1 @igrr
I can't test on plain sdk to see if its the arduino core or the sdk, most likely some "glue" here it is ok, no spikes on startup |
I have to revert my statement a bit. So with older SDK a mere reboot did work |
Good grief 5chufti, this is what I reported back in July.... |
very helpfull remark ... you didn't report this |
Except it wasn’t until core 2.1.0 that sdk 1.5.1_16_01_08 was integrated.
No worries, just a lot of wasted time here. I’m glad you confirmed it.
…On Fri, Jan 5, 2018 at 4:56 AM 5chufti ***@***.***> wrote:
Good grief 5chufti, this is what I reported back in July....
very helpfull remark ...
you didn't report this
*It works with core 2.0.0 & sdk 1.3.0_15_08_10_p1 it stops working on core
2.0.0 & sdk 1.5.1_16_01_08*
and I think it is relevant
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3408 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGCmg-g6haYW8v1zpSJvMpWXVuh6kv_5ks5tHfG3gaJpZM4OR9Aw>
.
|
@wb8wka I assume this is still relevant after 2.4.0 release, and I also assume you erased the whole flash before upload. You said there is no issue with using only the NONOS SDK system calls. Is this true when using pure system calls from within a simple sketch, or did you mean from a NONOS SDK standalone build without the Arduino core? Could you please pist an example? |
@devyte That would be my guess. 2.4.0rc1 I tried and it the issue was still there, Reviewing the change log for 2.4.0 I see no mention of a fix. I meant it worked with the NONOS SDK standalone build Here is a little clip
|
I think I have a fix for this, but need some time to set up a current measurement jig... |
@igrr did you get somewhere with your investigations? |
@igrr any news on the issue? Maybe some pointers for workaround? |
@wb8wka have you tried something like this?
|
It would be great to get a fix for this @igrr , could we help by testing out the fix you think you have?
|
or even any hints at what the possible fix mentioned here - #3408 (comment) - could be so we could try to implement the fix ourselves? |
I'd so much like to find a fix for this. Could anyone give any hints on where abouts in the code I could be looking for the problem? |
Any news on this issue? This is critical for battery power applications. Regards, |
@igrr sorry to keep pestering I know you must be busy on things but you did say earlier you thought you might know the cause of this so could you give any hints so we could try to find some fix? |
A hint on the root cause will be very usefull. On the other hand a possible work arround would be to modify the 108th byte of the init data (defined in core_esp8266_phy.c) and set it to 255. In principle this will make a call woth WAKE_RF_DEFAULT to calibrate the radio only once every 255 reboots from sleep. Is there any way to change this byte without patching the core? If not it could included with a similar macro to ADC_MODE/RF_MODE. |
It seems difficult to work this out with out any doc on what the rtc reg 24 and 30 are supposed to be for.
Appears to get RF_CAL to run again. But both rtc_reg[24] and rtc_reg[30] are xFFFFFFFF on wake up no matter what sleep mode was used to put the ESP to deepSleep. |
I came late to the party and so I am having a hard time replicating what is ben reported. It would be helpful to have one common set of code against everyone is testing. This way if there are different results for some reason it can be nailed down why that is. |
@Ivoatme the sketch I use for timing an esp-now sensor is here: https://github.com/HarringayMakerSpace/ESP-Now/blob/master/espnow-sensor-timing/espnow-sensor-timing.ino For me that outputs:
with slight variability in the 'now' time going to 30 or 31 ms sometimes. Would be interesting to have someone with a scope do a complete plot of the power usage and timing of the entire wake-send-sleep cycle. Or also see if there are any other savings somewhere, maybe removing all the use of Serial? |
Great example @torntrousers! One caveat, running at 160Mhz has no point here as the task is mainly IO waiting time. Have in mind that a esp (with RF disabled consume 20mA at 80Mhz but about 35mA at 160Mhz). To ilustrate the net effect, lets say that the gain of executing at full speed is 10m less time that running at 80Mhz. Then it would be detrimental for the battery life;
as you can see the extra power consumed at 160 Mhz will offet the speed gain of 10ms. The same argument affects the flash chip, it will consume more at 80Mhz. Here will depend on the actual chip and mesurement will be needed on your specific board. Also there cheap versions of the ESP12 that have trouble with 80Hz as they use low quality. I suposse that using QIO will be power neutral it only using a pair of addtional datalines to speak with the flash. The problem is that not all ESP boards out there implement QIO. |
Good point @ludiazv . And trying now the faster speeds don't actually make much of a difference now anyway, i think when I tried them before it was with bigger sketch and rf_cal running. |
Here is complete current plot of @torntrousers https://github.com/HarringayMakerSpace/ESP-Now/blob/master/espnow-sensor-timing/espnow-sensor-timing.ino |
Several observations here...
|
RF_CAL seems to be working fine if any changes to rtc_reg are disabled completely. That's how user_rf_pre_init() looks in my setup:
|
All, I'm now a bit lost with regard to which code is best for low power, or which set up is best, etc. At this time I'd like to ask you for a PR with an example sketch for lowest power, so that we can include it as part of the repo, and use it as basis for enhancements to the core api. We can continue to discuss what works better, or in which cases, in that PR, adding comments to the sketch as appropriate, including why certain inits are needed. |
@mailgpa just tested your suggestion with @ludiazv s sketch using ESP.deepSleep(2000000, WAKE_RFCAL)
unfortunately even using the diverse api functions in RF_PRE_INIT() does not affect the RF_CAL behaviour at startup in current 2.4.2 |
@torntrousers right now we have nothing, so any example you can add would help. More than one example, if there's more than one use case. |
All, what is the status here? Leaving the requested examples aside, are there any code changes needed here? |
Ok let me have a look over the weekend. |
I think further investigation and discussion is needed here. |
Ran into this today. Arduino IDE 1.8.5 (I don't like being on the bleeding edge) and board file version 2.4.1. The following DOES work for me (with the affected ESP.deepSleep calls removed)
|
@JamesNewton To confirm: you're saying it doesn't work with the ESP. deepSleep() call, but it does work with the direct sdk system_deep_sleep*() calls? |
Yes... "The following DOES work for me (with the affected ESP.deepSleep calls removed)" |
can you elaborate on what exactly is working?
as both of these lines may not be working for a reason:
|
How on earth is it not clear? The lines commented out do NOT work, the lines in the program that are not commented out DO work. |
@Tech-TX nice work untangling this. |
Summary
RF Calibration cannot be turned off after 2.0.0 in wake from deepSleep causing current spike and longer boot
Hardware
Hardware: Wemos D1 mini and ESP-12S, 470uf cap between Vcc and Ground
Core Version: 2.0.0 (works - No RF Calibration current spike), 2.3.0 (Not working, current spike)
Test equipment: Rigol Scope, 1ohm current shunt, "fuzz" is because I didn't do calibration on scope but traces are accurate.
Description
Using identical code function ESP.deepSleep(6000000, WAKE_NO_RFCAL); in 2.0.0 ESP can wakeup without large current spike from RF_CAL, however after 2.0.0 RF_CAL executes causing large current spike and longer run time. Please see attached current traces. Correct data is sent in both instances, only different is current spike, which appears to be RF_CAL executing.
Sketch sends simple beacon using wifi_send_pkt_freedom. GPIO16 connected to reset.
WAKE_RF_DISABLED does behave as expected in both 2.0.0 and 2.3.0
Also
has same characteristics in that it cannot turn off RF_CAL
Settings in IDE
Module: WeMos D1 Mini & ESP-12S
Flash Size: 4MB
CPU Frequency: 80Mhz
Flash Mode: qio
Upload Using: SERIAL
Images
Version 2.0.0 without RF_CAL current spike at head
Version 2.3.0 with RF_CAL current spike at head
Sketch
The text was updated successfully, but these errors were encountered: