I would like a “wireless call light” a device comprised of two parts a 9V “battery cap” with a LED, on/off switch and a single channel rf receiver and a wireless transmitter. When you push the button on the transmitter the LED flashes until the batter cap switch or the wireless transmitter off switch is actuated. Why a 9V battery? Because it could stand up on a desk without an enclosure. Ideas?
What exactly are you stuggling on there? Its not hard to actuate a switch or turn an LED on off. Presumably the wireless?
I’ve used Xbees to start with for their simplicity, but they are not as cheap as other options and no were near as good on power. From there I’m about to experiment with the nRF24L01+ modules which look very promising.
You can get a pre-made and functional nordic key fob with built in transmitter and battery life of years, for about $20 from SF shop which will completely take care of the transmittion side of things. Then you just need a receiver module, and connect it up to a uC to do a bit of work.
You could also use one of the Holtek encoder/decoder pairs or ones from Rentron along with a RF tx/rx transmitter pair from SparkFun:
May be a daft question buts whats the use in the decoder/encoder in general? The way I see it is you set a line high, and it will set the other line high. How is this different from hard wiring the line, and when you add wireless and have to send the data to a line in the first place, why not connect the switch line directly to the wireless, and the control line directly to the wireless on the other end, would that no act in exactly the same way? Or does the encoder/decoder turn high/low presses into RS232 data or something like that so it can be translated?
It would seem reasonable that you could simply key the transmitter and see the signal appear on the other end. However, encoders/decoders or micro-controllers are needed for three reasons:
-
These low cost ASK/OOP receivers operate in license-free bands that are shared between lots of devices. The receiver won’t know if the signal came from your transmitter or the next door neighbor’s doorbell or wireless thermometer.
-
Because of the interference potential from other devices, some type of retry logic or redundant transmission of data is necessary.
-
Most of these receivers have built in AGC (automatic gain control) and work best if the incoming data is equally balanced between 1’s and 0’s. That is why you see discussions of using Manchester Encoding or sending a data byte and then its complement.
And using encoders/decoders allow sending more than simple one-channel on/off information.
Ralph,
Interesting… I have a project I am going to start on next when I get some time free that uses the Nordic Keyfob from SF, and I need to make a receiver. Does this mean the keyfob is going to have the same problem and my receiver will not know if the message has come from the keyfob or not? I still dont know what type of message the keyfob sends as havent had time to look, but am guessing it isnt encoded.
I haven’t used the Nordic devices, but they far more advanced than the simple ASK/OOP modules that I was describing. They seem closer to XBee modules in that there is an established protocol that sorts those types of issues out. There have been a lot of discussions on the forum on the use of the nRF24L01 devices, and I’m sure someone more knowledgeable than I in this area can chime in.
Edit:I forgot to mention that the SparkFun site has some example code for the keyfob and keyfob receiver in C, so you can see exactly what is sent.