Skip to main content

ESPCLOCK 3.1

Here are the latest changes to the ESPCLOCK3 project.

Migration to PlatformIO

I have moved to PlatformIO for new projects, and migrated some of my older projects to PlatformIO as well. PlatformIO offers a lot of advantages over the Arduino IDE, including:

  • Intellisense quick info and code completion
  • Easy to target specific library versions in platform.ini
  • Easy to have multiple targets in the same project. For ESPCLOCK, this means target for ESP8266 and ATtiny85 in the same project.

There are minor pitfalls though. For example, to set fuse settings for ATtiny85 (eg. 1MHz clock, retain EEPROM, disable BOD), they have to be manually computed and added to platform.ini. This was not very intuitive and took me some time to figure out.

Dealing with low battery

In the original design, the ATtiny85 checks the VCC voltage level and writes vital info to EEPROM when voltage falls below 2.8V. 

The problem is, the discharge characteristics of NiMH battery is such that it operates at ~1.2V for most of its effective life, followed by a sharp fall. Common advice is not to let the voltage fall below 1V, at which point the battery is almost completely spent.

So I made a change by adding a voltage bridge to the ADC pin of the ESP8266 to read the voltage of the battery pack:

The input voltage range of the ADC pin is 0 - 1V. By using the voltage bridge, and assuming worst case of using 4 x AA akaline (1.55 nominal voltage), the maximum voltage to the ADC pin is (1.5 x 4 x (10 / 57)) = 1.05V. To compute VCC, simply reverse the equation i.e. VCC = ADC * 57 / 10.

In my code, I try to get a more accurate result by discarding the first ADC reading, then averaging the next 8 readings.

float getSupplyVoltage() {
  int sum = 0;
  analogRead(A0);
  for (int i=0; i<8; i++) sum += analogRead(A0);
  sum = sum >> 3; // divide by 8
  float ratio = sum / 1024.0;
  return ratio * 57.0 / 10.0;
}

So the ESP8266 will compute the supply voltage every time it wakes up. If the supply voltage falls to 4.2V (~1.05V on each AA battery), it turns off the RTC clock signal and sleeps indefinitely.

The ATtiny85 no longer uses the ADC to detect low power condition. Instead, it checks that the incoming clock signal is not longer present and stops the clock. This means we can turn off the ATtiny's ADC, which should help save 0.2mA.

Stuck SDA on the I2C bus

During tinkering, I found that occasionally the ESP8266 will wake up and find the SDA line on the I2C bus stuck low. I suspect the problem is nicely summarized on this page, but I am not 100% sure. Getting to the root of the problem is, I think, beyond my current expertise.

I ran an experiment whereby the ESP8266 wakes up every  5 minutes and scans the I2C bus. Out of 1240 wakes, there were 125 times where the SDA line was stuck low. The code then attempts to clear the bus using the I2C_ClearBus() function found in the web page above. I tried 2 approaches:

1. Repeatedly call I2C_ClearBus(), wait 5 secs, initialize I2C again by calling Wire.begin(), then scan the I2C bus.

2. Call I2C_ClearBus(), deep sleep for 1 minute, then wake up and run the setup routine again.

Method (1) did not produce the desired result. Maybe the wait time was not long enough. Almost always, the I2C bus did not recover.

Method (2) did succeed with bus recovery. Most times, the I2C bus recovered within the minute. However, there were times when this went on 10 to 20 times before the bus recovered. In the worst case, 62 attempts (62 minutes) were required before the bus recovered. However, the good news is the bus always eventually recovered. Never once did the bus stayed permanently stuck, unlike (1).

Strangely, during actual runs which default to 2-hour interval between wakes, I was unable to obtain the same result. Mathematically, the occurrence rate should be about 10%, yet after a few hundred intervals, I did not observe a single stuck SDA. Not sure why, but I will continue to monitor the outputs. Also, just to be safe, I have incorporated the same I2C_ClearBus() routine anyway into the production code. If the bus is stuck, the ESP8266 calls I2C_ClearBus(), deep sleep for 1 hour, then wake up and try again.

