ECG signals Compression/Decompression

[glen herrmannsfeldt]

David Brown <david.brown@hesbynett.no> wrote:

On 06/06/14 01:20, Weiss wrote:
But I suspect it is a project for an FPGA class.

I don't believe that should disallow soft processors.

Again, that depends. Let's hear the reasons and then discuss the
validity or other options.

(snip)

Yes, it's a project, so i must use a compression algorithm based on
orthogonal polynomials and it must be done on FPGA.

When you are looking for help with homework or a class project, please
be up front about it. Tell us the requirements, say what you have done
so far, and say exactly where you are stuck or need help or inspiration.
No one here will do your project for you - but if you show that you are
doing your best then you can get ideas and hints from experienced
developers.

But if you don't make everything clear, then people (as now) discuss
other ways to approach the problem - that might help you make a /real/
ECG monitor, but it won't help your project.

At a guess, if you are asked to do this in an FPGA then soft processors
will be "cheating" (even though they might be a good choice in real life).

If the project was practice for something that needed real speed, then
I would agree.

One idea that you might like to look at is MyHDL - this will let you use
a high level language (Python) for the code, but it generates VHDL (or
Verilog) and runs in "hardware" rather than "software". Your teachers
might object because it is not "proper VHDL" - or they might like the
creativity it shows.

To me, this is cheating much more than using a soft processor.

Well, partly the things I like to do in FPGAs don't lend themselves
to that style. Systolic arrays, very long piplines of fairly
simple unit cells, running as fast as possible. Cells containing
adders, comparators, and muxes, with pipeline registers as often
as possible.

In my opinion, it would have been better if i was able to use
Matlab and do a software solution.

Also, i'm not familiar with the mathematical portion of the
project, and my knowledge on FPGAs is basic (from VHDL courses),
that's why i'm trying to have some insight from more
experienced people in the Electrical Engineering field.

No-one said anything about my suggestion to resample such that all
cycles are the same length (in samples). Also, I am not so sure
how to do a resampler in FPGA.

-- glen

 

[Stef]

In comp.arch.fpga,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

Weiss <100383@embeddedrelated> wrote:

And resolution? 8-bit may be enough in some applications to send to send
the filtered result. Aquisition is often done at 24-bit, but this usually
includes a large DC offset.

I am pretty sure that 24 bits is too much. While I do record audio
in 24 bits, I am already pretty sure that many of the bits are
noise, such as from the amplifiers. There has to be a lot more
noise in the EKG signal.

Oh yes, 24-bit is too much for the output. As I said, when sampling a
DC coupled ECG at 24-bits, you sample a 10mV signal with a possible
+/-1 Volt or so offset. That's 8 bits lost already. The remaining 16
bits will contain a lot of noise that requires filtering. But just
cutting it down to 8 bits may be too much for some applications and
certainly for some doctors. ;-)


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

The hardest thing is to disguise your feelings when you put a lot of
relatives on the train for home.

 

[Stef]

In comp.arch.fpga,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

Weiss <100383@embeddedrelated> wrote:

(snip, I wrote)

But I suspect it is a project for an FPGA class.

Yes, it's a project, so i must use a compression algorithm based on
orthogonal polynomials and it must be done on FPGA.

I like FPGAs for these problems, as you can get them to run very
fast. You might be able to filter/compress input at 100MHz or so.
But that is completely useless for a 300Hz input rate.

In my opinion, it would have been better if i was able to use
Matlab and do a software solution.

You should still debug the algorithms in matlab before implementing
them.

IIRC there is a matlab module to create FPGA code from the matlab code.
So develop in matlab, export to FPGA and done!
But I guess there are some complications on that path. I think one of
them is that you need to develop in integer in matlab. But that could
of course be validated with a matlab FP model.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Save gas, don't use the shell.

 

[David Brown]

On 06/06/14 01:20, Weiss wrote:

But I suspect it is a project for an FPGA class.

I don't believe that should disallow soft processors.

