XTEINK X4 - battery drain problem

[secit-pl]

Hi,

I'd like to report a problem with optimal power usage. I'm using TRMNL 1.7.4 with a brand new Xteink X4, and the battery drains very quickly. I know this device doesn't have a large battery, but even with a 1-hour refresh rate, the device only lasts for a maximum of two days - that's only about 48 screen refreshes per full battery charge. This seems incredibly low and makes using TRMNL with the Xteink X4 impossible without a permanently connected power supply.

[DavidOrtmann]

Hi, thanks for reporting. We are actually mentioning this issue in our FAQ: https://help.trmnl.com/en/articles/13563787-connect-your-xteink-x4-to-trmnl#h_9ebc12df15
This is due to a pretty ineffective PCB design on the X4. In order to access the clock of the device and wake it up and download a new image automatically, the page must not enter Deep Sleep. However, this drains the battery very quickly. We are discussing ways to remedy that on a firmware level, but are within the hardware constraints of the device.
Thanks for bringing this to our attention, we will follow this up once we have something to show.

[secit-pl]

Thanks for the info. I hadn't seen this before.

I hope the deep sleep issue can be resolved. The Xteink X4 is the perfect size for tight spaces, and its support will open up many new possibilities for TRMNL.

[RobbieFrancis]

I was just about to buy a couple of X4's & Terminal License, as I'd like a couple of these dotted around the house, but alas.... if it can't last more than 48 hours, that's a no go. Anyone know if TRMNL has plans to release something tiny like the X4 with decent battery life themselves?

[secit-pl]

I have the same problem. I bought two licenses specifically for Xteink, and then discovered a problem with battery life. I hope this can be resolved.

[secit-pl]

@RobbieFrancis just found this PR #262 so I think the smaller version is also planned

[bitbank2]

This power drain issue cannot be solved directly because it's a flaw of the original PCB. When put into deep sleep, the X4 draws 3-4mA from the battery. The X4 design intention is to completely disconnect the battery when it is sleeping. This allows long battery life, but doesn't allow for the normal TRMNL workflow of waking up independently. A workaround is to have a second X4 environment profile in the trmnl-firmware which disconnects the battery after each update. This would require the user to press the power button for the next update to be displayed. How does this sound as a workaround?

[RobbieFrancis]

" require the user to push the button for the next update to be displayed. "

Interesting that you should say that, as I was thinking exactly this. Have the two buttons on the X4 be forward and backward, and essentially waking the device, and fetching the new screen at the same time. Would be a great configuration option!

[bitbank2]

" require the user to push the button for the next update to be displayed. "

Interesting that you should say that, as I was thinking exactly this. Have the two buttons on the X4 be forward and backward, and essentially waking the device, and fetching the new screen at the same time. Would be a great configuration option!

Only the power button on the side can wake the device when the system's LDO is disabled. The forward/back buttons would need to be pressed after it's powered on.

[RobbieFrancis]

Ah - makes sense. So can the sequence be set that on power-up it fetches the latest "current" (Last viewed page), and for X mins after that you can scroll to next or previous in your list, whereby it would fetch the latest each time?

[bitbank2]

Ah - makes sense. So can the sequence be set that on power-up it fetches the latest "current" (Last viewed page), and for X mins after that you can scroll to next or previous in your list, whereby it would fetch the latest each time?

Minutes of "on" time would drain the battery similar to what's happening with the current firmware. The normal behavior of TRMNL is to go forward through the playlist and then start over. You could do that as quickly or slowly as you like with the power button wake. Since the x4 won't show a new image unless you press the power button, you won't miss any. Why would you need to go back?

[RobbieFrancis]

My thinking is that if it is on Screen 3 (Of 8), and when it powers on, it updates screen 3, but if I want to scroll forward, to screen 4, or backwards to screen 2, I have the choice. On opening a new screen I would expect it to fetch it from the TRMNL backend API... That makes the most sense for me.... But maybe I am missing something?

[bitbank2]

Playlist navigation is something new that will only be supported on the TRMNL X (for now). Normally the user can wait for a normal update or skip immediately to the next image in the playlist.

[secit-pl]

If there really is no other way around this problem than physically pressing the power button (or maybe it can be simulated at the firmware level?), then in my opinion, every press of the button should behave exactly as it does now - that is, refresh the screen based on the current data from the server. If we were on screen 3 of 8 and refresh, and the current screen is 3, nothing changes (though some indicator/ loader to indicate that something actually happened after pressing the button, rather than, say, the battery dying and there being no response), if the current screen on the server is 4 of 8, the screen should switch to 4.

I think the best solution would be to set during the device WiFi configuration whether we want automatic reload (in which case the battery lasts max 2 days), manual reload (in which case it lasts as long as we keep clicking refresh), or even better - detecting whether an external power source is connected and then switching to auto-refresh. This would allow for full configuration flexibility for the selected use case.

[bitbank2]

If there really is no other way around this problem than physically pressing the power button (or maybe it can be simulated at the firmware level?), then in my opinion, every press of the button should behave exactly as it does now - that is, refresh the screen based on the current data from the server. If we were on screen 3 of 8 and refresh, and the current screen is 3, nothing changes (though some indicator/ loader to indicate that something actually happened after pressing the button, rather than, say, the battery dying and there being no response), if the current screen on the server is 4 of 8, the screen should switch to 4.

I think the best solution would be to set during the device WiFi configuration whether we want automatic reload (in which case the battery lasts max 2 days), manual reload (in which case it lasts as long as we keep clicking refresh), or even better - detecting whether an external power source is connected and then switching to auto-refresh. This would allow for full configuration flexibility for the selected use case.

There's no way to simulate turning on the physical internal power.
The code would work the way you envision already. If connected to power, it would wake on schedule and act like a TRMNL.