Cheap on-off remote

[Conrad_Turbo]

I am thinking along the lines of a wireless doorbell, however is there a product out there that has a simple raw boards? One for the switch input/transmitter and the other being the reciever with a switched output. I don't want all the excess doorbell chime mechanism or circuitry, just a very basic setup. Also the switch transmission frequencey can be selectable (like a garage door opener).

Reason why I want to avoid the excess mechanism/circuitry is because I will be wiring multiple switches (which are really tied to sensors) which will send the info to the receivers and give an output of the status of the sensors.

Anything like this commercially available for a good price? Probably only need 75-100ft range at the absolute max.

 

[pc88]

Check out this page:

https://jap.hu/electronic/codec.html

Near the bottom there is a list of links to radio module manufacturers.
If this is what you're looking for, then you might also check out some
of these ebay stores:

https://stores.ebay.com/e-MadeinCHN
https://stores.ebay.com/Ananiah-Electronics

 

[Conrad_Turbo]

Thanks for the links. A lot of them are 1 remote to multiple receivers as compared to what I want, multiple remotes (transmitters) and only 1 receiver.

But if I did go with this (since I will need each transmitter on their own code):

**broken link removed**

or possibly this:
**broken link removed**

Now if I used a receiver like this:
**broken link removed**

How would it know which transmitter is sending the signal? Or which data pin on that transmitter? That is what stumps me. I have a hard time visualizing how it can decipher which signal is which and how it ouput the difference. That way I can use my microcontroller to read that and then with the coding, control an output based on the all the inputted info.

 

[pc88]

How would it know which transmitter is sending the signal? Or which data pin on that transmitter? That is what stumps me. I have a hard time visualizing how it can decipher which signal is which and how it ouput the difference. That way I can use my microcontroller to read that and then with the coding, control an output based on the all the inputted info.

Generally a matching pair of encoder/decoder ICs are used. Each transmitter is configured to have a unique address, and when the transmitter sends its data (usually just a single byte), the address is sent with it so that the receiver knows which transmitter sent it. For instance, this is how these chips work:

**broken link removed**

Before buying anything, I would first ask for a datasheet. That will probably clarify a lot of things.

 

[Conrad_Turbo]

After reviewing the site this is what I found "best":

TX: KH Series - TXE-433-KH = $7.80/ea
https://www.electro-tech-online.com/custompdfs/2007/07/TXE-xxx-KH2_Data_Guide.pdf

**broken link removed**
Screen shot taken from the .pdf

RX: KH2 Series - RXD-433-KH2 = $11.95/ea
https://www.electro-tech-online.com/custompdfs/2007/07/RXD-xxx-KH2_Data_Guide.pdf

**broken link removed**
Screen shot taken from the .pdf

So with the transmitter I can tie in all my switch inputs and select the channel I want to be on with the DIP switch. Then the receiver I can put it on the same channel and read the D0-D7 outputs with my micro-controller. The one other thing I am wondering for further expansion is if I had a sensor tied to 555 timer, so say the temperature is rising the freq output of the 555 rises. Could I tie that cycling output to a pin on the transmitter and the signal would be replicated on the receiver for the microcontroller to decode?

Let me know if my logic is correct or way out in left field. I appreciate it!

Edit: The only "bad" thing about the TX/RX setup is that it's SMD type...makes it hard for a small scale project since it isn't easily solderable.

 

[pc88]

Yes you can - you can have the TE triggered by the 555. However, consider the following:

- when the TE line goes high, the transmitter sends the data packet three times.

- you might miss transmissions (that's why it's sent three times)

- you want to make sure the frequency that your 555 is generating isn't faster than the transmission speed (or really transmit speed / 3)

- you have to be careful about continuously sending data. I believe these devices operate (in the US) under a provision of the FCC regulations which allow for low-power and intermittent transmission, and you are responsible for correcting any interference. Regulations in other countries may be different.

re the SMD packaging: have a look at this RX/TX pair from Spark Fun:

**broken link removed**

And here's a uController project that uses modules like that:

**broken link removed**

 

[pc88]