Again, that depends. Let's hear the reasons and then discuss the
validity or other options.

--

Rick

Yes, it's a project, so i must use a compression algorithm based on
orthogonal polynomials and it must be done on FPGA.

When you are looking for help with homework or a class project, please
be up front about it. Tell us the requirements, say what you have done
so far, and say exactly where you are stuck or need help or inspiration.
No one here will do your project for you - but if you show that you are
doing your best then you can get ideas and hints from experienced
developers.

But if you don't make everything clear, then people (as now) discuss
other ways to approach the problem - that might help you make a /real/
ECG monitor, but it won't help your project.


At a guess, if you are asked to do this in an FPGA then soft processors
will be "cheating" (even though they might be a good choice in real life).

One idea that you might like to look at is MyHDL - this will let you use
a high level language (Python) for the code, but it generates VHDL (or
Verilog) and runs in "hardware" rather than "software". Your teachers
might object because it is not "proper VHDL" - or they might like the
creativity it shows.

In my opinion, it would have been better if i was able to use Matlab and do
a software solution.

Also, i'm not familiar with the mathematical portion of the project, and my
knowledge on FPGAs is basic (from VHDL courses), that's why i'm trying to
have some insight from more experienced people in the Electrical
Engineering field.

---------------------------------------
Posted through http://www.FPGARelated.com

 

[David Brown]

On 06/06/14 11:26, glen herrmannsfeldt wrote:

David Brown <david.brown@hesbynett.no> wrote:
On 06/06/14 01:20, Weiss wrote:
But I suspect it is a project for an FPGA class.

I don't believe that should disallow soft processors.

Again, that depends. Let's hear the reasons and then discuss the
validity or other options.

(snip)
Yes, it's a project, so i must use a compression algorithm based on
orthogonal polynomials and it must be done on FPGA.

When you are looking for help with homework or a class project, please
be up front about it. Tell us the requirements, say what you have done
so far, and say exactly where you are stuck or need help or inspiration.
No one here will do your project for you - but if you show that you are
doing your best then you can get ideas and hints from experienced
developers.

But if you don't make everything clear, then people (as now) discuss
other ways to approach the problem - that might help you make a /real/
ECG monitor, but it won't help your project.

At a guess, if you are asked to do this in an FPGA then soft processors
will be "cheating" (even though they might be a good choice in real life).

If the project was practice for something that needed real speed, then
I would agree.

I think using a soft processor changes the domain of the problem too
much - it becomes a software project rather than a hardware project. In
a real-world project, you use whatever mixture of software and hardware
makes most sense - but in a class project the aim is to learn about a
particular technique.

One idea that you might like to look at is MyHDL - this will let you use
a high level language (Python) for the code, but it generates VHDL (or
Verilog) and runs in "hardware" rather than "software". Your teachers
might object because it is not "proper VHDL" - or they might like the
creativity it shows.

To me, this is cheating much more than using a soft processor.

Well, partly the things I like to do in FPGAs don't lend themselves
to that style. Systolic arrays, very long piplines of fairly
simple unit cells, running as fast as possible. Cells containing
adders, comparators, and muxes, with pipeline registers as often
as possible.

MyHDL is not about using software instead of hardware in your FPGA - it
is not like the C-to-FPGA converters that are now popular. You have to
think in hardware - using pipelines, muxes, and whatever else you want.
You get what you ask for, and nothing more. But you express it in
Python rather than VHDL, which can make it easier to write - especially
for more complex hardware. You get easy integration with a very
powerful functional simulator, since you can write your simulations in
Python. And you don't have to worry about the silliness VHDL has with
using and converting between std_logic, boolean, integers, etc.

 

[glen herrmannsfeldt]

David Brown <david.brown@hesbynett.no> wrote:

(snip)

If the project was practice for something that needed real
speed, then I would agree.

I think using a soft processor changes the domain of the problem too
much - it becomes a software project rather than a hardware project. In
a real-world project, you use whatever mixture of software and hardware
makes most sense - but in a class project the aim is to learn about a

