A Wireless Programmable Pace Clock

High Level Design    top

Overview

Our project brings together a wide range of hardware and software design experience: from bit level inter-chip communication to processing our compact, original instruction set, to managing user interactions wirelessly in real time, to designing an intuitive user interface for configuring and interacting with the pace clock on an Android smartphone.

Standards

A variety of standards are used to implement communication between peripheral devices, and we use a large fraction of the peripherals available on the ATmega microcontroller. Communicating with the LED drivers is achieved using the SPI interface and a host of other connections required by the TLC5940 devices. These LED drivers are complicated and capable of 12-bit PWM current sinking using an external clock, as well as 6-bit dot-correction tables with persistent and SRAM storage registers. As a result, there is a lot of data formatting and transmitting required to get them to function, even if we only need DC illumination. Communication with a real-time clocking chip uses the I2C/TWI standard (I2C is a proprietary name owned by NXP); the chip itself has many configuration and data registers that can be read and written to perform clock and calendar timing operations. We wrote drivers with simple interfacing functions for both the LED drivers and the clocking chip. Our software uses Peter Fleury's open source I2C/TWI library, available from his website referenced at the bottom of this page. Communication with the radio module uses the microcontroller's onboard USART peripheral unit (asynchronously, so the 'S' can be dropped). The radio module itself uses the Bluetooth standard (Bluetooth is a proprietary name owned and managed by the Bluetooth Special Interest Group). Configuring the radio module can be done locally by the microcontroller or remotely from a Bluetooth equipped computer. The Android smartphone uses several levels of software abstraction to communicate with its Bluetooth hardware, and Google's API for Android App Development is used to design a useful configuration and remote control interface to our pace clock for an Android device.

Intellectual Property

Although we used a knowledge of Colorado Time Systems pace clocks in designing our project, we do not believe our work infringes on any of their patents (or other patents). In the References section, we have linked two patents that are in the same field, but not very similar to our project. The Colorado Time Systems patent refers to a modular display system which is reconfigurable and useful for changing a large display's format with cover panels and software/hardware to use it correctly. Colorado Time Systems sells wirelessly programmable pace clocks, but with different functionality and methods of programming; notably--using a physical push-button based programmer. The Swimnetix patent application in the References section also involves a programmable clock, but involves workout programming and monitoring via physical interaction with the swimmer though touch-pads in the pool and a wearable heart-rate monitor. Additionally, it is for a small waterproof unit that sits at the end of a swimmer's lane, not a large format display that is used by a whole pool of swimmers simultaneously (as ours is). We believe no one has sold or patented a pace clock with Bluetooth control like ours, and have not found anyone selling a smartphone controlled pace clock.

Hardware and Software Tradeoffs

One of the biggest design considerations when starting this project was the trade-off between hardware and software. We adopted an embedded system architecture inspired by microfabrication equipment (and probably used in a lot of industrial machinery too), that splits setup and runtime operation between software and hardware. The idea is that configurations and settings are done on a software-heavy very capable computer (the smartphone, in our case), and then data is formatted and sent to microcontrollers in a simplified format that the microcontroller can interpret. Execution of the task is then performed by the microcontrollers with only a reduced set of interactions available to the user (for example, the available operations could be limited to "stop", "next", "shut everything down", and little else). The obvious benefit is that the user interface can be graphical and doesn't need to be executed by the microcontroller. The real reason this is commonly used, however, is for stability. Critical operations are managed by the microcontroller firmware, which is simpler than graphics software, closer to the hardware signals, and hopefully more stable than a PC with an operating system and several concurrent programs and services running. In our project, the user configures routines on the smartphone interface, then switches to a simplified "remote control" tab with only 6 buttons. One of them uploads the data which the microcontroller stores in EEPROM (so the routines will still be stored after unplugging the pace clock), another button powers the clock on and off, so that leaves only 4 that are used to navigate through the instructions and timing intervals. The interface is clean, simple, and uses large buttons with limited and strictly defined functionality. The benefits of this architecture are many, and we touch on them throughout this report, but perhaps most significantly is that this method makes it easier to learn how to use the pace clock and the remote control can be simpler and less expensive.

High Level Block Diagram

More than anything, this project is about peripherals, and connecting hardware with software and software with human interaction in an intelligent, efficient way. The ATmega microcontroller has more than enough computation power to manage the pace clock’s large-format display, a connection to a real-time clock/calendar chip, and the user interaction that comes in over Bluetooth. Today’s smartphones have an enormous computational power that exceeds what is necessary to control the clock and allow the user to efficiently manipulate its behavior to aid in athletic training.

User Interface

