Browse Prior Art Database

USING BLUETOOTH FOR REAL TIME CLOCK SETTING AND REGULATION

IP.com Disclosure Number: IPCOM000004720D
Original Publication Date: 2001-Apr-19
Included in the Prior Art Database: 2001-Apr-19
Document File: 3 page(s) / 11K

Publishing Venue

Motorola

Related People

Ed Callaway: AUTHOR

Abstract

USING BLUETOOTH FOR REAL TIME CLOCK SETTING AND REGULATION

This text was extracted from a RTF document.
This is the abbreviated version, containing approximately 35% of the total text.

USING BLUETOOTH FOR REAL TIME CLOCK SETTING AND REGULATION

by Ed Callaway

In household settings, for example, it is often desirable to have many real time clocks (RTCs), in convenient locations. However, having a plurality of independent clocks entails monitoring and regulating the accuracy of each of them, an annoying and time-consuming task. What is needed is a method of regulating the accuracy of an entire household of clocks automatically or by monitoring and regulating a single clock.

To satisfy this desire, existing Bluetooth functions and features may be used to create a piconet of real time clocks (including wall clocks, watches and real time clocks in appliances, personal electronic devices, etc.) in which the clocks are synchronized to a single reference (typically, but not necessarily, the Bluetooth master). This means that their real time values not just their frequency references are synchronized at all times. The clocks never have to be manually set not even when first turned on.

Slaves' RTCs could be controlled by direct real time transmissions by the master (e.g., broadcast the real time to the piconet every second), but a more elegant solution involves the use of CLKE, the slave's estimate of the master's Bluetooth clock CLK, as described below. (If absolute real time were not required for example, in a stopwatch application or if manual time setting were acceptable, simple regulation of the slave frequency reference would be sufficient. This could be achieved, for example, by synchronizing the slave's frequency reference to the master's 1 MHz Bluetooth symbol rate.)

BLUETOOTH BACKGROUND

All Bluetooth devices are required to contain a 28-bit clock, operating at 3.2 kHz. Bluetooth slaves are required to maintain a clock offset value, indicating the offset between the master's clock and their own. (When a slave receives the FHS [Frequency Hop Synchronization] packet usually when joining the piconet the difference between its own clock value and the master's clock value included in the payload of the FHS packet is computed.

The clock offset is also updated each time a packet is received from the master.) This is done so that the slave may remain in word synchronization with the piconet, even if the master puts it to sleep for long periods. The Bluetooth specification, therefore, defines three clocks:

1. CLK, which is the master's 28-bit clock;

2. CLKN, which is the slave's native (i.e., uncorrected) 28-bit clock; and

3. CLKE, which is the slave's estimate of the master's 28-bit clock, made by adding the clock offset value to CLKN.

These 28-bit clocks roll over approximately every 23 hours, 18 minutes, 6.08 seconds; the Bluetooth specification does not require that they have any relation to the time of day.

BLUETOOTH RTC USE CASE

The core of this idea is the establishment of a relation between the master's Bluetooth c...