Pictures within microcontrollers

[warner]

Hi there all,
looking for some advice, within microcontrollers, i have been working on a project for over 6 months, its a medical use, im trying to develop it for children, whom are prone to heart conditions, within the hope of being able to save their life, or at least give them a chance of survival, the basic idea: to somehow input ecg readings from children whom have experienced heart conditions, and to be able to match the ecg read out to the saved ecg read out to tell the parents what is going on.
Im using the msp430 range of microcontroller, for this project, im wanting to either store scans of ecg readings or capture ecg reading to be able to use them as a matching system.
So far i have designed the system circuit, and am in process of testing it, but im not overally experienced with microcontrollers, but find them fascinating .

[suicidaleggroll]

msp430s are ideal for low power, low processing applications.  They tap out at 16 MHz on most models and 25 MHz on the fastest ones, you're not going to get a whole lot done with that little processing power.  It's almost a requirement that everything is done in integer or fixed point space as well.  Since there is no floating point co-processor, as soon as you introduce a float into the mix the libraries required will blow your program size up and slow the system to a crawl.

That said, it may be able to keep up with your demands, but you need to get a LOT more specific with your requirements.  What, exactly, does "match up the ecg read out to the saved ecg read out" mean?  What does this process involve, mathematically?  What are these ecg read outs?  What kind of format?  How large (msp430s are quite limited in RAM)?  How quickly are they coming in and through what interface?  How is the processor going to "tell" the parents the result?  A couple of blinking LEDs, a full graphical touch screen LCD, or somewhere in between?

[warner]

Although i do like microcontrollers, as i have a few PICs, a few MSP430's, and some arduino's ATMeGa's.
i have only recently got into mcu's,
What im looking to do is match up an Electrocardiography, with some form of image, or the details of the Electrocardiography of a person whom has had a heart condition.
Or i would like to be able to capture the Electrocardiography results, so they could be saved, to be able to use to match up with a real time Electrocardiography readout.
format would be by lcd screen graphics display.
How quickly they come through a normal heartbeat is around 60 BPM.
Im wanting something responsive fast to process, decent amount of memory ( EEprom),
im aware the msp430F2013 is not the best for memory, but when i first looked into mcu's i had no idea of what i was looking for, and choice the msp range simply because it seemed easier to use, i dont have a preference, i prefer to choose by working out what is best to use for the project, i am enthusiastic and love working and doing project, but im not experienced within microcontrollers, but really want to learn.
I have read aot of pdf's, scoured the net, watched videos, learnt about the architectures.... and still learning.
This information can be worked out mathematically yes, but i would need Electrocardiography graphs to be able to calculate the exact time frames, and voltages.

When i say match i mean the live Electrocardiography would "match" the captured or saved Electrocardiography.

[warner]

Dont get me wrong, i do know and understand there are plenty of medical applications out there, and i am aware i have not over defined what im trying to accomplish, and you are correct, in that what im doing is not a hobby project, its a project i started in college, very basic, but once college had finished, i know what i wanted to do, specialize in medical applications, because i want to do something that matters, something im passionate about, but with little experience, and only ONC qualified, im unlikely to get hired for electronics,
although i have not disclosed the full scope of this, but i have been working on this for 1 and a half years, i have asked for advice before ( a different forum), as was told this is a hard market, find something else to do.

Im aware what im doing is not easy and there are many professionals whom are better equipped for this field, that i am.

For me its not about the cost or the experience or quals, its about doing what i know, and learning how to use my knowledge to learn how to build it, and build it properly, i could do into detail about what im looking to do, exactly, but also nervous someone else may take my idea.
At the end of the day my aim is to want to save the lives of children from heart conditions,
oh and thank you for your comment

[suicidaleggroll]

I have to agree with evb149.

The invention of a device like this typically follows several important steps:
1) Gather the necessary information - ECGs from healthy patients, sick patients, questionable patients, etc.
2) Develop an algorithm that can analyze any given ECG and return some kind of probability of heart malfunction.
3) Quantify the performance of this algorithm, determine the accuracy, chance of false positives or false negatives, etc.
4) Iterate the algorithm as necessary to bring the accuracy to the desired level.
5) Analyze the logistics of implementing this algorithm in hardware.  Is the device supposed to gather the ECG itself, or import it from some other device, if so, how?  Will it be web-based, where it uploads the ECG to some central server where the hard processing is performed, or will it be stand-alone?
6) Design a circuit to implement this algorithm
7) Iterate as necessary

I'm not even including certifications that need to be obtained in the medical market, etc. these are simply the steps required to bring any new product to fruition.  I assumed in my first post that you had already completed steps 1-5, but it seems from your response that you're still at step 0 and are trying to jump straight into step 6.

If this is not the case, please let us know.  Otherwise, I highly suggest you jump back to step 1.

[warner]

The device would be handheld, wireless, to be used at home with young children, there will be a database of known conditions to "match" too.
I have a number of reports that i have made for this, circuit designed.
It will be stand alone.
There will be an algorithm, for this.

[suicidaleggroll]

The device would be handheld, wireless, to be used at home with young children

You're still focusing on the usability of the end product without regard for how you're actually going to implement anything.

there will be a database of known conditions to "match" too.

A database where?  In what format?  How will the device access it?  What does "match" mean?  Are we talking a cross spectral analysis?  Cross correlation?  Least square fit?  Poly fit?  What?

I have a number of reports that i have made for this, circuit designed.

I don't see how you could have possibly designed a circuit without knowing the basic device interconnection.  Where is your uC getting the ECG data from and how?  All you've said so far is that it's an "image", but what does that mean?  Is it a bitmap?  jpeg?  png?  tiff?  What kind of interface?  spi?  i2c?  uart?  ethernet?  What kind of data rate (60 BPM is not a data rate)?

Again, you're jumping straight to step 6 without bothering with steps 1-5.  Or maybe you have completed 1-4 and you're just being secretive, but your responses here make it very clear you haven't looked into step 5 at all yet other than some very high level brainstorming.

[AndreasF]

It sounds like you are trying to do something like this.

[tggzzz]

looking for some advice, within microcontrollers, i have been working on a project for over 6 months, its a medical use, im trying to develop it for children, whom are prone to heart conditions, within the hope of being able to save their life, or at least give them a chance of survival,

Your device could, even when working to specification result in a death. What happens when, not if, your devices fails to flag a condition and the child subsequently dies?

Having a device that is 99.9% accurate is insufficient - even if you could achieve that accuracy.

Don't even think of developing a device until you have proven algorithms plus answers to the above questions.

