Section 4
A First Implementation
This section details the first realization of a system implementing the Snap! toolkit. The same printed circuit board contained both the network and input/output modules. However, the design allowed a system designer to cut the board in half, physically severing the two modules. Connectors could then be soldered to provided pads, allowing the two modules to function independently from their original fabrication. A separate power supply board attached to a single node. The supply provided regulated power to the nodes from battery input.
4.1 Preliminary information
4.1.1 PIC 16F876
The first implementation of Snap! used the PIC 16F876 from Microchip as the processor for the network and input/output modules.[citation][www site] The 16F876 is an 8-bit RISC processor. It has 8096 words of flash program memory, 368 bytes of RAM, and 256 bytes of EEPROM data memory. The '876 features 3 timers, a 10-bit analog-to-digital converter (ADC), a synchronous serial port (SSP) which can be used for I2C serial communication, a universal synchronous-asynchronous receiver transmitter (USART) which can be used for RS-423 communication, and many digital input/output pins. Custom Computer Solutions [citation][www site] produces a C compiler that targets many PIC microcontrollers, including the '876. Use of the compiler to allowed development in a readable and maintainable high-level language.4.1.2 THE INTER-INTEGRATED CIRCUIT (I2C) COMMUNICATION SPECIFICATION
The first network modules used the Philips Semiconductor I2C networking specification to communicate.[citation][www site] I2C uses two signal lines, one each for clock and data. All devices are on the same two-wire bus. The specification allows either 7- or 10-bit addressing, supporting 127 or 1023 devices. The specification reserves a general call address to which all supporting devices respond in addition to their own. The I2C bus is a multi-master bus, allowing more than one device to control it. I2C detects contention when two devices attempt to control the bus simultaneously and defines an arbitration procedure to prevent data loss. The I2C signal lines are each normally pulled high through resistors. A device wishing to generate a low signal on the bus drives the line low; to generate a high signal it stops driving the line and allows it to be pulled high. Many manufacturers supply devices that communicate using I2C.
|
| FIGURE 9: First implemented networks A completely wired I2C bus and a hybrid I2C/wireless network comprised the first two implemented network interface modules. |
The network module linked to the input/output module with five lines: power and ground, I2C clock and data, and a traffic request line. Power and ground lines allowed an entire node to be powered from a single source, be it the network bus or a power supply board. The network module communicated with the input/output module via an I2C bus separate from that used for inter-node communication. The PIC on the network module used two digital input/output pins and software routines for this second bus. The interrupt request line was used by the input/output module to indicate that it had a packet to send.
Two light-emitting diodes (LEDs) and an additional connector for serial output, both controlled by the PIC, provided debugging information.
The input/output module transmitted a complete packet to the network module in several transactions. When the input/output module had a portion of a packet to send to another node, it would raise the traffic request line connecting the two modules. Raising the traffic request line triggered an interrupt in the network module. The network module addressed the input/output module on their I2C bus and read the packet portion from the input/output module. When the input/output module had sent a complete packet, the network module entered the master mode and sent the packet on the inter-node I2C bus. The network module could only buffer one packet from the input/output module. It would not react to the traffic request line being raised until it successfully sent the current packet or a time-out occurred.
4.2.2 WIRELESS
The creation of a wireless network module eliminated cumbersome wires. A PIC 16F877, similar to the 16F876 described above, connected to the inter-node I2C network described above. The 16F877 also connected to a RF Monolithics TR1000 wireless transceiver.[citation][www site]
The network using the wireless network modules was actually a hybrid. A collection of nodes spaced only a few inches apart communicated via the wired I2C network described above. Each network module contained a table listing the nodes that were local to it. When a network module had a packet to send, it checked the destination address against the table to discover if the other node was local. If so, it sent the packet normally. Otherwise, the packet was sent to the wireless network module.
Upon receiving a packet from the I2C network, the wireless network module transmitted it. The module first determined whether any other wireless module was currently transmitting. When none were, the module began by sending a series of synchronization bytes to train receivers to the correct timing. Following these, it sent a start-of-packet byte followed by a network identification byte. The network ID byte allowed several wireless networks to operate in proximity. Any wireless module receiving a different network ID differing from its own ignored the rest of the packet. The transmitter then sent the packet, followed by cyclic redundancy check (CRC) byte for simple error detection and noise rejection. The wireless network module then entered receive mode, waiting for data either from the I2C network or the wireless network.
The wireless network module was usually in receive mode. When the module began receiving synchronization packets, the circuit adjusted its timing. After receiving the start-of-packet byte and verifying the network ID, the module received and buffered the entire packet. The module then computed the CRC for the packet and checked it against the received CRC. If they matched, it transmitted the packet over the inter-node I2C bus to the destination node. Otherwise, it discarded the packet as corrupt. The wireless network module then returned to receive mode.
 |
