TTGO 2020 V1 Notes

Schematic Diagram · Library Source Code · ESP Arduino · My Watch Source


Native libraries used by TTGO Watch

TFT Library


Helpful Examples

FreeRTOS taskNotify mailbox · Queued Serial Port Task · Basic Digital Watch


Notes

Power Conservation

  • Out of the box the watch will consume ~140mA running most of the example code

Backlight / Display power off

  • Disabling the backlight with watch->closeBL() will save almost 90mA
  • Sleeping the display with watch->displaySleep() saves another 8-10mA

I’m able to get something close to 50mA standby current with the display off and processor at full speed reading the touch interface – touch to wake works well in this configuration.

Processor Configuration

  • 40mHz crystal clock, validated with getXtalFrequencyMhz()
  • Valid processor frequencies: 240, 160, 80, 40, 20, 10
  • Switching processor frequencies frequently messes with everything and will stall the watch.

Set clock speed with setCpuFrequencyMhz(160). Downscaling the CPU helps a bit with power usage but not as much as I’d expected. With the [basic pong game][1] running, I observe these numbers. There’s enough noise in the numbers that the moving window average is still chaotic with a window size of 50 samples. I measured these while the watch was plugged into USB power.

Frequency min mA avg mA max mA
10mHz 43mA 110mA 245mA
20mHz 35mA 115mA 247mA
40mHz 34mA 115mA 243mA
80mHz 36mA 130mA 252mA
160mHz 34mA 114mA 249mA
240mHz 21mA 145mA 251mA

Ideally I’d like to be able to downscale the CPU to 10mHz for low power, and then scale back up to 240mHz for a responsive user interface. After a time or two scaling down and back up, the watch becomes unresponsive without throwing a stack trace. I suspect this is because the Serial, I2C, and/or other configuration is relative to the CPU frequency and needs to be reinitialized when the clock multiplier changes. Measuring this out of circuit would be considerably more helpful.

Anecdotally the graphics performance between 160mHz and 240mHz is minimal and even 80mHz produces a barely noticable slowdown. For most circumstances I suspect 80mHz would be sufficient.

Monitoring Power Consumption

I’m refusing to tear down my watch to monitor the current coming out of the battery. Sacrificing some amount of accuracy I’m using the onboard ADC of the AXP202 to measure it. In order to get some idea about the sleep-time consumption I setup a moving average to track it.

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
// enable the axp202 to watch the power lines
watch->power->adc1Enable(
    AXP202_VBUS_VOL_ADC1
    | AXP202_VBUS_CUR_ADC1
    | AXP202_BATT_CUR_ADC1
    | AXP202_BATT_VOL_ADC1
, true);

// every so often, check the levels
battery_current.insert(watch->power->getBattDischargeCurrent());
vbus_current.insert(watch->power->getVbusCurrent());


// show usage on the screen
char display[255];

snprintf(display, sizeof(display),
    "%i%% %3.1fV %4.1fmA / %3.1fV %4.1fmA",
    watch->power->getBattPercentage(),
    watch->power->getBattVoltage() / 1000,
    battery_current.average(),
    watch->power->getVbusVoltage() / 1000,
    vbus_current.average()
);

screen->fillRect(0, 0, 240, 20, TFT_BLACK);
watch->eTFT->drawString(display, 0, 0, 2);

[1] https://github.com/red-fox-star/ttgo_watch/blob/84ba28be1b5ec415e124385ae82782faa7d19ecb/src/pong.cpp