Will alarm clock apps be able to wake up the phone when it's off?

In order to save energy, assuming that the capacity of the battery will be too little for the hardware.

I’m not an engineer, but i remember my old nokias being able to do just that. But no worries, i’ll happily use my librem-5 anyway :smiley:

1 Like

I had no idea that modern phones couldn’t do this! But, then again, I never really considered the complexity of it.

I rarely use my phone as an alarm clock, but it’s an old one with an alarm that works when the phone is off. Obviously “off” in this context just means it’s in a very low power state, not completely off. Maybe the main processor itself goes into a low power mode, or maybe it halts entirely and hands off alarm clock responsibility to a secondary, low-power management controller type thing that can restart the main processor when someone presses the power button or the alarm time comes around.

Certainly you get some screen flicker and a bit of a delay as it appears to boot up before the alarm sounds. If I recall correctly, it boots up a few seconds before the alarm time, so that the alarm itself is precisely on time. I suppose an Android device would need to boot up maybe five minutes in advance, to err on the side of caution, especially if third party alarm clock apps were involved.

I don’t really care whether the Librem 5 has this feature, given how little I’ll use it.


Schematics for the developer kit include separate real time clock, capable of raising an interrupt. I can’t tell if that interrupt is able to wake up the CPU + RAM + everything else needed to sound the alarm. My bet is that it is possible, but simply won’t be supported in software from day 1. Then again, I tend to loose most of my bets :slight_smile:


Yeah I remember those days too. Everyone posting here would rather give you advice rather than answering your question it seems.

Well, i got a (short) answer, i was just curious about this specific feature. I’ll keep using my classic alarm clock as i do every day :wink:

The part that makes this tricky to answer is the definition of “completely”. If your phone woke up, then it was not 100% off. It was using some energy to run the Real Time Clock.

For the L5, I’ve set up a tracking issue: https://source.puri.sm/Librem5/OS-issues/issues/120

We encourage all interested L5 and devkit owners to take this on :slight_smile: It’s quite likely that along the way you’re going to bring overall energy usage improvements.


You realise that you (Purism) as the operator of the forum can decrease the minimum post length?

:slight_smile: or how when i “power-off” the battery level is at 90% and 6 hrs later when i “power-on” it says 95% :smiley:

my RTC apparently charges my battery rather than depleting it :wink: what the devil is this ? :joy:

I see, but it wouldnt be a problem for me if it worked the same as old nokias did, some small about of battery power sacrificed to my daily routine :smiley:

Simply because is not accurate.

1 Like

The trick that the most nokias did was to have the RTC in the battery (seperate from the main OS). There would be a microOS that would be “only” for the alarm. So the battery was the actual alarm that you were dealing with when the phone was off.

As it stands this approach with the librem 5 would not work as there is no RTC in the batteries that they are using but there could be something that could be setup within the bios to handle but then again you are thinking about bios plugins… which can be fun and risky.


I think that some BIOSes do have that kind of functionality on desktops. You set a wake up time in the BIOS and power off and the computer will boot at the specified time. Presumably that relies on having a clock chip that runs even when powered off - because there’s a CR button cell that powers the clock chip. Obviously the computer has to be still connected to mains power and switched on at the wall.

So something like that is possible to do - but it only really makes sense if the wake-up time is sufficiently far in the future and you can tolerate the delay of a full boot-up sequence. (In the context of a mobile phone, you wouldn’t need a separate button cell and the normal phone battery would do the job.)

1 Like

Testing this is part of standard functionality tested in Intel gpu driver test suites. I’m sure your computer can do that too. Unfortunately, I don’t remember which tool controlled that.

1 Like

To power-on the phone, the RTC has to be a hardware component (i.e. not a just some data kept in RAM by the operating system). Where it is located is less important than how it is connected, be it inside a battery or not.

From what I gather reading the issue linked to by @dcz, the Librem 5 has two hardware RTCs. It would be really silly not having at least one of them connected to power even when the phone is off. Without a constantly running RTC, you would have to enter the current time and date every time you switch on your phone. And RTCs are very low-power devices, at least the ones I have used.

Normally, the RTC can be programmed with at least one alarm. The OS will set this up before putting the CPU to sleep. At the set time, the RTC will signal an interrupt (a hardware thing) to wake up the CPU. From there on, the OS takes care of things, eventually leading to an audible alarm.

That doesn’t work when the phone is off, though. So the RTC interrupt has to be wired in a way that powers up the phone and the OS needs to know that it was started because of an alarm. This is what @kieran and @dcz were talking about above.

The challenge here, if I understood that issue right, is not the interrupt wiring or the power supply, but the fact that there are two independent hardware RTCs. Apparently, it is tricky to make sure the right one is used at all times - after power on, when an alarm triggers boot, at wake-up, …


precisely the case with my bb-q10. i think they purposely did NOT try to implement that to discourage users from completely removing the battery even though it IS hot-swapable … naughty-naughty manufacturers ! :weary:

Or it would get the time from the network (be it the mobile network or via the internet, via cellular or WiFi) every time you switch on.

Raspberry Pi devices have no RTC (by default) and just use NTP to set the clock on each boot, via ethernet or WiFi. Of course it is painful if something is wrong with the network connection at startup and I have seen anomalies at startup if there are components that need to have some idea of the correct time.

1 Like

Of course with the hardware kill switches off you can’t get time from the network (which is a valid starting state) so you’d need to at least have the option to either enter time or have a default power on time every time you boot with the kill switches off assuming you’re not giving power to the RTC.


My router (off-the-shelf device, runs Linux) takes the approach of defaulting to Unix base time at power on. That is OK because you aren’t expecting to use a kill switch on a router. Kinda pointless. But the WAN can be down when the device boots. It does not retrospectively correct the time on early log entries after normal booting.

(If your router has attached storage then it can be quite important to have the correct time. I think my router supports attached storage but I don’t use the functionality.)

Other devices that I have seen, where they have associated disk storage, store the last known time / last shutdown time, so that the time will at least a) never go backwards, and b) be in the right ball park even before NTP is used.

1 Like

I think it’s worth mentioning that just because a device forgets the time when you remove the battery or cut the power does not necessarily mean it lacks an RTC, only that it lacks an extra battery to keep the RTC running. It may lack an RTC, but you can’t tell from those symptoms alone. (I think you probably know this, but your post can be construed the other way.)

A related anecdote: I have a NAS device that truly lacks an RTC and suffers from quite a large amount of clock drift as a result. It requires regular NTP updates to stay in sync. If I recall correctly, there is some code that compensates for the drift by measuring the previous drift and slowing down or speeding up the clock in software. The fact it forgets the time when you turn it off is only a secondary concern!