CHAPTER 3 WIRELESS SENSOR NETWORK
3.3. F IRMWARE AND S OFTWARE D ESIGN
3.3.4. Implementation of the ZigBee Protocol Stack
This ZigBee protocol stack uses an Operating System (OS) called the CMX Tiny real time multi-tasking operating system, which provides a true preemptive operating system and a wide range of functions, and uses as little RAM as possible. We port the CMX Tiny real time multi-tasking operating system on the TI MSP430 platform, and the RTOS supports many kernel functions to handle interrupts, timer, task scheduling and resource management of the hardware. First of all, the firmware system initializes the Universal Asynchronous Receiver/Transmitter (UART), the serial peripheral interface
(SPI), the micro-controller unit (MCU) and the MAC, and then it creates three tasks, the timer task, ISR task and system task. Finally, these tasks are initiated.
This study implements the network layers of the ZigBee protocol stack based on the MAC layer.
When the ZigBee chip receives a packet or sends a packet, its ISR is run. The ISR is responsible for saving the event status of RX or TX and then waking the ISR task to process receive events or transmission events. The firmware employs four tasks to handle four necessary jobs, including interrupt handles, transmission of bio-signals, maintenance of the system timer and device functionality.
According to ZigBee specifications, the device type is divided into three types, the end device, router and PAN coordinator. The system task is responsible for implementing the functionalities of each device in PAN.
3.3.4.1. End Device with Sensor
This device is a passive type device that is responsible for sending physiological data to the associated router. This study uses two sensors, an ECG sensor and SpO2 sensor. The output data of the ECG sensor is an analog value, so it should been sent into the ADC of the MCU for conversion. When the conversion of ADC is completed, the ADC12 ISR is run. The ADC12 ISR is used to obtain conversion results and send them to the associated router. Because the SpO2 sensor outputs sensing data to the UART, we should connect the UART of the end device with the UART of the SpO2. When the end device receives data from the UART and the process of parsing had been completed, it sends data to the associated device. The hardware structure is shown in Fig. 3-6.
a. ECG Sensor Device a.1. Flowchart Description
The firmware of the end device with ECG sensor has four tasks, including the timer task, ISR task, system task and send task, which are responsible for doing necessary jobs according to their attributes.
These are illustrated below. The flowchart is shown in Fig. 3-5.
Timer Task: The timer task is responsible for waiting for one system tick and storing the TTL (time to live) of packet to the TX buffer.
ISR Task: When the ISR task starts, it enters suspend status until the ISR wakes it. The ISR task is waked when the ISR occurs. The ISR task is used to process the received packet and parse the RX frame if the interrupt is an RX event. Or, it stores the status of packet transmission into the TX buffer if the interrupt is a TX event.
System Task: The responsibility of this device is to join a router according to the results of network discovery and start the send task.
Send Task: When this task has been started, it remains in sleep mode until it receives a start command. If it receives a start command, it is awakened from sleep mode to normal mode to start a timer and the ADC. When conversion of the ADC has been completed, it runs the ADC ISR that is responsible for getting conversion results and sending them to the associated router. When the timer expires, the send task stops sending data to the router and enters sleep mode again.
Fig. 3-5 Flowchart of end device with ECG sensor
Development board
MCU SPI mode ZigBee chip
ECG Sensor ADC Analog input
Fig. 3-6 Hardware block diagram
a.2. Message Flow of the ECG sensor device
When the end device with ECG sensor is powered on, it does network discovery by issuing the NLME-DISCOVERY-request primitive and joins a router of the network according to the discovery results returned from the NLME-DISCOVERY-confirm primitive by issuing the NLME-JOIN-request primitive. Furthermore, it remains sleeping until receiving a start command from the associated router. If the end device with ECG sensor receives a start command, it starts a timer and ADC converter that is used to convert the physiological analog signals of the ECG and sends the results of conversion to the associated router by issuing the NLME-DATA-request primitive. When the timer expires, the end device with ECG sensor stops converting and remains sleeping until receiving a start command from the associated router. The message flow chart of the ECG sensor device is shown in Fig. 3-7.
Fig. 3-7 Message flow chart of the end device with ECG sensor
b. SpO2 Sensor Device b.1. Flowchart Description
The firmware of the end device with SpO2 sensor is comprised of three tasks: the timer task, ISR task and system task, which are responsible for doing the necessary jobs according to their attributes.
This firmware implements a parser of data type 2 for the SpO2; the parser is used to extract the SpO2
value, heart rate value and plethysmographic pulse value from raw data. The flowchart of the SpO2
sensor device is shown in Fig. 3-8, and the hardware structure of the SpO2 sensor device is shown in Fig.
3-9.
Timer Task: The timer task is responsible for waiting for one system tick and storing the TTL of a packet to the TX buffer.
ISR Task: When the ISR task has been started, it enters suspend status until the ISR wakes it. The ISR task is awakened when the ISR occurs. The ISR task is used to process received packets and parse the RX frame if the interrupt is an RX event. Or, it stores the status of packet transmission into the TX buffer if the interrupt is a TX event.
System Task: This task first joins a router according the results of network discovery and remains sleeping until receiving a start command. If the device receives a start command, it starts a timer and polls the UART to determine whether it has received any data. If the UART has received data, the system task uses a parser for SpO2 data type 2 to extract a SpO2 value, heart rate value and plethysmographic pulse value and sends them to the associated router until the timer expires.
Fig. 3-8 Flowchart for the end device with SpO2 sensor
Development board
MCU SPI mode ZigBee chip
UART COM Port SpO2 sensor
Fig. 3-9 Hardware block diagram of the end device with SpO2 sensor
b.2. Message Flow of the SpO2
When the end device with SpO2 sensor is powered on, it first does network discovery by issuing the NLME-DISCOVERY-request primitive and then joins the router of a network according to the discovery results returned from the NLME-DISCOVERY-confirm primitive by issuing the NLME-JOIN-request primitive. Afterwards it remains sleeping until receiving a start command from the associated router. When the end device with SpO2 sensor receives a start command, it starts a timer and parser that are used to extract a SpO2 value, heart rate value and plethysmographic pulse value and send them to the associated router until the timer expires by issuing the NLME-DATA-request primitive.
When the timer has expired, the end device with SpO2 sensor stops sending and remains sleeping until receiving a start command from the associated router. The message flow chart is shown in Fig. 3-10
Fig. 3-10 Message flow chart for end device with SpO2 sensor
3.3.4.2. Router
The router is responsible for scheduling sending time for each associated device according its neighbor table and using hierarchical routing to forward data to specific devices. To reduce power consumption of sensor devices, this study inserts an idle time in the middle of the sending time of two devices. The idle time is adjusted by the scheduler according to number of associated end device and end device‘s attributes that contain type of signal and signal frequency. The time slice diagram of sending times for each device is shown in Fig. 3-11.
Fig. 3-11 Time slice diagram of sending times for each device
a. Flowchart Description
The firmware of the router performs four tasks: the timer task, ISR task, system task and switch task, which are responsible for doing the necessary jobs according to their attributes. The flowchart of the router is shown in Fig. 3-12.
Timer Task: The timer task is responsible for waiting for one system tick and storing the TTL (Time to Live) of a packet to the TX buffer.
ISR Task: When the ISR task has started, it enters into suspend status until the ISR wakes it. The ISR task is waked when the ISR occurs. The ISR task is used to process received packets and parse the RX frame if the interrupt is an RX event. Or, it shows the processing status of packet transmission if the interrupt is a TX event. If the received packet is a data frame, the router sends data to the associated PAN Coordinator wirelessly.
System Task: The responsibility of router is to schedule sending times of each associated device and wait for other devices to join. The router first does network discovery by requesting the NLME-network-discovery-request of the network layer services. The NLME-network-discovery-request
issues the NLME-scan-request primitive of the MAC layer services to do active scanning, which broadcasts beacon request commands to existing devices of the POS. Finally, the router chooses a PAN Coordinator to join according to the number of associated routers and the distance between the PAN Coordinator and the router.
Switch Task: The switch task is responsible for scheduling sending time for each associated device according its neighbor table and adjusting its idle time according to the signal type and attributes of the associated end device.
Fig. 3-12 Flowchart of the router
3.3.4.3. PAN Coordinator
The PAN Coordinator is only one device of the wireless personal area network; its responsibility is
to manage the WPAN, gather data from associated routers and wait for other unassociated routers to join.
a. Flowchart Description
The firmware of the PAN Coordinator is comprised of three tasks: the timer task, ISR task, and system task, which are responsible for doing the necessary jobs according to their attributes. These are illustrated as follows. The flowchart of the PAN coordinator is shown in Fig. 3-13.
Timer Task: The timer task is responsible for waiting for one system tick and storing the TTL (Time to Live) of a packet to the TX buffer.
ISR Task:When the ISR task has been started, it enters into suspend status until the ISR wakes it.
The ISR task is awakened when the ISR occurs. The ISR task is used to process received packets and parse the RX frame if the interrupt is an RX event. Or, it shows the processing status of packet transmission if the interrupt is a TX event.
System Task: The responsibility of the PAN Coordinator is to form the network and wait for the router to join. The PAN Coordinator first does network formation by requesting the NLME-network-formation-request of network layer services. The NLME -network- formation-request issues the NLME-scan-request primitive of MAC layer services to do energy detection and select a channel that has the maximum energy in all channels as the current channel of packet transmission. The PAN ID of the network is determined by a random number or input parameters of the NLME -network-formation-request, and then does active scanning by issuing the MLME -scan-request primitive of MAC layer services. Finally, it configures a new super-frame by issuing the MLME-start-request primitive of MAC layer services. When the PAN Coordinator has received a beacon request, it first delays a random tick time and then broadcasts a beacon frame to existing devices of the POS. Due to different arrival times of the beacon frame, the router can get all information of the existing PAN Coordinators in the POS.
Fig. 3-13 Flowchart of the PAN Coordinator
b. Message Flow for the PAN Coordinator
When the PAN Coordinator device is powered on, it starts a new personal area network (PAN) by issuing the NLME-network-formation-request primitive and remaining asleep until receiving data. The NLME-network-formation-request primitive first does energy detection by issuing the MLME-scan-request primitive with scan type parameters set to energy detection. Once the energy detection scan is completed, its results are returned via the MLME-scan-confirm primitive. The PAN coordinator accesses the channels according to increasing energy measurements and discards those channels whose energy levels are beyond an acceptable level. Furthermore, the NLME-network -formation-request searches for existing networks by issuing the MLME-scan-request primitive with active scanning and a valid channel list.
The NLME-network-formation-request selects a suitable channel and PAN ID that does not conflict with other existing PANS. Once a suitable channel and PAN ID are determined, the NLME-network-formation chooses 0x0000 as the 16-bit network address. Then the NLME-network-formation initializes the new super-frame configuration by issuing the MLME-start-request primitive with PAN coordinator parameters set to true. The beacon order and super-frame order are set the same as those given to the NLME -network-formation-request.
Finally, the NLME-network-formation-request issues the NLME-network –formation -confirm to notify the next higher layer of the request status with the same status returned from the MLME-start-confirm primitive. The message flow chart is shown in Fig. 3-14.
Fig. 3-14 Message flow chart for the PAN Coordinator