PaperLedger is a cryptocurrency ticker display that supports monitoring multiple cryptocurrencies, is battery powered and has price alert functionality.
The device consists of a 2.9 inch ePaper display, a speaker and comes in a fully enclosed 3D printed white case.
There is also a supporting Web Portal to view, manage and configure the various features of the device.
With the battery implemented it makes sense to use the deep sleep capabilities of the ESP32.
This would make the battery last up to months with a single charge.
This estimates are heavily dependent on how long the device is awake for.
The workflow is as follows:
Tickers view is shown
Store necessary state
Go into deep sleep for "ticker scroll frequency"
Wake up
Restore state
6-Aug-2018
Some quick measurements about the device consumptions and other metrics:
Display Consumption
3
mA
Battery capacity
500
mA
Device Consumption
85
mA
Peek Consumption
150
mA
On time
2
sec
Theoretical battery estimates:
Updates per day
Hourly Consumption / mah
Daily consumption / mah
Battery last / days
1
0.05
1.13
441.18
2
0.09
2.27
220.59
3
0.14
3.40
147.06
4
0.19
4.53
110.29
6
0.28
6.80
73.53
12
0.57
13.60
36.76
24
1.13
27.20
18.38
360
17.00
408.00
1.23
1300
61.39
1473.33
0.34
9-Aug-2019
In order to maintain a state during deep sleep cycles the ESP32 has another CPU (ULP) and RAM (RTC) that stay awake during deep sleep, all other peripheals are turned off (depending on the sleep mode). These are ultra low power components that, as expected, are very limited. An alternative to using RTC would be to use SPIFFS but its best to avoid constant writes to it since it has a limited number of write cycles. With the current approach, the total boot time needs to be maintained during sleep cycles in order for the tickers to function properly. RTC is only able to store uint16's so two addresses have to be used in order to store a long (epoch time).
12-Aug-2019
The device outperforms the theoretical charts by a lot, more tests are required but it lasted more than 16h on a single charge (~30% battery left) with 10sec scroll time and 60sec update rate.
One persistent issue is the speaker pop sound on power on/power off cycle. This seems to be caused by noise or unfiltered outputs on the chip NS4148 (3w amplifier). The chip has a sleep mode pin which should reduce the pop sound but its currently connected to 3V3 thus not being available to the ESP32. For now the N Speaker wire was soldered to pin IO27 in order to control when the speaker is on. A big downside is that this essentially renders the amplifier useless making the speaker around half as loud.
The GPIO on the ESP32 works at a 3.3v level and the battery is 3.7v (4.0v while charging) so a voltage divider has to be added to the board in order to bring the voltages down.
The board already has a charging circuit but the charging LED (or any charging signal) is not available in the GPIO header, so either "charging mode" is detected by voltage increase on VBAT or "LED_G LED0603 BLUE" has to be remapped to the available GPIO.
14-May-2019
In addition to the VBAT pin the charging pin (VBUS/CHRG) is hardwired to the onboard USB which will be hard to get around without some hackish solutions. Ideally a vertical USB connector would replace the existing one thus removing the need for an extra USB.
The cases are likely to be reprinted since the battery barely fits the existing model. A 2mm increase in depth should be enough to accommodate the battery nicely.
The device consumes ~85mA while powered, peaking to ~150mA when pulling data.
In deep sleep mode the device consumes 7mA which is higher than the researched values of around 10μA (https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/). This is likely to be related with the onboard LED's (charding and power) that are always powered on. Ideally these would be removed in order to save power.
Software wise, deep sleep can be implemented with ease and a prototype has been sketched out. The network connection and deep sleep functionality have to ported out of "Manager" into the modules that require it (eg: TickerView). The "Manager" module has to store the current view in RTC in order to be aware of what view the module is at since the CPU and RAM are powered off in deep sleep.
28-Jul-2019
A new board has been manufactured which includes the following changes:
Remove SM_20PIN header.
Replace SM_20PIN pads with PCB through-hole.
Remove MICRO_USB_SMT.
Replace MICRO_USB_SMT pads with PCB though-hole.
Remove LED_G LED0603 BLUE (charging LED)
Remove LED_G2 LED_G LED0603 GREEN (power LED)
Connect VBAT with pin 13 on SM_20PIN (IO34).
Connect CHRG on TP4054 with pin 14 on SM_20PIN (IO33)
PaperLedger is a cryptocurrency ticker display is a super product for newbie's cryptp investors like like me in market to remain updated with latest prices of coins while woring on my other projects.
Hi! how much time takes the display to refresh? i could not get it lower than 12sec aprox. i´m using the same board. i'm struggling with the battery life because of this!
12 seconds is a lot. This is an vague estimation but I would say you can get around <500ms refresh time. I can scroll through the menu with minimal latency, by using GxEPD2 instead of GxEPD the latency was reduced even further.
Make sure you are using partial refresh and that no other code is blocking the main loop.
There are a few examples on GxEPD2 github repo or, since you have the same board, you can give the PaperLedger code a go. I suggest using the improvement/layout branch.
The board uses WiFi to get the ticker prices from CoinGecko and it serves its own web interface by browsing its ip.
PaperLedger is a cryptocurrency ticker display is a super product for newbie's cryptp investors like like me in market to remain updated with latest prices of coins while woring on my other projects.
can i sharre your product on my website:
https://cryptocurrencynewsdaily.com/