I have a 433MHz receiver whose demodulated output is connected to a micro c ontroller input. The bit width is 1ms. ZERO is 375us low and 625us high and ONE is 625us low and 325us high. When the transmitter is little far away there are spikes with duration of less than 50us and the micro is not able to properly interpret the data. Though these can be easily filtered out in the micro but due to other priority tasks micro is doing I am looking at ha rdware solution. Will a simple RC filter at the input of micro do this? One problem I see is the edges may get softned. Any other potential problems? or any better hardware solutions?
controller input. The bit width is 1ms. ZERO is 375us low and 625us high a nd ONE is 625us low and 325us high. When the transmitter is little far awa y there are spikes with duration of less than 50us and the micro is not abl e to properly interpret the data. Though these can be easily filtered out i n the micro but due to other priority tasks micro is doing I am looking at hardware solution. Will a simple RC filter at the input of micro do this? O ne problem I see is the edges may get softned. Any other potential problems ? or any better hardware solutions?
Well just the impedance of the RC, so try and build an RC low pass with RC~10 us or so. (maybe 10k ohm and 1nF?) and see what it looks like.
It would be interesting to know where the "spikes" are coming from. There's an awful lot of junk at 433.925 MHz coming from home weather stations, remote controls, garage door openers, electronic keys, data radios, door bells, robotics, burglar alarms, etc. I've put a scanner on that frequency and heard quite a bit of digital junk in metro areas. It might be that your receiver is hearing some local interference source in it's present location, and will hear other sources if it were moved to a different location. It might also be that the 50usec spikes are coming from your own equipment, in which case some bypassing might make it disappear. While filtering will help, eliminating the interference at the source is probably more effective.
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
You'd do better with a higher order filter, a 2 to maybe 4 pole Bessel lowpass. I'd go for maybe 100 us rise/fall time, which would be about 3.5 KHz. A simple RC will have long step tails, which causes ISI (intersymbol interferance) and sloppy edges.
An active filter would be fine in this speed range, with one or two opamp sections. There are online calculators, like FilterPro, that will design it.
--
John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com
Precision electronic instrumentation
Assuming it is a simple AM or, worse, on-off protocol I suggest to look into FSK modes. Those are more resistent to interference.
If you must filter then the LC method John suggested is usually best. But in that case make sure that your uC either has Schmitt inputs with hysteresis or place a Schmitt buffer/inverter between RX out and uC. A uC without Schmitt input typically does not like signals with transitions slower that 100nsec or so on its port pins.
Several of my favorite ways to use slew-rate control to "de-spike" noisy signals...
I've even used this in an automotive environment to get rid of ignition "sparking" noise on an inductive pick-up. ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| San Tan Valley, AZ 85142 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
I suggest that you rethink your idea of filtering the data outside of the MCU. If the MCU has a hardware timer you can set an interrupt on the edges of the input and read the timer to measure the time interval. Some timers even have a "capture" mode to do this automatically. It would be a very simple piece of code to use these measurements to distinguish "real" data pulses from the noise that you describe.
How does the MCU currently measure the pulse widths to distinguish data ones from zeros? The filter would just be an extension of that to also distinguish data from noise. :)
btw, are your given timing values correct? The full bit time is not equal between the data one and the data zero for the timing values you give.
Of course if you are seeing noise of a much shorter period then setting an interrupt from the input could cause a problem. A simple RC filter can be used to exclude very short noise pulses. If you add any sort of filter to this input that significantly slows the edge rate, you should condition it with a Schmitt trigger. MCUs and other digital inputs don't behave well when given an analog signal. Sometimes the MCU inputs already have a Schmitt trigger.
--
Interesting problem.
1. You say the symbol time is one millisecond for both ONE and ZERO,
instead in order to yield the same symbol time for both ZERO and
ONE?
2. What are the jitter tolerances on the demodulated edges?
3. What is the absolute maximum width and the absolute maximum
number of spikes which can occur during one symbol time?
John Fields
micro controller input. The bit width is 1ms. ZERO is 375us low and
625us high and ONE is 625us low and 325us high. When the transmitter is little far away there are spikes with duration of less than 50us and the micro is not able to properly interpret the data. Though these can be easily filtered out in the micro but due to other priority tasks micro is doing I am looking at hardware solution. Will a simple RC filter at the input of micro do this? One problem I see is the edges may get softned. Any other potential problems? or any better hardware solutions?
Have you got a spare UART on your microcontroller? If so, invert your receiver output and feed it to the UART input, tell the UART it you have an 9600baud async signal 8 data, no parity, one stop bit then use a lookup table to convert bytes into bits,
You know, that is the best idea yet. The way you describe the UART will be sampling the input at about 10x the bit rate to give a fair amount of redundancy in measurement. But if there is noise pulses wide enough to trigger a false start bit, which would be just about the 50 us the OP is seeing in the noise, it could cause a false timing to the start. But the devil is in the details. It certainly is worth a try and a deeper analysis. Good job!
If you can turn the bits-per character in the UART down to 1 that would help, but I don't think I've seen any that go that low, but yeah lower is better.
If you are designing a production to be sold in Europe, the 433.920 MHz ISM band is in the middle of the 70 cm amateur radio band with at least 100 W transmitter power authorized. Thus your device might be disabled as long as that amateur radio transmission occurs.
Even if that strong transmission does not directly hit 433.920 MHz, the selectivity of these wireless devices is typically so bad that a strong signal disables the receiver, even if there is a strong signal is more than 1 MHz away. It is interesting to look at some car owner frantically trying to open their car door with a wireless key :-)
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| San Tan Valley, AZ 85142 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
I don't follow. Running the UART bit rate at 10x the rate of the data you get a very nice oversampling with sufficient resolution to be able to average out the noise. As you say, use a lookup table to separate the noise from the signal. I expect that would work *very* well. 1 start bit, 8 data bits and 1 stop bit will give you 10 measurement points. Nothing is captured until the input goes low, so the start bit is assumed. The stop bit will give you a framing error if wrong so a bit can be added.
With 8 bits your character time is just over 1 ms, so maybe 7 data bits is better, the the framing error flag can be added to form 8 bits total for the lookup table. Then the UART will always be listening for the next start bit. Most UARTs start looking after the middle of the stop bit so even with 8 data bits the next start bit should be detected, but any noise at the wrong time can impact this and cause the loss of a bit.
If the MCU has a built in UART, which nearly all do, I can't see how a noise filter would provide much help and requires extra circuitry.
Yup. It boils down to "wait until true for >50us before declaring it true" ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| San Tan Valley, AZ 85142 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
I call it a slew-rate filter, either with current mirrors or an R/C you control how fast a signal can change from "0" to "1", apply that to a device with lots of hysteresis and it ignores "slivers".
The third example would be easy to try in LTspice... play with it. ...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| San Tan Valley, AZ 85142 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
The US 70 cm ham band goes from 420 to 450 MHz. The ARRL band plan has 433 MHz as auxiliary repeater links: Locally, much of this band plan is ignored. To the best of my knowledge, most hams are smart enough to ignore this frequency area.
Listening on my scanner on 433.925 MHz in the forest, I don't hear much in the way of potential interference. Right now, just an occasional burst of noise from one of a dozen wireless weather station sensors in the neighborhood. The frequency is much more active in denser metro areas.
The lack of receiver sensitivity makes up nicely for their lack of selectivity. It's difficult to interfere with a communications system that uses a deaf receiver.
Automotive key fobs in the US are on 315 MHz for American made automobiles, and 433.925 MHz for European and Japanese automobiles.
Anyway, I'm suspicious. It takes some effort to consistently interfere with a fairly deaf receiver on 433.925 MHz. My guess(tm), based on doing battle with a similar remote control used to run a backyard water fountain and lights, is that most of the interference is probably locally generated. For example, this [deleted expletive] fountain remote control refused to turn OFF the lights because the RFI/EMI from the CFL and LED lighting produced enough junk to confuse the decoder. Turning ON worked normally because the lights were not generating RFI/EMI when not powered. (My fix was some ferrite beads and selecting LED other lights that didn't generate RFI/EMI).
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
In Europe ITU-R region 1 (Europe and Africa) the 70 cm amateur band is at 430-440 MHz and in some countries even only 432-428 MHz. In the latter case the repeater duplex interval is only 1.6 MHz and thus repeater input frequemcy (and thus handset output frequency) is in the range 433-434 MHz.
The situation is different in Europe and in the USA,
And that is the real problem.
As I said, the situation might be quite different in Europe than in the USA.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.