ESP8266 Community Forum

- Sun Nov 08, 2015 7:42 pm #33505

Does the ESP8266 not include a built in RTC? If so it would most likely be based on the Cadence IP defined here. Assuming that it exists, and that the on-board RTC is powered from the same source as the main processor, does this not make an additional RTC redundant?

Nope, not redundant in my view. The main purpose of using an external RTC - and the original purpose of this thread - was to develop a circuit that would power up the ESP8266 and related circuitry and various intervals. After doing its thing, the ESP would then shut itself off. The RTC would then turn things back on for the next interval. The idea being to have some very long lasting batteries as you would be drawing juice only when the ESP826 needed to do its thing and then only briefly. This could, potentially surpass even deep sleep type low power solutions.

The power circuit that I arrived at has already appeared earlier in the thread and it represents improvements based on some comments from some contributors. It is working just fine and I am close to actually doing a long term test.

Also, while some would call this a classic solution, my approach is to share the schematics and code out for anyone to use and improve.

- Sun Nov 08, 2015 8:35 pm #33507 UPDATE: So this is where I am at with the project. Again, it's not much of an excuse, but I have such limited time to work on this I am always feeling like it is taking too long. But, in fact, I am learning quite a bit as it goes...and it goes pretty well...I think.

The RTC is an MCP79410. Off the shelf and very cheap. Earlier in the thread, I posted a picture of the home brewed board, and the schematic I used is straight from an application note (AN1365, appendix B). Really, the only differences are the values of a few components. I used 2.2k pullups on the I2C lines because that is what I had. Also, the RTC is the *only* device that will have pullups. Looking at my notes, I ended up with a 4.7K instead of 10K resistor and for the diode I used a BAT43. The caps on the crystal that I used are 10 pf because that is what I saw used in AN1355. The RTC is working well and I am sure that there are others that would also work well. I like soldering my own boards sometimes, so I went this way instead of using one of the DS boards that are ubiquitous.

Software for the RTC right now is my own writing. I couldn't find a full blown library and I really didn't look too hard. From the MCP79410 data sheet I could figure out what I needed to set the time, set an interrupt alarm and clear it. There is admittedly more on this chip and I may get to that stuff at some time.

The sensors worked out pretty well. I am using an ESP8266-11 - not a lot of GPIO on that one. So, GPIO0 and GPIO2 serve as SCL and SDA for the I2C. The ESP8266Arduino interface is working out very well.

For the temp and humidity, I already had interfaced an HTU21D on a Galileo so I used that board. The software for that is taken almost completely from the public domain (beerware actually) posted by Nathan Seidle at Sparkfun.

For the light intensity, I used a BH1750 - again an I2C device that I had previously used. I actually did write some simple code because the examples I found, and there are many out there, did not use the highest resolution. Nevertheless, it was pretty trivial.

I have nothing against Thingspeak, but it does not interest me. I want the ESP8266 to log on to my server, send the packet and power off. I want my server (right now working with a WIN7 implementation) to be listening all the time and log the packets. My knowledge of Visual Studio (VB etc..) is weak and archaic. But it was relatively easy to use examples from MSDN to work up a simple TCP listener and to make matters very simple, right now the code writes the packets to a file - which I can process as I see fit. The simple text file ends up looking like this:

11,8,2015,9,42,0,7,23.44,37.96,63.75
11,8,2015,9,43,0,7,23.44,38.13,63.75
11,8,2015,9,44,0,7,23.46,37.88,62.50
11,8,2015,9,45,0,7,23.47,37.69,62.92
11,8,2015,9,46,0,7,23.49,37.96,62.92
11,8,2015,9,47,0,7,23.50,38.11,81.67
11,8,2015,9,48,0,7,23.53,38.23,214.17
11,8,2015,9,49,0,7,23.54,38.01,217.92
11,8,2015,9,50,0,7,23.55,38.00,217.92
11,8,2015,9,51,0,7,23.55,37.83,218.75
11,8,2015,9,52,0,7,23.56,37.82,219.58
11,8,2015,9,53,0,7,23.58,37.78,218.33
11,8,2015,9,54,0,7,23.59,37.89,218.75
11,8,2015,9,55,0,7,23.60,37.98,217.92
11,8,2015,9,56,0,7,23.61,37.91,216.67
11,8,2015,9,57,0,7,23.61,37.69,215.83
11,8,2015,9,58,0,7,23.62,37.62,215.83
11,8,2015,9,59,0,7,23.64,37.69,215.42
11,8,2015,10,0,0,7,23.65,37.54,214.58
11,8,2015,10,1,0,7,23.66,37.59,214.17

On to the packet itself. The figure shows the approach I am taking right now although it may change. Very simple and straightforward - comma delimited values.