One more thing about I noticed about the receiver ... I think the address lines are inputs to the chip. That would mean it only responds to data from the configured address. If you were thinking of setting different transmitters to different addresses, then you'll have to tap into the raw data signal and perform packet decoding yourself.

 

[Conrad_Turbo]

One more thing about I noticed about the receiver ... I think the address lines are inputs to the chip. That would mean it only responds to data from the configured address. If you were thinking of setting different transmitters to different addresses, then you'll have to tap into the raw data signal and perform packet decoding yourself.

What I figured is that I could have is at most 8 transmitters, all of which would use a separate input (Dx) pin and have set on the same channel. Or I could bank "zones" on each pin so when the info is sent to the receiver it will know which zone has been tripped. This is a yard monitoring system I plan on building which is why it has to be wireless.

Then I could keep the receiver on the same channel and tie each pin into the microcontroller and the coding for it would determine what the output would be.

I wasn't aware that it sends a signal 3 times...interesting, I could definatley ensure that the 555 frequency is less than transmit speed/3, thanks for the heads up.

Thanks for the links, so with something like that I'd need 1 transmitter per sensor (of course) and need 1 receiver per used transmitter? For example if I have 5 sensors around the yard, I will need to order 5 pairs correct? Then I will have 5 receivers connected to the microcontroller? I would also have to specify that I need 5 different frequency pairs?

I could see a RX/TX setup like that being ideal for wireless programming of the microcontroller, or pulling information off it wirelessly.

Edit: The more I look into this the more I am picking up. If I were to use a basic TX/RX pair I would need a set of encoder/decoder on either end of the RX/TX pair. Similar to this?

**broken link removed**

The Linx Technology unit seems to be a basic RX/TX setup with the encoder/decoder built in. I wish they made the KH/KH2 series in a SIP package.

 

[pc88]

Thanks for the links, so with something like that I'd need 1 transmitter per sensor (of course) and need 1 receiver per used transmitter? For example if I have 5 sensors around the yard, I will need to order 5 pairs correct? Then I will have 5 receivers connected to the microcontroller? I would also have to specify that I need 5 different frequency pairs?

I could see a RX/TX setup like that being ideal for wireless programming of the microcontroller, or pulling information off it wirelessly.

With something like the Spark Fun devices you can get away with using only one receiver and N transmitters like this: set each transmitter to a different address; on the receiver, tap into the digital output (pin 2 on the RLP434) and do your own decoding of the signal with a microcontroller:

https://www.electro-tech-online.com/custompdfs/2007/07/TLPRLPA.pdf

It's more work, but I'm sure it's been done before, and I'm sure the Holtek encoder protocol is well-known.

Then you can monitor traffic from all the transmitters. They would all be transmitting on the same frequency, but this shouldn't be a problem if the transmissions are short.

I don't think having your sensors send data as a pulse frequency is going to work all that well. A better idea would be to have your 555 increment a counter which is tied to the transmitter data lines. Periodically trigger a transmission and then clear the counter.

 

[Conrad_Turbo]

With something like the Spark Fun devices you can get away with using only one receiver and N transmitters like this: set each transmitter to a different address; on the receiver, tap into the digital output (pin 2 on the RLP434) and do your own decoding of the signal with a microcontroller:

https://www.electro-tech-online.com/custompdfs/2007/07/TLPRLPA-1.pdf

It's more work, but I'm sure it's been done before, and I'm sure the Holtek encoder protocol is well-known.

Then you can monitor traffic from all the transmitters. They would all be transmitting on the same frequency, but this shouldn't be a problem if the transmissions are short.

I don't think having your sensors send data as a pulse frequency is going to work all that well. A better idea would be to have your 555 increment a counter which is tied to the transmitter data lines. Periodically trigger a transmission and then clear the counter.

I understand what you mean. I'd rather have the decoding done by a chip and then have that fed into the microcontroller (for simplicity sake at the expense of using extra input pins on the microcontroller).

So this is what I am looking at then:

RF Link - 4800bps - 315mhz - $16.95 (figured the extra $2 for double the transmit speed might help with future projects)

