Analog to Digital Converter and Communication Protocol
The ECG/EMG device will provide 2 analog channels having range of 0-3 volts and frequency varying from 1 to 100 Hz. There are 7 analog to digital channels available on the Freescale development board. Each capable of doing conversion at 10 bit resolution of voltage varying from 0 to 3 volts. The signal from ECG/EMG device was converted into digital form using 2 of the analog to digital channels on the Freescale board. This signal was then transmitted to another Freescale board. For this particular process, in order to avoid aliasing, we have to have sampling rate that is more then double the maximum frequency range. So just to be on the safe side, the sampling frequency was selected to be at 300 samples per second.
The digital data converted from the analog to digital converter is encoded in a packet in a unique way as shown in Figure 3. As shown in the Figure, character X represents channel 1 and Y represents channel 2. The 2 byte character after X represents the 10 bit of analog data coded in 16 bits. The last 6 bits are unused. And similarly, 2 byte character after Y represents the data from channel 2. In presence of multiple devices, this type of protocol will be very efficient.
As shown in the Figure (3), character X represents channel 1 and Y represents channel 2. The 2 byte character after X represents the 10 bit of analog data coded in 16 bits.
Fig. 3: Transmit Protocol from Medical Device to UII
The last 6 bits are unused. And similarly, 2 byte character after Y represents the data from channel 2. In presence of multiple devices, this type of protocol will be very efficient. If for example, a scale need to work concurrently with the ECG/EMG device, then wireless communication board attached to scale can be programmed to send A and followed by the data packet. This will enable the wireless communication board attached to the CerfCube to know from which device is the data coming from. Similarly, if the Freescale board connected to the black box wants to send some data to the ECG/EMG device, it can send in a packet coded as shown in the diagram below:
Fig. 4: Receive Protocol from UII to Medical Device
Just as before, x represents information for channel 1 and y represents for channel 2. In this case, lowercased letters were used to indicate information is sent by the CerfCube Freescale board to the medical device Freescale board. And hence, the device wireless board is the only program to listen to broadcasted information only directed to them.
The wireless board attached to the CerfCube is a universal listener. It will listen to information send to it and check if the data is in correct format. Once it does that, it will transfer it to the CerfCube via built in RS-232 port.
Fig. 5a: Zigbee Transmitting Software Flow Diagram
Fig. 5b: Zigbee Receiving Software Flow Diagram
The software on the Freescale boards is programmed in the way that it can be used as the transmitter for the medical devices or receiver for the CerfCube. If one of these boards is to be used as transmitter, it needs to be reset while pressing any one of the 4 push buttons on the Freescale boards. This will tell it to go to the transmitter loop. And as default, if a pushbutton is not pressed, the board will act as a receiver on the CerfCube side.
Medical Device Side Software
The Freescale board for the ECG/EMG device side will go in a infinite loop where it will read the data from the two analog to digital converters, encode it in a way that the CerfCube board can understand what the data is and where it is coming from. There after, the receiver is turned off so the transmitter can send the data to the CerfCube. And once that is done, the receiver is turned on to accept commands from the CerfCube as per which digital lines need to be turned on and off for ECG/EMG device to select proper channels. This process is shown in Figure (5a). When the wireless board sends the string xcym, the program gets interrupt and raises a flag. This flag is then handled inside a code where it decodes the messages just translated to send a request to channel 1 to send the ECG signal and channel 2 to send the EMG signal. This is done by raising digital output line, which represents channel 1, to high and dropping the output line, which represents channel 2, to low. Once this command is carried out, the program goes back to its regular routing where it gets that data from the ECG/EMG device and transmits it to the other device.
CerfCube Side Software
For this program, the CerfCube Freescale boards main task was to receive data and send it to the CerfCube. Hence, this board was programmed to be in the receive mode and once it received something, it causes an interrupt. It would send all the information to the RS-232 port via UART in the same way it received (Figure 3). When a data packet is received in the wireless receiver buffer, it generates an interrupt. It takes just 1.16 milliseconds to handle this interrupt, check for the valid data and send it to the RS-232. This process is described in Figure (5b).
Figure (6) and shows the oscilloscope reading that confirms the sampling rate at 330 Hz. A doctor or a health care provider could also be able to switch between what they want to see on channel 1 and channel 2. The CerfCube is programmed in a way that when a doctor selects to view channel 1 as ECG signal and channel 2 as EMG, it will send a data packets which are 4 bytes wide to the Freescale board connected to it via the RS-232.
Fig. 6: 1/Delta X shows the Sampling Frequency
These data packets are in the same form shown in Figure (4). Once this data is send to the UART, it generates an interrupt, goes to transmit mode and sends the same data packet and then returns back to the receive mode. This entire process takes 1.02 milliseconds.
Setting up the CerfCube
The CerfCube is a server that runs Embedded Linux. It is running a web server called Boa which hosts a website that is viewed by a doctor. The Freescale boards are connected to the CerfCube via the RS-232 port which receives the medical data from the devices and sends the commands to the medical devices. This is done using a CGI script running in near real-time when a call is made through the website. The CerfCube hosts an html website which takes the user to screen shown in Figure (10). When the view button is clicked after selecting the required signals on particular channels, the CerfCube sends parameters and runs a CGI script which writes the command needed to be sent to medical devices on the RS-232 port. Once this is done, it starts receiving all the information from the medical device. Five seconds worth of this information is stored in an array which is there after passed to a java script. The java script, which will run on the client side, will take these points received from both the channels and then plot them as shown in Figure (11). The CGI script is written in such a way that it will plot five seconds worth of data points as it refreshes every five seconds. The CGI script is also programmed to have a start and a stop button on the website. A doctor can choose to stop the refresh and view the received data and start it when ever he/she wishes. Figure (9) shows how this module works.
Fig. 9: CGI Software Flow Diagram
Future Design Additions
The project is to demonstrate the feasibility and usability of the medical internet interface idea. Ideally, this project will be broadened to include multiple health monitoring devices such as pulse and blood pressure monitors. A patient user interface would also be likely developed for easy controlling for the patient. The past winter group already included the use of a weight scale. From the projects developed over the winter and spring quarter (the scale and the ECG/EMG), the hardware, software and documentation should be at a point where further implementation should follow with some ease.
It is also to be noted that this system can be used as a platform to develop larger systems to incorporate multiple medical monitoring devices.