The most important part of this project is that the clock acts in the way the user expects it to act. The user knows what he or she wants—a measure of time in customizable way that a simple clock cannot provide. The microcontroller software and the Android App software should act in intuitive ways to accomplish the timing intervals and workout scheduling that the user specifies.

Fundamentally there are two parts to the user control. The first is intended to mimic the workout design that a swim coach would write down (or program in some software platform if they have such technology). This means specifying a series of strokes, drills, and intervals, with programmatic and spontaneous pauses for coaching or for the swimmers to rest. On our system, the user can organize many intervals and instructions for the clock to execute into 32 routines on an Android smartphone. Each timing interval can include a message that specifies which strokes or drills to do. These routines are compiled and sent over the phone’s Bluetooth connection to the microcontroller managing the clock. The clock saves these routines permanently until a new set of routines (perhaps the following week’s workouts) are uploaded.

The second interface is much like a television remote control, and indeed, could be implemented as one without much difficulty. It purposefully pares down the available commands to just 5 buttons (in addition to the upload button used previously), allowing the user to skip through the uploaded routines, pause timing intervals, and jump between different workouts or routines on the fly (as is often necessary when coaching a real swim practice). The available commands are implemented as large buttons on an android screen (see the Mobile Application section under Software for more detailed description).

During execution, the user may change the clock's state asynchronously with the 6 buttons or when prompted by the clock's interpretation of an instruction that needs user input. For example, the microcontroller handles the user: setting times in the clock-set mode or the scheduled-start-time mode, skipping through intervals and loops, restarting intervals, pausing/resuming, and selecting routines in an arbitrary order. Powering on/off of the system is also accomplished over the Bluetooth remote, as is uploading. In a powered-down state, the system consumes significantly less power than with the screen on, and the electronics are put in low power modes with the exception of the Bluetooth module which must still respond to power-on commands from the user. The following table illustrates the available transitions between the pace clock’s states, depending on the current state. It specifies the behavior for any button press at any time.

One of the major benefits of our two-tier interface (upload; then remote control to execute the uploaded information) is that it allows a division between high-cost high-complexity interfaces—such as the routine configuration utility—and low-complexity interfaces—such as the remote-control screen used after uploading the day’s or week’s workouts. This allows the lower-complexity controller to be much lower cost, if desired. For example, any garage door opener with a handful of buttons or a Universal TV remote could be interfaced with the microcontroller to control the execution of the instructions and data uploaded from a more complex system. Not everyone has an Android smartphone, so wireless uploading could be done from any computer including a nearby desktop, then the user could control the clock with a simpler, cheaper remote control.

Note that the pace clock does not need to be controlled using an Android device because it specifies an open-source protocol for uploading data and manipulating the execution of its instructions, therefore any variety of devices at a wide range of price points (from commercial timing systems to garage door remotes) could be made to control the pace clock’s operation. The Android application was designed to take advantage of an intuitive user interface for the high customizability of our pace clock as well as its ease of distribution. See the next section for a specification of the instructions and their behavior in more detail with respect to how the clock reacts to a particular instruction.

A Compact Instruction Set

The operation of the interval timing is managed by interpreting a compact instruction set which we have specified. A variety of instructions are available to implement all the necessary functions of a programmable pace clock. The full instruction set is available here, and a summary of the functionality is shown below. The user essentially programs these instructions in the routine-configuration tab of the Android App. Instructions and timing interval data are stored in the persistent EEPROM memory, and interpreted by the microcontroller when parsing through during normal operation. Compactness is key, since our microcontroller has only 1024kB of memory. All instruction-format items are 1-byte and all timing-format items are 2-bytes (one byte for minutes, one byte for seconds). Compiling from the graphical user interface to the 1024kB file is accomplished by the Android App, with a few modifications from what the user sees in the configuration tab. These differences are: 1) A routine prompt instruction precedes all other data, 2) A jump to routine 1 follows the last routine, and 3) A routine prompt instruction is placed at the end of the body of every routine. To get around (3) and advance to the next routine automatically (without prompting for input after completely parsing a routine), the user simply needs to put a jump instruction as the last entry of a routine.

Instruction	Function
Jump N	Immediately jump to routine N
Outer Loop Header K	Serves as the top of a loop and performs initialization to do K iterations of the repetend
Inner Loop Header J	Same as above, but for the inner loop
Routine Header	Denotes the beginning of a routine (index inferred by parsing) and displays it for 1 second
Display Clock	Displays the time of day in hours:minutes format
Set Clock	Prompts the user to set the clock in hours:minutes format
Routine Prompt	Prompts the user to select a routine
Scheduled Start	Prompts the user to set a workout start time, displays clock until that time, then proceeds
Programmed Pause	Halts and blinks the colon until user advances
Outer Loop Footer	Handles looping back to the top of the outer loop if necessary
Inner Loop Footer	Same as above, but for the inner loop
Screen Test	Demonstrates the screen by cycling through numbers and the short segments
Display Cycles Remaining	Displays the number of cycles remaining in a loop for <1 second
Millisecond Timer	Starts the 10-millisecond timer (counts up only)
Minutes Data	Encodes minutes (should be 0..59) in BCD and a count-up/count-down bit
Seconds Data	Encodes seconds (should be 0..59) in BCD

