Knocker-Upper Service (KUS)

Family History

I dimly recall my Mum telling me that someone in the family was a “knocker-up”, or “knocker-upper”.  This was in a time before inexpensive alarm clocks, and so getting to work on time was a challenge, especially if you had a physically tiring job, or were a regular attendee of the pub.  Being late for work carried serious consequences, which might mean pay being docked, or simply being dismissed.    It also produced the joke about “knocking up whole streets before breakfast”.

Workers lived in row-houses (like Kismet) where the front wall of the house adjoined the pavement (footpath), and the main bedroom was upstairs at the front.  Because the houses were small, the sleeper’s ears would be but  a yard or so away from the window.  So the knocker-up would tap on the upstairs window until they saw a face at the window. Tapping on old glass risks breaking the glass which would be a major expense, and annoyance – especially in the winter.  So many knocker-uppers had a long pole with some sort of  ‘tickler’ on the end.  It was just enough to make an irritating noise on the window, but with much less chance of breaking the glass.  In return for waking the client, the knocker-upper would receive a few pennies per day.  If the worker failed to make it to work on time, the income streams of both knocker and knockee might be terminated, so the knocker-up was motivated.

What’s this got to do with WUR?

The objective with a wearable is to save power whenever possible by switching the uC off.  A typical approach is to wait for some external signal – typically a wireless signal, or an interrupt generated by an attached sensor, or a clock.  Listening for a wireless signal consumes power – perhaps a few mA.  Keeping a sensor running consumes power too.  Even a few-hundred microamps consumed over hours, days or months mounts up.  Quite a small battery can listen out for several months or even years, but the battery adds substantially to the size of the system.  It is often the case that the size of the device is compromised by the battery size.

One approach is simply to hibernate the uC completely so that the current it consumes is basically just a few hundred nanoamps.  Then the the process of waking up, the equivalent of pressing the ‘boot’ button, can be delegated to some local service that has the means to wake up the uC – a “knocker-up service”.

But even then, if no “knocker-up” service is available, then you are on your own, and have to monitor conditions (clock, activity, radio-input) yourself.

Knocker-up service System concept

How KU services are deployed

A knock up service is a wireless service that can be used to wake up a hibernating client.  We assume this service has a constant source of power.  It is assumed that the client has entered a mode where it is using little, or no power so it doesn’t have the wherewithal to rouse itself.  However the KUS can radiate energy, and the client has an antenna large enough to scavenge enough energy from the radiated radio signal to jump-start itself.  After that point, the client has to use whatever resources it has to hand to determine why it has been woken up, and to act accordingly.

When a client knows is ready to hibernate, it uses some means (BLE perhaps) to check to see if there is a KUS nearby.  The KUS service sends a ‘rehearsal knock’ to make sure that the client is able to hear the knock-up signal.  If the client receives the test knock, then it can contract with the KUS to be reactivated under whatever conditions the KUS is willing to offer.  A simple example might be, “In 10 minutes”.

A more elaborate, but perhaps more useful case is when the client wishes to go to sleep until some third-party service wants to communicate with the client – to send an alert of some kind.  Before going to sleep the client might contact the alert service, providing two bits of information: the IP-address of the client’s KUS (it’s proxy);  a secret number that has been previously arranged with the particular KUS.  When the alert service decides it needs to wake up the client, it sends a wake-up request to the client’s proxy (the particular KUS), together with the previously shared secret.  The KUS checks the secret is valid, figures out which client it should wake up, and sends the wake-up event. 

In the simplest of all worlds, the client wakes up and has to check in with the KUS to find out which of perhaps many services, has tried to get in contact.  Then it is on it’s own to contact the specific service and finish business.

If the client fails to wake up, then perhaps the KUS retries a few times, but finally logs the attempt, and then gives up.

In a more complex implementation, the KUS might share the wake up request with a few geographically proximal peer-KUS services to see if they can wake up the client.

Leave a Reply