Using RF Transmitter/Receiver to Power LEDs

I have a pressure sensor that gives off 4 volts when actuated and I would like to transmit it a distance to an LED light. So I found these RF Link Transmitter/Receiver at 434MHz:

https://www.sparkfun.com/products/10534
https://www.sparkfun.com/products/10532

The data sheets and instructions I've read all suggest a microcontroller. What I'm asking is this:

For the transmitter side of my project (sensor that gives off 4V), could I use something other than a microcontroller to convert the 4V to send through the transmitter?

I do have an Arduino Yun that I could use for the receiver side, but lets say I didn't have an Arduino, what would I be able to use to convert the data from the receiver?

I don't have much experience with wireless transmission and any help is greatly appreciated.

Thank you for your attention!

How do you want the LED to respond to the pressure sensor output?

* Illuminated above a certain pressure and extinguished below that pressure? If you don't want the LED to flicker if the pressure lingers at the transition point (or "set-point"), then you'll need to add "hysterisis" to the system.
* Illuminated when a certain pressure is reached and extinguished when some sort of "reset signal" is sent (or when reset that the LED side of the system)? In other words, the LED comes on when a certain pressure is reached or exceeded and stays on until it is turned off by some other means.
* Something else?

For your simple application, you can think of the transmitter and receiver as either end of a piece of wire, but one where the signal only goes one direction.

If you just want to light the LED at a distance, and there are no other tranmitters around on this frequency, you can just use the data input as an on-off switch, and the data out at the receiver as the other end of it, to control the LED. This would be suitable for a demo or science-fair type thing, where the transmitter is not going to be on very long, but not for a permanent installation, since it's bad practice to just leave an unmodulated transmitter on.

The microprocessors in the usual application notes are there to encode various data inputs into a pulse stream of a few hundred to a few thousand bits/sec, which then turns the transmitter on and off at that rate. The receiver just turns those transmitted radio pulses back into a bit stream for another microprocessor to decode. (Simple encoders and decoders can also be done in hardware.) The pulse stream helps make the RF signal more immune from interference, and reduces the power consumption of the transmiter.

Mark: Are you sure the Sparkfun RX/TX modules can modulate/demodulate a DC signal (i.e. a DC input to the TX causes it to output a continuous carrier that the RX converts to a continuous DC change at it's output)?

If not (i.e. if the TX has a capacitor in series with it's input), then it still may send an RF pulse that the RX might convert into a pule on it's output which could be sent to a pulse stretcher or latch to light the LED -- BUT as Mark pointed out, this would not be very reliable and only suitable for something like a science-fair!

Another possibility would be to find a wireless doorbell that you could hack. Or, even, a garage door opener.

Also, consider if the LED is to light only when the pressure is above/below a set-point, you might want to add hysteresis to keep the LED from flickering in the case that the pressure changes slowly and lingers at the set-point.

It's going to be a simple "on/off" system. When an object is on the sensor, the LED will light up on the receiver side and stay on until the object is off of the sensor. Your second bullet is probably what I'm talking about.

And what about reliability and noise immunity? It is going to operate in an environment where there may be a lot of RF interference at that frequency? Also, the FCC specification for that frequency is for infrequent transmissions. Which has two implications:

1. If everyone around you is playing by the rules, then this system can be fairly responsive in a "crowded" environment.
2. Having it transmit for the duration of something being on the sensor, could be a violation of FCC rules. In which case, I suggest a system where the transmitter sends a short "sensor activated code" when an object is placed on the sensor, followed by a short "sensor deactivated code". Such a thing will probably require a couple of microcontrollers, or a hacked two button remote control, such as the Linx OTX-433-HH-KF#-MS keyfob transmitter, along with the "Figure 6: LR Receiver and MS Decoder Schematic", see PDF below:

* https://www.linxtechnologies.com/resources/data-guides/otx-xxx-hh-kf-ms.pdf

Use D1 for the "stuff is on the sensor" signal and D3 as the "stuff removed from the sensor" signal. Then wire the sensor to a couple of "one-shot" flip-flops, one that triggers on a rising edge, and the other that triggers on a falling edge. Wire one of the one-shot outputs to the S4 button and the other to the S2 button. The S4 button toggles the D3 line on the transmitter and the S2 button toggles the D1 line. Then all you will need is an RS flipflop at the receiving end to toggle the LED. Tie the D1 output to the R input and the D3 output to the S input. Then use Q or ~Q as appropriate to light and extinguish the LED (you might also need a driver between the RS FF output and the LED).

Or, you could purchase the parts, separately, that make up the keyfob (the schematic is included in the above document) and build your own.

I love the idea of hacking a wireless doorbell. That is exactly what it sounds like he needs, and it takes care of all the intermediary RF interfacing stuff for him.

My experience with little ASK transmitter/receiver units is at least 10 years old, but the ones I worked with were all DC coupled in and out. Dunno about the Sparkfun units; the data sheet is particularly uninformative.

bq). the data sheet is particularly uninformative

Yeah, good -- I'm not the only one who thinks that ;)

bq). I love the idea of hacking a wireless doorbell. That is exactly what it sounds like he needs, and it takes care of all the intermediary RF interfacing stuff for him.

