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.

RF Receiver/Transmitter

Status
Not open for further replies.

ibwev

Member
I am using this RF Transmitter/Receiver pair https://media.digikey.com/pdf/Data Sheets/Seeed Technology/113990010_Web.pdf

I am currently trying to troubleshoot and understand the Receiver and Transmitter. I have the receiver connected to 5 volts and the out pin of the receiver connected to an LED. I have the transmitter powered by 9 volts and am using 3 volts on the data pin of the transmitter to send a transmission.

Results:

When the receiver and transmitter are within 5 feet, the LED remains lit when the data pin of the transmitter receives 3 volts. However, when the distance between the receiver and transmitter is greater than 5 feet, the LED blinks about 4 times a second. When I remove the 3 volts from the data pin, the LED strobes too fast to count.

Questions:

1) Why does the LED connected to the out pin of the receiver not remain steady when the receiver and transmitter are well within range of each other and 3 volts is applied to the data pin of the transmitter?

2) Why does the LED strobe when the receiver is not receiving a signal from the transmitter?
 
You have a learning curve ahead of you...

The transmitter has to be pulsed over a narrow range of pulse repetition rates and duty-cycle for the receiver to follow.

The de-modulator inside the receiver is not DC-coupled. The receiver output will randomly pulse on noise when the transmitter is not keyed as the receiver sets its AGC to maximum sensitivity when not receiving any valid signal.

Read :https://www.romanblack.com/RF/cheapRFmodules.htm

Right here: Forum post

To create a steady output that follows the transmit keying, you have to add quite a bit of external electronics.

If you buy the more expensive transmitter/receiver pair that includes the SC2272 encoder/decode chipset, it makes the job much easier.

Another useful forum thread here.
 
Last edited:
Thanks for the help MikeMI. I have learned a lot from your response.

I am trying to connect a variety of sensors, each of which are connected to a separate RF transmitter/receiver pair. All the receivers will be connected to a Raspberry Pi 3.

Sensor->RF Transmitter ----- RF Receiver->RaspberryPi3<-RF Receiver ----------- RF Transmitter<-Sensor

Originally, I thought I could just leave the transmitter in a high state when a sensor detected an issue. The sensors could possibly remain high for days. After reading https://www.romanblack.com/RF/cheapRFmodules.htm , I learned that this may not be legal and after about 50 – 100ms of a high signal the gain on the receiver will be reduced.

One response on https://www.electro-tech-online.com/threads/cheap-ebay-rf-modules-made-easy-and-fast.134224/ mentioned using a random delay between transmissions.

Is it possible to accomplish a random delay between the sensor and RF Transmitter through circuitry or do I need to put a pic between the sensor and transmitter?
 
All 433MHz transmitters nominally transmit on the same channel. The receiver is as broad as barn door, so it will lock on to the strongest transmitter it hears, meaning it will likely be blocked from receiving any additional signals if at least one signal is already present. Worse, if it hears two or more signals simultaneously, then likely nothing can get decoded successfully.

You are essentially building a many-transmitter to a single-receiver system, so the only hope you have is give each transmitter its own time-slice using time-diversity, which means having it make a short-duration transmission at a puesdo-random interval to minimize the likelyhood of a collision with another transmitter. Unless you put a receiver at each sensor, then a given sensor cannot know that its mate is transmitting.

I would use a micro-controller at each transmitter to implement short duration transmission but at slightly different periods. I would modulate each transmitter with a different square-wave frequency, say 1kHz, 1.5kHz, 1.8kHz, 2.1kHz, ... and so on. Then connect a single receiver to the PI and write code to recognize the frequencies.

You could even allocate two tone frequencies to each sensor. That way, you can poll all the sensors to check that the sensors are all healthy (and within radio range) as well as that one or more of them is sending an alarm...

Alternatively, if you use micros that have a UART, hardware or software, have each blurp out one of two unique ASCII chars, repeated say five times each transmission. e.g. for sensor 1, A means sensor 1 is healthy, B means sensor 1 is alarming, sensor 2 use C and D, and so on. Use a slow baud rate, like 110baud per Roman. Repeat each character five times and have the Pi validate by receiving the expected char say three times in a row...

The goal is to maximize the probability that the receiver hears a single sensor at a time, without a collision...
 
Last edited:
Hi MikeMl.
Either Ian Rogers or Nigel Goodwin suggested what sounds like a good approach to this sort of problem using HC-12 modules. The base sends out the address of one of the sensor stations which cause it to respond with a reading. He was using a single ASCII character as an address but a more complex addressing system could be used. I have copied the idea but I use the "#" character before the address character as in my system the sensors send the data back as an ASCII string and other sensors could see their address in the string sent by another sensor. I chose the "#" character as this will never be part of the string sent back by a sensor.

Les.
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top