Tuesday, February 14, 2012
A Wireless Programmable Pace Clock with Android Bluetooth Control
This original design achieves the functionality of commercailly available pace clocks but with an intuitive user interface that goes beyond anything that is available in the current marketplace, all at a small fraction of the cost.
The clock runs from an Atmel ATmega32A microcontroller and a host of peripheral integrated circuits with a Bluetooth connection to an original Android smartphone application to configure swimming workouts, timing intervals, and real-time wireless control of the clock's features.
A pace clock is a large format clock used to time intervals in athletic training, most commonly in swimming or track. Modern pace clocks are large format 4-digit LED displays, with either a grid or 7-segment layout. Swimming workouts are typically organized in advance of a swim practice and include a series of different strokes and drills at various speeds and of various distances. The interval timing can be done with a single count-up clock display, requiring the swimmers and coaches to calculate the appropriate start times and estimate their pace mentally by following a clock. Alternatively, as many proactive collegiate swim coaches do, the day’s or week’s workouts may be programmed into a programmable pace clock to automatically time the swimmers’ sets. This means, for example, that the clock would either count up-to or down-from the interval time (eg. 1 minute and 20 seconds) and then move on to the next interval. This improves workout efficiency by ensuring that the swimmers start the next set on time, and that they receive accurate feedback about their performance and pacing.
An item within a workout will convey to the swimmer (usually in this order): the number of repetitions, the distance, the stroke with optional comments, and an interval. For example, a swimmer might see the following item in a day’s workout:
This indicates the swimmer must swim 100 yards (or meters, depending on the pool) of the butterfly stroke 10 times, on an interval of 1 minute and 50 seconds, with the first half of each 100 being a butterfly drill and the second half being the standard, full stroke. A pace clock makes this timing possible, and a programmable pace clock makes it easier by counting up to 1:50 (which allows swimmers to see their pace as they finish each 100) or down from 1:50 (which allows swimmers to quickly see how much time remains before they must start the next 100 fly).
Swimming workouts are structured with repetition, loops, and variable intervals, basically a series of the above items that may appear as the repetends of loops. Loops may also appear in the repetends of loops. There are thousands of workouts which can be found online for further clarification.
Pace clocks are expensive and can be cumbersome to use for those not willing to learn their operation and programming method. One of the leading companies selling pace clocks is Colorado Time Systems. A wirelessly programmable pace clock such as the one we have designed and built costs roughly $900-$1400, not including the programmer which costs $440 and is required for programmable workouts. There are additional features on these systems which we did not intend to implement. These may account for some of the difference in expected price between our design ($75 maximum) and the $1k-$2k commercial systems. These differences include battery operation, multiple screen-controlling with a single ($440) controller, and standard interfacing with a much larger product line, including race-accurate timing pads for competition. Many swim teams, particularly in summer swim leagues, cannot afford such elaborate timing systems and cannot justify a fully integrated race timing solution since they rent time at public pools and use rather low-tech timing solutions for races: parents equipped with stopwatches.
"This would be extremely beneficial to competitive swimming at all levels: 'age-group' to collegiate!"
Christaina DiMaria, Cornell Swim Team Captain
By designing a wireless, programmable pace clock in the price range of smaller swim programs, and enabling its wireless control through a Google Android Smartphone App, we have produced a viable product with a much broader buyer market than the currently available commercial systems. To our knowledge, no such product exists at this time. The coupling of a Android-based controller (and its intuitive, simple interface) with reliable and cost effective microcontroller operation can vastly improve the cost effectiveness and usability of these training tools to make pace clock timed workouts accessible to more athletes.
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.
The greatest impact of our project is that it brings high-functionality wirelessly programmable pace clocks into a price range that small swim teams, local pools, and even individual athletes can afford while simultaneously enhancing the user interface with intuitive, ubiquitous Bluetooth smartphone control. To our knowledge, a pace clock with this level of cross-platform integration (supported by open source instruction compilation and wireless interface commands) does not yet exist in today's marketplace. Compared to the sleekness of smartphone control, existing pace clock systems use specialized proprietary programmers with physical buttons, tiny alphanumeric LCD screens, and larger packages.
Buying only small quantities of the required parts, we were able to build a prototype wireless programmable pace clock for nearly an order of magnitude lower cost than the commercially available Colorado Time Systems clocks. This comparison is not completely fair, since their systems are much more polished, have more features, include technical support, operate with a suite of other products, and are made by people with nonzero labor costs (unlike ECE students). With scaled up production, even greater savings could be achieved, or profit for us if we sell these clocks at a fraction of the price of the current commercially available systems.
Additionally, the simplified, open-source format of our instruction set means that any electronic device can control (or program, if sufficiently sophisticated) the pace clock. Drivers can be written to adapt control to any software program that a coach likes to write workouts in, including Excel and the commercial HyTek meet manager software. By moving the workout design and programming method into software (with mouse clicks or touch screens rather than physically actuated buttons), it can be made easier and more intuitive to use, as well as allow a wider range of computing media to interact with the pace clock.
With reference to the IEEE code of ethics, we strove to complete this project working in an ethical manner, and to ensure that the finished project does not violate any ethical considerations. In particular, we have assisted colleagues (several other groups) working on similar projects as well as completely unrelated projects. We have had friendly interaction with our professor and with other students that were professional, respectful, and beneficial to our project and, hopefully, to theirs. We have reported our results accurately, making only realistic truthful claims about our successes, and acknowledging our mistakes. We have sought and accepted criticism in the design of this project, and cited the sources of other people's code that we used (all with permission). We have referenced the companies whose products are similar to our project, reviewed their patents, and explained why we believe we are not infringing on any of their intellectual property in the design of our pace clock.
We have also offered to provide our experience, time, and circuit boards to help other people add Bluetooth control or communication to their designs. We have engaged in discussion and explanation of the projects being undertaken by our classmates, and both provided and received suggestions about how the projects could best apply microcontroller technology to realize embedded systems that maximize their potential and impact. The IEEE code of ethics also makes references to the engineering decisions we make to design electrical systems, and how their design, misuse, or impact should be consistent with “the safety and welfare of the public” and not expose others or their property to damage. For safety and usability considerations such as these, please refer to the safety section of this website.
During the Android application development process, some sample source code and tutorials were consulted. Copyright disclaimers can be found in the project source code. The README file in the project also contains a breakdown of the sources used. The references mainly consists of material from Google's Android Open Source Project and a tutorial by Josh Clemm, both of which can be found in the References section.
There are some safety considerations with having an electronic system close to a pool. There are a number of mitigating factors related to this concern. Many manufacturers adopt administrative control—the clock must not be placed near the pool; for example, it could be mounted on a wall rather than sit on the pool deck. The commercially available pace clocks are splash resistant but not waterproof. Adding a plexiglass font panel (beyond our budget) would make it almost as splashproof, and a full enclosure would bring it to the level of commercially available systems. This type of timing system is not intended to be submerged in the water; electrical shorts would occur and it would damage the integrated circuits. Other systems use batteries to avoid tripping on a cord extending to the wall outlet, although that certainly complicates electronic measures if the system does fall into the pool with high capacity batteries. Pool water is fairly conductive, so all electronics would quickly be shorted within very short distances if the unit did fall into the water. We are not using batteries for this system, so a knot limiting the length of the power supply cord can be placed to ensure that the pace clock becomes unplugged from either the wall or its rear DC power connector before the unit comes within reach of the pool edge.
Our project is not intended to be used by people with special needs such as blindness or a physical/mental disability which prevents them from pushing buttons on a remote control or seeing the LED display. The system is very easy to use, and simplified graphical interfaces on the Android workout configuration tab and the remote control tab allow even computer illiterate users to easily design a workout and upload it to the pace clock. Simplified controllers that do not implement the configuration or uploading functionality are a possible future addition.
Another safety concern is with regard to epileptic users and the fact that 3-4% of epileptic people may have a seizure triggered by strobe lights flashing in the range of 15-20Hz. (source). In recognition of this issue, we have designed our “rave mode” screen demonstration conservatively, and present below a number of mitigating factors to explain why the screen should not cause problems for people with photosensitive epilepsy.
There are a variety of mitigating factors related to this concern. Our system never updates the screen faster than 4Hz except during the millisecond-timer mode, which counts upwards at 100Hz (counting 10-millisecond intervals), so the common trigger range is avoided. Furthermore, the fact that numbers are being counted means that not all of the digits are being changed simultaneously, and the pattern of illuminated segments is not a strict on/off strobe effect, but instead it is a rearrangement of the illuminated segments. Distance is also a mitigating factor, since with a wall-mounted pace clock, users will be at least 10 feet from the clock and it will occupy only the periphery or a small fraction of their vision in most cases. Additionally, since the display is fairly directional, a photosensitive epileptic sufferer will not be subjected to strong illumination simply by being in the same room (as with the ultra high brightness of a strobe light, which can illuminate an entire room). Finally, and perhaps most importantly, the changing digits represent only a fraction of the total light intensity, which is the main concern for photosensitive epilepsy—that is, out of all the illuminated LEDs, only a few segments switch on or off at each cycle, so the variation in light intensity is not like a strobe light (strong on/strong off), but rather a small fluctuation of total light intensity as more or fewer segments are illuminated.
The radio frequency radiation of our design is addressed in the legal consideration section below.
Our project will plug into a wall outlet, but all power safety standards are already handled by the laptop power brick we are recycling from a broken HP laptop. Power bricks provide isolation through transformers and a rectifying bridge, ensuring that we cannot damage electrical systems (or feed power back into the grid) by making electrical wiring mistakes on the DC output end of the power brick. The inputs and outputs are current-limited. This is essentially just as safe as using the 9v power supplies that we do for the STK500 and target boards. The only difference is that our power supply runs at 18.5v to provide sufficient overhead to drive 9 LEDs in series between the power rail and ground.
We have used a DC/DC switched buck regulator to use the 18.5v power supply to power our 3.3v electronics. This regulator switches at 500kHz, and is reported by Texas Instruments to be within the FCC’s limit for allowable radiation at that frequency. The FCC regulates RF power radiation at frequencies above 9kHz. A measurement system is not available in the lab to confirm this, but since the trace length between the regulator and its inductive/capacitive smoothing filter were minimized (less than an inch on the circuit board), and the signals were confirmed to have mostly DC content after smoothing, we believe that the radiated power from the regulator and power circuitry is insignificant—it certainly does not cause problems with our Bluetooth radio link, which operates at a higher band.
The Bluetooth module we used operates in the 2.4 GHz Industrial, Scientific, and Medical (ISM) Band, and is governed by Part 18 of the FCC rules. The device is a Class-2 Bluetooth module, with a maximum transmit-power of 4dBm, lower than the cutoff for it being labeled as a Class-1 device. The Bluetooth module we used in our circuit, as well as any Bluetooth module included in our US-legal HTC smartphones, are licensed devices and guaranteed by the manufacturer to comply with the FCC maximum power regulations, frequency hopping standards, and interference specifications. Even with improper inputs, the Bluetooth module cannot violate the FCC interference and power limits, and it effectively serves as a transparent link between the phone’s application and the microcontroller’s received data from its USART hardware. The total radiated power from our Bluetooth module is on the order of 0-4dBm, which is an order of magnitude less than the maximum permissible radiated power of a cell phone (33dBm), so we do not expect human radiation absorption to be an issue with our design. Furthermore, humans will not be very near to the pace clock, and the phone will be held an arm’s length away from the user when using its buttons (not near the brain, as it is with cell phone conversations), so there is no significant RF radiation concern with our design.