6
\$\begingroup\$

Carrying on further from my previous post and drilling down to specifics, I am trying to figure out the right way to implement "glitch remover", or "noise remover", using electronics (i.e. not in software). From one of the answers in my previous post, I learnt that one could use a RC-circuit for this purpose, and the principles seem to be same (I think) as used for switch debounce.

My key objective is to decode RF data, but noise is triggering my ISR way too fast and starving my main loop() of previous cycles. My device being Arduino (atmega328).

Edit: (about the RF module) I am using this ISM band ASK/OOK receiver module. While the spec page or the website doesn't have a photo of the reverse side PCB, I can tell that it has a miniature white (what looks like) a trimpot. If I had a scope, I'd have tried to turn the trimmer to see if affects the AGC. However it might very-well be for trimming L-C parameters, since same module works for 315 and 433MHz, and the trimmer might just be the factory settings for 433MHz.

At a very high level, the following diagram describes the purpose of "glitch remover". We have a noisy signal on input, but output is fairly noise-free. Noise is any signal transition that is shorter than a certain duration (say 400us).

enter image description here

Edit: Actually the "glitch-free waveform" shown on right is a fake. I quickly drew it up by cleaning the narrower marks in paint. In fact, the waveform on left is actually all noise. In the midst of the high-frequency noise, the real transmitted signal is quite well formed and easy to make out, as it's frequency is much lower, and there is a 'guaranteed' trailing long-space, marking the end of the packet. The real transmitted signal is 12-bits + 1 sync bit. Each bit is represented by 1 Mark, 1 Space, 1 Mark, 1 Space of, where length of Mark/Space vary, e.g.

0: HHHH LLLL LLLL LLLL HHHH LLLL LLLL LLLL 1: HHHH HHHH HHHH LLLL HHHH HHHH HHHH LLLL F: HHHH LLLL LLLL LLLL HHHH HHHH HHHH LLLL (Floating address pin) S: HHHH LLLL LLLL LLLL LLLL LLLL LLLL LLLL

where each H/L has a duration of 100us, and each bit thus takes 3200us. Noise spike are typically 30-40us duration, which is what is causing my ISR to overwork. Based on what I understood from the answer from supercat in my previous question, and based on a little research, I think this is the schematic of what I roughly need.

enter image description here

Need help to check if the schematic is correct ? And what might be the potential values of R1, R2 and C ?

If I understood supercat's response, then to filter out noise signals less than 400us, I can use a 0.22uF capacitor for C, and R2 of 1K, and probably 100R for R1. Is that correct ?

Or, should the schematic be this (of course, this is closer to supercat's description). enter image description here

With R=1K and C=0.22uF ?

I do not have a scope, so unable to do fine measurements and see waveforms, but do have a logic-analyzer. This probably limits what and how I can test if I experiment.

BTW, can I expect that such a "glitch remover" to leave the desirable signals completely intact, or would they suffer some distortion of some kind ?

\$\endgroup\$
5
  • 9
    \$\begingroup\$ If the waveforms in your first drawing are representative, you have a very difficult problem. You have more glitches than signal on the input side in that drawing. How would your circuit know if its supposed to be in a zero state or a one state when the signal is spending near half the time in either state? The kind of glitches you might be able to remove with a simple circuit like you propose is when there's a single, isolated, short glitch in a much longer period where the signal remains constant at the "correct" value. \$\endgroup\$ Commented Dec 20, 2011 at 18:03
  • 1
    \$\begingroup\$ Replying to your edit, even though you can distinguish the high frequency parts of your signal from the low frequency parts, during the low frequency parts I don't know whether I'm looking at positive glitches on a signal that should be low, or negative glitches on a signal that should be high. The passive circuits you proposed won't know either. ... If you know that the signal should always be zero in the low frequency part, for example, you may be able to eliminate the glitches. But you will need some kind of digital circuit (I'd think more a CPLD than a uC) rather than just an RC filter. \$\endgroup\$ Commented Dec 21, 2011 at 1:14
  • \$\begingroup\$ Thanks @ThePhoton for your answers. I see your point regarding the uncertainity of positive/negative glitches. I believe that initial dev/design cost of CPLD is an order-of-magnitude higher than what I'd that an RC would add, and would need me to step out of my "tinkerer" comfort-zone. I know for sure that a rather inexpensive home-automation controller I have decodes the same RF signal, using a uC (in fact, the same uC i.e. ATmega328), and does a whole lot more, and as far I can tell by studying the PCB they don't use a CPLD (no unmarked/unidentified ICs)... \$\endgroup\$ Commented Dec 21, 2011 at 3:17
  • \$\begingroup\$ ... so I am guessing, there must be something fundamentally wrong in my approach, since decoding the same signal I am trying to do, has been done. Anyhow, I deviated from main point, i.e. is there an easy (& cheap) way to "help" the uC deal with the signal, by letting ISR be less busy, and I see that it'd have to be a software only approach. \$\endgroup\$ Commented Dec 21, 2011 at 3:19
  • \$\begingroup\$ I had a similar problem and I solved it in software only. I can give you a detailed answer, if you can use the USART module of the microcontroller to receive the RF data packets.. \$\endgroup\$ Commented Dec 24, 2011 at 4:27