(Long long ago, my "solution" when developing a lung ventilator was to explicitly define the device was not to be used for any life support applications! The customer understood, and purchased it )

[warner]

ok,
im trying to build this heart detection machine, for children with heart defects,
it works by sensors being in a sheet, so its contact less, for newborns, it pick sup there heartbeat , and measures it,
looking for signs of heart problems,
yes im still along way off from it being complete but thats part of why im here,
i know what im looking to do, and im still doing tests, my circuit is by no means perfect,
when i say images, im talking jpeg.
and when i say match i mean match the childs heartbeat to the heart beat of a child whom has a heart attack,
i know what i am doing is not easy to do, far from it, and it will take alot of hard work,
which  i dont mind, all i want to do is give something back to children,
the idea of this is to be able to try and prevent infants dying via heart attack

[fcb]

I'm also going to agree with all the posters to this topic.

It seems to me that you don't know what you don't actually know, and that your going to hit a hard stop with your project. Now I'm not trying to be rude or put you off electronics/embedded systems.

If you have a novel sensor, then I suggest you pursue that rather than an end product. You are far more likely to achieve your goal of giving back than trying to develop a complex and very heavily regulated product that you are proposing.

[tggzzz]

the idea of this is to be able to try and prevent infants dying via heart attack

Do you understand that your device might cause a death?

How? By failing to diagnose a problem so the infant isn't seen by a medic.

[warner]

yes im aware of the possible impact,
the idea of the machine is to try get the child to the hospital quicker,
and once i have managed to develop it, i want doctors and cardiologists, to help me so this does not cause any damage or deaths, that is why im here,
i do enjoy constructive criticism, but all people seem to want to do, is advice me to stay clear of this field,
and grated im only ONC qualified, but i am trying, i have several projects on the go, but this one is important to me.
im not prefect, and i am still learning, i know what the aim of the project is, im usually a highly quiet person, and low on confidence but i get up everyday, and work it on.
But now i know i need help with this, in order for me to progress and for it not to cause any harm.

i have got a basic circuit working, but i dont know a great deal about micro controllers, but im getting there slowly.
for the sensors, im looking to make some embedded into a sheet for eg, although, i do have a proper pair of ecg leads for testing.



 

[dannyf]

A few things to consider.

First, sensors. If it is contactless, you may be able to sense heart beats only. No ecg. You can do a lot with just heartbeat but far less so than ecg.

If you can get ecg type charts, you need to be able to detect patterns and match them. Not easy.

You also need some capability to update the pattern database.

Not to mention all the regulations and legal stuff.

Doable if you set goals commensurate with your skills.

[warner]

thanks dannyF, and yes i know you are all correct,
and i do agree,
firstly for sensors, the main reason for me wanting to make this contact less is because although infants an be still when they sleep but the rest of the time, they move, like all living organisms,
yes the database would need to be update able,
and surrounded by laws and legal stuff, but right now my aim is to make it work then see professionals, for help and advice.
i know i am a few years off this even being completed yet, but i believe its worth while

[AndreasF]

Let's go back to your original question and forget about the higher level purpose and the whole regulatory issues surrounding medical devices.

You said, that ...

...im wanting to either store scans of ecg readings or capture ecg reading to be able to use them as a matching system. ...

and your topic title is "Pictures within microcontrollers" (and later you mention jpg format). Here is already the first clue that maybe you're thinking about this whole problem in the wrong way. Why? Because it's completely nonsensical to store ECG recordings as images. Just because we visualize them as graphs/images doesn't mean they should be stored in this way, and certainly not in a highly resource constrained device like a microcontroller. ECG recordings are one-dimensional vectors/arrays, i.e. a series of values, sampled at regular time intervals from some sort of sensor (array). Those can theoretically be stored in any microcontroller, though you will very quickly run into RAM limitations for some of them. In other words, the simple task of storing ECG recordings "within microcontrollers" is at least in principle a trivial issue.

Instead of building a full device from scratch, why don't you research what devices are already out there for this type of application, learn how exactly they work, and then identify how they can be improved? That way you would still make a difference but wouldn't waste your time working towards a solution that is bound to fail, and can tailor your efforts to your strengths.

[dannyf]

Even a cordless hear rate monitor can be quite helpful for infants.

[Wilksey]

It's a bit harsh to say the machine he wants to make might cause death!

I would look at it a positive way i.e. a child has 80% chance more of being diagnosed than before, but it's not a pace maker, just a ECG effectively from my understanding, so it won't CAUSE death.

If it doesn't pick up one then that is unfortunate, but you shouldn't rely on the machine alone, and it's not fair to blame the maker of the machine, it's not a life support machine.

I think it's a good idea, as long as you use it within it's safety and operating limits, bit like a sat nav, use it 80 - 90% of the time as it does get it right (these days), the remainder is down to other devices or knowledge, i.e. signs to look for.

As long as the operational limits are understood then it will be a good tool.

It might be that it picks up the issue and theres nothing that can be done even, but even if it helps to save just 1% more of sick infants, surely that alone is enough to warrant it's existence?

I think it's a good idea and you should continue to develop it.

[tggzzz]

right now my aim is to make it work then see professionals, for help and advice.

Do it in that order and you may spend a few years of your life developing something nobody wants.

I suggest you might like to make a "napkin prototype" and show it to professionals. A napkin prototype is something that is drawn on the back of a napkin in sufficient detail that the overall objectives, inputs, outputs and algorithms can be understood and believed - but there is zero implementation. If you can't do that then you don't understand your problem well enough to start implementation.

Fail early, fail fast, if necessary move onto the next thing.

[tggzzz]

It's a bit harsh to say the machine he wants to make might cause death!

Harsh, but accurate - and I even gave the scenario.

As for your other points: good luck arguing those points in court against a well-prepared lawyer.

I would look at it a positive way i.e. a child has 80% chance more of being diagnosed than before, but it's not a pace maker, just a ECG effectively from my understanding, so it won't CAUSE death.

If it doesn't pick up one then that is unfortunate, but you shouldn't rely on the machine alone, and it's not fair to blame the maker of the machine, it's not a life support machine.

I think it's a good idea, as long as you use it within it's safety and operating limits, bit like a sat nav, use it 80 - 90% of the time as it does get it right (these days), the remainder is down to other devices or knowledge, i.e. signs to look for.

As long as the operational limits are understood then it will be a good tool.

It might be that it picks up the issue and theres nothing that can be done even, but even if it helps to save just 1% more of sick infants, surely that alone is enough to warrant it's existence?