The Android user configuring routines cannot modify the loop header at the beginning of each routine. Also, the loop footer instructions and the optional instruction to display the remaining iterations of a loop appear on the same entry in the configuration utility. Minutes and seconds data have the same format, so the interpretation is that the byte at a lower data array index represents minutes and the immediately following byte represents seconds. The count-up/count-down bit position in the seconds byte is ignored. We use the term "index" and not "EEPROM address" because in AVR-GCC we declare an array with a specifier to indicate that it should be stored in EEPROM; the actual hardware addresses used by the compiler to turn an array index into byte address are abstracted away.

The total number of routines and their collective maximum size is dictated by the size of the EEPROM, which can be made arbitrarily large with external memory ICs. However, with our ATmega32A, which has 1024kB of EEPROM, we estimate that the user could store weeks worth of workout data, vastly exceeding the amount that typical swim coaches “plan ahead” for a workout.

The Large Format 4-Digit 7-Segment Display

As seen in the pictures of our system, the pace clock includes a large format display with 544 high-brightness red LEDs to display the time and communicate visually with users. The display and its mounting panels measure 40” x 15”, and comprise 28 long segments for 7-segment digits and 8 short segments for the decimal places, the colon, and the hyphen. See the hardware section for more information on the design and construction of the display. We have chosen to use narrow-angle, high-brightness, red LEDs and designed printed circuit boards to simplify the wiring. Equal brightness is achieved with long series strings of 9 LEDs (half a segment) controlled by open-drain current sinks on an LED driver integrated circuit, with precision reference resistors used to give equal brightness across the 4 panels (plus the half-panel containing the hyphen and colon).

Clock and Timing Interface

Real time clock/calendar interfacing is accomplished with an external integrated circuit (PCF8563P), a very low power chip which counts time using a 32.768kHz crystal and logic functionality to maintain calendar, clocking, and alarm functions. A professional production of this pace clock might use a battery backup supply on this chip to maintain the date and time even when the whole system (microcontroller, display, and radio) are not powered on. The main benefit of delegating a peripheral IC to the clocking and timing role is that accuracy can be increased with a more accurate external crystal or oscillator applied to the clocking chip, without any changes necessary to the microcontroller code or its interface with peripherals. Timing synchronized with other wirelessly networked clocks can also be achieved in this manner if more pace clocks were built. Additionally, a lower frequency oscillator is more accurate for a given ppm tolerance, since there are fewer cycles over which a systematic frequency error can accumulate. The millisecond timer of the pace clock uses the microcontroller’s crystal since the 32Hz reference clock output of the clocking chip (and even its 32.768kHz output option) are not the right frequency to easily time 10-millisecond increments.

By intelligently reading and writing the registers in the real time clocking chip, our microcontroller can keep track of the time, halt its advancement, count up and down, and correctly advance to subsequent timing intervals by reading and writing data on the interface bus to the external chip. For persistently-powered systems (either permanently plugged in, or those with battery power to the clocking chip), continuous day, month, year data could also be implemented since we have written drivers to take advantage of all the features of the clocking chip.

Radio Interface

The radio link to upload an entire EEPROM size data file and to interact with instructions and timing intervals being displayed on the clock screen is implemented over Bluetooth, using the RN-42 bluetooth module. Received data is asynchronous (it originates from user button-presses), so it is handled through interrupt service routines and flagging communication modes between the main program execution and the intentions of the user as interpreted by the received data. Data transmission between the Bluetooth module and the microcontroller is at 115.2kbps, although the radio link has hardware flow control communication and some overhead to maintain the Bluetooth connection to the phone. The actual radio bandwidth usage is not known, although with our compact instruction set and byte-size commands (limited by the bandwidth of the user’s finger that is pressing buttons), it is not restrictive at all. Transmission is one-directional, since the pace clock need not communicate to the handheld system electronically—it can already communicate to the user with its screen, at which the user is presumed be looking.

Hardware    top

Hardware Overview

