Wireless Electromyogram (EMG) signal transmission

Projects Discussion and Showcase Science and Measurement
1

Hello everyone :slight_smile:

For my university final year project I have constructed an op-amp circuit to measure a biological signal called Electromyogram(EMG). EMG is basically a voltage generated due to muscle activity. It can be used in many applications such as robotic prosthetic arm control or analyzing the strength of a bodybuilder during an intensive workout. I have attached the oscilloscope output waveform and also the op-amp circuit I have used to get these signals (measured from my forearm).

Now I want to transmit this signal wirelessly using an arduino and xbee transceivers to a National Instruments DAQ and computer running labview 8.5 software. Since this signal has both positive and negative components ranging from -3V to +2V, my first step is to construct an op-amp circuit to offset this circuit so that the range of the signal becomes 0V to 5V and I can input this signal into the ADC pins of the arduino. This signal has been band pass filtered between 20Hz to 500Hz. How should I achieve wireless transmission of this EMG signal? Is a combination of xbee tranceivers and arduino suitable for this application? This is a university project and its not meant for commercial/medical purposes. However I do want to maintain as much as possible the waveform and frequency components of the signal in order to conduct experiments relating hand grip strength levels to EMG.

EMG_result.bmp (731 KB)

EMG_circuit.pdf (296 KB)

2

I just tested the new BMA180. It is an I2C accelerometer chip that reads gForce (obviously). I get three values -- x,y and z

The rate on the interrupt line is 74 Hz. There is not much vibration. It is configured in mode 3, and a 150Hz bandwidth..

The Arduino and PC combination work together with no problem. There does not appear to be a significant number of dropped packets. I am sending 48 byte UDP packets from the arduino to the PC -- a four core AMD system running Vista 64 with a custom program written in Delphi to read and stamp packages and sequence stamp them -- in addition to the seq. stamp sent by the Arduino. The Arduino Mega2560 Has the Arduino built (Wiznet) Ethernet shield with the SD card interface. Only the BMA180 I2C accelerometer is active.

(BTW -- The constraint appears to be the UDP packet system.)

Carrying on.... However, when I switch to a Bandwidth of 1200Hz the PC receives packets at a rate of 175 Hz, but the clock rate at the interrupt pin is about 448 HZ the BMA180 rate. I do not need 1200Hz bandwidth so this is not really meaningful for me....

In other words I start to drop about 2 packets out of every three -- a little less actually...

This is a system rate! So you can be sure that if you transfer via UDP you are maybe going to be able to read three values off a fast ADC and send them to a PC such that you can somewhat reliably reproduce a 60Hz signal -- which is sufficient for me. Unless I add more stuff to the program. Since I need to send the data to a database that could be interesting. I often collect three million samples on a run -- not counting all the dropped packets of course.

I also did a run at 1g sensitivity, 300Hz bandwidth (Mode 3 again) and got a clock rate of 149Hz from the BMA180 -- the Arduino-PC system programmed in Delphi received all the packets with no dropped records. I have an internal sequence counter in the code which matches the count from the Arduino if no packets were dropped. Each packet from the Arduino has a sequence number. So that would give a decent performance for me at 70Hz Low Frequency Noise rate -- and lower. This is less certain for your project if you wish to maintain the accuracy of the waveform shape. This assumes that your instrument is recording an accurate wave shape -- I assume it is an oscilloscope -- which should be. A strip chart recorder is a different issue...

I may have to put the data handling (To the Interbase SQL server) in a different thread though. I will make these same tests as I add each segment to the final program.

So this is one way of testing if the System response is sufficient. This is what you need to know. Speccing individual parts will not help you except to let you know if it could work at the desired rate.

Hope that gives you some food for thought!

Message for the ARDUINO Guys!
Clearly we need the 32MHz Arduino Meag2560Plus which I am sure is on the drawing board as we speak. XD
I'll take two!
Right GUYS?????

3

Thanks for sharing your experience WillR :slight_smile:

If I dont use an arduino, are there other options for microcontrollers and wireless transmitters/receivers which are suitable for transmitting this signal? Perhaps PIC 18 series working together with another transmitter such as the UM96?

4

Jazlan:

There are good systems out there -- advertised in Servo and Elektor and the like. The start-up time is longer cost is two to three times that of Arduino. I have my eye on one with replaceable CPU modules that fit onto an experimentation board that might do. They have design trade-offs as well though.

I would try the Mega2560 and a fast ADC chip based on I2C communication and go from there. I showed you how to evaluate the throughput -- though you would have quickly seen it anyway.

Guys like you and I may have to get into "Overclocking" though. :slight_smile:

Try it and see -- you should be able to get the 150-200SPS rate working.

Welcome to the world of engineering. It is a different discipline than science.

5

The Wiznet Ethernet shields are notorious for having limited bandwidth, much slower than people expect of Ethernet.

Since you have multiple sensors, you might want to use multiple micros and radios. Perhaps something like the Jeenode, but you'll need to look into how well they can coexist (I have no idea, because I haven't done that homework).

Also, on this thread, someone reported finding really cheap Bluetooth modules, which could be combined with the RBBB to make Bluetooth equivalents of the Jeenode. BT radios are supposed to handle all the problems of collisions for you transparently, so having a small number of them (say, 2-4) running in the same room should be okay.

6

Your signal has a bandwidth of 500Hz - suggests sampling at 2 to 5kHz or so to reduce aliasing on the tail of the bandpass filter - thats 20 to 50kbit a second of data which you will need to packetize and send on a suitable link.
If 8 bit resolution is enough then that simplifies packing the data. Getting accurate sample timing in the face of interrupts associated with the RF link might be an issue.

7

The amplified signal you generate is impressive. Nicely done.