|
I have a design which expects a TTL level square wave from a radio reciever which is fed into a microcontroller. There is some TTL level noise as no encoding is done on the transmit end. I was wondering if anyone had any pointers on how you could decrease the noise in software? (I understand there are a number of hardware solutions, but I am interested more in learning) I am not looking for anyone to solve my problem for me, just for some advice. Names/articles/topics would be great! |
|||||||||||
|
|
There are many ways to work with noise in software, and they are becoming more and more effective to implement in software instead of hardware, reducing system cost. Instead of attempting to explain it myself, I am going to pass you on to Jack Ganssle, an embedded systems consultant that I have grown from reading the articles of. He has a listing of his articles online, the first one I would like you to is about analog noise in embedded systems. The second article I have to link you to is about using software to reduce noise in your system. I would also suggest his article in smoothing digital inputs and self calibrating systems. After spending time working with embedded systems I hard picked up some of this information from my own errors, but I really enjoyed reading his ways of thinking. The self calibrating system was very obvious to me, but the way he suggested going about it was valuable to me. You may not need the information, but his articles have helped me. |
|||
|
|
|
I've found Digital Signal Processing and the Microcontroller by Grover and Deller to be the only book on filters that I can understand. Unfortunately, it's hard to find cheap. |
|||||||
|
|
Perhaps the "noise" is a problem caused by the lack of encoding. Simple transmitters and receivers require NRZ - Manchester code is often used. |
|||||||||||||
|
|
From your latest comment, I would suggest oversampling the input. Record several consecutive samples, and then your output should be whatever the majority of the recorded samples are. For instance, say you record 10 samples. If you get a noise spike, only one or two of the samples will be corrupted, while the majority of them are the correct value. If you get actual data, then eventually the 1s will outnumber the 0s and the output will change. |
|||
|
|
|
Does your software poll this input, or do you use an interrupt scheme to process it? If you're polling, presumably you read the input at a much higher rate than the expected changes in the signal. If the noise is well separated, very high frequency spikes, these would then look like isolated samples of the 'wrong' polarity. You could mitigate this by keeping the most recent N samples and deciding to read the input as whichever polarity is in the majority. I.e., if N=5, then if you have 3, 4 or 5 '1' bits, your input is a '1'; if you have 0, 1, or 2 '1' bits, your input is a '0'. This is really just a sort of low-pass filter in software. If you are using the input to trigger interrupts on change (both edges), you can have the interrupt routine (ISR) start a timer to cause a second interrupt a short time later, but longer than the noise spike time. Rather than have the input pin ISR directly accumulate signal bits, you have the timer ISR do it. For example, if the signal is low, and a high spike comes along, the rising edge start the timer, but before the timer count expires, the falling edge of the spike resets it, so when the timer interrupt finally does go off, you're looking at the signal, not the noise. The signal, on the other hand, will kick off the timer just once, and the timer ISR will be able to grab the new signal level. Of these two, Polled vs Interrupt, personally I'd go for the polled approach, b/c (1) interrupts are just more complicated, and (2) a pathologically placed pair of spikes could still give you false input. |
|||
|
|
