In this lesson I would like to look briefly at some of the system design considerations. Signal quality and that data key affects the bandwidth if we need to transmit the signal and both of them have an impact on the battery power and the sensor life. So the parameter that directly affects the signal quality and, inversely, the sensor life, is the number of bits per sample from the ADC, the analog to digital converter. So you can see the errors visually with a two bit and a three bit quantizer, have four levels and eight levels respectively compared to the analog values. So the one on the left is two bit quantizer. The equation below shows the SNR signal to noise ratio. It is also something that is called SQNR: Signal To Quantization Noise Ratio. In terms of the number of ADC bits per sample that is the Q. There is also a rough rule that I use quite often and it works quite well. That is six times the number of bits Q. So if you have a eight bit ADC, you can get about 48 dB dynamic range. [COUGH] And the sampling theorem does not tell us how many bits per sample for the ADC we need. We need to look at some other sources on how to come up with this and most of the times it is the signal properties the physics of the signal that we should be knowing already. The picture here shows the speech and other noise levels in nature. It's shown in dBA. That is dB scale with A rating. A rating is applied to instruments that are used to measure sound levels in an effort to account for the level of loudness perceived by the human ear, the ear is less sensitive to very low audio frequencies and very high audio frequencies as we saw in course one. So from this graph you can see that the conversational speech is at 70 to 80 db level. So you need 12 bits per sample. If you're dealing with audio and music, you need much larger dynamic range. Anywhere from 90 to 120 db dynamic range for audio signals. [COUGH] So one of the most difficult questions is to nail down the ADC parameters before we know what kind of algorithms we want to run on the DSP. And what the intended application is. So just to give you an idea, I listed some signals on this graph and the resulting data race. These are ballpark numbers, take it with a pinch of salt. So if you're building a heart rate monitor for example. You just need to detect the peaks in the waveform. These are called r locations in the QRS complex. I should have put a picture here maybe I'll do that in a future revision. But, in the QRS complex, just to do a heart rate variability, or heart rate monitoring, 1.86 kilobits per second is enough. But if you're building a clinical ECG system it needs to detect subtle changes in the signal that correspond to abnormal patterns in the electrical activity of the heart muscles. So for this you need one kilohertz sampling about 18 bits per sample comes to about 54 to 144 kilobits per second depending on if you're doing a 5 lead ECG or a 12 lead ECG. Similarly for the accelerometer, if you're sampling at 100 Hz with 10 bits per sample, it's pretty good for most of the pedometer fitness applications that you would come across. So the main point that I want to make here is, there's some key considerations you will face in designing the sensory system. How do you pick the transducer for a given battery budget? You will invariably see accelerometers, pressure sensors, and temperature sensors that have very low power consumption and also very high power consumption. So that tends to be one of the big design factors. Then based on that, and the physics of the signal you get to pick the right ADC that you will use. Typically below 12 bits per sample there starts successive approximation resistor A to D converters. They're very, very low power. The other big question is the interchip communication. Because you use I2C or SPI or UR. What really ends up happening is you can send all the data to the processor much sooner and have the processor sleep at the other times. That includes the radio also. Similarly, you can do some processing locally before transmitting the information to the cloud so that you can reduce the amount of data that you are transmitting. In this case, you need to consider the trade off between CPU power for local computation versus the radio power for transmitting that additional delta of the data. One of the most useful ways that I found to optimize the battery life is to take advantage of the latency at the application level. If you do not need the sensor data immediately, like in the case of Wipe which is a realtime system, you can aggregate data, maybe do some local processing and burst at much higher rates very, very infrequently. So If I'm using WiFi, for me this feeds part is about 48 transmissions per second if I'm dealing with diagnostic grid, ECG, and EEG. So these are some of the high-level aspects for sensing and activation. And as I talked about there's huge potential for building really clever systems. Hope you will have fun getting hands-on experience with the board and some of the sensors that you'll be playing with.