5 Answers 5

Reset to default
1
\$\begingroup\$

When I have a design problem like this, I first think "how would I decode this by hand" and then I try to implement my thought process through use of electronics.

So, when I look at your two diagrams I see only one thing that my brain can use to determine what is data and what is noise, that is the width of the pulse. The problem with passive components in a situation like this is that for one you have a square wave that will have harmonics much higher then the cut off point for your filter. This will result in a not so square wave.

The easiest way to do this will probably be in software. You can still use interrupts, but it will take a bit more work. Essentially what you will have to interrupt on an edge, and then count time until the next edge. If the length of time is long enough then you can call it a logic 1 otherwise you can consider it noise on top of a logic 0.

If you must go with passive components you might want to consider a low pass filter followed by a comparator. You would have to play with the low pass filter to get it just right, but essentially you would aim to have the capacitor charge just high enough to cause the comparator to switch its output when the bit has been on long enough. What makes this difficult is that your "glitches" are very similar to your data and it is difficult to tune your circuit just right to get your data with no glitches. Even if you are able to perfect it on paper your components wont be very precise either. It is because of this that you should seriously consider doing this digitally.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Thanks @Kellenjb. In fact, I started exploring this "hardware assistance" to my software approach, after trying a pure software-only approach. My approach is exactly how you explain. Have an ISR be triggered on both rising and falling edges, and count elapsed duration. I ignore the parts where duration is less than 300us, yet the noise frequency is so high that my uC is overwhelmed serving the ISR, and the main loop gets very little time to do anything useful with valid data. \$\endgroup\$ Commented Dec 21, 2011 at 3:49
3
\$\begingroup\$

Edit:

A low pass filter will ruin your nice square waves, but if all you want to do is trigger an interrupt, you can give one a try. Based on your new explanation I believe what you want is a low-pass filter where your cut-off is slightly above what is considered a valid bit which is:

1/(100 microseconds) = 10 kHz (valid bit)

I would select something like 12 kHz as your target cut-off and tweak from there. Judging by the values you've chosen in your question, you will not achieve a cutoff frequency of interest. Try the circuit in this example:

enter image description here

You can calculate your cutoff like so:

$$ f_{cutoff} = (\frac{1}{2*pi*RC}) $$

Some ball park values: R=68K and C=220pF will get you a cutoff of roughly 10.6 kHz. This is a pretty poor filter and can be far improved, but give this a try and tell us if it attenuates those 30-40us pulses. If it barely does anything (as I might suspect because this is first-order filter that attenuates 20dB/decade) then ask about second-order filters here. You will get plenty of good answers.

Previous answer:

It seems that your receiver sensitivity is extremely high. Can you share any more details on the transmitter, modulation, encoding, and receiving techniques? You may have to tweak things there first.

This reminds me of a project I was involved in long ago (that also ended up winning an IEEE competition at our school :D) where we created a custom asynchronous protocol which sent pulses over a loosely coupled magnetic circuit which triggered a comparator and generated pulses similar to what you're seeing. Since our baud rate was known on both ends, we ended up implementing a guard time on the receiving microcontroller and the transmission included a checksum as well.

Basically once we detected what we thought was a valid bit, we disabled the ISR for a period (corresponding to the baud rate of our transmission) before re-enabling it and accepting the next bit. If the checksum didn't match we would throw it out and ask for a re-transmit.

We were operating in a very narrow band so we didn't get much noise, and we didn't have to deal with anything nearly as bad as what is depicted in your diagrams - If it had been that bad our technique probably would not have worked at all, or would have taken a very long time to send a valid transmission. I would consider going over your front-end again and seeing if its ideal for what you want to accomplish.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks @Jon for answering and following up. I think I'd need to re-read your original answer couple of times, because I sense something quite interesting in the s/w approach, but mind is too numb to grasp it, after a long night :), in the mean time, let me answer some of your queries about my setup. BTW, is output of the low-pass filter circuit above inverted ? \$\endgroup\$ Commented Dec 21, 2011 at 3:22
  • \$\begingroup\$ Receiver sensitivity is probably very high, thanks to the auto-gain control, but the RF-Rx module is very poorly documented (a cheap east-asian model), so I've no idea how to turn down/off AGC. The module is an ISM band ASK/OOK receiver module, and the proprietary modulation is already explain via an edit in my question. I'll add a page to the little information on this module in my question. \$\endgroup\$ Commented Dec 21, 2011 at 3:39
3
\$\begingroup\$

