Simple RF Transmit and Receive

[koossa]

Good day All

I am playing around with RF and just want to send something from one PIC to another.
I'm using the Radiometrix RX2 (RX2-433-160-5V) and TX2 (TX2-433-160-5V) (http://www.radiometrix.com/html/products/emc.html) on a standard bread board.
It only works about every 30th time I test it.

Do anyone have an idea why this is happening?

Attached is the Schematics, Photos and Below the Source.

<hr>

<code>
'************************************************* ***************
'* Name : Transmit.bas *
'************************************************* ***************

Include "modedefs.bas"

DEFINE OSC 4 ' Set the Xtal frequency
SerialOutPin VAR PORTC.2 ' Serial Out
LEDPin Var PORTC.3
DEFINE CHAR_PACING 1000
ADCON1 = 7

Main:
&nbsp;PAUSE 5000

&nbsp;Serout SerialOutPin, N2400, ["go"] ' Send Data
&nbsp;HIGH LEDPin
&nbsp;Pause 1000
&nbsp;LOW LEDPin
&nbsp;PAUSE 1000

END
</code>

<hr>

<code>
'************************************************* ***************
'* Name : Receiver.bas *
'************************************************* ***************

Include "modedefs.bas"

DEFINE OSC 4 ' Set the Xtal frequency
SerialInPin VAR PORTC.2 ' Serial Out
LEDPin Var PORTC.3
DATAReceived VAR Byte
I VAR BYTE
ADCON1 = 7

Main:
HIGH LEDPin
Pause 5000
Low LEDPin

Loop:
&nbsp;Serin SerialInPin, N2400, 1000, Loop, ["g"], DATAReceived
&nbsp;If (DATAReceived = "o") Then
&nbsp;&nbsp;for I = 1 to 10
&nbsp;&nbsp;&nbsp;HIGH LEDPin
&nbsp;&nbsp;&nbsp;Pause 100
&nbsp;&nbsp;&nbsp;LOW LEDPin
&nbsp;&nbsp;&nbsp;PAUSE 100
&nbsp;&nbsp;next I
&nbsp;ENDIF

NOTFound:

Goto LOOP

END

</code>

[Kamikaze47]

There are a number of things you can do make RF comms more reliable. The first things I would recommend is a preamble, and a good 'start of data' byte.

This is what I use for my RF projects:

Serout2 rf_pin,17197,[$55,$55,$66,data]

and

Serin2 rf_pin,17197,[wait ($66),data]

The $55,$55 is the preamble, and the $66 byte tells the receiver that the next byte(s) are the data.

If you want to get more fancy you can add manchester encoding/decoding subroutines.

[chuck]

Also bread boarding is not very good for RF stuff, You could be getting interferance form the bread baord, the best thing is solder or make a baord.

like Kamikaze47 said send some preamble or search here and you will find all about manchester encoding

[Jerson]

First off, the modules require a long wire antenna. What you have connected is a whip antenna which has a ground terminal too. This is not required.

Second, a good preamble is a must.

Third, make sure your code works when wired between tx and rx. Only then, go to the wireless part.

Fourth, make sure your data rate is acheivable by the modules.

JF

[dhouston]

Those are FM modules so you really don't need to worry about a preamble. Just use the carrier detect pin on the receiver to determine when it's receiving a signal. Radiometrix probably has some detailed instructions for their use.

Also, you can ignore the advice re breadboards. The modules are basically self contained and all you need the breadboard for is the interconnections, power, etc. the breadboards won't affect the RF modules.

And the antennas you're using are fine.

[koossa]

Thank you very much!!!!

Will try out all the suggestions

[dhouston]

The test circuit shown on p6 of http://www.radiometrix.com/pdf/tx2rx2.pdf shows how to use the CD pin. You'll need to modify your receiver schematic to add the transistor, resistor and cap. Then, just monitor the /CD signal to determine when a signal is being received. Depending on the response time, you may need to prepend a non-data byte to all messages. FSK signalling is much more reliable than ASK. If you add manchester encoding to FSK, you get a really robust system.

[koossa]

Thank you very much Dave, I will add the manchester encoding!!

[koossa]

What will hapen when 2 or 3 transmitters, transmit at the same time?

[Acetronics2]

Hi,

Like here, at home ...

The door bell will ring when it recognizes " something known " in the wheather station transmission !!!

so, think to add a checksum to valid your message ...