For testing, I am running 1 minute intervals although I am finding out that my ISP, AntiVir and or Router are not crazy about 100s of logins in a short period of time, but I am pretty sure that it has nothing to do with the ESP code (a longer explanation is required but it has been looked into). Speaking of that, generating a simple TCP client for this application is pretty much like all the applications that you see. Because I am powering off the ESP after sending, I am not burdened by maintenance cleanup. Of course, it has to power down if it can't log in and send the packet (can't sit there forever) for some reason, but that was trivial and it is so far so reliable that I had to turn off the listener for testing.

That's where I am at right now, I will keep all updated and I am fine sharing the code on any of this - especially after I "unslop" it Just ask.

Cheers,

DrG

edited to include the correct jpg

Last edited by DrG on Sun Nov 08, 2015 9:13 pm, edited 1 time in total.

- Sun Nov 08, 2015 8:40 pm #33508

Does the ESP8266 not include a built in RTC? If so it would most likely be based on the Cadence IP defined here. Assuming that it exists, and that the on-board RTC is powered from the same source as the main processor, does this not make an additional RTC redundant?

Nope, not redundant in my view. The main purpose of using an external RTC - and the original purpose of this thread - was to develop a circuit that would power up the ESP8266 and related circuitry and various intervals. After doing its thing, the ESP would then shut itself off. The RTC would then turn things back on for the next interval. The idea being to have some very long lasting batteries as you would be drawing juice only when the ESP826 needed to do its thing and then only briefly. This could, potentially surpass even deep sleep type low power solutions.

The power circuit that I arrived at has already appeared earlier in the thread and it represents improvements based on some comments from some contributors. It is working just fine and I am close to actually doing a long term test.

Also, while some would call this a classic solution, my approach is to share the schematics and code out for anyone to use and improve.

DrG, your approach does have many distinct advantages, not the least being that it uses easy to source parts, and well documented code, however it would certainly be useful to explore the built in RTC in greater detail, in case it can be pressed in to service, potentially saving component count, pin count and complexity.

The problems I have uncovered in my brief trawl round the internet for information on the ESP8266's built in RTC, do not however paint a very clear picture. Furthermore, some of the pins required to use it, may not be brought out on most boards. VBat and the RTC oscillator input for example. I'll keep trawling however and see if I can make any sense of what I find, in particular I'll see if there is any similarity between the Cadence documentation and any info for the ESP8266.

- Sun Nov 08, 2015 8:44 pm #33509

Hi Andy,

Glad to see you here !

Hi Martin, I'm late to the party as always it seems

For the ESP8266 RTC, unfortunately, Espressif never give much details about it. In fact, RTC means here more Real Time Counter than Real Time Clock. Although, I didn't verify myself, some people reported that this counter is even reset to zero when waking up from deep-sleep.

That might be simply because it has no battery backup perhaps.

Also, most softwares are only using the SDK function system_get_rtc_time(), but not much more, although there are some other functions to access registers, but since no docs are provide for them, it is difficult to run in the fog.
I hope that with ESP32 things will become clearer and that we can get a real RTC with a VBat pin.

I wonder if I can marry up the registers with the cadence IP docs. or at least try to make some sense of the registers, starting with this little lot.

Code: Select all#define PERIPHS_RTC_BASEADDR        0x60000700
//RTC reg {{
#define REG_RTC_BASE                PERIPHS_RTC_BASEADDR
#define RTC_SLP_VAL                     (REG_RTC_BASE + 0x004) // the target value of RTC_COUNTER for wakeup from light-sleep/deep-sleep
#define RTC_SLP_CNT_VAL                 (REG_RTC_BASE + 0x01C) // the current value of RTC_COUNTER
#define RTC_SCRATCH0                    (REG_RTC_BASE + 0x030) // the register for software to save some values for watchdog reset
#define RTC_SCRATCH1                    (REG_RTC_BASE + 0x034) // the register for software to save some values for watchdog reset
#define RTC_SCRATCH2                    (REG_RTC_BASE + 0x038) // the register for software to save some values for watchdog reset
#define RTC_SCRATCH3                    (REG_RTC_BASE + 0x03C) // the register for software to save some values for watchdog reset
#define RTC_GPIO_OUT                    (REG_RTC_BASE + 0x068) // used by gpio16
#define RTC_GPIO_ENABLE                 (REG_RTC_BASE + 0x074)
#define RTC_GPIO_IN_DATA                (REG_RTC_BASE + 0x08C)
#define RTC_GPIO_CONF                   (REG_RTC_BASE + 0x090)
#define PAD_XPD_DCDC_CONF               (REG_RTC_BASE + 0x0A0)