HT12D - 8 bit decoder - $1.50
**broken link removed**

HT12E - 12 bit encoder - $1.50
**broken link removed**

So in total I'm looking at a total point A-B wireless cost of $19.95. However if I want to buy another transmitter how would that work since Sparkfun sells them as tuned pairs? Then with every additional transmitter I'd have to use the HT12E unit.

Looking correct?

 

[Nigel Goodwin]

So in total I'm looking at a total point A-B wireless cost of $19.95. However if I want to buy another transmitter how would that work since Sparkfun sells them as tuned pairs? Then with every additional transmitter I'd have to use the HT12E unit.

If you're using a micro-controller why use the Holtek chips?, just use your existing micro-controller to do the same job - the Holtek devices are simply pre-programmed micro-controllers.

 

[Conrad_Turbo]

The more I look at the Linx KH2 the better they keep looking...considering it has an output distance of up to 3,000ft and only costs $25. I wish they made them in a through hole variant.

If you're using a micro-controller why use the Holtek chips?, just use your existing micro-controller to do the same job - the Holtek devices are simply pre-programmed micro-controllers.

To be 100% honest I am involved more with mechanical engineering than electronics engineering, and I am not familiar with how to write code to decode the transmission... I'm using a BasicX-24 for this project. If you have any tips or links that may be of help I am all ears! Writing the code would save me $1.50 and a lot of input pins on the microcontroller, however I would still need the HT12E correct?

 

[pc88]

You'll need some sort of data encoder on the transmit side - either a HT12E or microcontroller will work.

We've discussed a lot of ideas in this thread, and my overall advice would be that you go down a path that you know you can make work. Don't worry about getting it right the first time (that's rarely happened to me!) You'll learn a lot just by getting one prototype working, and it will help you decide what the second iteration of your design should look like.

That said, let me describe how using a micro-controller (in both the receiver and transmitter sides) could help your design:

- most uC's have built-in ADC units and this would eliminate the 555 and associated circuitry needed to digitize your sensor reading

- a uC can encode the data packet into a serial bit stream thus performing the function of the HT12E

- a uC can decode a serial bit stream into data bytes thus performing the function of the HT12D

- a uC can manage the power of your application; it can turn off circuits (even external ones) that are not in use, and itself can go into sleep modes in which it only consumes microamps. This could be very beneficial for battery-powered applications which are only intermittently active.

As for using a uC for encoding and decoding, have a look at this example for the Spark Fun units:

https://www.electro-tech-online.com/custompdfs/2007/07/KLP_Walkthrough.pdf

They only show code for a PIC and Atmel Arduino board, but you should be able to do the same with a Basic Stamp. Essentially you just use the built-in serial UART to perform the "encoding" and "decoding". It's not the same encoding and decoding as the Holtek chips, but it's a method that will work.

Again, I would urge you to adopt an approach which you are confident you can succeed at. Often it's more valuable to get something working than to come up with the "best" solution (however that's measured.)

 

[Nigel Goodwin]

To be 100% honest I am involved more with mechanical engineering than electronics engineering, and I am not familiar with how to write code to decode the transmission... I'm using a BasicX-24 for this project. If you have any tips or links that may be of help I am all ears! Writing the code would save me $1.50 and a lot of input pins on the microcontroller, however I would still need the HT12E correct?

My tutorials provide code for both transmitter and receiver, using Manchester coding - but it's in assembler.

 

[Conrad_Turbo]

You'll need some sort of data encoder on the transmit side - either a HT12E or microcontroller will work.

Okay makes sense. If I use an encoder on one end I am not sure what will come out of the other (at this moment) so for simplicity sake I could just use a matching decoder on the other end and have it convert it for me...at the expense of using extra microcontroller pins.