Alain

[koossa]

Thank you, I will build in a checksum.

I am fairly new to RF and PICs, and want to understand what I am doing.

What is the reason for using the CD Pin signal detection, why doesn't it work if I only monitor the input?

[dhouston]

What will hapen when 2 or 3 transmitters, transmit at the same time?

Most likely you'll receive a nonsense transmission if they indeed transmit at the same exact time. You need to embed a transmitter ID within the transmission packet and add a CRC or checksum to determine whether the data packet is valid and, if so, from whence it came. Also, there are limits on how often a transmitter can transmit. Adding a bit of randomness to the transmission schedules will minimize collisions. What's the application?

[koossa]

Thank you very much Dave.

I want to build my own simple wireless motion detector for outdoor security.

Could you please tel me what is the reason for using the CD Pin signal detection, why doesn't it work if I only monitor the RF input?

[dhouston]

Could you please tel me what is the reason for using the CD Pin signal detection, why doesn't it work if I only monitor the RF input?

With the FSK modules, a logic 1 is represented by one frequency and a logic 0 is represented by a slightly different frequency. the Carrier Detect (CD) output indicates when either frequency (or any frequency close to them) is present and that's a fairly strong indication that a signal is present. Just monitoring the RF input (which really should be labelled Antenna Input) will give you a lot of ultralow level random noise as it is before any tuned circuits - it's equivalent to throwing away the receiver and just attaching the antenna to a PIC input. There are two data output pins - both are demodulated so they are in the audio frequency range. The AF pin is an analog output. Its amplitude can be usually used as an indication of received signal strength. The RXD pin is a digital output of the logical ONES and ZEROS. Use CD to tell you when to monitor RXD.

My web page is down right now due to a mixup with a new hosting service I've moved to. As soon as it's back up (later today, hopefully), you can see how to use your soundcard like an oscilloscope to record the audio frequency output signals as wave files. It's much easier to grasp the basics when you can see the signals output by the receiver.

EDIT: My page is back up. The second section - Wireless Application Notes may help you.

[koossa]

Thank you very much Dave, I really appreciate your help!!

[dhouston]

The FM transmitter/receiver pair you're working with are rather costly for this type application, especially if you are planning on several sensors. You can reduce the cost by using ASK modules like those I list on my web page (or those designed/sold by Ioannis, one of the regulars here) and using a simple protocol like the one I've posted an example of in the Code Examples forum.

• http://www.picbasic.co.uk/forum/showthread.php?t=6261

[koossa]

Thx Dave!

I was actually looking for a cheaper option, but did not know what to look for.

[koossa]

What is a typical application for a FSK chip?

[koossa]

I have updated my circuit to monitor the CD pin on the Receiver
If high, I turn on an LED, but the LED switch on about every 10 seconds while the transmitter is still switched off?

[dhouston]

What is a typical application for a FSK chip?

FSK is needed when higher data rates are desired. The pair you're using can go as high as 160kbps while ASK modules are usually limited to 4-8kbps. In simple terms, ASK is like AM radio which is subject to interference while FSK is like FM which has better noise rejection.

[dhouston]

I have updated my circuit to monitor the CD pin on the Receiver
If high, I turn on an LED, but the LED switch on about every 10 seconds while the transmitter is still switched off?

I'm not sure what you're saying. If you are using the recommended circuit (p6 of the PDF), the /CD signal goes low when there is a signal.

[koossa]

Oops!!
I must have missed it and just assumed it must be high, sorry!

Will this code do the job to just test the CD pin functioning?
<code>
........
&nbsp;IF CDPin = 0 THEN
&nbsp;&nbsp;&nbsp;&nbsp;HIGH LEDPin
&nbsp;&nbsp;&nbsp;&nbsp;Pause 1000
&nbsp;&nbsp;&nbsp;&nbsp;LOW LEDPin
&nbsp;&nbsp;&nbsp;&nbsp;PAUSE 1000
&nbsp;ENDIF
.......
</code>

[dhouston]

Pin 3 (CD) probably doesn't have enough swing to be sensed directly by a PIC pin. That's why the transistor is needed. In effect, it amplifies and inverts CD.

I'm not sure what you want the LED to indicate. I would just capture and decode the RXD pin whenever /CD is low. What you get on RXD should match what you send with the transmitter.