The basic problem with the simple RC circuit you proposed (your first diagram, or the diagram in Jon L's answer) is that when the signal is chattering, the input to the uC will not be kept strictly high or low, but it will tend to drift toward the average voltage of the receiver output, which will depend on the frequency of the chatter and the width of the glitches. If the average voltage happens to be near the threshold voltage for the uC digital input, the micro will still get meaningless input transitions, but they'll happen slower and may be more difficult to distinguish from your desired signal.

Here's something that might work on the assumption that glitches only happen when the desired signal is low. That is, I'm assuming when the message signal is high, it can really pull the line high, but when its low, that's when the glitches occur.

Modified RC low-pass filter circuit

This circuit will make it so the uC responds quickly to a high-to-low transition, but a low-to-high transition needs to stay high for some time before it will be seen by the uC input. You will probably want to fiddle around with the R & C values in a simulator, using various chatter patterns, to find values that correctly clean up the glitches.

A Schottky diode may be preferable, especially if the uC input has a TTL input (which could have a threshold around 0.8 V)

The drawback of this circuit is it doesn't delay high-to-low and low-to-high transitions equally, so it will end up shortening your high pulses...hopefully you will be able to work around this difficulty in the software that decodes the different pulse patterns you mentioned to detect '1', '0', 'S', and 'F'.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks @ThePhoton. I think this is probably one thing I'd try before switching back to the fast-sampling method that I'd began with as a pure software solution. \$\endgroup\$ Commented Dec 21, 2011 at 12:24
1
\$\begingroup\$

You are not going to pull that off with exclusively passive components... maybe you could put a dedicated microcontroller in there running software that delayed (buffered, absorbed, whatever) your input stream (at a sufficiently high sample rate for the glitch features of interest - i.e. at least half the interval of your shortest "low" period) for 400us to determine if an incoming pulse is sufficiently long to classify as real, and then emitted its own manufactured 400us pulse. This might be considered in violation of your explicit "not in software" requirement, but that's what drove me to suggest a dedicated microcontroller for this purpose.

\$\endgroup\$
4
  • \$\begingroup\$ Thanks @vicatcu. I can see reading all the answers that pulling this off with passive components is quite improbable. Adding another uC, I don't know, because that's pretty much what I am doing right now. An ATmega328 running at 20MHz is not able to keep-up, which is currently pretty-much dedicated to this decode stuff. \$\endgroup\$ Commented Dec 21, 2011 at 3:45
  • \$\begingroup\$ it might be able to keep up if that's all it's doing and you use an interrupt driven code style... \$\endgroup\$ Commented Dec 21, 2011 at 19:06
  • \$\begingroup\$ Well, right now, my approach is interrupt-driven, and at the moment, this is all that it is trying to do. \$\endgroup\$ Commented Dec 24, 2011 at 6:35
  • \$\begingroup\$ @icarus74 perhaps with "bare" ISRs written in assembly then :) \$\endgroup\$ Commented Dec 26, 2011 at 4:45
1
\$\begingroup\$

The schematic with the series resistor, and with a resistor to VSS and a cap to VDD is almost right, except that the cap should go to VSS (R2 most likely should do so as well). I would suggest starting by arbitrarily selecting 1K as a series resistor, and choosing R2 such that then the output from the RF receiver is at half-rail, the input to the processor will be near its switching point. A value of 2.2K for R2 should probably be good if the processor switches at around VDD/3. THe precise value probably won't matter too much. In any case, compute the effective parallel resistance of the two resistors together by taking the reciprocal of each, adding those values, and taking the reciprocal of the result. With the values given, 1/(1/1000 + 1/2200) = 687.5 ohms.

Next, figure out the fastest signal transitions you're interested in. Let's say you're interested in Manchester-encoded data sent at 100,000 bits/second. Since Manchester-coded data requires two signal transitions per bit, the time per transition would be a minimum of 5us. Divide the computed time (e.g. 5 microseconds) by the computed resistance (e.g. 687.5 ohms) to yield an approximate required capacitance value (in this case, roughly 0.0072 microfards). It's probably better for your cap to be a little small than too big; experiment and see what you get.

Addendum

If the sender and receiver will both have crystal-controlled bit rates, I'd suggest putting the signal through an analog filter circuit, and using an ADC to sample the output of the filter at 10Khz. Put the incoming signal into a rolling buffer long enough to handle the whole packet, and also use a 32-bucket accumulator to sum the difference between the present signal and the signal 384 samples ago (so the first difference gets added to bucket #0, the second to bucket #1, the 32nd to bucket #31, the 33rd to bucket #0, etc.). There should be two consecutive buckets with a huge difference between them (the later bucket having a much higher value than the previous). When that difference is spotted, that will indicate that one has found the rising edge of a pulse. At that point, one should be able to sum together groups of four samples from the original signal and recover the signal levels at those points.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks @supercat, but in my case the signal encoding is not quite Manchester. It seems to be loosely similar to Manchester but proprietary, as explained via an edit in my question. Do you think this logic might still work ? \$\endgroup\$ Commented Dec 24, 2011 at 6:34
  • 1
    \$\begingroup\$ My present suggestion is that you use an RC filter to smooth out changes that are faster than your sampling rate; I'd suggest analog sampling at 10KHz, which would be one sample for each 'letter' in your timing diagram. I'll add more about how I'd suggest digital processing for the indicated waveform. \$\endgroup\$ Commented Dec 24, 2011 at 23:12

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.