Seems like it would depend on how much of the logic is in soft
processor and how much isn't. But as I suggested before, if it is
practice for a problem that can't be done in a processor, then it
makes sense that it not be.

One idea that you might like to look at is MyHDL - this will let you use
a high level language (Python) for the code, but it generates VHDL (or
Verilog) and runs in "hardware" rather than "software".

(snip, I wrote)

>> To me, this is cheating much more than using a soft processor.

(snip)

MyHDL is not about using software instead of hardware in your FPGA - it
is not like the C-to-FPGA converters that are now popular.

Seems to me that, more and more, FPGAs are being used to replace
big blocks of logic, including processors. In that sense, a C
to FPGA converter that generates a processor to run compiled C
code doesn't seem so useless.

As I might have written to many times now, my favorite FPGA
problem is systolic arrays, but they look so different from serial
implementations of algorithms, that it doesn't make sense to expect
a compiler to figure it out.

Trying to think up an example of about the right complexity,
say you have many 100x100 matrices in base 4 (that is, each entry
is 0, 1, 2, or 3. You want to matrix multiply all of them, computing
the result elements modulo 7, and find which one(s) have the most 6's
in their product. (This may or may not be much help to the OP.)

It isn't hard to write the matlab to do a matrix multiply, loop over
all combinations of inputs, compute the modulo 7 and count.
In C, you can write the five nested for loops. The numbers were
chosen, as I suspect the logic to compute the module 7 sum of the
products of small numbers is fairly simple, and can be done in a
nice pipeline. Now add one more complication: you need it for all
cyclic permutations of the rows of the matrices. This last
requirement makes the pipeline of the inner loop especially
efficient. A simple table lookup for the products, and a nice
simple (in logic) modulo 7 adder, makes the pipeline very simple.
All the complication is getting the data into and the results
out in the right order.

You have to think in hardware - using pipelines, muxes, and
whatever else you want.
You get what you ask for, and nothing more. But you express it in
Python rather than VHDL, which can make it easier to write - especially
for more complex hardware. You get easy integration with a very
powerful functional simulator, since you can write your simulations in
Python. And you don't have to worry about the silliness VHDL has with
using and converting between std_logic, boolean, integers, etc.

Sounds like the reason I use verilog instead of VHDL. Verilog also
doens't have std_logic. Just bits to move around. Usually I can
read VHDL well enough to work on problems with it, but I normally
don't try to write it.

-- glen

 

[glen herrmannsfeldt]

Tim Wescott <tim@seemywebsite.really> wrote:

(snip)

The biggest practical barrier is the word "relevant". What's relevant in
an EKG? Coming up with a lossy compression scheme that is both efficient
and leaves you with something useful is not something that could be done
by a lone engineer, or even a lone engineer with a lone cardiologist
standing by his shoulder.

I think the 24 hours must be important here, in addition to the
complications of compression.

The ones I usually see on TV shows take about 10 seconds. (Well,
partly it is to get the drama right.) But that is the people who
will be dead in minutes if they don't figure out what to do.

So, maybe there are some (small number) of cardiologists that know
what to do with 24 hours of data, for some specific cases.
(Obviously, ones that won't be dead in minutes.)

In that case, I am not so sure that a lone engineer and lone
cardiologists couldn't do it.

An important part of compression is finding similarities in data,
(such as repeats) and representing them only once in the output,
and then finding the difference between those and the actual data.

Seems to me that the cardiologist will want to know those differences,
and very little about the similarity. There will be a lot of thermal
noise in the data, which, if the compression is to work well at all,
will have to be removed (filtered).

As I mentioned before, I beleive you want to resample so each
period is the same length (in samples). Seems to me that resampling
it already a pretty good project.

Hmm... If you do the expansion in Legendre polynomials, integrating
each over one period (Legendre polynomials are from -1 to 1) then
that isn't so different from resampling. (As far as I can tell,
the Legendre Transform is different from an expansion in Legendre
polynomials.) So maybe there isn't a need for resampling.

But I don't know at all how many terms you need.

-- glen

 

[Tim Wescott]

On Thu, 05 Jun 2014 14:32:37 -0500, Weiss wrote:

For some applications, 10 seconds may be enough. But in others you would
want to see an entire 24h period, looking for rate variations and other
abnormalities.

And resolution? 8-bit may be enough in some applications to send to send
the filtered result. Aquisition is often done at 24-bit, but this
usually includes a large DC offset.

--
Stef

Exactly, this algorithm is needed for those cases where you need to
record 24H worth of the signal, and then upload it, which will take too
much time with no or lossless compression.

I just want to be clear about this, so basically, this algorithm has to
: 1- Sample the ECG signal (Analog) to pick every cardiac cycle.
2- Decompose every cardiac cycle signal using an orthogonal polynomial
base (Legendre polynomials for example).
3- Save the more relevant coefficients of this decomposition, it's the
compression part. (These coefficients will be used to recreate the
signal)

And all that must be done on an FPGA.
And about the comp.compression, i don't know which one you are referring
to, because i only found one Google group.

The biggest practical barrier is the word "relevant". What's relevant in
an EKG? Coming up with a lossy compression scheme that is both efficient
and leaves you with something useful is not something that could be done
by a lone engineer, or even a lone engineer with a lone cardiologist
standing by his shoulder.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Tim Wescott]

