Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
08/26/09 15:47
Read: times


 
#168562 - not so fast ...
Responding to: ???'s previous message
Ghulam Mustafa said:
Thanks for my correction.
Actually i am working on ECG and interfacing it with the LABVIEW. So i am sending the data thorough the microcontroller and manipulating it in LABVIEW. As you informed me to be aware of the noise, using LabView, I think it will not be a problem. as it has built in filter to separate the noise from the original signal.
Well, the higher the resolution of the signal I think the most appropriate the result will be.

Thanks


Just because a converter claims 14- or 16-bit resolution doesn't mean that your "effective number of bits" will be any greater than 4. The first thing to which you must pay attention is the protection of the analog reference supply, and particularly at the points at which it enters your measurement system, in this case, the MCU. LabView will help you ignore the noise, but it won't help you remove it from the measurement problem. There are random noise inputs that are relatively easy to deal with, but there are also systematic repetetive noise elements e.g. internal clocks, external clocks, etc, other switching signals all of which combine to form a noise profile that isn't so easy to "filter" out. Yes, some of it can be dealt with, but, for example, if you use a MAX-232 type of level shifter, its oscillators contribute systematic and repetetive noise to the system supply that is very pervasive, gets into everything, and therefore is much more difficult to filter out with simple means than totally random noise. What makes random noise easy to filter out, particularly in LabView is that it is totally random. Those repetitive signals unrelated to what you are doing are the ones that cause the real trouble.

My 8-digit GPIB-interfaced DMM's have the potential of being very, Very, VERY accurate, but, sadly, I seldom depend on them for more than a 4- or 5-digit reading because it is so difficult, even with entirely "quiet" (<.1% noise) power supplies, careful supply bypass, etc, to reduce the supply-induced noise beyond that level of accuracy (repetitive precision). That says nothing of the system-induced noise, and the signal from the local radio stations. I've even, at times, had to put my system under test in a Faraday cage to protect it from RFI, whether from radio stations or from the HVAC system. Unfortuntately, my high-precision DMM's sample at 1 kHz. Higher frequency noise escapes their notice, i.e. LabView can't really discern its spectral content, because of aliasing and the result is that it simply raises the noise floor. That noise floor quickly "eats" those last few digits on the display. They often change so fast I cannot read them anyway.

High ADC precision is a good marketing tool, but reasonable understanding of what causes variations in measurement of purportedly DC levels is pretty important. If you are absolutely certain that your power supply to the MCU has less than 1 part in 16384 of random variation at the reference voltage and analog ground pins, you can then hope to extract precise measurements to the level of, say, 12 bits. After all, the internal switching phenomena will quickly disturb your 14-bit measurements. If you carefully study the datasheets and application notes of the MCU and its converter, that will become clear.

Did I mention switching power supply ripple? If there's a switching power supply in the room, it will affect a 14-bit converter, even if it's not connected to the circuit under test. I use power-line conditioning and constant voltage AC supplies, and linear regulation just to avoid external impact on my measurements.

Take a look at your supplies with an oscilloscope and you'll see what I mean about random noise. It will be difficult to distinguish between RFI on the probe and random noise on the supply. That's where the work begins!

RE



List of 26 messages in thread
TopicAuthorDate
Which Controller to choose            01/01/70 00:00      
   Few Questions            01/01/70 00:00      
      More details needed            01/01/70 00:00      
         Details            01/01/70 00:00      
            Too little info to suggest anything.            01/01/70 00:00      
               More detail            01/01/70 00:00      
                  Wrong approach - always focus on signal integrity            01/01/70 00:00      
                     Can you provide more detial            01/01/70 00:00      
                        Always focus on signal integrity            01/01/70 00:00      
                  not so fast ...            01/01/70 00:00      
                     Pls also identify there solutions            01/01/70 00:00      
                        the solutions are self-evident            01/01/70 00:00      
                           And how to get rid of the others            01/01/70 00:00      
                              Get rid of them, probably not, but ...            01/01/70 00:00      
                                 If you consult the documentation your MCU manufacturer provi            01/01/70 00:00      
                                    Precision            01/01/70 00:00      
                                       precision and presision            01/01/70 00:00      
                                          precison vs. accuracy            01/01/70 00:00      
      Controller and ADC type            01/01/70 00:00      
         Possible?            01/01/70 00:00      
            I will try it            01/01/70 00:00      
            That may not work            01/01/70 00:00      
               Original question was about time...            01/01/70 00:00      
   Perhaps This May Help            01/01/70 00:00      
   Concatenate            01/01/70 00:00      
      depends on channels etc            01/01/70 00:00      

Back to Subject List