Hello,
I am working on my senior project and I am stuck with the programming part. We have mixed majors in our group and our school is not programming oriented and we need some help.
We are trying to programming into the HCS12 dragon board, with uses the RS-232.
We are going to take inputs from two devices, an ECG and an Accelerometer. The ECG will take in an analog signal but it won't be a signal the hcs12 would recognize so we would have to convert it to a TTL wave. How would that be done in programming?
Another question. Using the Input Capture mode. This is a function on the HCS12. Would we use the capture mode for both the ECG and accelerometer? This information is going to be transmitted wirelessly to another microcontroller.
This thread moved from C programming forum by one of the moderators.
There is more than one kind of HCS12. You should provide a pointer to the one you are using. It would also be useful if you could point us directly to any online manuals for the board you are using.
What is an ECG?
Which accelerometer are you going to be using? Does it have digital or analog output?
Analog signals should be wired to one of the ADC channels on your board. You might have to also supply some signal translation to bring it into an acceptable range for your ADC input. Consult the specifications for the ADC and the outputs for the devices you intend to hook up.
Accelerometers can sometimes be a bit noisy. You have both mechanical and electrical noise to deal with. You can run a filter algorithm to improve the signal to noise ratio or you can use various filter circuits to precondition the signal. Often, a combination of the two; software and hardware based filtering are advisable. Definitely apply a 60Hz notch filter to your inputs if the board doesn't already supply one between the MUX and the ADC. You might not need the filters if sufficient mechanical damping and electrical shielding are maintained, but these dev boards are usually operated without any cover, so think about noise.
You'll probably also want to mount that accelerometer on a piece of stiff foam or some surface that will yield somewhat to high accelerations. Dropping an accelerometer from just a few inches to a hard surface can easily over stress most devices. Mount it and protect it from over-shock.
EDIT: Do tell us what programming language you are using.
It is a shame his other almost-but-not-quite identical thread (http://forums.devshed.com/c-programming-42/i-need-help-programming-using-hcs12t-651011.html) was not moved also. My answer from there:
We are going to use an HCS12 Dragon board microcontroller which uses the rs-232.Uses RS232 for what? Is that the only I/O you have? You also make the bizarre assumption that we know what "an HCS12 Dragon board microcontroller" is; post a link so we can see what I/O you have available.
The ECG is an analog signal that needs to be converted to a signal that the microcontroller can understand, a TTL wave. How would that be done?How is that a programming problem rather than a hardware problem.
If what you have is this (http://www.evbplus.com/hcs12.html#) then it has 16x10bit ADC channels so what is the problem?
What is the bandwidth and amplitude of the of ECG signal?
Accelerometers can sometimes be a bit noisy. You have both mechanical and electrical noise to deal with. You can run a filter algorithm to improve the signal to noise ratio or you can use various filter circuits to precondition the signal. Often, a combination of the two; software and hardware based filtering are advisable. Definitely apply a 60Hz notch filter to your inputs if the board doesn't already supply one between the MUX and the ADC.
No amount of digital filtering will remove aliasing introduced by sampling lower than 2 x channel bandwidth, so an analogue anti-aliasing filter should be used at least.
Why 60Hz? Is this a mains frequency issue? Mains is at 50Hz where I am sitting. Is this acceptable in this application? 50 to 60 Hz is inside a normal heart-rate range - it is a frequency of interest that you are filtering. I'd be worried if mains interference were occurring on an ECG signal!
I take it all back; this (http://quequero.org/Introduction_to_ECG_filtering) suggests that mains power frequency is an issue to be dealt with on raw ECG data
If the noise is white noise, it can usefully be used to increase the dynamic range of a low resolution ADC by dithering. Oversample at say 8 times the Nyquist limit (i.e. 16 times the highest frequency of interest), and use a rolling-sum of 8 samples, this will give you four bits of additional resolution, plus the anti-aliasing filter cut-off can be eight times higher (which is often then simpler and smaller to implement); in fact it must be higher, because in this case you need the noise for the dithering to work.
[user manual of dragon 12-plus] (http://www. evbplus.com/download_hcs12/dragon12_plus_hcs12_manual. pdf)
ha wow, I'm not allowed to post URLs because I'm a new user?
It uses C.
Two threads were made because when I clicked submit on the first thread, it went to a white screen.. i refreshed it and it still wasn't there on the list so I made another one. Then the other one popped it when I finished the second thread but I couldn't delete the other thread because it said I don't have the administrative tools to do it.
ECG is the same as an EKG if you heard of that, electrocardiogram where you take samples from the heart beats. You get voltage readings out of it, mV.
Since the ecg is going to spit out that weird wave, the program would not be able to recognize it as a ttl wave. Because I plan on using the Input Capture mode to catch the rising edges. I thought to convert it would have to be in the programming, not the hardware.
You do not seem to be reading (or understanding) the answers already given. You should respond to specific suggestions and counter questions, so that those proposing them can a) see that you have considered the suggestion, b) see that you have understood the suggestion, c) get the information they need to better understand you problem and assist you further.
As it is you seem stuck on your flawed solution of converting the waveform into a pulse stream (thus discarding much of the useful diagnostic information contained), to the point that you appear to be ignoring anything that does not directly do what you have decided is right (which it is probably not). You are also asking for a software solution to what appears to be a hardware problem. And you repeatedly assert that the processor cannot handle analogue input; which is patently untrue - I've obviously read more of the data sheet that you. The manual you posted is good in that it tells you about the board, but to program it, you really need the user manual for the micro controller used on the board.
You should use one of the 16 analogue input channels on your device as suggested. Once in the digital domain, you can perform signal processing algorithms to extract the information you need.
Here are some examples of ECG processing:
http://www.librow.com/cases/case-2
http://quequero.org/Introduction_to_ECG_filtering
They are written in MATLAB not C, but it is the principles you need to absorb not the specific implementation. That said I wonder if your board is even capable of doing this processing in real-time?
Please don't just repeat your question again in a different way; that is not the way forward. Address the suggestions already made so that we can better understand what it is you need to do, and why you think it is a problem. Get someone else in your team to read the answers, perhaps if it is meaningless to you, your colleagues may be more inspired.
Clifford
Of course I am going to be taking what is suggested into consideration. I am not working on it as I am replying, I still have other classes and work to get done before I had time to look at it again. And I wasn't enforcing that what I was saying was correct, I was saying what I have been told by other students I have asked. I don't know what is wrong and right at this point, I wasn't assuming or thinking that my statements in the thread was right.
Those links were pretty useful. I have experienced a little Matlab in a previous class so that page was simple to understand. My other team member mentioned to me before that the ecg circuit built has a problem now and is not cooperating. He is testing it with a function generator and does not get the relevent peaks for a signal.
Not sure what the bandwidth was for the ecg signal but the amplitude that we had was around 43mV. We took the circuit and built it based off a project ecg found on the internet. It should have been amplified to the 5V range approx.
[Schematic] http://www. eng.utah.edu/~jnguyen/ecg/bigsch. gif
Well as Clifford pointed out, you don't want to use a mains frequency notch filter on the inputs to your ADC for an EKG. 50/60 beats per/second is a little slow, but definitely within the range of the kinds of signals you want to detect. But you probably will pick up a strong mains signal from your test leads and the body they are attached to! Grounding the body helps, but that can be very dangerous!
Your instrument amplifier circuit on the other hand is susceptible to any mains frequency ripple on the DC supply if it is not battery powered. The circuit diagram doesn't show the voltage regulation circuit you intend to use. I recommend using one or more 9 volt batteries to supply power to this thing. Batteries are quieter and they pose much less risk of electrocution.
I'll have to dig for specs on those op-amps, but I think the intended output is supposed to be compatible with the line-in input to your sound card on your PC. The circuit appears to be primarily for isolation and low pass filter with some gain (how much depends on the gain of those amps).
Not sure what the bandwidth was for the ecg signal but the amplitude that we had was around 43mV. We took the circuit and built it based off a project ecg found on the internet. It should have been amplified to the 5V range approx.The input range for teh ADC is probably the microprocessor supply voltage, which may be 3.3volts or lower, so exercise caution if feeding it 5 volt signals.
The bandwidth you need to determine is the maximum frequency of interest in the signal. This will be higher than the maximum heart rate if you intend to extract diagnostic information other than just heart rate. Either way, you need to sample at least twice this rate, and you need to filter all frequencies above that rate to prevent aliasing.
If there is white-noise on the signal, you can use it to increase resolution by oversampling at a much higher rate (which may make your anti-aliasing filter simpler), you then take the rolling-sum of n samples, such that Sf/n is > 2 x max_frequency_of_interest, this will give you greater resolution and remove the unwanted noise.