I'm not a real "DSP Guy", but I have to make a recommendation within
the next few days and I am hoping I can get some advice here on
whether a particular solution is viable.
It involves the use of an electrocardiogram (usually abbreviated ECG
or EKG) in a medical device.
To jog people's memory, an ECG uses electrodes and an
oscilloscope-like screen to display a person's heartbeat. While I am
sure everyone has seen this numerous times on TV and in movies, if not
in real life, here is a very crude ASCII art of the display for a
normal beat.
/\
/ \
________ / \________
\/
My issue is this: I have an ECG that sends 256 samples per second
over a serial port. I have a medical device that needs to receive
exactly 100 samples per second over a serial port. The baud rates and
format of the data (integer in both formats) are different, but these
conversions are trivial. The real issue is the difference in sample
rates.
I can put a DSP in between the ECG and the consumer. I think that a
proper DSP solution involves upsampling, low-pass filtering,
decimation, and low-pass filtering. My questions are:
1. Are those the correct steps? If not, what?
2. Would the signal need to be upsampled to some common multiple of
the two sample rates (i.e., 25600 samples/sec)?
3. The big question is how much delay would be introduced from input
to output for an accurate conversion? I don't know yet how much delay
is tolerable, I am still waiting for that piece of information, but it
will no be much.
The samples output for each beat at 100 Hz must be a very close
approximation of what true 100 Hz sampling by the ECG would be. The
receiving device is running its own computational algorithm on the
samples to determine the time of the positive peak and other
characteristics of the heart beat.
I am hoping someone can give me an outline of the DSP solution and in
particular a reasonable expectation of what the delay would be doing
this in real time. For timing estimation purposes, assume the integer
data could be processed at 50 to 100 MIPs with either 32-bit integer
or 32 bit fixed-point math, using a TI 281x DSP running at 140 MHz.
Thanks in advance for any advice.
--
Jack Klein
Home: http://JK-Technology.Com
Advice for non "DSP Guy"
Started by ●July 11, 2004
Reply by ●July 12, 20042004-07-12
Jack Klein <jackklein@spamcop.net> wrote in message news:<13v3f0pdps6od8fu6potpqb4td5439r6t4@4ax.com>...> I'm not a real "DSP Guy", but I have to make a recommendation within > the next few days and I am hoping I can get some advice here on > whether a particular solution is viable. > > It involves the use of an electrocardiogram (usually abbreviated ECG > or EKG) in a medical device.[- snip -] Many years ago I attended a conferance where some papers on DSP in EKG applications were presented. The one thing I remember from those discussions, is that one of the experts on "EKG DSP" warned against medical doctors interpreting DSP side effects (i.e. transients due to filtering) as new and exciting phenomena of the signal generated by the heart. Rune
Reply by ●July 12, 20042004-07-12
Jack Klein wrote:> I'm not a real "DSP Guy", but I have to make a recommendation within > the next few days and I am hoping I can get some advice here on > whether a particular solution is viable. > > It involves the use of an electrocardiogram (usually abbreviated ECG > or EKG) in a medical device. > > To jog people's memory, an ECG uses electrodes and an > oscilloscope-like screen to display a person's heartbeat. While I am > sure everyone has seen this numerous times on TV and in movies, if not > in real life, here is a very crude ASCII art of the display for a > normal beat. > > /\ > / \ > ________ / \________ > \/ > > My issue is this: I have an ECG that sends 256 samples per second > over a serial port. I have a medical device that needs to receive > exactly 100 samples per second over a serial port. The baud rates and > format of the data (integer in both formats) are different, but these > conversions are trivial. The real issue is the difference in sample > rates. > > I can put a DSP in between the ECG and the consumer. I think that a > proper DSP solution involves upsampling, low-pass filtering, > decimation, and low-pass filtering. My questions are: > > 1. Are those the correct steps? If not, what? > > 2. Would the signal need to be upsampled to some common multiple of > the two sample rates (i.e., 25600 samples/sec)? > > 3. The big question is how much delay would be introduced from input > to output for an accurate conversion? I don't know yet how much delay > is tolerable, I am still waiting for that piece of information, but it > will no be much. > > The samples output for each beat at 100 Hz must be a very close > approximation of what true 100 Hz sampling by the ECG would be. The > receiving device is running its own computational algorithm on the > samples to determine the time of the positive peak and other > characteristics of the heart beat. > > I am hoping someone can give me an outline of the DSP solution and in > particular a reasonable expectation of what the delay would be doing > this in real time. For timing estimation purposes, assume the integer > data could be processed at 50 to 100 MIPs with either 32-bit integer > or 32 bit fixed-point math, using a TI 281x DSP running at 140 MHz. > > Thanks in advance for any advice. >I've seen "Secret Rabbit Code" mentioned here for sample rate conversion (look at the acronyms to see the joke). I haven't used it. The least common multiple of 100 and 256 is 25*64 = 1600, which is better than 25600! Depending on the frequency content of your input signal and your precision requirements you may be able to just pick the closest input sample, or do a simple linear interpolation between the two points that span your output sample. If this device needs to pass FDA certification it may be better to use some idiot-simple algorithm with less than optimal, but rigidly quantifiable, performance. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 12, 20042004-07-12
Jack Klein wrote:> I'm not a real "DSP Guy", but I have to make a recommendation within > the next few days and I am hoping I can get some advice here on > whether a particular solution is viable. > > It involves the use of an electrocardiogram (usually abbreviated ECG > or EKG) in a medical device. > > To jog people's memory, an ECG uses electrodes and an > oscilloscope-like screen to display a person's heartbeat. While I am > sure everyone has seen this numerous times on TV and in movies, if not > in real life, here is a very crude ASCII art of the display for a > normal beat. > > /\ > / \ > ________ / \________ > \/ > > My issue is this: I have an ECG that sends 256 samples per second > over a serial port. I have a medical device that needs to receive > exactly 100 samples per second over a serial port. The baud rates and > format of the data (integer in both formats) are different, but these > conversions are trivial. The real issue is the difference in sample > rates. > > I can put a DSP in between the ECG and the consumer. I think that a > proper DSP solution involves upsampling, low-pass filtering, > decimation, and low-pass filtering. My questions are: > > 1. Are those the correct steps? If not, what? > > 2. Would the signal need to be upsampled to some common multiple of > the two sample rates (i.e., 25600 samples/sec)? > > 3. The big question is how much delay would be introduced from input > to output for an accurate conversion? I don't know yet how much delay > is tolerable, I am still waiting for that piece of information, but it > will no be much. > > The samples output for each beat at 100 Hz must be a very close > approximation of what true 100 Hz sampling by the ECG would be. The > receiving device is running its own computational algorithm on the > samples to determine the time of the positive peak and other > characteristics of the heart beat. > > I am hoping someone can give me an outline of the DSP solution and in > particular a reasonable expectation of what the delay would be doing > this in real time. For timing estimation purposes, assume the integer > data could be processed at 50 to 100 MIPs with either 32-bit integer > or 32 bit fixed-point math, using a TI 281x DSP running at 140 MHz. > > Thanks in advance for any advice.Let me rephrase the requirements and system parameters as I see them, so I can be sure we are both thinking about the same problem. A device you have generates 250 samples per second. The samples presumably represent a bandwidth of about 100 Hz. You need to feed samples to a device that expects 100 samples per second. The bandwidth of the feed must necessarily be less that 50 Hz. The samples you get and the ones you must supply are in serial format. From the mention of "serial port", I deduce that the samples contain 8 data bits and the serial format is asynchronous. I imagine that EKG traces can be adequately drawn with 8-bit signed numbers. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The serial asynchronous data format consists of eight data bits and start and stop bits. To manipulate the data, you will probably want the data bits all at once, and you will need to discard the framing (start and stop) bits. The processing chain I see is ___________ ________ ___________ ___________ | serial to | | low | | sample | | parallel | -->| parallel |-->| pass |-->| rate |-->| to serial |--> | converter | | filter | | converter | | converter | ����������� �������� ����������� ����������� The serial-to-parallel and parallel-to-serial converters are two halves of the same separately clocked UART. The sample-rate converter can be a chip which, IIRC, includes the necessary low-pass filter. Although you can certainly use a DSP for the middle two functions, I don't think you need one. An advantage of not having one is not having to program it. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 12, 20042004-07-12
1600/256 = 6.25! How about 6400 rather than 1600? Still better than 25600! Cheers, Syms. "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message news:10f5lca3cc63nca@corp.supernews.com...> > The least common multiple of 100 and 256 is 25*64 = 1600, which is > better than 25600!
Reply by ●July 12, 20042004-07-12
Symon wrote:> 1600/256 = 6.25! > How about 6400 rather than 1600? Still better than 25600! > Cheers, Syms. > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message > news:10f5lca3cc63nca@corp.supernews.com... > >>The least common multiple of 100 and 256 is 25*64 = 1600, which is >>better than 25600!How do you figure? 256:100 = 64:25, which can be implemented directly or by going 8:5 twice. That's either 1600 or 40*40, which is the same as closely as I can calculate. :-) Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 13, 20042004-07-13
Jerry Avins wrote:> Symon wrote: > >> 1600/256 = 6.25! >> How about 6400 rather than 1600? Still better than 25600! >> Cheers, Syms. >> "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message >> news:10f5lca3cc63nca@corp.supernews.com... >> >>> The least common multiple of 100 and 256 is 25*64 = 1600, which is >>> better than 25600! > > > How do you figure? 256:100 = 64:25, which can be implemented directly or > by going 8:5 twice. That's either 1600 or 40*40, which is the same as > closely as I can calculate. :-) > > JerryNo, to my chagrin he's right - 1600/256 _is_ 6.25. 256 = 2^8 100 = 2^2 * 5^5 LCM = 2^8 * 5^5 = 6400, indeed. Interesting how as you get older you learn more and more complicated stuff, until eventually your brain is so clogged with z transforms and detection theory that you forget your 8th-grade math! -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 13, 20042004-07-13
Jack Klein <jackklein@spamcop.net> wrote in message > My issue is this: I have an ECG that sends 256 samples per second> over a serial port. I have a medical device that needs to receive > exactly 100 samples per second over a serial port. The baud rates and > format of the data (integer in both formats) are different, but these > conversions are trivial. The real issue is the difference in sample > rates. > > I can put a DSP in between the ECG and the consumer. I think that a > proper DSP solution involves upsampling, low-pass filtering, > decimation, and low-pass filtering. My questions are: > > 1. Are those the correct steps? If not, what? > > 2. Would the signal need to be upsampled to some common multiple of > the two sample rates (i.e., 25600 samples/sec)? > > 3. The big question is how much delay would be introduced from input > to output for an accurate conversion? I don't know yet how much delay > is tolerable, I am still waiting for that piece of information, but it > will no be much. > > The samples output for each beat at 100 Hz must be a very close > approximation of what true 100 Hz sampling by the ECG would be. The > receiving device is running its own computational algorithm on the > samples to determine the time of the positive peak and other > characteristics of the heart beat. > > I am hoping someone can give me an outline of the DSP solution and in > particular a reasonable expectation of what the delay would be doing > this in real time. For timing estimation purposes, assume the integer > data could be processed at 50 to 100 MIPs with either 32-bit integer > or 32 bit fixed-point math, using a TI 281x DSP running at 140 MHz. > > Thanks in advance for any advice.Your approach is correct. This is a resampling process. But you don't have to really upsample to 25600, only to certain common multiplier in order to maintain the 100/256 rate conversion. As for the delay, this is a little bit involved: you need to know the anti-alising low-pass filter realization since the delay are dominantly from there. In your draft, you also include a second LPF which also introduces delay but this LPF may not be necessary in your application. If a FIR anti-aliasing LPF is used, the delay is rougly (1/downsampled) of the length of the FIR. If an IIR is used, you know the delay also depends on the input(not linear phase). The accuracy of the resampled-version 100Hz signal is also affected by the length of this filter. Some tradeoff might need. You may look at MATLAB's "resample" command. Note that only a FIR anti-aliasing filter is used in their realization. I don't know how the TI spec here is interpreted.
Reply by ●July 13, 20042004-07-13
Jerry Avins wrote:> Symon wrote:>> 1600/256 = 6.25! >> How about 6400 rather than 1600? Still better than 25600! >> Cheers, Syms. >> "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message >> news:10f5lca3cc63nca@corp.supernews.com...>>> The least common multiple of 100 and 256 is 25*64 = 1600, which is >>> better than 25600!> How do you figure? 256:100 = 64:25, which can be implemented directly or > by going 8:5 twice. That's either 1600 or 40*40, which is the same as > closely as I can calculate. :-)The LCM of 256 and 100 is 6400, what you seem to be saying is that the LCM is not the way to figure the complexity of resampling, which I agree with. -- glen
Reply by ●July 13, 20042004-07-13
Jerry Avins <jya@ieee.org> wrote in message news:<40f34c4c$0$1191$61fed72c@news.rcn.com>...> Symon wrote: > > > 1600/256 = 6.25! > > How about 6400 rather than 1600? Still better than 25600! > > Cheers, Syms. > > "Tim Wescott" <tim@wescottnospamdesign.com> wrote in message > > news:10f5lca3cc63nca@corp.supernews.com... > > > >>The least common multiple of 100 and 256 is 25*64 = 1600, which is > >>better than 25600! > > How do you figure? 256:100 = 64:25, which can be implemented directly or > by going 8:5 twice. That's either 1600 or 40*40, which is the same as > closely as I can calculate. :-) > > JerryThe way I would answer this, was to expand the numbers 100 and 256 in products of prime numbers like so: 100 = 2*2*5*5 256 = 2*2*2*2*2*2*2*2 Removing common factors leaves 256/100 = 2^6/5^2 = 64/25 Which leaves the following question: Is the product of prime numbers unique, given the arbitrary natural number N? To my naive mind, it is "obvious" that the fact that the prime number factorization is unique, but can this be proven? [DISCLAIMER: I never liked number theory when in university, it reminded me too much of numerology, 'magic squares' and other mysticism. So I may very well have missed some cruical basic theorem on number theory...] Rune