On Thu, 05 Jun 2014 18:20:35 -0500, Weiss wrote:

But I suspect it is a project for an FPGA class.

I don't believe that should disallow soft processors.

Again, that depends. Let's hear the reasons and then discuss the
validity or other options.

--

Rick

Yes, it's a project, so i must use a compression algorithm based on
orthogonal polynomials and it must be done on FPGA.

In my opinion, it would have been better if i was able to use Matlab and
do a software solution.

The way you approach this sort of a problem is done in steps: first, make
it work in Matlab by any means possible; then, make it work in Matlab
using only operations that you know are easily available on your target
(which, in this case, is your FPGA that's programmed from a description
in VHDL); finally, implement your Matlab code in your target.

When I'm doing this sort of thing professionally, I'll often be going
back and forth among the steps (Google for the "waterfall model" of
project management). In addition, I'll often be responsible for steps 1
and 2, while my client will provide the engineer(s) who take my Scilab
code or detailed algorithm document and work on step 3.

Also, i'm not familiar with the mathematical portion of the project, and
my knowledge on FPGAs is basic (from VHDL courses), that's why i'm
trying to have some insight from more experienced people in the
Electrical Engineering field.

Then you need to do the separate steps all the more -- you don't want to
be in a position where nothing works and you have no clue why. If you
get the math working in Matlab and it doesn't work in the FPGA, then you
know it's an implementation issue, not the math. If you can't get the
math working in Matlab, then you know that there's no point in wasting
time with HDL.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[rickman]

On 6/6/2014 3:23 AM, Stef wrote:

In comp.arch.fpga,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
Weiss <100383@embeddedrelated> wrote:

And resolution? 8-bit may be enough in some applications to send to send
the filtered result. Aquisition is often done at 24-bit, but this usually
includes a large DC offset.

I am pretty sure that 24 bits is too much. While I do record audio
in 24 bits, I am already pretty sure that many of the bits are
noise, such as from the amplifiers. There has to be a lot more
noise in the EKG signal.

Oh yes, 24-bit is too much for the output. As I said, when sampling a
DC coupled ECG at 24-bits, you sample a 10mV signal with a possible
+/-1 Volt or so offset. That's 8 bits lost already. The remaining 16
bits will contain a lot of noise that requires filtering. But just
cutting it down to 8 bits may be too much for some applications and
certainly for some doctors. ;-)

Why would you need to DC couple an EKG signal? Just define the low end
of the frequency range needed and AC filter the input. Then you can use
a much less costly or complex ADC.

Just how large is a typical EKG signal anyway?

--

Rick