I think it's a good idea and you should continue to develop it.

[warner]

ok i can completely see what you are saying, i have already done research on this, seen what devices are out there,
i completed this as a college assignment, and got a merit for it,
I understand how a ECG machine works, i know there are many different types.
i have already built a WORKING ecg circuit, i bought my oscilloscope just to be able to test the circuit out, and it does pick up my heart beat,
The reason for my question is im trying to find a way to compare the ECG readout whether it be graph mathematics algorithms, and when i say compare i mean the heart reading of a person having a heart attack to the person who is actually using it.
Now i have tested it on myself but i dont have any heart conditions so a little hard to test, and im not willing to put anyone else in danger, so i will only test it on me.
the only reason i have build this device from scratch was to complete my college project, and now i want to improve on the circuit by adding a micro-controller, and then program it.
Im trying to find what would be the best micro-controller  for this project.
As i have said i have spend about 1 and  a half years researching, going through datasheets, making up schematics, and doing reports, how to's guides, and learning as much as im able to able how it works, and the best method detecting the heart.

That i am aware, you cant upload pictures to a micro controller, what im looking for is a method or way that i can cross examine or compare to heart readings or the sinusoidal wave of their beating hearts, one being from a live feed, one for a algorithm, or database, but getting the micro controller to be able to do the processing ,

it does not bother me what mcu i use.

I am open to ideas, an i enjoy all constructive criticism, i am not rich, but do have what i think to be a decent selection of components both passive and active, limited range of mcu's,
i would not mind buying a ecg to play around with, test etc, but as i still have my college project built and working, i am playing round with that for now, at least until im able to buy or someone suggests a better idea or method.
Im no expert but if i just stop because everyone tells me its too hard, or its really complex, then i will never get anywhere in life, and this is something i love doing, it makes me want to wake up everyday.
 

[warner]

Ok correct me if im wrong here, but im not creating something that intends to hurt babies infants etc, the idea is to be able to detect heart conditions before they arise at the end of the day an infant cannot talk, cant say im in pain, or my heart is going really fast, and the majority of early parents usually panic when and if they knwo there child is in pain,
the idea if this is to be able to tell the parents to get there child to a hospital, to be able to give them the precious minutes which could save that child's like, and yes fair enough no one might watn it, but i know when i had my first child, and if she had a heart condition, i would want a working device like this that tells me when my child is having a heart problem.
Im not doing this to make money , im doing doing because i want to help give infants a voice, to be able to possibly save a few lifes, for ME thats worth spending 25 years developing something that will in advanced tell me when my child is going to have heart problems, being able to reduce the number of deaths within infants i believe to be highly important.
Im looking for help to choose the right mcu, because i dont know enough about mcu's to be able to choose one.

Btw thank you for your polite comment Wilksey

[tggzzz]

Im no expert but if i just stop because everyone tells me its too hard, or its really complex, then i will never get anywhere in life, and this is something i love doing, it makes me want to wake up everyday.

True, and that's why people are giving you hints about how to succeed.

But, as some Nobel laureate or other put it, "the trick is to pick problems that are hard but soluble within a reasonable time"

[tggzzz]

im not creating something that intends to hurt babies infants etc,

Im not doing this to make money

While true, in plausible worst-case scenarios those points are irrelevant.

[warner]

thanks tggzzz,
and i do agree, but you also need to be passionate about it.

[timb]

The problem isn't your MCU choice at this point, as others have stated. The problem is you don't know enough about your project requirements to even be thinking of an MCU at this point.

You need to take this idea to a professional cardiologist or academic in this field and work with them to figure out simple, basic stuff like: What formats are ECG readouts stored in.

You can't even answer that question, yet you want to know the best MCU to use for processing them? It makes no sense.


Sent from my Tablet

[AndreasF]

...
The reason for my question is im trying to find a way to compare the ECG readout whether it be graph mathematics algorithms, and when i say compare i mean the heart reading of a person having a heart attack to the person who is actually using it.
Now i have tested it on myself but i dont have any heart conditions so a little hard to test, and im not willing to put anyone else in danger, so i will only test it on me.

The article I linked to in my first reply mentions a database of ECG recordings that they used to evaluate the classification performance of their device. You could see if you could can get access to these data as well to work on yours.

... Im trying to find what would be the best micro-controller  for this project.

For a prototype you can always go with a more powerful controller. Once things are working OK, you'll have a better estimate of actual memory and processing requirements, and you can then optimize to see if a less powerful device would work as well. Since the detection and classification algorithms will probably involve some pretty sophisticated math, you will probably want a decent ARM processor, maybe one that can do HW floating point operations such as the Cortex M4.

[jeremy]

Wow! I work in medical electronics, so this is kind of my area. But I take no responsibility for you following any of my advice Of course, I agree with everyone here, but you asked the question so I think you at least deserve a real answer.