| FIGURE 10: Snap! node implementation The first Snap! implementation combined both input/output module and network module on one printed circuit board that could be cut in half to interchange components. |
The input/output module provided an expansion connector that connected to its transducers and actuators. The expansion connector provided power and ground lines directly from the input/output module as well as a switched power line controlled by the PIC. The jack contained pins connecting to the PIC: two for the USART, four analog-to-digital channels, one to the external interrupt pin, and one standard digital input/output pin. The USART, analog-to-digital, and external interrupt pins could all be reconfigured as normal digital input/output pins if their additional functions were not needed.
The input/output module also had two LEDs controlled by the PIC for displaying debugging information.
The sensor nodes in first Snap! implementation used two broad types of measurement variables: those that contained a single value and those that contained an array of sampled values. When a variable with a single value was accessed, the input/output module would take a single reading from the transducer, perform any necessary conversion and calculation on the value, and report it. In some cases, the transducer data was cached. When the variable was accessed, the current time was checked against the time at which the data was cached. If there was insufficient difference between the two times, the cached data was used; otherwise a new measurement was taken and reported. Variables with arrays of values operated differently. When the variable was accessed, the module began taking samples from the transducer at the configured sample rate. The node stored the samples in the external EEPROM. After completing the sample session, the input/output module incrementally read the stored samples from the EEPROM, creating and transmitting a packet for each sample.
Following initialization and bootstrapping, the input/output node entered an infinite loop. While in the loop, it would respond to incoming packets and run its behavior scripts.
Each input/output module had the capability to run two or three behaviors. Unless other operations, such as responding to a packet or executing another behavior interfered, the behaviors ran once each second. By setting a behavior to trigger on the time variable differing from its last successful trigger by a certain amount, an input/output module reported automatically at regular intervals. This was the default behavior for the input/output modules in the first implementation of Snap! The report intervals varied according to the rate at which the transducers were expected to change, i.e. short intervals for a GPS receiver, longer intervals for temperature.
Currently, ski designers and equipment testers rely on laboratory tests and reports from people using the equipment in the field. While both of these data sets are useful, combining quantitative results from wired people using instrumented skis in the field provides much more precision than is currently possible. Additionally, data that may simply not have been available to designers before, such as whether a tester's tiredness is due to an inherent design flaw in the equipment or the skier's level of exertion the previous day, will help eliminate guess work. As described below, two domains of inquiry, as well as the challenge of measuring data not previously recorded, provided an ample test for the design requirements and functions of the Snap! toolkit.
Work done at Harvard University on the energetic cost of skiing relied on roller skiing and treadmills during experimentation. The conclusions state:
This example concretely states that a ski system such as SWAT would be of direct use to researchers studying skiing.
One important aspect of cross-country skiing is the athlete's technique. There are two main styles of cross-country propulsion. The traditional diagonal stride places the skis parallel to each other. The arm of the ski being pushed backward is placed forward, diagonally opposite of the ski. A much faster technique, under constant refinement, is the skating stride. A skating skier sets the skis in a V-position, using the edges to drive him forward. The poles are either both used simultaneously and symmetrically or in a manner that more closely resembles the diagonal method of poling. As athletes train and refine their own technique, data about how a change effects the overall physical being of the athlete would be useful in determining whether a change has a net positive or negative effect. The holistic measurement of overall time around a track can only indicate so much.
Coaches and athletes alike often have only limited biometric data available to them. While secondary effects, such as tiredness, increase in heart rate, and poor training times for a given day, may point to a problem, it may difficult or impossible to diagnose. Biometric data collected in real-time may be able to help a coach or athlete tailor a particular part of a workout for maximum effectiveness. A system capable of indicating that an athlete is pushing the aerobic threshold on an easy day, or not pushing hard enough on a hard day, may provide the extra information needed to take the athlete to the next step of competitive excellence.
Changes in any one of the above variables can have an effect on important observed measurements of the skiing system. Perhaps chief among these is the speed at which the skier moves forward. This singular measurement may be further influenced by the amount of the ski in contact with the snow, the degree to which the ski grips the snow versus sliding along it, and the ease with which the ski maintains its forward path.
Research done at the University of California-Berkley and Institute for Medical Physics in Austria both relied on instrumented skis to measure the ski as a dynamic system and the characteristics of a ski gliding on water. Two references:[citation][citation]
To those who design skis, the ability to directly measure the effects of the design variables on the performance of the ski will allow for improvement of the scientific design process. Skis on the market today have remarkably similar designs. It is unlikely that uniform ski designs are equally suitable for men, women, and children. For those who sell skis, detailed measurements will allow a better match to an individual when selecting equipment. Being able to dynamically measure how differing cambers effect the stride of a potential customer will offer a great deal of improvement of the current technique of passing a sheet of paper beneath the skis while the customer is in the store. Finally, such measurements will again prove useful to the athlete. Being able to look at the current speed of the ski may improve enjoyment of the sport as well as provide further feedback about technique and the day's wax application.
Finally, the ski system represented a valid use of the Snap! system as a tool for prototyping. As detailed in the composition section below, the platform comprised sensors of both broad and limited use. Sensors such as the heart rate monitor, temperature sensor, and barometric pressure sensor would undoubtedly be used in many systems. This required that they be constructed for reuse and configurable to their current system. The sensors on the ski, such as the boot angle or snow temperature sensors, would probably not be reused. Thus, it was important that they be easy and quick to build, so as not to spend too much time on a one-time use component.4.3.2 SOFTWARE
The software for the input/output module consisted of several core functions organized in libraries. These library functions made up the bulk of the code that resided on each input/output module. Additionally, each node contained specialized code for its particular transducers and actuators.4.3.2.1 Network module interface code
One group of functions provided an interface to the network module, allowing discrete packet portions to be sent to the network module. The input/output module also implemented an interrupt routine for I2C traffic. When addressed by the network module, the PIC would vector to the routine. According to the function dictated by the network module, the routine would send the traffic that the input/output module had ready or receive a packet from the network module. After receiving a complete packet, the routine would set a flag to notify the main loop that a packet had been received.4.3.2.2 Variable implementation
The first implementation of Snap! did not include all the variables specified in the design. The subset of implement variables comprised ds.id, ds.meas, bhv.0-2, measName, measName.format, and time. The variable values were stored in structures on the PIC, either in RAM or in the internal EEPROM. These structures were set when the PIC was first programmed, but could be dynamically altered through set packets or behaviors. Only the initial variable values had to be changed, so the code surrounding the accessing of these variables did not. One of the PIC's internal timers was used to implement the time variable.4.3.2.3 Packet response
Upon notification through a flag that a packet had been received, the input/output module responded as described in the design specification. As noted above, only a limited set of variables were implemented. The modules ignored operations that referenced any variables they did not implement.4.3.2.4 Behavior implementation
The first implementation of the Snap! toolkit contained a relatively simple behavior script. A behavior consisted of a triggering condition and a specification for a packet to be generated if the triggering condition was met. The triggering condition comprised a comparison opcode and, depending on the opcode, one or two operands. The supported opcodes consisted of two parts. One half specified a basic comparison: greater than, less than, equal, or not equal. The second half indicated what the operands were: two current variable values, a variable value and the value of the same variable when the behavior was last triggered, a variable value and a constant, or the difference between the current variable value and the value of the same variable when the behavior was last triggered and a constant. The packet specification consisted of a destination address, packet opcode, and variable name.4.4 SWAT: Skiing With Advanced Technology
The implementation of the Snap! toolkit described above, without a system to apply it to, was little better than the specification in terms of demonstrating the usefulness of the Snap! concept. Cross-county skiers and their skis presented an intriguing and valid challenge for the Snap! toolkit.4.4.1 SWAT MOTIVATION
Cross-country skiers and their skis represent a complex, dynamic system. This alone makes them a useful target for testing the implementation of a sensor network built using the Snap! sensor toolkit. Cross-country skiing, which has been used as a means of transport since pre-historic times, and draws a large recreational following today, has been seriously neglected in studies. A survey of articles on the topic of skiing in general reveals few papers. Most focus on the frictional and vibration dynamics of downhill skis on a short test run.4.4.1.1 The athlete
Cross-country skiing presents athletes with a range of distances similar to those found in long distance running events. Olympic distances range from five kilometers to the greater-than-marathon distance of fifty kilometers. As with any sport, dedicated athletes practice for hours each day in a quest for excellence. Several training aids currently exist to help maximize the effectiveness of this training. Heart rate monitors may be worn to roughly indicate the exertion level of an athlete. Training on machines can provide certain quantitative measurements of force and technique. However, no system yet exists to gather useful data about the athlete as he or she trains in the field.Although propulsive forces during roller skiing and snow skiing differ because of effects of wind resistance and the friction between the ski and the skiing surface, our results show that metabolic rate values depend on the application of ground force regardless of the amount of force required.
4.4.1.2 Equipment
A wide variety of skis are available for all sorts of snow types: short, metal-edged skis for backcountry touring; waxless skis for warmer, wetter snow; and waxable skis for those who prefer to optimize their gliding and gripping surfaces. The ski itself has a characteristic camber that determines how hard the skier must press down on the ski to cause the "kick zone" to catch the snow and move the skier forward. Debate as to whether longer, slimmer skis or shorter, fatter skis provide better performance remains unresolved. In a single system, fixed variables include length, width, camber, rigidity, and materials of the ski, as well as the length and stiffness of the poles. Any single skiing excursion adds air temperature, temperature, humidity, and compaction of the snow, and the choice of waxes applied to the base of the ski for both grip and glide. This list includes only the most important, readily observed variables of the system.[citation]
| Sensor type | Variable type (single reading or sampled) and reporting interval | Sensor information and description |
|---|---|---|
| Sensors carried in backpack | ||
| Heart rate monitor | Single reading / 30 seconds | Polar OEM module and coded chest strap[citation][www site] |
| External temperature sensor | Single reading / 4 minutes | National Instruments LM135 [citation][www site] |
| Barometric pressure sensor | Single reading / 2 minutes | Motorola MPX5100AP [citation][www site] |
| Sensors mounted on ski | ||
| Orientation | Single reading / 30 seconds | Precision Navigation TCM2 provided compass direction, pitch, and roll of the ski[citation][www site] |
| Accelerometers | 17 readings over 2.25 seconds / 30 seconds | Analog Devices ADXL210AQC - Two two-axis accelerometers were gave acceleration in three directions: parallel to the ski length, parallel to the ski width, and vertical[citation][www site] |
| Toe angle | 16 samples over 2.10 seconds / 30 seconds | Interlink Electronics #402 force sensitive resistors and conversion circuit - Measured the of the boot to the ski base [citation][www site] |
| Boot flex | 16 samples over 2.10 seconds / 30 seconds | Abrams Gentile Entertainment bend sensor and conversion circuit - Measured the angle where the boot flexed, between the ball of the foot and the base [citation] |
| Heel pressure | 16 samples over 2.10 seconds / 30 seconds | Interlink Electronics #406 force sensitive resistor and conversion circuit - Measured the amount of pressure applied to the heel of the boot |
The Iceland system used a PalmIIIx personal digital assistant (PDA) [citation][www site] to log the data reported by the sensors. An input/output module was configured to send the packets it received over the serial transmit line in the expansion connector. The PDA's serial port connected to the expansion connector. The I2C-to-serial node achieved rough time stamping by sending a fixed string once every ten seconds. A terminal emulation program, Online, wrote the data received over the serial port to a file on the PDA. The contents of the file could later be downloaded to a personal computer for further analysis. The PDA contained 4 megabytes of storage, enough to store all the data recorded in one day.
| Sensor type | Variable type (single reading or sampled) and reporting interval | Sensor information and description |
|---|---|---|
| Sensors carried in backpack | ||
| Heart rate monitor | Single reading / 30 seconds | Polar OEM module and coded chest strap |
| External temperature sensor | Single reading / 30 seconds | National Instruments LM135 |
| Barometric pressure sensor | Single reading / 30 seconds | Motorola MPX5100AP |
| GPS receiver | Single reading / 30 seconds | Trimble Lassen board with 28367-00 antenna - reported latitude, longitude, altitude, horizontal speed, altitude, and time of day [citation][www site] |
| Sensors mounted on ski | ||
| Compass heading | Single reading / 30 seconds | Precision Navigation Vector 2X |
| Snow temperature | Single reading / 30 seconds | National Instruments LM135 - mounted on only one ski per pair |
| Accelerometers | 75 readings over 3.75 seconds (20 Hz) / 30 seconds | Analog Devices ADXL210AQC - Two two-axis accelerometers were gave acceleration in three directions: parallel to the ski length, parallel to the ski width, and vertical |
| Toe angle | 75 samples over 3.75 seconds (20 Hz) / 30 seconds | Interlink Electronics #402 force sensitive resistors and conversion circuit - Measured the angle of the boot to the ski base |
| Sensors mounted on boots | ||
| Boot flex | 75 samples over 3.75 seconds (20 Hz) / 30 seconds | Abrams Gentile Entertainment bend sensor and conversion circuit - Measured the angle where the boot flexed, between the ball of the foot and the base |
| Heel pressure | 75 samples over 3.75 seconds (20 Hz) / 30 seconds | Interlink Electronics #406 force sensitive resistor and conversion circuit - Measured the amount of pressure applied to the heel of the boot |
In order to make the collected data more useful, the timing of the measurements from the ski and the boot (accelerometers, toe angle, boot flex, and heel pressure) was coordinated. The left ski accelerometer node served to synchronize the others: when its measurement variable was accessed, it first sent an acknowledgment packet, with its payload set to the SYNC value, to the other sensors. All the coordinated nodes waited 50 milliseconds after receiving the synchronization packet. Then they all took their samples as configured and reported. As long as the interval between two synchronization packets was less than 40 seconds, each coordinated sensor would only measure and report with the others. The coordinated nodes would report spontaneously if they did not receive a synchronization packet. While this reduced the usefulness of the collected data, it eliminated the left acceleration node as a single point of failure.
 |
| FIGURE 13: Norway SWAT system diagram Three different containers held the sensors for the Norway SWAT system: one on each ski, one on each boot, and one in the backpack. |
The Norway SWAT system used a custom designed logger. The logger contained a PIC 16F874, similar to the PIC 16F876 described earlier in this section. The 16F874 connected to the inter-node I2C network and a SmartMedia holder. [citation][www site] SmartMedia cards are about the size of two postage stamps, wafer-thin, and can store between 2 and 32 megabytes. Since SmartMedia cards use flash memory, they provide non-volatile storage. A 4 megabyte SmartMedia card stored data from a complete day of skiing. The logger stored all packets addressed to it. The logging board could be removed from the network and the data transferred via RS-232 connection to a personal computer for further analysis.
 |
| FIGURE 14: SWAT system The author models the SWAT system he wore in Norway. Notice the wire trailing from backpack to pants and boxes for power and ski sensors mounted on the skis. |
Section 5 - Results and Evaluation
Send comments to the author