This project involves a lot of hardware--8 integrated circuits on the target board--and a lot of wiring to connect the 64 LED driver outputs to strings of LEDs on the display. The design section of this report (above) has summarized the structure and organization of the hardware, as well as the interfaces used to communicate between the integrated circuits. We have used a 3.3V rail for the electronics, provided by a Texas Instruments switching buck regulator stepping down from 18.5V. All passive component values are calculated based on formulas provided in the integrated circuit data sheets, linked in the References section. The programmer pin-out was derived from a combination of the Atmel application note in the References section and the class's own target-board design, available from the ECE 4760 home page. Future designs will reduce the labor required by expanding the wiring accomplished on the display PCBs, connectorizing the current sink outputs that drive the display, and potentially reworking the target board layout to simplify the 6 connections that must be made to the LED drivers.

Hardware Design

The electrical schematic for our design is shown below, with two sub-cells describing the connections of the display's two varieties of segments and the connections that the Bluetooth breakout board makes to the RN-42 module. From pictures you can see that with a single sided copper board and this compact layout, a lot of wiring must still be done by hand to connect the LED drivers (the daisy chained green wires). A larger board layout or double sided copper boards could decrease the amount of external wiring required. See the Appendix for a complete parts and budget listing.

Printed Circuit Boards

Introduction

The pace clock requires a large format display with several hundred LEDs. To purchase circuit boards that are the size of the digits (roughly 12”x6”) would be prohibitively expensive--several hundred dollars--since manufacturers calculate pricing based on area. Additionally, there is a lot of sparse area in the center of the 7-segment digits, which needs no circuitry. For this reason, we decided to make only the segments themselves as 5”x0.75” strips to wire the LEDs together and provide a flat surface to ensure that all LEDs point in the same direction. These strips are then wired with standard 22-gauge solid copper “lab wire”, and held to panels of sound insulation fiberboard with short carpet tacks, for easy repositioning and connection debugging.

Without the class’s budget restriction, we would still have fabricated the boards at home, but using complete FR4 panels that connect all the segments’ individual LEDs, wire their power supplies to a single source, and collect their 15 current sinks (14 half-segments plus 1 decimal point) into a single header. Then, connectorized ribbon cables could more easily connect each panel to the headers on the target board, where the 16-output LED drivers sit.

Paul designed and fabricated all the printed circuit boards at home over spring break, using about 162 square inches of single-sided copper-clad FR4, plus about half that for backup parts and to make a second display for a wireless time synchronization project.

Since this DIY fabrication method uses only single-sided boards, a lot of wiring must still be done by hand, considering the 6 signals required to communicate with the LED drivers and the fact that the circuit is non-planar. These connections were broken out to header pins and then wired with homemade jumper cables / wiring harnesses made from standard solid-core 22gauge wire and locking header pin connectors. These female header pins were found in a surplus bin for $0.05 each, since they lack the plastic housing into which they are intended to be inserted. Our tight budget precluded buying both the inserts and the SIP housing, so adjacent pins are shielded from touching by wrapping each female connector with electrical tape.

Circuit Board Designs

