Printable View
I am using a PIC16LF84A and a radio frequency receiver. I would like to know how I can read the data out of the receiver and input it to the microcontroller. Also, I would like to know how I can use that data and extract bits of data so that I can perform operations on it. For example, if my input is 1100, I would like to know how I can input the 1100 string and then extract one of the bits (like 1) . I am thinking of using Serin but I am not sure how I can extract bits from it.
So far we know....Nothing!Quote:
Originally Posted by oneohthree
Which receiver are you using?
Which transmitter are you using?
Show us some example code which YOU have written and then I'm sure a number of people will be more than happy to help you with your application...
Use the search function...
In fact, let me re-order those just a bit:
Use the search function provided free of charge at the link at the top of this web page.
Tell us which receiver you are using
Tell us which transmitter you are using
Show us some example code which YOU have written and then I'm sure a number of people will be more than happy to help you with your application...
And finally use the search function provided free of charge at the link at the top of this web page.
The transmitter being used is the TLP-434 and the receiver used is the RLP-434
A link to the data sheet is: http://www.sparkfun.com/datasheets/RF/TLPRLP.pdf
Code:
B2 VAR PORTB.0 'Variable B2 set to pin 0
Serin 0,N2400,B2 'Serial in to pin 0
RX1 VAR PORTB.0 'Variable RX1 set to bit 0 (address)
RX2 VAR PORTB.1 'Variable RX2 set to bit 1 (address)
RX3 VAR PORTB.2 'Variable RX3 set to bit 2 (mode)
RX4 VAR PORTB.3 'Variable RX4 set to bit 3 (mode)
action VAR PORTB.4 'Variable action set to bit 4
alert VAR PORTB.5 'Variable alert set to bit 5
PORTB.0=1 'Set bit 0 of Port B = 1 (address)
PORTB.1=0 'Set bit 1 of Port B = 0 (address)
PORTB.2=0 'Set bit 2 of Port B = 0 (mode)
PORTB.3=1 'set bit 3 of Port B = 0 (mode)
B0 VAR PORTB.6 'Set B0 to bit 6
B1 VAR PORTB.7 'Set B1 to bit 7
PORTB.6=1 'Set bit 6 to 1 (hard wired address to compare to)
PORTB.7=0 'Set bit 7 to 0 (hard wired address to compare to)
B0=1
B1=0
'Tracking
If (RX3==0) && (RX4==0) Then 'Check if only tracking mode
If (RX1==B0) && (RX2==B1) Then 'Check if the address matches
RX3=1 'Convert third bit to 1 and send
action = RX3
High 0
alert = 0
Low 1
Else 'back to transmitter
action = RX3 'No matches. third bit remains 0 to send
Low 0
alert = 0
Low 1
Endif 'back tor transmitter
Endif
'Track and Find
If (RX3==0) && (RX4==1) Then
If (RX1==B0) && (RX2==B1) Then 'The receiver will take action to find the child
RX3=1
action=RX3
High 0
alert=1
High 1
Else
action=0
Low 0 'If no match will send 0 to transmitter
alert=0
Low 1
Endif
Endif
That's better...Quote:
Originally Posted by oneohthree
Is this your first time using these RF modules?
If it is, you'd do well to do a search on manchester encoding.
You should find everything you need...we had a thread here awhile back that went a number of pages, dealt with transmitting temperature readings, but will be easily adaptable to your application.
Or you could do something wierd and write all your own code...
Get back after you've read up on the encoding a bit...
I am only transmitting 4 bits from the transmitter to the receiver. Would manchester encoding be necessary, because from what I read it's not needed.
Then you didn't read enough of the posts.Quote:
Originally Posted by oneohthree
Generally speaking, you can't send straight serial data into the transmitter and get that same straight serial data out of the receiver.
As all of those posts said, you have to sync up the receiver by sending sync bytes.
Since you are only sending 4 bits, you encode them at the transmitter end (giving you 8 bits total), and decode that byte at the receiver end (getting back your 4 bits from 8).
But again, as I've stated elsewhere, you're dropping all the way into your project without taking little steps first.
Hook up a couple of LEDs to the RX PIC and get those to flash on command from the TX PIC, anything to prove that you can write the code needed to do the job.
Then work your way up to sending functional data across the RF link to do the job you need.
As to whether or not manchester encoding would be needed?
Maybe not, but your data will be a whole heck of lot more reliable (up to the point of being almost completely unreliable if you didn't encode it) at the receiver end if you implented some sort of coding.
come to think of it, do a search on 'data slicer', will probably give you a bit more info.
Hi,
Without going into much technical blah... blah.. (Which I don't understand :D)
Skimask please correct me if I am wrong as I have never used a Tx/Rx module.
Your Tx and Rx module uses ASK (amplitude shift keying). This is the most frequent and low cost. It means that your receiver demodulates the signal by finding a difference of the transmitted carrier level. Now take for example that you need to transmit 255 = b'11111111' . For 8N1 you would actually set the output (carrier) high for the start bit and since all of your bits are high through the ending stop bit you would be keeping it high for the entire byte. This is NRZ (Non return to Zero) and drives your receiver nuts and it cannot see a practical shift in the amplitude.
Thus comes manchester to the rescue. It ensures transition for every bit. It is used for automatic clock recovery but here it eases the ASK demodulation.
Attachment 1499
Attachment 1500
If you are sending only a specific byte, (if the sending is in your hand) then you can actually use shifting 1s. Guess what you get at the receiver side ? I will leave that for your research ;)
Are you asking me a question, trying to tell me something or what?Quote:
Originally Posted by sougata
As long as I've got an equal number of 0's and 1's, I don't care how I get it to work (manchester encoding, lookup/lookdown tables, whatever), as long as it works. Data slicer stays happy, I stay happy...and it works very well. I've got a few sets of the TLP/RLP-434's and a few others from Rentron. Funny thing though, the spec sheets say that they max out at about 2400bps (maybe 4800, I forget). I've been able to use them at 19.2kbps (albiet shorter range) successfully a number of time.
Dear Skimask,Quote:
Originally Posted by skimask
I have clearly mentioned that I have never used a Tx/Rx module ever. I tried to explain something which is not practically tested by me. So I was seeking support to correct me if I state something.
I was trying to clarify the same thing.Quote:
Originally Posted by sougata
In the earlier post, if you are trying to explain something and asking me if your explanation was correct, then, I would have to say, for the most part, yes. Train the receiver with a stream of 1's and 0's, keep the receiver happy with an equal number of the one's and zero's equal, and all should work well.
I wrote some test code for a transmitter and receiver,
Transmitter:
Include "Modedefs.bas"
START:
serout Portb.3, t2400, ["A", 1010]
Pause 1
serout Portb.3, t2400, ["A", 1010]
Pause 1
GOTO START
Receiver:
Include "Modedefs.bas"
B0 var portb.1
serin portb.0, t2400,["A"], B0
I would like to read a the first bit in B0 how would I be able to do it? Do I need to store it somewhere temporarily?
You didn't read any of those RF module posts completely...did you?Quote:
Originally Posted by oneohthree
'cause, for the most part, what you've got above won't work
Main problem, just like it says in all those posts, no preamble for the recevier's data slicer.
Oh, don't get me wrong, it might work. I'd bet money it won't.
What's the purpose of: serout Portb.3, t2400, ["A", 1010]
explain it to me so I can tell you where you logic is flawed...
How do I write code for the preamble for the receiver's data slicer? I was thinking of sending a start bit in front, so that serin can know when it should start reading data. I dont know if that is the correct way to do it though.
RE-READ THE SERIN SEROUT PROBLEM thread that you've been reading. It's all right there. I don't feel like retyping things that have already been done.Quote:
Originally Posted by oneohthree
As far as sending the start bit in front so that serin can known when it should start reading data....
How do you think serial data transmission works? By sending the stop bit first? Not so much....