Help me with a simple alarm with the 2400bps 434MHz RF Link

Wireless & IoT
1

Hello, I just got this rf link (http://www.sparkfun.com/commerce/produc … cts_id=872) and wanted to make a simple alarm trigger with it, pretty much all I need is for the transmitter to send a signal to the receiver to make it turn on a buzzer, I want this to be as simple as possible, if possible, using a 555 timer for the transmitter, any help? All that is gona happen is a button will be pressed on the transmitter side, and on the receiver side would be hopefully a relay or transistor to trigger a buzzer. I thought at first sending just a low voltage signal through the data pins would work, but a sparkfun staff member informed me that it has to have a varing signal in order for the connection to work.

Also I dont want to program a chip to interface with transmission or receiving; unless that is the only way, then I would like suggestions on what to use.

thanks

2

The transmitter uses ASK/OOP, which means the data is sent by turning the transmitter on and off. The digital output of the receiver detects those on/off transitions. You should be able to use a 555 as a one-shot so when the alarm is triggered, it turns on the transmitter for a short period of time – say 500ms or so. On the receiver end, you activate your relay after a signal has been continously present for at least 400ms (using another 555).

The thing to keep in mind is that when there isn’t a signal present, the receiver’s digital output will be noisy, i.e. you’ll get random output from the pin. That is why you need a circuit that requires a signal to be present for a longer period of time before activating your relay.

3

riden:
The transmitter uses ASK/OOP, which means the data is sent by turning the transmitter on and off. The digital output of the receiver detects those on/off transitions. You should be able to use a 555 as a one-shot so when the alarm is triggered, it turns on the transmitter for a short period of time – say 500ms or so. On the receiver end, you activate your relay after a signal has been continously present for at least 400ms (using another 555).

The thing to keep in mind is that when there isn’t a signal present, the receiver’s digital output will be noisy, i.e. you’ll get random output from the pin. That is why you need a circuit that requires a signal to be present for a longer period of time before activating your relay.

I’d take it farther - use an encoder and decoder with the tx/rx pair. you really want to avoid falses. If you don’t want to write code, look into the holtek stuff. I’d consider using the HT-12E and HT-12D 4 bit encoder & decoder. They are pretty cheap and easy to use with that TX/RX pair. I don’t think SFE carries them but renyolds does - http://www.rentron.com/PicBasic/RemoteControl.htm

4

thanks

How would I go about detecting a certain length of transmission on the receiving end? Would it be possible to use a 555 with that too?

5

In days past before I used microprocessors, my controllers would use 555s for hang-time and timeout timers. What you want to create is a type of a debounce circuit using a 555 in monostable mode. [This circuit provides a good start with the following changes:

  1. Connect pin 4 (reset) to pin 2 (trigger). This will cause the timer to reset if the trigger goes high and then low again during the timing cycle. This handles the noise situation common with these types of receivers.

  2. Choose the values of R1 and C1 to give the desired timeout period (say 400ms or so). There are calculators on the net that will help you choose the appropriate values.

  3. Connect pin 3 (output) to one side of your relay making sure you don’t exceed the current capacity of the 555.

  4. Connect the base of a PNP transistor via a 1k resistor to the trigger input (the switch side, not pin 2 of the 555).

  5. The emitter of the PNP transistor goes to +5 volts.

  6. The collector of the PNP transistor goes to the other side of your relay.

  7. Place a damping diode across the relay coil, the cathode to the lead that is connected to the PNP emitter and the anode to the output of the 555 (pin 3).

When the trigger input goes low, the PNP transistor will conduct, however the 555 timing has begun and pin 3 is at 5v. When the 555 times out AND the trigger input is still low, the relay will turn on for as long as the trigger input is low. You will want to probably add some type of latch and reset circuit, but this gives you the basics. If you have a few 555’s laying around, you can easily test this circuit and see if it suitable for your purposes.

For a more robust solution you may want to consider using the Holtek chip set as Philba suggested. They provide the encoding and decoding as well as signaling between different types of activation signals (door open, door closed, panic, etc.)](http://www.mitedu.freeserve.co.uk/Circuits/Switching/debounce.htm)

6

riden:
In days past before I used microprocessors, my controllers would use 555s for hang-time and timeout timers. What you want to create is a type of a debounce circuit using a 555 in monostable mode. [This circuit provides a good start with the following changes:

…[/quote]

Ok thanks a bunch, but what parts are for the reciever and which are for the transmitter, and does the 555 need to be used on both ends?

Sorry I have been really short on time and havent had much of a chance to attempt at building this yet. I would say with the next week or 2 I should get it put on a breadboard](http://www.mitedu.freeserve.co.uk/Circuits/Switching/debounce.htm)

7

I can relate to a lack of time!

The 555 would be used on the receiver side. However, I’d only use a 555 if I needed something right away (for a demo, proof-of-concept, etc.) and the project was something of a throw away. You would be far ahead using the [Linx LICAL encoder/decoder set or something like them. You can’t get much simpler than that, and they were built for that purpose you’re describing. Take a look at the [LICAL manual to see what I mean.](http://www.linxtechnologies.com/documents/LS_Manual.pdf)](Reviews of Software & Service Providers | SERP)

8

ok, thanks a bunch, I will buy those encoder/decoders, and post how it all goes :slight_smile:

9

is using PICBasic an option for you? maybe a mate of yours has a programmer you could use, if so check out how to interface with them here;

http://users.tpg.com.au/gramo/rf_modules.htm

10

Well there a bunch of ways to do this but your best way is to use a micro and send X amount of pulses with X amount of lengths and then the receivers micro analyzes these and perform its task according to the command. However you must be very careful as you can only use that band for commands and cannot use it for telemetry(Data) also your duty cycle must be less than 2% if I remember correctly. If you dont abide by those rules you are breaking FCC regulations which may or may not matter depending on your take on the situation. However if I were nearby I wouldnt be happy as it could possibly interfere with something I may be working on or your can interefere with an old garage door opener.

11

Based on the advice in this thread, I bought the Linx encoder and decoder and coupled them with the 434 http://www.sparkfun.com/commerce/produc … cts_id=872.

My results still weren’t what I was expecting. On the transmit side, I have a photointerrupter (the exact product: http://www.sparkfun.com/commerce/produc … cts_id=203) whose signal is fed into the encoder. The encoders data out is fed into the transmitter’s data in. I also have an LED on the signal of the photo-interrupter so I can see the source signal.

On the receive side, it’s pretty much the opposite of the transmit side. The receiver’s digital data out is fed into the decoder and the decoder’s data out is fed to an LED.

So, pretty simple, wireless switch type setup. The results were this:

When the photointerrupter fires (goes high), the transmit LED lights continuously while the obstruction is interrupting the switch. On the receive side, I get one fairly quick (<500ms) flash of the LED indicating the transition.

However, if you read the Linx encoder and decoder specs, their flow chart clearly shows that it will continue to send packets as long as a data pin is high. Theoretically, the encoder’s encoding in such a way that the transmitter should still be sending something. As it is, I only get a quick blip on the receiver side.

In the application I have I really want to be able to have the receiver be an exact mirror of the state of the photo-interrupter, so if it’s interrupted and high, then the receiver side should be shining solid as well, but it’s not.

I’m missing something. Either the encoder is not doing what it says it should be doing (I need to probe the output side of that to be sure, but the input side is definitely staying high), or the 434 RF signal is being clipped or cutoff after a short burst.

Can anyone identify what the issue is? I’ve tried to follow the various pieces of advice I’ve seen around this topic and thought for sure the Linx encoder/decoder would do the trick - certainly from the data sheet it sounded like it would.

12

These devices were built for doing what you want to do. However, I have a two questions to ask. Which Linx devices did you get, the LiCal or CIP ones? Where is your RX LED connected (output of receiver or one of the data out pins?

13

Thanks for your response. The answers to your questions are:

I have the Linx LS001 8 pin encoder (LICAL-ENC and LICAL-DEC) from Reynolds.

On the TX side, the opto-interrupter signal goes into D0 of the encoder. The TX LED lives on the D0 side of the encoder (vs the D-out)… I wanted to see exactly the source signal.

On the RX side, the LED is attached to the decoder D0->current limiting resistor->ground.

Any ideas to pursue are appreciated.

14

Look at how you have your TX LED wired to DO. If you have the TX LED anode connected directly to D0 and the cathode to ground, you won’t get a logic 1 level on D0. Even if you have a separate limiting resistor for the TX LED, the level on D0 may be too low. Disconnect the TX LED and see if that fixes the issue.

If disconnecting the TX LED from D0 doesn’t help, confirm that the transmitter is transmitting continously by connecting the TX LED (with limiting resistor) to DATA_OUT. If it transmits whenever the beam is interrupted, then look at the receive side. Make sure you are using the digital output from the receiver (pin 2) and not the analog (pin 3).

Let us know how it goes.

15

Look at how you have your TX LED wired to DO. If you have the TX LED anode connected directly to D0 and the cathode to ground, you won’t get a logic 1 level on D0. Even if you have a separate limiting resistor for the TX LED, the level on D0 may be too low. Disconnect the TX LED and see if that fixes the issue.

I misspoke - this was actually my configuration (LED on the data out side of the encoder going to the transmitter.) The only thing going into D0 is the signal from the photo-interrupter. The LED was on the DataOut side of the encoder. That said, having it connected or disconnected on the DataOut side hasn't changed the behavior, not surprisingly.

If disconnecting the TX LED from D0 doesn’t help, confirm that the transmitter is transmitting continously by connecting the TX LED (with limiting resistor) to DATA_OUT. If it transmits whenever the beam is interrupted, then look at the receive side. Make sure you are using the digital output from the receiver (pin 2) and not the analog (pin 3).

According to the TX LED, it looks like it's continuously transmitting. It looks like it's solidly lit - no perceptible flicker - when I obstruct the photo-interrupter switch. The blip on the receiver side is definitely correlated with the transition of the switch to high, but the RX LED goes out very quickly after that.

On the RX side, I also double checked and I’m definitely coming out of the digital data port of the receiver directly into the DataIn port of the decoder. I have the decoder D0 pin->LED->current limiting resistor->ground. (For what it’s worth I’ve tried both the analog and digital receive ports and the behavior is the same in this case.)

If it would help you I can get some images of it so you can see the setup.

16

Here are some close-up shots of the circuits:

Transmitter with opto-interrupter switch:

http://flash.360vl.com/~lcox/breadboard/transmitter.jpg

Receiver:

http://flash.360vl.com/~lcox/breadboard/receiver.jpg

I think these are macro enough to see labels and connections pretty well.

17

Thanks for posting the photos, it helped me understand your configuration.

From what I can see, everything looks in order. The fact that the RX LED lights for a brief time indicates to me that the receiver successfully decoded a packet, but no other valid packets were received. There is a 130ms timeout on the receiver that will place all the data lines to logic 0 in the absence of valid packets.

Here is what I would do if I were troubleshooting this on the bench:

  1. Take the opto-isolator out of the picture. Connect a 100k-200k resistor from the TX’s D0 line to GND. Then pull up DO by connecting it to +5V and observe the RX LED. If that takes care of the problem, reconnect the opto-isolator leaving the pull-down resistor in place.

  2. Take the RF link out of the picture. Connect DATA_OUT to DATA_IN and see if the problem goes away.

Another thing to check is to confirm that an LED connected to D1, D2, or D3 DOES NOT light when D0 is high and D1…D3 are low. The LED shouldn’t light, but if any of the other ports light when D0 is activated, it may be indicative of a problem in the chipset (unlikely, but worth checking if everything else was checked).

18

Here is what I would do if I were troubleshooting this on the bench:

  1. Take the RF link out of the picture. Connect DATA_OUT to DATA_IN and see if the problem goes away.

I did a direct connect and it behaves exactly as I would expect - a solid obstruction in the photo interrupter results in a solid lit LED out of the decoder.

I’ll check the other suggestions as well to see if I can narrow this down further.

Thanks,

Landon

19

landon:
I did a direct connect and it behaves exactly as I would expect - a solid obstruction in the photo interrupter results in a solid lit LED out of the decoder.

That seems to point to a problem in the RF link. I can’t tell if you are using one or two protoboards, but connect about a 6" length of wire to pin 4 (ant) of the transmit module and see if that helps. The transmitter isn’t being loaded now, and that could be a problem.

To test the RF link, unhook the DATA_OUT line from the transmitter and connect a wire from the tx data pin of the transmit module. If you have a multimeter (a LED/resistor could be substituted), measure the output of the receiver as you connect the tx data line to +5 volts and then to GND. You should see a very definate and constant transition on the data line. If you connect the data pin to 5v and the output of the receiver is NOT constant, that will be a problem. Only bring the tx data line to +5 for a second or so, as you don’t want to transmit continously.

20

I bought the 434 antennas from Reynolds http://www.rentron.com/Linx/RA-Antenna.htm and put one of them on the TX side instead of the 6" wire. Assuming the transmitter wasn’t loaded at all, this should load it.

I also got identical behavior as before. Solid LED on the TX side and quick blip on the RX side.

I’ll pursue your other suggestions and report my findings.