But, it still might be good to rig it so it sends a short signal with a code of some sort--to comply with FCC regulations, and all -- but Sean's choice -- in other words, having something on the sensor would be like someone leaning on the doorbell button {aka annoying relative or persistent salesperson ;} So, better if the sensor output is sent to a one-shot. Then, maybe to make it simper at the receiver end, have the LED toggle -- one push turns it on, then another push turns it off... Only trouble is, the LED can get out of sync (especially of the sensor output gets "bouncy"--like during the placing of the item and/or removal of the item from the sensor). Perhaps a reset circuit (on the receive end) to turn the LED off if it's been on too long. But, the best case would be one code for weight, and another code for no weight. Or two button pushes for weight and one push for no weight. Or a long push for weight and a short one for no weight...something like that.

Yes, I thought the same exact thing about the data sheet - so UN-informative!

My university has the same exact transmitter/receivers and I just tried Mark's idea of just hooking the sensor (5V) up to the data input and hooked up a multimeter on the data out of the receiver. With 0V, I would get anywhere between 50 mV to 1V. When I inputted 5V, my multimeter would read between 2.5 to 3 volts. But it's very jumpy.

The doorbell idea is great! I might have to do some more research on that one before I jump in but that is a great direction.

That jumpiness of the output of the receiver may be related to the signal strength (though that would be pretty lame for an alleged data receiver). But at least it sounds like it's at least good enough to detect presence or absence of signal, which would be all that would be necessary for the most rudimentary sort of radio link. Of course you might get the same sort of result with a spark gap transmitter and a coherer detector (radio circa 1900-1910)!

Yes, I'm sure the receiver is recognizing the voltage, but now my next dilemma is that I have 4 sensors and I don't think I can use 4 transmitters with 1 receiver. Seems like I would need different frequencies for each spot which would be a pain. That's why I was looking into a microcontroller like an Arduino so I could differentiate each sensor so the receiver can recognize certain sensors.

This is probably a stupid question, but did you connect an antenna to both the transmitter and the receiver? Also, would be good if the antennas matched frequency and output/input impedance

Ah, scope creep. (That is, the scope of the project is increasing from your original post.)

Now you see the need for some kind of encoder and decoder. In the olden days, I'd have used a DTMF (telephone dial) encoder and decoder pair with the radio link , but nowadays it certainly makes more sense to use a micro of some kind. There are plenty of choices in addition to the Arduino -- I've used the BasicStamp series for simple tasks, since I'm an analog guy and can just about handle BASIC programming.

Yeah, the datasheet doesn't even give the threshold voltages for input low/high. What's the noise immunity, etc.

Get a 10$ after Christmas remote a/c controller; wire the push button to an Lm324 op amp and presto cheap RF pressure indicator!
Cheers!