The first step to make custom printed circuit boards, whether you are fabricating them at home or sending your designs to a manufacturer, is to design your circuit schematic and lay it out using a PCB software package. Eagle PCB is a commonly used program, but the free version has maximum board size restrictions. Paul chose FreePCB instead; it has fewer features and lower reliability, but worked adequately for our purposes. FreePCB builds Gerber and drill files which can be sent to PCB manufacturers, used to make PCBs at home. Once satisfied with the design, Gerber files can be generated and viewed using this free online tool (http://circuitpeople.com/). From there Paul downloaded PNG files of the top-copper layer of the Gerber files, and printed them from Photoshop. Measuring the distance between two holes in the PCB layout software and comparing that to their separation distance in the printed design, Paul then rescaled the image in Photoshop--interpolating with high oversampling--to give the correct-size design in real printed pages. This method worked well, and there were no alignment problems at all.

The circuit board designs Paul completed and fabricated are available for download or viewing below. The long segments are used as the segments of four digits. The short segments (several per strip) are used for the decimal points, the colon, and the hyphen. The RN-42 breakout board is used to expand the useful pins of the Bluetooth module to 0.1” header spacing. The target board is the main circuit board for all the electronics, including the regulator and its associated power components, the microcontroller and its connections to the peripheral integrated circuits, the 4 LED driver chips, the real-time clock chip, the Bluetooth module on its breakout board, and passives/wiring to connect all these subsystems.

There are several files available for download or viewing, including pre-scaled PDFs of the designs for DIY PCB makers, Gerber files for those who prefer to send their designs out, and screenshots of the designs from FreePCB. We will release the FreePCB layout files upon request, as well as the circuit schematic above, which was drawn using ExpressPCB’s schematic editor.

Part	PCB Design	Gerber Image	Scaled PDF	Gerber Files
Target Board			Download	Download
RN-42			Download original or mirrored version	Download
LED Segments (Long)			Download	Download
LED Segments (Short)			Download	Download

Note that the original RN-42 breakout module was not mirrored, a mistake Paul made in the design. To fix this, we have posted a version of the target board PDF with only the RN-42 breakout board (which must be mirrored before printing), as well as a PDF that has already been mirrored (and therefore should be printed directly). The original place on the target board where the RN-42 breakout board was drawn (the lower right corner) has been blanked out since it is a non-mirrored surface mount component on a through-hole board design. Interestingly, Paul did remember to mirror the connections of the regulator--the only other surface mount component—so the power circuitry works as intended. When making PCB boards on your own, visualize flipping your design ink-side down onto the copper, and verify that the mirroring is correct. As a general rule, an all-surface-mount design needs to be mirrored, and an all-through-hole design does not (mounting the sockets, etc. on the non-copper-clad side). The trick is making designs that incorporate both types. In retrospect, Paul expects this to be a mistake he will only make once; since this was his first time with homemade PCBs, it was a learning experience.

Since these boards were fabricated before figuring out which connections to make between the microcontroller and the bluetooth module, only the power and ground connections are made to the bluetooth module. The UART connections can be made with jumper wires between the breakout headers, with connections as shown in the circuit schematic. There are two other modifications to these boards to make them match the final schematic: the CLKOUT output of the PCF8563P (pin 7) should be connected to the microcontroller's D.0/INT0 (pin 14) on the ATmega32A, not D.7 (pin 21). This allows it to properly trigger the external interrupt INT0. The connection to D.7 can be broken before or after etching the copper, or it can be left alone if the code leaves D.7 as an input. Finally, we discovered that the CLKOUT output of the PCF8563 is only a current-sink, so a pull-up resistor is necessary just as on the TWI clock and data lines. Other people on online forums have had this problem because the NXP datasheet is not clear. The board already has a hole to insert one lead of the resistor to connect to the PCF8563P pin 7, but the resistor must share a hole with the other two pull-up resistors at its connection to Vcc, or else be tied there on top of the board.

DIY Printed Circuit Board Fabrication

Paul has made a set of instructions for DIY PCB fabrication, which can be downloaded here.

Recommended Tools and Lab Equipment

The following were either useful or essential to complete the PCB fabrication and display construction.

Item	Comment
Free PCB	For PCB Design (Eagle is only free for small boards)
Circuit People Gerber File Viewer	Excellent online tool with selectable size downloads
Photoshop or Other Image Editing Software	For image resampling, scaling, and printing
Drill Press	Holes can be drilled with sufficient accuracy by hand.
Circular Saw	For cutting the fiber board and/or other wood enclosure
Jigsaw with tile/glass abrasive blade	Required to cut FR4; or use a shear/guillotine.
Hobby/Exacto-Knife with sharp blade	Essential for fixing shorts/problems on patterend PCBs
Tungsten Carbide "Wire Size" Drill Bits	Drill Bit City #80 - #56 Gauge, retipped ones work great
Anhydrous Ferric Chloride	Cheap (ebay) and reusable (does not degrade)
Paper Towels, Newpapers, Cardboard	To clean up chemical tanks and any spills
Plastic Etch and Rinse Tanks/Containers	Should have flat bottoms to minimize liquid required
Nitrile Gloves	To protect you from the Ferric Chloride
Plastic tongs, hook, and/or mixing stick	Ferric chloride etches all metals, even stainless steel!
Scissors	To cut out the PCB design
Acetone	To clean PCBs before iron-on, and to remove toner after
Green Scotch-Brite Pad	For cleaning/abrading copper before ironing on
Window cleaner	To clean PCBs after scotch-brite, which leaves particles
Old Clothing Iron	Water removed, hottest setting, may get ink on it!
Glossy Magazines	Cheap, uncrinkled, non-recycled, glossy, thin paper
Samsung Laser Printer	Factory Brother ink and DIY refill inks do not work!
Wire Cutters and Strippers	Many PCB connections made on unprinted side
Soldering Iron and Lead Solder	ZD-929C from MPJA. 1/32" tip, plus 1/64" tip for RN-42
Electrical Tape	For wrapping connections to the screen
Heatshrink and Heat Gun	(I didn't use these, but highly recommended over tape)
Solder Flux, Flux-Pen, or Paste	(I didn't use these, but would simplify RN-42 soldering)
A Good-Quality Digital Multimeter	Absolutely indispensible. Should have audio-out for low-R.

Software    top

The Pace Clock

TimeSystem.c

This function is the main operating program that runs on the microcontroller in the pace clock. It handles parsing through the data memory, interpreting commands, updating the display, communicating with all the peripheral chips (except the regulator), and managing user interactions that arrive wirelessly over Bluetooth. The state of the clock can be one of several modes, corresponding fairly closely with the available instructions in the instruction set specified above. Flagging between the main program execution and the interrupt service routines acts as the main way that the user can advance to different modes, skip through intervals, pause the clock, and upload new data to the EEPROM. The most complicated part about writing the code for the microcontroller was handling user interactions that arrive ashynchronously, but must be interpretted and applied to the state of software system, which would otherwise only be changed at the data parsing rate. The program was designed to check for user pauses, upload requests, and power on/off requests at the maximum possible rate, and to enter the lengthy instruction and timing interval updating/parsing code only when necessary. This is necessary, in general, once per second, since pace clocks operate on a minutes:seconds time scale for the majority of their operating modes.

In normal operation, the 32Hz clockout output from the PCF8563P real-time clocking chip serves as an external interrupt which acts as a screen update "heartbeat" for timing intervals and parsing new data from the EEPROM. New instructions are parsed, and the display is updated for interactive modes such as the routine prompt instruction. The main execution halts in an infinite loop for these cases, escaping when the state of the clock has been changed in an ISR due to receiving a byte over Bluetooth, which is interpreted by the USART ISR. After advancing out of a particular instruction or finishing a timing interval, flags are set to indicate that another piece of data (one byte for instructions or two bytes for timing intervals) needs to be read from EEPROM memory and interpreted. During interval timing, when new data does not need to be parsed, the clock simply reads the minutes and seconds from the real-time clock/calendar chip and optionally performs subtraction for counting down, or no subtraction for counting up to correctly update the display buffer. A large part of the code requires converting between the data-encoding formats of the external chips (both the LED drivers and the real-time clocking chip) and the formats that are used internally in the microcontroller memory. A large number of auxiliary functions are defined to simplify these lengthy conversions, and make the code more compact. The interpretation of the instructions is necessarily complicated and lengthy because each instruction in the instruction set is designed to do something different from the others; there is only so much sharing of code that can be done to minimize its expanse.

During normal parsing operation, the external interrupt ISR sends the newly updated display buffer to the LED drivers, at a rate of execution which is timed by the persistent 32Hz clock rate applied by the PCF8563P chip to the microcontroller external interrupt pin INT0. The exception to this is the millisecond timer mode, which must be timed using the on-board crystal because the PCF8563P uses a 32.768kHz crystal, whose period is not an integer divisor of 10 milliseconds. In this mode, the external interrupt is disabled, and a 8-bit counter/timer compare-match interrupt internal to the microcontroller is activated to accurately time 10 millisecond interval steps and update the screen.

The software implements a low-power sleep mode with the screen turned off when the user pushes the power button. However, the Bluetooth chip, the regulator, and the clocking chip remain on during this time. In spite of this, the power consumption is expected to be much less than with even a handful of segments illuminated on the display.

Parsing of the instructions and time intervals read from memory is handled in a large switch statement, whose cases implement the functionality specified in the instruction set. For example, the Set Clock instruction, when encountered, flashes the hours, prompting for the user to cycle through to the desired hour. After the user hits Enter, the infinite hours-blinking loop escapes, and program execution enters an infinite minutes-blinking loop so the user can specify the minutes. After escaping this, the values are written to the clock chip to keep accurate time, and parsing continues with the next data index.

The USART ISR decodes the 6 button presses available to the user on the Remote Control tab of the Android app, and calls button-press-handlers. Depending on the state of the pace clock, these handlers either perform no action or changes the clock state as described in the state transition matrix included above in the Design Overview section. Since most button presses are handled with simple "flag-setters" they can be decoded extremely quickly, and we do not have problems with missing interrupts from either the user interaction or the external interrupt from the clocking chip. The main program execution reads these flags and acts accordingly to advance the execution, pause it, parse backwards, etc. Since the ISRs are kept very compact, keeps the button presses are very responsive from a user's perspective.

The exception to the above is the Upload mode, which goes into a fast data-buffering state to record all the bytes received over the UART from the Bluetooth module. This is necessary because the 1024kB data is burst transmitted from the smartphone and we want to keep the upload time to a minimum. A software watchdog timer checks for a timeout condition if the upload is incomplete or interrupted so the pace clock doesn't break down if the uploaded data is incorrect or incomplete. After successful uploading, the uploaded data is written to the EEPROM, the state and parsing variables are reset, and the clock begins executing the instructions and data in its new program/data memory.

clockInterface.h

Specifies macros for all the available registers that can be read or set in the PCF8563P, as well as global configuration settings for its clock output frequency.

clockInterface.c

Initializes the PCF8563P real-time clock/calendar chip settings. Specifies a single function using Peter Fleury's TWI library to either read or write a register in the peripheral PCF8563P chip.

LEDinterface.h

Specifies the port for the SPI communication to the LED controllers and pin definitions for the six connections to the LED controllers.

LEDinterface.c

Specifies a lookup table to turn the numbers and the selected group of letters displayable with the 7-segment screen into one-hot encoding for the seven segments and the period of each panel. Initializes the SPI output, sends dot-correction data once at startup, and sets the communication speed. Uses a 96-Byte brightness value vector, which is selectively null-ed to write different values to the screen. Has a function to send a vector of bytes out the SPI port to the daisy-chain of LED controllers, latches the data, and sets the TLC5940 drivers to DC illumination. Has a function to take in a vector of four digits to display on the four panels, a byte for the colon, decimal places, and a display options character to format the 96-byte long buffer. Fosc/2 SPI clock rate.

twimaster.c

Peter Fleury's TWI library used without modification. See references section at the bottom of this page. 400kHz TWI clock used.

uart_mega32.c

Modified from the provided UART driver for the class to work on an ATmega32.

eeprom_data.h

Specifies macros to encode the bytes for particular instructions that are interpreted by the microcontroller in the pace clock, and initializes a EEPROM vector the size of the capacity of the microcontroller with a sample set of instructions for debugging. Also provides two functions to easily get a byte from EEPROM and to write a byte to EEPROM at particular indices.

The Mobile Application

The mobile application aspect of this project provides a novel way for the user to interact with the pace clock. Conventional (and very expensive) pace clocks either lack in configurability, or ease of use, or even both. The mobile application gives the user a cost-effective and time-efficient way to easily configure the pace clock remotely while providing the user with a much better picture of the contents of each individual routine. The user is able to control the pace clock with a mobile application written in Java and the Android SDK. Named TimeSystem, the application interacts with the pace clock by transmitting data via Bluetooth connection. TimeSystem consists of two tabs: Remote Control and Routine Configuration. The Remote Control tab provides the user with a familiar interface to send commands, while the Routine Configuration tab allows the user to build the desired training routines with an easy-to-use GUI. The application stores a private SQLite database of all 32 fully configurable routines and compiles the database into a 1024Byte file for upload to the EEPROM.

Overall Design

For the user's convenience, the application should consist of intuitive interfaces for the following features:

1. Scanning of Bluetooth devices in range
2. Pairing request for unpaired devices
3. Establishing RFCOMM channel/socket and device connection
4. Transmitting simple "remote control" command bytes
5. Configuring and storing 32 routines with timing events and all instructions
6. Compiling the 1024Byte file to upload to the EEPROM

Remote Control

The Remote Control tab is the first screen that appears when the user first launches the application. If Bluetooth is not enabled on the user’s device, then a dialog will appear asking for the user’s permission to enable Bluetooth. If the user denies the request, then a small notification will say that Bluetooth connectivity is required to interact with the pace clock. By design, the application does not require a Bluetooth connection to perform other functions such as the configuration of individual routines. Once the user enables Bluetooth on the mobile device, the user can touch the hardware “Menu” button that exists on all Android phones to bring up the Bluetooth connectivity options menu. The “connect a device” menu option allows the user to connect to the clock, or other Bluetooth-enabled devices for testing purposes. The “Make discoverable” option makes the user’s mobile device discoverable to other Bluetooth-enabled devices. Generally, the “Make discoverable” feature is not used except in application or device testing.

In the devices menu, the user can also scan for not-yet-paired devices. By touching the desired device, the application will attempt to establish a connection with the selected device. Once a connection with the pace clock is established, the device name for the clock will appear on the top right corner of the screen. At this point, the user is able to interact with the clock by using the buttons on the Remote Control tab. Touching each of the buttons sends a byte of instruction to the clock, and the expected behavior of the clock when each button is touched at different states is outlined in the User Interface State Machine above. However, note that the Upload button behaves differently from the rest of the buttons. Once the Upload button is touched, a dialog asks the user for upload confirmation. After the user touches the OK button, the application sends an upload instruction byte to the clock, waits for a second to ensure that the clock is in upload mode, and prepares the 1KB file for upload.

Routine Configuration

The Routine Configuration tab displays the list of 32 configurable routines to the user. Upon selection of a specific routine, the content of the routine is brought forward to allow user configuration. The user touches the hardware Menu button to bring up two event options:

Add timing event:A timing event serves as the core of each routine. The user can select the desired time interval in minutes and seconds using a custom time picker and indicates whether the clock should count up or down using radio buttons. The user is also able to insert a training message that will be displayed alongside the instruction. Finally, the user can touch the Add button to insert the instruction.

Add an instruction: A list of instructions for the clock is displayed to the user when this option is selected, and the user is able to select the desired instruction to add to the current routine. The instructions Loop and Jump require further user input. More specifically, when the Loop instruction is selected, the application prompts the user for the desired number of loops, whether the clock should display the number of loops remaining, and whether the current loop to insert is an inner loop. When the Jump instruction is selected, the application prompts the user for the routine number to jump to.

All new instructions are added to the end of the current routine. It is up to the user to move each instruction to the desired location within the routine. The user can choose to have each instruction moved up, moved down, or deleted from the current routine by simply touching the instruction. However, the user must make sure that the headers and footers of the loops are in correct order. More specifically, each loop must be properly enclosed by a loop footer and no loop, outer or inner, can exist within an inner loop. To better differentiate the loop headers and footers from the rest of the instructions, outer loop headers and footers are colored green while inner loop headers and footers are colored cyan. Additionally, the user may choose to edit a timing event by long-pressing any existing timing event in the routine.

Screenshots

Results    top

The pace clocked works very well, and the wireless control from the smartphone is very low latency and functionally correct. The routine configuration tab in the Android software is full featured and implements all the instructions we originally included in our project proposal. The remote control tab works as intended and is easy to use with its oversized buttons. The pace clock correctly parses all the instructions and we have iterated on the basic design to give the most informative and intuitive behavior when counting through intervals, looping, setting the clock, powering on and off, etc.

We modified and improved some of the instructions behavior in slight ways, compared to the project proposal. For example, the scheduled start time is no longer encoded in the data memory since then the user would have to re-upload the whole page file to account for delays or day to day scheduling of a routine's start time. Instead, the user is prompted to enter the scheduled start time just as they are to set the clock in the clock setting mode. Skipping through and pausing/resuming timing intervals works as it should, as do all the loop instructions, the jump instructions, the selection modes, the uploader, and the power button. The Android routine configuration tab correctly converts the user's selections into the machine code that is sent to the microcontroller during an upload operation.

There is one undesirable behavior which we believe is caused by the RN-42 Bluetooth module during connection. That is that the first few connection attempts from the smartphone to the Bluetooth module do not succeed. This occurs most notably when we have been controlling the pace clock from one smartphone, and we want to switch to controlling it from another. The RN-42 stores a table of 8 paired devices in a FIFO list, and we believe this problem is just that the Android Bluetooth drivers have a connection-attempt timeout which is shorter than the processing time for the RN-42 to recognize and connect to a different device. Fortunately, this is not a problem after the first connection is made, and connection attempts succeed on the first try after quitting the app (which closes its Bluetooth session by design of the Android operating system) and re-opening it. Furthermore, our app makes it easy to retry the connection with only 2 or 3 taps, since the Bluetooth connection list is available directly from the remote control app. From personal experience, we believe this slowness in hopping between connected devices is common in all low-complexity Bluetooth modules, as it has been an issue with a Motorola hands-free audio device when switching its connection from one cell phone to another.

The method of wiring all the segments by hand is cumbersome, and stresses on the joint between the wire and the PC board (from carrying it around for weeks for this project) occasionally broke connections that needed to be repaired. A package and mounting scheme that is more robust than our kludgey fiberboard and plywood system would drastically improve this, as would monolithic integration of several segments and perhaps the LED drivers on a single printed circuit board. For reconfigurability and ease of performing repairs in this prototype pace clock, the segments are carpet-tacked to sound insulation fiberboard; they would be more securely attached in a real product.

The most satisfying part of this project is pausing and resuming the millisecond timer. Because we disable it by nulling a single ISR mask bit in the microcontroller code, and because the Bluetooth communication is very fast, the result is so low latency that it feels almost like you are controlling a handheld stopwatch! Its actually even better than that, because the buttons on some handheld stopwatches are notoriously bad, and the smartphone touchscreen is so responsive. You can see some of this in the video we have posted. Although the video doesn't do the screen justice (it's really really bright!), the screen looks great, the 100-millisecond steps appear perfectly timed, and the 10-millisecond digit is too fast for the human eye to decipher. There is absolutely no skipping, halting, or stuttering, and there are no problems with missed button presses. Late in the debugging stage, we noticed some glitching of the display segments when running the millisecond timer, but we believe the problem was that the SPI connection to the LED drivers is shared with the STK-500 programmer connection, and that was causing some display glitches. After removing the ribbon cable used to program the microcontroller from the STK-500, the glitching appears to be fixed. We knew from class that problems programming could be attributed to other SPI circuits in your embedded design. This however, was the opposite case: the STK-500 connection was causing problems with our SPI data transmission when we were not programming the microcontroller over it.

All of the above successes are the result of many hours of [coding, debugging, testing] repeatedly.