We've discussed a lot of ideas in this thread, and my overall advice would be that you go down a path that you know you can make work. Don't worry about getting it right the first time (that's rarely happened to me!) You'll learn a lot just by getting one prototype working, and it will help you decide what the second iteration of your design should look like.

That's exactly what I am looking for. Something that is simple, feed a 1 or 0 into an input on one end and have that 1 or 0 come out on the other end without paying too much for it. I know using a decoder is wasteful in terms of cost and useage of microcontroller pins...but the goal is to make it work the first time, then optimize it after that. I dabble in electronics a bit, but I know I'm not even close to what you guys do.

That said, let me describe how using a micro-controller (in both the receiver and transmitter sides) could help your design:

- most uC's have built-in ADC units and this would eliminate the 555 and associated circuitry needed to digitize your sensor reading

True, however the microcontroller (Basicx) I know how to program is $50/each...and I'm wanting to build each sensor for around $15-20/each in electronics and around $5/each in metalwork. However for right now I am just creating sensors that create an on/off ouput for a yard monitoring system. So there won't be any really heavily streamed data going on. In the future however I would like to stream data from sensors, but first I want to get my feet wet with a simple on/off transmission.

- a uC can encode the data packet into a serial bit stream thus performing the function of the HT12E

This is something I will definately have to look into in the future as my current situation doesn't allow this to be cost effective.

- a uC can decode a serial bit stream into data bytes thus performing the function of the HT12D

I wish I could do this now...but for now the minimal cost of purchasing one HT12D is a non-issue. It's the extra use of pins will be the issue in the future, something which I could correct once I learn how to write the code to interpret the HT12E.

- a uC can manage the power of your application; it can turn off circuits (even external ones) that are not in use, and itself can go into sleep modes in which it only consumes microamps. This could be very beneficial for battery-powered applications which are only intermittently active.

True, my sensors won't be battery powered yet...because the sensors themselves will use a fair bit of power while they are on. However in the future I'd like to be more energy efficient and allow for battery powered remote sensors to be tied into the "network".

Again, I would urge you to adopt an approach which you are confident you can succeed at. Often it's more valuable to get something working than to come up with the "best" solution (however that's measured.)

I 100% agree, which is why I like the Linx Technology units...but since I cannot use them in a through hole configuration I have to look elsewhere. I'm debating buying them and finding a way to solder it to a PCB...they seem so much more superior than most units out there. Considering it has 6 times the range as the unit on SFE and all I need is the chip, 10-dip switch and antenna. However if I do go with say the 4800bps RF link from SFE, can I buy 1 receiver and 10 transmitters? I know they are purchased in "matched pairs", but if I need to add more transmitters what do I do?

My tutorials provide code for both transmitter and receiver, using Manchester coding - but it's in assembler.

I have no idea what that code is like...I'm only familiar with the BasicX unit.

 

[Conrad_Turbo]

pc88 you mind answering these questions for me?

However if I do go with say the 4800bps RF link from SFE, can I buy 1 receiver and 10 transmitters? I know they are purchased in "matched pairs", but if I need to add more transmitters what do I do?

That's all I think I need to know.

 

[pc88]

pc88 you mind answering these questions for me?

However if I do go with say the 4800bps RF link from SFE, can I buy 1 receiver and 10 transmitters? I know they are purchased in "matched pairs", but if I need to add more transmitters what do I do?

That's all I think I need to know.

If you're asking whether or not all of the, say, 433.92 MHz units will interoperate with each other, then I think that's true, although I would confirm that with either SparkFun or the manufacturer.

 

[Conrad_Turbo]

If you're asking whether or not all of the, say, 433.92 MHz units will interoperate with each other, then I think that's true, although I would confirm that with either SparkFun or the manufacturer.

Ya that's what I'm wondering, is because they are sold as a pair, however in the future I'd want to run more transmitters than receivers. I will pose the question to SF.

Thanks for the info in this thread! You made something completely unknown to me...understandable.

 

[pc88]

Let me know if you want to get into PIC or AVR microcontrollers. They would be very well suited for a project like this and only cost $2-$3 a piece. Also, let me know when you want to add more transmitters - I'm pretty sure I can help you out with the decoding process.

 

[Nigel Goodwin]

Let me know if you want to get into PIC or AVR microcontrollers. They would be very well suited for a project like this and only cost $2-$3 a piece. Also, let me know when you want to add more transmitters - I'm pretty sure I can help you out with the decoding process.

Or he could read my tutorials?.