The PDF file says the CD signal has a fast response but doesn't say how fast. Instead of trying to use serin/serout I would first just look at the pulsetrain to determine if CD is fast enough that you won't miss bits.

[koossa]

Dave

Thank you for all your help

I'm not sure I know how to do this?
Must I use something like the Pulsin command, I have not done this before?

The PDF file says the CD signal has a fast response but doesn't say how fast. Instead of trying to use serin/serout I would first just look at the pulsetrain to determine if CD is fast enough that you won't miss bits.

<hr>

I am using the LED just to test if it goes low if I send data with the transmitter, just to make sure my circuit is wired correctly and that it only works if my receiver is sending data.

I have added 2 LEDs for debugging purposes.
A green one on PortB.4 and a Red one on PortB.5
If CD is low, the green LED will blink, if CD is high, the Red LED will blink.
While the transmitter is still powered down, I switch on the receiver, and the Green LED just constantly blink on and off, which tells me that the CD is Low from the beginning?
When I then swith the Transmitter on and send data, the Green LED still blink at the same frequency?

I'm not sure if I am missing something, but I am still in the amateur student phase.

Here is my code.

<code>
'************************************************* ***************
'* Name&nbsp;&nbsp;: Receiver.bas&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs p;&nbsp;&nbsp;&nbsp; *
'************************************************* ***************

Include "modedefs.bas"

DEFINE&nbsp;&nbsp;&nbsp;&nbsp; OSC&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp; ' Set the Xtal frequency
SerialInPin&nbsp;&nbsp; VAR&nbsp;&nbsp; PORTC.2 ' Serial Out
LEDPin&nbsp;&nbsp;&nbsp;&nbsp; Var&nbsp;&nbsp; PORTC.3
REDLed&nbsp;&nbsp;&nbsp;&nbsp; VAR&nbsp;&nbsp; PORTB.5
GreenLED&nbsp;&nbsp;&nbsp;&nbsp;VAR&nbsp;&nbsp; PORTB.4
CDPin&nbsp;&nbsp;&nbsp;&nbsp; VAR&nbsp;&nbsp; PORTD.2
DATAReceived&nbsp;&nbsp;VAR&nbsp;&nbsp; Byte
I&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VAR&nbsp;&nbsp; BYTE
ADCON1 = 7

Main:
HIGH LEDPin
Pause 5000
Low LEDPin
&nbsp;&nbsp;
Loop:

&nbsp;&nbsp;IF CDPin = 0 THEN
&nbsp;&nbsp;&nbsp;&nbsp;HIGH GreenLED
&nbsp;&nbsp;&nbsp;&nbsp;Pause 100
&nbsp;&nbsp;&nbsp;&nbsp;LOW GreenLED
&nbsp;&nbsp;&nbsp;&nbsp;PAUSE 100
&nbsp;&nbsp;else
&nbsp;&nbsp;&nbsp;&nbsp;HIGH REDLed
&nbsp;&nbsp;&nbsp;&nbsp;Pause 100
&nbsp;&nbsp;&nbsp;&nbsp;LOW REDLed
&nbsp;&nbsp;&nbsp;&nbsp;PAUSE 100
&nbsp;&nbsp;ENDIF
Goto LOOP

END
</code>

[dhouston]

If you are connecting the receiver CD pin (pin 3) directly to PORTD.2, CD may not go high enough to be seen as HIGH by PORTD.2. That's why the transistor is needed and why you need to monitor /CD (refer to p6 of the PDF specs for the receiver).

Look at the code I referenced earlier in Code Examples for how to encode/transmit and receive/decode a pulse train. It's all you need for this application. It sends two bytes. Both bytes are followed by their complement so some basic error detection is built in. One can be an ID and the other indicate motion or all clear. All clear is sent when motion is followed by a period with no motion plus every hour or so to indicate "all's well".

[koossa]

Dave, I will implement your code, thank you!

Will it be possible for me to connect the Receiver's RF In Pin to the PC's Comm Port?

Thx!!

[dhouston]

Will it be possible for me to connect the Receiver's RF In Pin to the PC's Comm Port?

No. The Receiver RF IN pin is where you connect the antenna.

[dhouston]

Will it be possible for me to connect the Receiver's RF In Pin to the PC's Comm Port?

No. The Receiver RF IN pin is where you connect the antenna.

[koossa]

What I mean is the RXD pin, can I connect it to the PC's Comm port.
Or do I have the wrong understanding of the RXD pin?