Update: Spoke too soon. I have now started to observed occurrences of stuck SDA, with the worst case of 7 consecutive observations before resolution. 

Update #2: Switch back to calling I2C_ClearBus() at 5-minute intervals after stuck SDA detected.

Phantom power

Apparently, this is a common problem with I2C bus where multiple power sources are present. In this case, the ATtiny85 is powered by a supercapacitor. so when the battery power is removed, the SCL and SDA lines on the bus are still powered by the ATtiny85 aka. "phantom power"

These are my observations for the ESPCLOCK3 circuit with respect to phantom power.

For the ESP8266, due to phantom power, VCC is maintained at some residual voltage when battery power goes down. This may result in the ESP8266 not booting up at all when battery power is re-applied. The workaround to this is to press the reset button briefly to reboot the ESP8266.

For the RTC, what happens is the clock signal does not stop immediately when battery power is removed. Instead, it continues to supply the clock signal for a further 8~10s before dying down The result is the physical clock may continue to run for up to 15~18s when battery power goes down (10s for clock signal to stop, and 8s before WDT on the ATtiny85 triggers to check).

Power consumption

With the new setup (add voltage divider hardware, remove VCC voltage check from ATtiny85, add battery pack voltage check to ESP8266), the power consumption is between 1.20mA to 1.24mA, pretty much on par with before.

Note: The latest code and schematic has been updated on Github.








Comments

Popular posts from this blog

Adding "Stereo Mixer" to Windows 7 with Conexant sound card

This procedure worked for my laptop (Thinkpad E530) with a Conexant 20671 sound card, but I suspect it will work for other sound cards in the Conexant family. I was playing with CamStudio to do a video capture of a Flash-based cartoon so that I can put it on the WDTV media player and play it on the big screen in the living room for my kids. The video capture worked brilliantly, but to do a sound capture, I needed to do some hacking. Apparently, there was this recording device called "Stereo Mixer" that was pretty standard in the Windows XP days. This allowed you to capture whatever was played to the speaker in all its digital glory. Then under pressure from various organizations on the dark side of the force, Microsoft and soundcard makers starting disabling this wonderful feature from Windows Vista onwards. So after much Googling around, I found out that for most sound cards, the hardware feature is still there, just not enabled on the software side. Unfortunately, to

Attiny85 timer programming using Timer1

This Arduino sketch uses Timer1 to drive the LED blinker: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 /* * Program ATTiny85 to blink LED connected to PB1 at 1s interval. * Assumes ATTiny85 is running at 1MHz internal clock speed. */ #include <avr/io.h> #include <avr/wdt.h> #include <avr/sleep.h> #include <avr/interrupt.h> bool timer1 = false , led = true ; // Interrupt service routine for timer1 ISR(TIMER1_COMPA_vect) { timer1 = true ; } void setup() { // Setup output pins pinMode( 1 , OUTPUT); digitalWrite( 1 , led); set_sleep_mode(SLEEP_MODE_IDLE); // Setup timer1 to interrupt every second TCCR1 = 0 ; // Stop timer TCNT1 = 0 ; // Zero timer GTCCR = _BV(PSR1); // Reset prescaler OCR1A = 243 ; // T = prescaler / 1MHz = 0.004096s; OCR1A = (1s/T) - 1 = 243 OCR1C = 243 ; // Set to same value to reset timer1 to

Hacking an analog clock to sync with NTP - Part 5

This is how it looks after I have put everything together. The Arduino sketch is available here . The 2 jumper wires soldered to the clock mechanism are connected to pins D0 and D1 on the ESP-12 (in any order). When the device first boots up, it presents an access point which can be connected to via the PC or smartphone. Once connected, the captive portal redirects the web browser to the configuration page:     A custom field has been added to the WiFi configuration page to enter the current clock time in HHMMSS format. Try to set the clock time to as close to the current time as possible using the radial dial at the back of the clock so the clock will have less work to do catching up. In the config page, the HTML5 Geolocation API is also used to obtain your current location (so if your web browser asks if you would like to share your location, answer "yes"). This is then passed to the Google Time Zone API to obtain the time and DST offset of your time z