Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Low-Power decoder

Status
Not open for further replies.

MikeMl

Well-Known Member
Most Helpful Member
I'm sending a signal from a 433Mhz transmitter to a receiver. I want to validate that the receiver is in-fact receiving the signal from my transmitter, rather than just "noise", or other non-related signals that may happen on that channel frequency.

The easiest way of modulating my transmitter is On-Off-Keying (OOK), with a 50-50% duty cycle. In fact, the receiver expects OOK; it uses an AC-coupled detector, so that a steady-carrier would not be detected properly. The keying rate can be between 2Hz and 3kHz.

If the receiver sees just noise (no signal), the receiver output randomly pulses between a logic high and a logic low, where the period between up-edges is quite random. I plan to do a histogram of noise-induced periods, and I will choose a OOK rate which is away from the peak. ;)

If the receiver sees my OOKed signal, the period between up-edges is determined by the OOK keying signal period.

I would like to implement a software "tone-decoder", which effectively validates the receiver output based on getting n-successive periods of the expected duration, sort of like an old NE567 PLL tone-decoder. n should be settable to something like 10 to 50 periods. It can take a second or so to validate the signal...

I plan to use a low-power processor (simple PIC?) to watch the period between up-edges. For further power saving, I would like to use some sort of period measurement based on a free-running (but slow, like 32kHz) crystal clock, where clock cycles are counted in a timer-counter, and where the processor only wakes-up (comes out of sleep) briefly during each up-edge of the receiver detector output.

I can rely on the stability of a similar 32kHz clock at the transmitter, so I might not actually have to implement a PLL; just rely on the two oscillators being close enough.

Anybody done anything like this before? Any previous threads?
 
Last edited:

MikeMl

Well-Known Member
Most Helpful Member
Just detect one bit of data: is the signal there or not! :D but at extremely low power consumption (total current <5uA), and with high SNR (i.e. low bandwidth or baud rate)

Where in your tutorials do I look?
 
Last edited:

MikeMl

Well-Known Member
Most Helpful Member
Ok, I found how to do it: which can easily be coded into a PIC.
 

MikeMl

Well-Known Member
Most Helpful Member
The 433 TX module is FM or AM? If it is FM, you should not be so worried about the SNR.

AM. The receiver outputs random logic transitions on noise. If receiving a barely-detectable OOKed signal, I am trying to detect the OOKing rate to determine that the receiver is in fact receiving a signal from MY transmitter, vs just noise, or an unrelated signal which shares this channel.

The problem would be no different if FM was being used instead of AM. It takes a slightly better SNR to detect a weak, noisy FM signal compared to an AM signal. It still leaves the problem of detecting the presense of MY tone vs someone else's unrelated transmission.
 
Last edited:

Mr RB

Well-Known Member
Ok, I found how to do it: which can easily be coded into a PIC.

Huh? What does DTMF have to do with your question of detecting a constant transmission from the RF module?

If you are just after range tests or similar I would pulse the transmitter at a low continuous audio frequency like 500Hz (or even 500Hz in bursts) and connect the receiver module to a button type headphones (ie ipod type) through a 560 ohm resistor. The logic level digital output of the receiver will drive that fine. Then you just listen to it, your ear will probably pick up a lot of problems like glitches, hf noise, dropped pulses etc that might not be easily apparent with a PIC doing the testing.
 

MikeMl

Well-Known Member
Most Helpful Member
Huh? What does DTMF have to do with your question of detecting a constant transmission from the RF module?...

The algorithm supports detecting a single tone as well as two tones simultaneously.

re the headphones, audible detection is not what I am after. I am trying to implement a very-low power (few uA) single tone decoder using a PIC. It will have a single logical output: Tone Detected, Tone not detected.
 
Last edited:

Hayato

Member
Well, you are going to transmit a tone train.

What about letting your RX knowing when you are going to TX?

For example, before start a data TX, send a 1 kHz - 4kHz - 1 kHz - 1 kHz - 4 kHz - 4 kHz tones pulses sequence.
 

Mr RB

Well-Known Member
The algorithm supports detecting a single tone as well as two tones simultaneously.

re the headphones, audible detection is not what I am after. I am trying to implement a very-low power (few uA) single tone decoder using a PIC. It will have a single logical output: Tone Detected, Tone not detected.

Ahh I see.

You could run the receiver output through a high Q tuned filter (reosnant) and heaps of attenuation, then in software just get the PIC to average any "good" periods (ie periods within +/- 10% of X), then if enough good periods are detected within a second you have proof of tone.

That will be easy in hardware, easy in software, and quite tolerant of noise and glitches.
 

MikeMl

Well-Known Member
Most Helpful Member
...

You could run the receiver output through a high Q tuned filter (reosnant) and heaps of attenuation, then in software just get the PIC to average any "good" periods (ie periods within +/- 10% of X), then if enough good periods are detected within a second you have proof of tone.

That will be easy in hardware, easy in software, and quite tolerant of noise and glitches.

I thought of using a CMOS op amp as a bandpass filter, but when I ran the numbers, at around 1KHz, the opamp power is much higher than waking up a PIC or MSP430 or C8051F930 to execute a few instructions every 250us. The quadrature nature of the algorithm requires sampling the incoming modulation four times per cycle. Remember, I'm trying to do this with an average power input of <5uA at ~2V.
 

Mr RB

Well-Known Member
Sorry I missed the <5uA post. After re-reading the thread it looks like it's not going to be easy.

It still leans toward a solution of a tuned passive LC (low power) then the PIC counting a few "good" periods until you get proof of tone.

You could decrease power consumption by only testing every 500mS, or maybe test every 250mS but if there is no sign of tone end the test quicker to save power. That depends on whether you prefer a false negative or false positive in tone detection. I assume the tone event will be infrequent so that system would save power over a fixed length test.
 

kchriste

New Member
Forum Supporter
Does your Rx module have RSSI squelch? If so, detection of RF is simple. You'd still have to test for a valid signal if another TX came up on the same frequency. What is the current draw of the RX module? Usually it is the RX which is powered on briefly every 200-500ms by the MCU to check for a signal.
 
Last edited:

MikeMl

Well-Known Member
Most Helpful Member
The Rx has an RSSI output, but not a squelch. My impression is that the RSSI out would not be a very reliable way of knowing that a signal is present. An increase in noise would produce the same slight increase in RSSI reading as a weak signal.

The RX will operate on 70uA at ~2V. A further power saving will result in not having it on all the time. The same processor as times the RX sampling will be doing the tone detection.

I have simulated the tone detection, and it works very well. The only issue is that the algorithm decodes all odd multiples of the fundamental frequency, i.e. 3X, 5X, ... , so an analog low-pass filter ahead of the one-bit quantization will be required...
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Top