[thye]

Hi....I'm new here and a beginner in PICBasic Pro...

I'm using PIC 16F877A for Tx and Rx project also....what is the simple code for Tx and Rx?

Thanks a lot....

[koossa]

Dave

In your code for the receiver there is a pin for the pulsout, GPIO.1.
Is this the CD Pin?

[dhouston]

If you continue to use SerOut with the transmitter, then the receiver RXD pin output timing will be the same as RS232 but the polarity will depend on what polarity you use at the transmitter. The COM port on a PC expects inverted polarity.

However, the RF link in the example code I'm suggesting is not RS232 compatible. It is an example of the NEC protocol which is widely used for remote control and for applications like yours. X-10 uses it for all of their RF applications, including motion sensors. For an RF link it's much simpler to implement than SerIn/SerOut and is very reliable for small amounts of data. It does use Debug to output the received codes to a PC serial port. See the PBP manual for how to implement this.

I think you mean GPIO.1 and PulsIn. That is equivalent to your RXD pin. The code was written for ASK modules which have no CD so you can ignore CD if you try to adapt my code.

[koossa]

Dave

I am busy implementing your code and all your suggestions.
What must the Comm. port settings be on the PC Side (see attachment)?
I'm using MS Terminal to monitor the incoming data on the PC.

[dhouston]

What must the Comm. port settings be on the PC Side (see attachment)?

9600 8N1 - See the Define statements in my example.

DEFINE DEBUG_REG GPIO
DEFINE DEBUG_BIT 2 				'GPIO.2
DEFINE DEBUG_MODE 1 				'Inverted
DEFINE DEBUG_BAUD 9600

You will need to change DEBUG_REG and DEBUG_BIT to reflect the pin you use for output to the PC. I wrote this for a 12F629.

[koossa]

Ok, so my settings is correct, but it does not work?
I will upload my new schematics and code.
Mayby I have missed something.

[koossa]

Dave

I have updated my Schematics and used your source code.
I have made a couple of mods on the code, but it does not seem to work, don't know if I have missed something.

I am using MS Terminal to view the incomming data on the PC. The data did only came through once and it was a couple of junk characters.

Thank you very much for all your help!!

[dhouston]

In your schematic, change both 22K resistors to 1K. These merely limit the current to what is safe. 5V / 1000R = 0.005A (5mA). The 22K is needed only when the voltage is higher as with an input from a PC using RS232 voltage levels. Here, all the voltages are 5V max.

In the code, comment out IF (space<40) OR (space>175) THEN init.

In the code, modify DEBUG (RF[i] REV 8) to send either hex or decimal representations of the bytes. I'll let you consult the manual for details. My code sends the Ascii byte values which may not all be printable characters, especially in MS Terminal.

HEX 50 AF 42 DB
DEC 80, 175, 66, 189
ASC P, », B, ╜

The protocol is explained at http://davehouston.net/rf.htm

[koossa]

Dave

I have made all your suggested changes.
I don't receive anything on the PC side, but for a test I have moved the RS232 to the transmitter. (Disconnected the TXD Pin and put the RS232 in its place)
Then I receive the following characters.

ðððððððððððððððððððððððððððððððððððððððððððððððððð ðððððððððððððððððððððððððððððð
ðððððððððððððððððððððððððððððððððððððððððððððððððð ðð

[dhouston]

I don't have your hardware so I cannot set this up here and test it. I don't have the time for that anyway. I can only tell you I've used the code many, many times with 12F629, 12F675 and 12F673 and ASK RF modules.

You will only see garbage when you connect the transmitter TXD pin to RS232 as it is sending NEC protocol not RS232 protocol.

However, if you go back to your original approach, using SerOut & SerIn, you can send RS232 from the transmitter which might serve as a sanity check.

[lil_mark]

Hi All, Hi Dave
I wish you all a happy new year.

I'd like to thanks Dave for his code and... compliments for your website. It's full of precious infos.

I'm using your code on a pair of 18F4550@4Mhz and a couple of LAIPAC RLP/TLP 434 with success.

I'm asking for your(Dave's) help because I'd like to use the receiver code using a PIC clock speed @ 20Mhz.

I'v tried dividing the timings by 5 but without success.

Can you kindly help me posting a code sample working @ 20Mhz.

Sorry for this apparently stupid question, but i'm trying and trying again...

Thank you,
Regards,
Mark.