First of all, you shouldn't connect an oscilloscope to you without an isolation transformer on the mains or optical isolator on the output of the frontend. Whether or not you feel safe doing it, it's against medical safety regulations to do so. You should look at IEC60601 for more information (but it isn't free unfortunately).

Secondly, a good source of information for you would be an article named "The Principles of Software QRS Detection" by some chaps at the Berlin University of Technology. It's a good overview of the sort of technologies used in this area. Note though that this only goes into detection of the QRS complex, not the P or T waves which would probably be needed for diagnostic purposes. Be prepared for a lot of mathematics.

Generally, the methods of detection other than simple thresholding are very heavy in DSP, so you would probably want a Cortex M4 or a true DSP like a Blackfin. I don't think an 8/16bit micro is a good idea (AVR, PIC, MSP430, STM8S, etc).

And just one question for you before I go: why do you think the device you're designing hasn't been invented yet?

[warner]

thanks timb, and andreasF
yes i do agree, i need to speak with a professional cardiologist, snf s good point to i can always change the mcu

[Codemonkey]

If I were you I would find a simple way of hooking up your ECG circuit up to a PC (soundcard input or something), and develop your software on a PC. Once complete, you'll have a better idea of the resources required to implement your solution, then you can look at cramming it all into a microcontroller. Probably not what you want to hear, but you'll be a lot more productive and it will be MUCH easier to debug the thing. Save the ECG traces in WAV files or something, then you can use a WAV file editor to create example traces to simulate the conditions you want to detect. Quite how you're going to compare the live data against all the condition traces I don't know, but its not going to be trivial or a simple case of overlaying things.

To be honest, I think you're way out of your depth. The very fact that the thing is going to be used to potentially diagnose some sort of medical condition means that it will be subject to more stringent testing even if it can't directly cause any harm to the wearer. I believe some other product recently fell foul of the same regulations and release to the market had to be delayed until more testing had been completed (sorry, can't remember what it was now).

[jeremy]

"the trick is to pick problems that are hard but soluble within a reasonable time"

(bold mine)

Oh man this made my day. I think I'm going to start saying that.

[jeremy]

... you will probably want a decent ARM processor, maybe one that can do HW floating point operations such as the Cortex M4.

Just for the record, the M4 can't do hardware floating point, only the M4F. The F stands for "Floating point" I think But they both have DSP extensions. In general, I don't think there are any reasons that you couldn't do this with fixed-point math.

[warner]

thanks jeremy
i have looked into QRS complex, and the timing with this.
thank you all for your comments, highly appreciated,
i have gone into the maths side although i find it hard, but i have still done it, ive gone into all or alot of the different types of heart conditions, looked at ecg images ( from google).

I have arranged an appointment to see a cardiologist

[warner]

i am aware, i probably am out of my depth, but i want to learn, this is something im passionate about.

[WarSim]

... you will probably want a decent ARM processor, maybe one that can do HW floating point operations such as the Cortex M4.

Just for the record, the M4 can't do hardware floating point, only the M4F. The F stands for "Floating point" I think But they both have DSP extensions. In general, I don't think there are any reasons that you couldn't do this with fixed-point math.

Yes I do see your point.  But I will add this for you consideration.  The op seems to want this device to be closer to an ECG monitor that a Heart rate monitor.  ECG characteristics are much more varied in the infant and child. 

Performing a usable comparison would require floating point math.  If the sample and example are normalized for integer math many features will be lost.  The reason the most common answer says he will need to use floating point math, unless the op gives indication he is looking to build something much closer to a heart rate monitor. 

Besides requiring a floating point math dose not make the project unfeasible.

[Rasz]

there is always https://www.google.com/search?q=ecg+compressed+sensing


Whole thread reads like Nigerian scam chain mail. Im impressed how everyone is so nice and accommodating, Im barely able to stop myself.

[mtdoc]

Warner-

I commend your enthusiasm and intentions but irregardless of the technical difficulties (which others have described well) I don't think your planned device makes sense from a medical perspective.   ECGs are of marginal use for most pediatric heart problems.  Most pediatric heart conditions are structural (valves, heart chambers, etc) that affect the heart's pump function and oxygenation of lungs and the rest of the body.  These problems are best monitored by an echocardiogram (basically an ulstrasound of the heart).

Conditions causing fatal arrhythmias are extremely rare and in most cases not easily identified by ECGs ahead of time.  The exception is bradycardia (slowed heart rate). There already exists several commercial infant heart rate monitors - yet even this simple type of home monitor has been found to be of little benefit - causing lots of parental anxiety with false alarms, etc.  They have not been shown to save lives.

The bottom line is that even if you could create a device to be used at home which would monitor a childs ECG and compare it to previous ones - it would be of little or no benefit medically except perhaps to give overly anxious parents something else to worry about....

Good luck and keep thinking outside the box.  If your interested in medical device design, I'd recommend some education (formal or informal) in biomedical engineering to better identify where the need is for new innovative devices.

[warner]

Warner-

I commend your enthusiasm and intentions but irregardless of the technical difficulties (which others have described well) I don't think your planned device makes sense from a medical perspective.   ECGs are of marginal use for most pediatric heart problems.  Most pediatric heart conditions are structural (valves, heart chambers, etc) that affect the heart's pump function and oxygenation of lungs and the rest of the body.  These problems are best monitored by an echocardiogram (basically an ulstrasound of the heart).

Conditions causing fatal arrhythmias are extremely rare and in most cases not easily identified by ECGs ahead of time.  The exception is bradycardia (slowed heart rate). There already exists several commercial infant heart rate monitors - yet even this simple type of home monitor has been found to be of little benefit - causing lots of parental anxiety with false alarms, etc.  They have not been shown to save lives.

The bottom line is that even if you could create a device to be used at home which would monitor a childs ECG and compare it to previous ones - it would be of little or no benefit medically except perhaps to give overly anxious parents something else to worry about....

Good luck and keep thinking outside the box.  If your interested in medical device design, I'd recommend some education (formal or informal) in biomedical engineering to better identify where the need is for new innovative devices.

Thank you, much appreciated, this is something i am highly interested within, and thank you for the information,
and i will certainly look into biomedical engineering, thank you so much

[WarSim]

i am aware, i probably am out of my depth, but i want to learn, this is something im passionate about.

In reading this thread I think the biggest concern is that you need to know the costs.  I know several people that have lost their houses because they stepped into the medical device field unprepared. 
The points I want you to consider are: 
1:  The medical device field is very regulated, and layers of regulation costs you money.  Ie many years ago a friend paid $30,000.00 for a preliminary design review and received the answer "design criterial not met" answer.  After allot of head scratching he figured out he didn't specify the specific type suffix on one cap. 
2:  Your device does not need to cause death for you to loose everything.  It is possible to be sued for perceived harm.  Everyone want to help an infant, but few can risk the legal dangers.  The biggest reason only the well connected huge companies enter this area for the huge profits, less the cost of a huge legal team of course.  After all a hot cup of coffee cost one company big just because the hot coffee was actually hot. 
3:  Just because this project is medical device it will take you years to get it out there.  But it will take a big company much less time to like your idea and make their own. 
4:  testing of any sort of a medical device has many regulation.  Please don't even use the device on your own kid, and tell anyone about it.  If child welfare finds out from the wrong people you could have a battle you don't want.  Technically testing the device on your self is not allowed but Darwinism is an accepted concept.

The advice given is advised options. 
If you only want the device created and no money back.  Pitch your uncertified unfinished device to a medical device company.  Who knows they may hire you to develop it for them.  This has happened before. 
If you do not want to give up control, and still not get profit.  Go back to your school and see if you can make it under a fellowship.  The easiest way I know of to be classified as research for a medical device. 

Your options are endless.  Just understand the medical device field is very different in many ways (legally, technically and psychologically).  My personal choice was to stay away, but you are free to make your choice.  I just want you to enter it with as much information you can get. 

The rest of the comments about process are valid but also but not the purpose of my response.

[paulie]

when i say images, im talking jpeg.

ignoring liability and medical issues for now i suspect a microcontroller is not the best tool for this job. a full size pc may have a shot. certainly the easiest first iteration. comparing "pictures" is not  trivial. programming, not circuit design, will most likely eat up virtually all the development time and money.

also appears this must be farmed out. judging from comments i estimate 20-30 year learning curve for diy.

[jeremy]

... you will probably want a decent ARM processor, maybe one that can do HW floating point operations such as the Cortex M4.

Just for the record, the M4 can't do hardware floating point, only the M4F. The F stands for "Floating point" I think But they both have DSP extensions. In general, I don't think there are any reasons that you couldn't do this with fixed-point math.

Yes I do see your point.  But I will add this for you consideration.  The op seems to want this device to be closer to an ECG monitor that a Heart rate monitor.  ECG characteristics are much more varied in the infant and child. 

Performing a usable comparison would require floating point math.  If the sample and example are normalized for integer math many features will be lost.  The reason the most common answer says he will need to use floating point math, unless the op gives indication he is looking to build something much closer to a heart rate monitor. 

Besides requiring a floating point math dose not make the project unfeasible.

Well unfortunately this is not true, and I know because I have previously done the exact thing you have said is not possible. I can't give any sources, but it's anecdote vs anecdote here anyway. Sorry! 

[warner]

when i say images, im talking jpeg.

ignoring liability and medical issues for now i suspect a microcontroller is not the best tool for this job. a full size pc may have a shot. certainly the easiest first iteration. comparing "pictures" is not  trivial. programming, not circuit design, will most likely eat up virtually all the development time and money.

also appears this must be farmed out. judging from comments i estimate 20-30 year learning curve for diy.

yes, you are right, there are alot of different ways and methods this could be built and alot of ways i could get sued or in legal problems, but this is why i test it on ME, i refuse to test on anyone else but me,  and thank you for pointing out all the legal side, this is something i need to go deeper into once i have completed the build and got it all working ( second circuit).

[Jeroen3]

I've seen someone walk around with a device like this. It was powered by some small batteries, and it could beep and store any anomalies it measured in the heartbeat.
Then you go to the hospital, they read it, and voila an basic ecg from when something did actually happen.
These are used to investigate arrhythmia. Because when you're hooked up to the hospital ecg, everything looks fine...
Another feature was that you were able to push a button when it detected something. Because some physical activities might trigger a false-alarm.

For educational purposes this is a great project, and part of my last university year had to develop such device. For elderly people.
Detect basic life signs, and detect when they fall. The problem was is that elderly people might fall, and are not able to get up due to weakness or hip fractures.
Some groups used this: http://people.csail.mit.edu/mrub/vidmag/

[mtdoc]

I've seen someone walk around with a device like this. It was powered by some small batteries, and it could beep and store any anomalies it measured in the heartbeat.
Then you go to the hospital, they read it, and voila an basic ecg from when something did actually happen.
These are used to investigate arrhythmia. Because when you're hooked up to the hospital ecg, everything looks fine...
Another feature was that you were able to push a button when it detected something. Because some physical activities might trigger a false-alarm.

Yes, "Holter monitors" which record continuously (usually for 48 hours) and "Cardiac event monitors" ( which record and store a buffer then only keep the data immediately before and after an "event" which is marked by the patient pushing a button, have been around for years. Traditionally, these were kept for a short period by patients and the data was later downloaded for review by a physician.

Now the trend is to use small, one time use, devices which are mailed by the patient into the company that makes them for preliminary data review which is then passed on to  a physician locally.

The "Zio Patch" is the leading brand which I use for my patients.

These are useful for adults (where cardiac arrhythmias are common) but rarely used in children for reasons I described above.

[warner]

good to know, thank you

[paulie]

Cardiac event monitors" ( which record and store a buffer then only keep the data immediately before and after an "event" which is marked by the patient pushing a button

A perfect application for MCU. Pushing a button a lot easier to detect than analyzing EKG data for anomalies or comparing pictures. Several orders of magnitude easier.

[WarSim]

... you will probably want a decent ARM processor, maybe one that can do HW floating point operations such as the Cortex M4.

Just for the record, the M4 can't do hardware floating point, only the M4F. The F stands for "Floating point" I think But they both have DSP extensions. In general, I don't think there are any reasons that you couldn't do this with fixed-point math.

Yes I do see your point.  But I will add this for you consideration.  The op seems to want this device to be closer to an ECG monitor that a Heart rate monitor.  ECG characteristics are much more varied in the infant and child. 

Performing a usable comparison would require floating point math.  If the sample and example are normalized for integer math many features will be lost.  The reason the most common answer says he will need to use floating point math, unless the op gives indication he is looking to build something much closer to a heart rate monitor. 

Besides requiring a floating point math dose not make the project unfeasible.

Well unfortunately this is not true, and I know because I have previously done the exact thing you have said is not possible. I can't give any sources, but it's anecdote vs anecdote here anyway. Sorry! 

Cool,  BTW I did not intend that it was "not possible".  I meant to say that I agree with the previous post saying an FPU maybe required.  I am just making my opinion based on information I received from prenatal medical persons. 
I spent the last 8 years of my career doing things that was deemed impossible.  I would never intentional say something was not possible.  I added that even if it did need a FPU doesn't mean the project is not possible, to emphasize that the project is still possible.  I guess I did not stress that point enough.

[paulie]

I have a strong suspicion that real time detection of EKG anomalies, specially comparing with JPGs, without an FPU is VIRTUALLY impossible. The real question is whether any off the shelf MCUs would provide a cost effective solution.

[nali]

I've seen someone walk around with a device like this. It was powered by some small batteries, and it could beep and store any anomalies it measured in the heartbeat.
Then you go to the hospital, they read it, and voila an basic ecg from when something did actually happen.
These are used to investigate arrhythmia. Because when you're hooked up to the hospital ecg, everything looks fine...
Another feature was that you were able to push a button when it detected something. Because some physical activities might trigger a false-alarm.

Yes, "Holter monitors" which record continuously (usually for 48 hours) and "Cardiac event monitors" ( which record and store a buffer then only keep the data immediately before and after an "event" which is marked by the patient pushing a button, have been around for years. Traditionally, these were kept for a short period by patients and the data was later downloaded for review by a physician.

Now the trend is to use small, one time use, devices which are mailed by the patient into the company that makes them for preliminary data review which is then passed on to  a physician locally.

The "Zio Patch" is the leading brand which I use for my patients.

These are useful for adults (where cardiac arrhythmias are common) but rarely used in children for reasons I described above.

I used to work for a company making Holter recorders/analysers back in the '90s. For the analysis we used a bunch of analogue filters to isolate & separate the component parts of the waveform (P-wave, QRS, T-wave) then once the ECG had been broken down into basic digital data a couple of 8-bit micros looked for misshapen, early/late beats, tachycardia etc. One of the biggest challenges was separating the ECG from EMG (electrical noise produced by muscles).

Even then, the ECG was just replayed and detected events just highlighted for a human to decide whether they were of real concern or an artifact...

It's a noble enough project, but more sited for a Uni degree or something like that IMHO.

[jeremy]

...
Well unfortunately this is not true, and I know because I have previously done the exact thing you have said is not possible. I can't give any sources, but it's anecdote vs anecdote here anyway. Sorry! 

Cool,  BTW I did not intend that it was "not possible".  I meant to say that I agree with the previous post saying an FPU you me required.  I am just making my opinion based on information based on information received from prenatal medical persons. 
I spent the last 8 years of my career doing things that was deemed impossible.  I would never intentional say something was not possible.  I added that even if it did need a FPU doesn't mean the project is not possible, to emphasize that the project is still possible.  I guess I did not stress that point enough.

No biggie, wasn't trying to be argumentative, just saying that I've done it already, that's all  . The trouble with FPUs I have found is floating point ops can get tricky when you have hardware interrupts. I believe this is the reason the linux kernel has a blanket ban on floating point operations (or at least it did the last time I checked).

I have a strong suspicion that real time detection of EKG anomalies, specially comparing with JPGs, without an FPU is VIRTUALLY impossible. The real question is whether any off the shelf MCUs would provide a cost effective solution.

Ok, well if you're going to be like that, then please be kind enough to explicitly define what you mean by "real time", "detection", "EKG" (number of leads, position?) and "EKG anomalies". Also, please read this: http://link.springer.com/chapter/10.1007%2F978-3-642-53862-9_31 (title is: "Using Fixed Point Arithmetic for Cardiac Pathologies Detection Based on Electrocardiogram")

[warner]

It's a noble enough project, but more sited for a Uni degree or something like that IMHO.

yes i do agree, and i would like to go to do my hnc/hnd,and further into the field, but for now, all i can do is work with what i have, and at least attempt to work on it, and try and complete until im able to go to uni.

[free_electron]

maybe a silly question but let's take a look at step 1 :

do you have a working circuit that can pick up the heartbeatsignal and reject all the unwanted 'noise' ( baby tossing an turning, hitting the side of the bed, some kid with a badly dampened motorcycle nextdoor gooing brumbrumbrumbwabwabwabweeeeeeee ( you know what i mean , those undampened spark plugs cause massive noise in the spectrum ) ,and all other possible sources of disturbances.

that alone is not easy to do : picking up reliably the heartbeat.  you say you want to put the sensor in a blanket.. what if the kid shifts a bit in respect to where the sensor is.

have you actually tried those things with a real baby ? does it work 100% ?

if not -> back tot the drawing board. you ain't even close to tackling the cpu part.
a cpu with display showing pictures is the easy part.

the hard bit is the acquisition and conditioning of a reliable clean signal ... that is where most of the hard work will be

[warner]

maybe a silly question but let's take a look at step 1 :

do you have a working circuit that can pick up the heartbeatsignal and reject all the unwanted 'noise' ( baby tossing an turning, hitting the side of the bed, some kid with a badly dampened motorcycle nextdoor gooing brumbrumbrumbwabwabwabweeeeeeee ( you know what i mean , those undampened spark plugs cause massive noise in the spectrum ) ,and all other possible sources of disturbances.

that alone is not easy to do : picking up reliably the heartbeat.  you say you want to put the sensor in a blanket.. what if the kid shifts a bit in respect to where the sensor is.

have you actually tried those things with a real baby ? does it work 100% ?

if not -> back tot the drawing board. you ain't even close to tackling the cpu part.
a cpu with display showing pictures is the easy part.

the hard bit is the acquisition and conditioning of a reliable clean signal ... that is where most of the hard work will be

Hi thanks for your comment, yes i have a working circuit, when i say working i mean it picks up my heartbeat, when in bed, the sensors are embedded into a sheet, with conductive thread, its not wireless at the moment,
i have a bandpass filter, which was accurate enough for my college project, and had no problems picking up my heart beat, for 48 hours, i have not tried it on a child, simple because im not prepared to put anyone in any form of danger, until im told by someone whom is qualified in hnc/d checks the circuit, although i was told by my college teacher, it was fine, but i prefer to be the test subject, until i know its protected from anyone else getting any type of feedback, bear in mind this circuit which works is without a mcu.

[Wilksey]

Well, that escalated quickly!

It won't have medical approval so it can't be used as the holy saviour of the medical world, but for a bit of monitoring, where's the harm?

Purely depends on how it is marketed, it is not a device to prevent heart failure, it is a monitoring TOOL.

Am I oversimplifying this? The tool can be used to alert parent's / carers if anything is awry, serious cases will be hooked up to a pukka heart monitor in the hospital anyway.

This can be used on adults as well as infants.

If a child is born with a hole in it's heart for example, I guess you could monitor for abnormal rhythms and the like.

I still think it's a good idea, just expect to put in a LOT of work if it has to ever meet medical approval.

And hey, even if it doesn't sell, at least you will have learned a lot by trying!

[warner]

Well, that escalated quickly!

It won't have medical approval so it can't be used as the holy saviour of the medical world, but for a bit of monitoring, where's the harm?

Purely depends on how it is marketed, it is not a device to prevent heart failure, it is a monitoring TOOL.

Am I oversimplifying this? The tool can be used to alert parent's / carers if anything is awry, serious cases will be hooked up to a pukka heart monitor in the hospital anyway.

This can be used on adults as well as infants.

If a child is born with a hole in it's heart for example, I guess you could monitor for abnormal rhythms and the like.

I still think it's a good idea, just expect to put in a LOT of work if it has to ever meet medical approval.

And hey, even if it doesn't sell, at least you will have learned a lot by trying!

Hi there wilksey, thanks for your input so far,
The way it started was to build an ecg, some way i could watch and monitor my heart beat,
then my son was born, thats what made me think, hmmmm, why cant i use this type of device, to monitor and and possibly prevent infants from heart conditions,
so yes to answer your question,
it has been built as a monitoring tool, and to try and prevent infants from dying whom have heart conditions from an early age, with the idea, of being able to put the sheet under infants cot, and it alerts the parents /careers or guardian of any possible up and coming heart conditions, there is alittle more to it within the coding side, ( ie to be able to give guidance on what to do and what not to do ( depending on what type of heart condition is happening) this will be done by professional medical personnel only)).
The basic idea behind it, and please do correct me if im wrong here, but if a infant was at home, after birth and is known to have heart problems, ( that im aware off heart attacks etc normally only last upto 2 minutes, that im aware off an ambulance takes around 5 upto 10 mins, depending on where they live of course,
therefore if i infant was to have a attack, they would have around 2-5 minutes max before possible death,

If i can get this device to work how im wanting it too, the basic idea is, infants "hooked up to it", parents are alerted say 20 mins before it happens and machine tells they to take infant to hospital as childs having congestive heart failure.
With the hopes the paretns would take the child to hosptial, child can then be seen by professional docts, who might be able to save childs life,
And yes it is possible it could work on adults, and oap's,

"If a child is born with a hole in it's heart for example, I guess you could monitor for abnormal rhythms and the like." yes i completely agree there, i have a list of heart related problems, how they are caused, what patterns to look for, what i t looked like on an oscilloscope etc.

[warner]

Differentiating the P-, QRS- and T-waves
Because of the anatomical difference of the atria and the ventricles, their sequential activation, depolarization, and repolarization produce clearly differentiable deflections. This may be possible even when they do not follow one another in the correct sequence: P-QRS-T.

 Identification of the normal QRS-complex from the P- and T-waves does not create difficulties because it has a characteristic waveform and dominating amplitude. This amplitude is about 1 mV in a normal heart and can be much greater in ventricular hypertrophy. The normal duration of the QRS is 0.08-0.09 s.
 If the heart does not exhibit atrial hypertrophy, the P-wave has an amplitude of about 0.1 mV and duration of 0.1 s. For the T-wave both of these numbers are about double. The T-wave can be differentiated from the P-wave by observing that the T-wave follows the QRS-complex after about 0.2 s.





Supraventricular rhythms

Definition
Cardiac rhythms may be divided into two categories: supraventricular (above the ventricles) and ventricular rhythms.
 The origin of supraventricular rhythms (a single pulse or a continuous rhythm) is in the atria or AV junction, and the activation proceeds to the ventricles along the conduction system in a normal way. Supraventricular rhythms
Normal sinus rhythm
Normal sinus rhythm is the rhythm of a healthy normal heart, where the sinus node triggers the cardiac activation. This is easily diagnosed by noting that the three deflections, P-QRS-T, follow in this order and are differentiable. The sinus rhythm is normal if its frequency is between 60 and 100/min.<

The extra Definition part, is a reminder for me for when I look back at this part.


Name   Description   Heart and beat
Sinus Tachycardia   If the sinus rhythm is irregular such that the longest PP- or RR-interval exceeds the shortest interval by 0.16 s, the situation is called sinus arrhythmia. This situation is very common in all age groups. This arrhythmia is so common in young people that it is not considered a heart disease. One origin for the sinus arrhythmia may be the vagus nerve which mediates respiration as well as heart rhythm. The nerve is active during respiration and, through its effect on the sinus node, causes an increase in heart rate during inspiration and a decrease during expiration. The effect is particularly pronounced in children.
 Note, that in all of the preceding rhythms the length of the cardiac activation cycle (the P-QRS-T-waves together) is less than directly proportional to the PP-time. The main time interval change is between the T-wave and the next P-wave. This is easy to understand since the pulse rate of the sinus node is controlled mainly by factors external to the heart while the cardiac conduction velocity is controlled by conditions internal to the heart.   
Wandering Pacemaker   Paroxysmal atrial tachycardia (PAT)
Paroxysmal atrial tachycardia (PAT) describes the condition when the P-waves are a result of a reentrant activation front (circus movement) in the atria, usually involving the AV node. This leads to a high rate of activation, usually between 160 and 220/min. In the ECG the P-wave is regularly followed by the QRS-complex. The isoelectric baseline may be seen between the T-wave and the next P-wave.
Atrial flutter
When the heart rate is sufficiently elevated so that the isoelectric interval between the end of T and beginning of P disappears, the arrhythmia is called atrial flutter. The origin is also believed to involve a reentrant atrial pathway. The frequency of these fluctuations is between 220 and 300/min. The AV-node and, thereafter, the ventricles are generally activated by every second or every third atrial impulse (2:1 or 3:1 heart block).
the AV-nodal impulse reaches the atria before, simultaneously, or after the ventricles, an opposite polarity P-wave will be produced before, during, or after the QRS-complex, respectively. In the second case the P-wave will be superimposed on the QRS-complex and will not be seen.   
Junctional Rhythm   In ventricular arrhythmias ventricular activation does not originate from the AV node and/or does not proceed in the ventricles in a normal way. If the activation proceeds to the ventricles along the conduction system, the inner walls of the ventricles are activated almost simultaneously and the activation front proceeds mainly radially toward the outer walls. As a result, the QRS-complex is of relatively short duration. If the ventricular conduction system is broken or the ventricular activation starts far from the AV node, it takes a longer time for the activation front to proceed throughout the ventricular mass.
 The criterion for normal ventricular activation is a QRS-interval shorter than 0.1 s. A QRS-interval lasting longer than 0.1 s indicates abnormal ventricular activation. Ventricular arrhythmias are presented in Figure 19.3.
Premature ventricular contraction
A premature ventricular contraction is one that occurs abnormally early. If its origin is in the atrium or in the AV node, it has a supraventricular origin. The complex produced by this supraventricular arrhythmia lasts less than 0.1 s. If the origin is in the ventricular muscle, the QRS-complex   
Ventricular Tachycardia   When ventricular depolarization occurs chaotically, the situation is called ventricular fibrillation. This is reflected in the ECG, which demonstrates coarse irregular undulations without QRS-complexes. The cause of fibrillation is the establishment of multiple re-entry loops usually involving diseased heart muscle. In this arrhythmia the contraction of the ventricular muscle is also irregular and is ineffective at pumping blood. The lack of blood circulation leads to almost immediate loss of consciousness and death within minutes. The ventricular fibrillation may be stopped with an external defibrillator pulse and appropriate medication.   
Ventricular Fibrillation   A ventricular rhythm originating from a cardiac pacemaker is associated with wide QRS-complexes because the pacing electrode is (usually)   
A-V Block, First Degree   If the PQ-interval is longer than normal and the QRS-complex sometimes does not follow the P-wave, the atrioventricular block is of second-degree. If the PR-interval progressively lengthens, leading finally to the dropout of a QRS-complex, the second degree block is called a Wenkebach phenomenon.   
A-V Block, second  Degree   Complete lack of synchronism between the P-wave and the QRS-complex is diagnosed as third-degree (or total) atrioventricular block. The conduction system defect in third degree AV-block may arise at different locations such as:
•   Over the AV-node
•   In the bundle of His
•   Bilaterally in the upper part of both bundle branches
•   Trifascicularly, located still lower, so that it exists in the right bundle-branch and in the two fascicles of the left bundle-branch.
 
Third-degree atrioventricular block.
Bundle-branch block
Definition
Bundle-branch block denotes a conduction defect in either of the bundle-branches or in either fascicle of the left bundle-branch. If the two bundle-branches exhibit a block simultaneously, the progress of activation from the atria to the ventricles is completely inhibited; this is regarded as third-degree atrioventricular block (see the previous section). The consequence of left or right bundle-branch block is that activation of the ventricle must await initiation by the opposite ventricle. After this, activation proceeds entirely on a cell-to-cell basis. The absence of involvement of the conduction system, which initiates early activity of many sites, results in a much slower activation process along normal pathways. The consequence is manifest in bizarre shaped QRS-complexes of abnormally long duration. The ECG changes in connection with bundle- branch blocks are
Right bundle-branch block

If the right bundle-branch is defective so that the electrical impulse cannot travel through it to the right ventricle, activation reaches the right ventricle by proceeding from the left ventricle. It then travels through the septal and right ventricular muscle mass. This progress is, of course, slower than that through the conduction system and leads to a QRS-complex wider than 0.1 s. Usually the duration criterion for the QRS-complex in right bundle-branch block (RBBB) as well as for the left brundle- branch block (LBBB) is >0.12 s.
 With normal activation the electrical forces of the right ventricle are partially concealed by the larger sources arising from the activation of the left ventricle. In right bundle-branch block (RBBB), activation of the right ventricle is so much delayed, that it can be seen following the activation of the left ventricle. (Activation of the left ventricle takes place normally.)
 RBBB causes an abnormal terminal QRS-vector that is directed to the right ventricle (i.e., rightward and anterior). This is seen in the ECG as a broad terminal S-wave in lead I. Another typical manifestation is seen in lead V1 as a double R-wave. This is named an RSR'-complex.   
Right Bundle Branch Block       

[mtdoc]

Warner, the problem is that those ECG findings are generally  not sensitive or specific enough to be of use in evaluating pediatric heart disease - at least not in the context you are looking at.

To learn more about what I mean by sensitivity and specificity in a medic context see HERE

[warner]

Warner, the problem is that those ECG findings are generally  not sensitive or specific enough to be of use in evaluating pediatric heart disease - at least not in the context you are looking at.

To learn more about what I mean by sensitivity and specificity in a medic context see HERE

Hey mtdoc,
completely agree with you, but it is a learning curve, i need to understand the basics of the heart conditions before i can work out how to do it electronically, without me understanding how these problems occur, happen causes etc, then i wont be able to work out how to be able to pick them up/ detect, or know where to start on being able to do this.

[paulie]

Ok, well if you're going to be like that, then please be kind enough to explicitly define what you mean by "real time", "detection", "EKG" (number of leads, position?) and "EKG anomalies".

By real time I assume the few seconds required to take remedial action. As far as leads there don't seem to be any except for wires embedded in a sheet. My only experience resembling anything like this was an EEG analyzer for interpreting brainwave patterns. Research not medical. Even with sophisticated electrode design and electrolyte composition signals were too noisy for a run of the mill MCU so we resorted to a PC at 1/10th the development and 1/5th production cost. Practicality and economy prevailed over portability. It was some time ago but things have probably not changed that much. In my experience the relationship between signal to noise and processing requirement was not a linear nor a favorable one.

Also, please read this: http://link.springer.com/chapter/10.1007%2F978-3-642-53862-9_31

I'm not willing to shell out the 80 bucks to actually read your document but the vague reference to "electrocardiographic registers" and FPGA tells me there was a lot of preprocessing going on and maybe no MCU at all. No mention of JPG database either although we are not sure if OP is on the right track there either.

In any case whether FPU is used or not a PC would probably be a more practical and cost effective solution to what is proposed in this thread. Most certainly first iteration anyway. And VERY unlikely the OPs msp430 based design is up to the task.

[warner]

wow love it, loads of info, awesome thank you love the links,
thank you,

and thank you too all whom give me advice muchly appreciated

[Wilksey]

What you are trying to achieve is perfectly do-able.

As others have said, there is a lot of information contained in this thread, I will not admit to knowing anything about medical equipment, just that it needs to have met certain approvals to be used professionally.

I can imagine it being sold in a similar capacity to a baby monitor almost, in the fact that it is an aid rather than anything else, regardless of it's uses if anything occurs whilst the device is being used, i.e. it alerts you to a heart attack etc.

If you work within the medical profession, or even if you know people who do, you can always ask them, if in doubt, you can always consult a lawyer about potential come backs if the product went into production, there's a lot of them in the UK that will give you 30 mins free advice, just find a decent one!

It's amazing how many useful products have emerged from someone's prototype which might or might not have been all that safe at one point, they may have even been told it was a rubbish idea, they don't have the right approvals etc etc  so even if you do manage to produce a working prototype, it might not be that hard afterwards to improve it to the point where you can get approvals!  You just don't know!

Most of all, have fun and good luck with your project!

[warner]

thank you wilksey
appreciated

[edavid]

i need to understand the basics of the heart conditions before i can work out how to do it electronically...

So why are you here asking about electronics 

[warner]

i need to understand the basics of the heart conditions before i can work out how to do it electronically...

So why are you here asking about electronics 

im asking about mcu's, and i already understand the basics of heart conditions, i learnt that over a year ago whilst doing research, im here to learn more about electronics, and about mcu's especially, plus gather information and advice on building it.

[suicidaleggroll]

i need to understand the basics of the heart conditions before i can work out how to do it electronically...

So why are you here asking about electronics 

im asking about mcu's, and i already understand the basics of heart conditions, i learnt that over a year ago whilst doing research, im here to learn more about electronics, and about mcu's especially, plus gather information and advice on building it.

You need to start by developing and testing your algorithm on a regular computer with a regular compiler, graphics, debugger, etc.  Only after you know exactly what mathematical operations, precision, and processing power you're going to need should you even consider moving to an embedded system.  You're putting the cart WAY before the horse here.  Develop the algorithm first, turn it into a product second...not the other way around.