A Performance Analysis System for the Sport of Bowling
A Performance Analysis System for the Sport of Bowling
A Performance Analysis System for the Sport of Bowling
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
By filtering <strong>the</strong> data, and <strong>the</strong>n counting <strong>the</strong> number <strong>of</strong> samples between <strong>the</strong> peaks, it is<br />
possible to find <strong>the</strong> angular velocity (rpms) <strong>for</strong> each <strong>of</strong> <strong>the</strong> revolutions. In Figure 2-9,<br />
<strong>the</strong>re are between 16 and 17 samples in each <strong>of</strong> <strong>the</strong> revolutions, and <strong>the</strong> time between<br />
samples is 8.333 msec (120 Hz sample rate), yielding an angular velocity <strong>of</strong> 424 to 450<br />
rpms (7.06 - 7.50 Hz). In Figure 2-11, <strong>the</strong>re are between 15 and 16 sample times,<br />
yielding an angular velocity <strong>of</strong> 450 to 480 rpms (7.50 to 8.0 Hz).<br />
One concern immediately apparent from <strong>the</strong> results just obtained is that by using <strong>the</strong><br />
method described (measuring time by counting samples), a difference <strong>of</strong> one sample time<br />
resulted in a change <strong>of</strong> ~25-30 rpms over a range <strong>of</strong> 425-480 rpms (± 2.8%). A finer<br />
resolution in <strong>the</strong> angular velocity calculations is probably required. Ano<strong>the</strong>r concern is<br />
developing a method <strong>for</strong> calculating appropriate cut-<strong>of</strong>f frequencies <strong>for</strong> <strong>the</strong> digital filter.<br />
Suggestions <strong>for</strong> dealing with <strong>the</strong>se problems are presented in Section III.<br />
2.8.5 Communications<br />
The module's s<strong>of</strong>tware UART has turned out to be quite reliable. In an infrared (IR)<br />
wireless environment, <strong>the</strong> proximity <strong>of</strong> <strong>the</strong> communicating devices and ambient<br />
background light infiltration are <strong>the</strong> two main concerns. The proximity <strong>of</strong> <strong>the</strong> devices is<br />
fixed at about 1 3 / 8 " (1.375"), as long as <strong>the</strong> user does not remove <strong>the</strong> COMM wand during<br />
communications.<br />
Normally, an IR filter would be used to block visible light, but in this application,<br />
detection <strong>of</strong> visible light is necessary. By having <strong>the</strong> module detect <strong>the</strong> presence <strong>of</strong> <strong>the</strong><br />
COMM wand (by looking <strong>for</strong> a very low light level), <strong>the</strong> module can assure that<br />
background light infiltration has been reduced to an acceptable level be<strong>for</strong>e initiating<br />
communications with <strong>the</strong> wand.<br />
One recurring problem was encountered that will be fixed in a later version <strong>of</strong> <strong>the</strong> module<br />
s<strong>of</strong>tware. During <strong>the</strong> upload portion <strong>of</strong> <strong>the</strong> "Transmit" command, if <strong>the</strong> COMM wand<br />
was moved such that light infiltrated during <strong>the</strong> wand's reception <strong>of</strong> <strong>the</strong> EEPROM<br />
contents, <strong>the</strong> data file could be corrupted without detection by <strong>the</strong> MASTER program.<br />
There is no handshaking going on during this portion <strong>of</strong> <strong>the</strong> exchange, and if <strong>the</strong> COMM<br />
wand is positioned just right, it is possible <strong>for</strong> <strong>the</strong> 120 Hz fluorescent noise to simulate<br />
repeated START bits. The wand continues to see START bits, and consequently continues<br />
to receive data until it has counted 512 bytes, at which time it proceeds to process <strong>the</strong><br />
data.<br />
Suggested improvements <strong>for</strong> <strong>the</strong> communication routines are discussed in <strong>the</strong> "Future<br />
Work" section.<br />
2.8.6 Battery Life<br />
A major design goal was to limit <strong>the</strong> overall current drawn by <strong>the</strong> module. Lithium coin<br />
cells are rated in milliamp-hours (<strong>the</strong> number <strong>of</strong> hours <strong>the</strong> battery can supply one<br />
milliamp <strong>of</strong> current while maintaining its rated battery voltage). Several different<br />
techniques were used to limit <strong>the</strong> current draw <strong>of</strong> <strong>the</strong> module. The TSL251 light sensor is<br />
turned <strong>of</strong>f when not in use, reducing current draw by 800 µAmps. While <strong>the</strong> module is<br />
running, <strong>the</strong> 87C752's IDLE mode is used between sample times. This cuts <strong>the</strong> average<br />
current draw <strong>of</strong> <strong>the</strong> module from 3.5 mAmps to under 2.0 mAmps. Extensive use <strong>of</strong> time<br />
outs has also helped to limit <strong>the</strong> run time <strong>of</strong> <strong>the</strong> module. For any given shot, <strong>the</strong> average<br />
current draw is 2.5 mAmps <strong>for</strong> 3-4 seconds, yielding 7.5-10 mAmp-seconds per shot.<br />
33