|
Also, I tested my transmitter and receiver with the microcontrollers. I was able to transmit the 1101 sequence from the transmitter to the receiver. I got the encoded version of the 1101 sequence. But, the microcontroller on the receiver end the serin command does not work for the microcontroller. When I look at the pins where I have serout on I don't see any signal. Did I do something incorrect?
|
What? Doesn't make any sense...Originally Posted by oneohthree
|
I don't know what is wrong either. Somehow the serin command isnt taking the data that I send in from the receiver. I check the output at pin 1 and pin 3 using a logic analyzer and I get nothing. Is there something wrong with my receiver code. Also, should I send data in inverted (n2400) or non-inverted (t2400)?
|
No, I meant your sentence didn't make any sense...
|
Do you have any suggestion on how I can get my serin command to work correctly?
|
Yes, READ the WHOLE 'Serin SerOut Problem' thread, not to mention a half a dozen other PIC-PIC communication threads in the 'Serial' section of the forum, just like I've suggested in the other thread and more than once. And start simple and build up. You're still using the RF modules, but I don't see anything that says you're sure it all works without the RF modules. I don't see anything that says you're sure the whole thing works just between the 2 PIC's, a couple of buttons and a couple of LEDs.
|
Encoding for RF communications
Simple RF receivers need a preamble to condition the data slicer. I have had great success with low power Rf comms by using a pseudo Manchester strategy.
Manchester code is usually recommended because it guarantees at least one transition per bit so a long run of 000 or 111 can be successfully decoded.
The following also works. Assuming a 4 bit nibble is to be sent, build a character of start bit, 8 data bits and one or preferably 2 or more stop bits. Use Char_Pacing to get extra stop bits. 8 bit bytes need to be broken into two halves before sending. A checksum on any data block is highly recommended.
Byte bit 0 is nibble bit 0
Byte bit 1 is inverted nibble bit 0
Byte bit 2 is nibble bit 1
Byte bit 3 is inverted nibble bit 1
Byte bit 4 is nibble bit2
Byte bit 5 is inverted nibble bit 2
Byte bit 6 is nibble bit 3
Byte bit 7 is inverted nibble bit 3
Now transmit this character many times - say 32 or more. The first few characters act as the preamble and the data stream is very nearly 50:50 duty cycle so the receiver data slicer is happy. Depending on link characteristics you may be able to cut the transmitted data down to 16 or even less repetitions.
Perform tests on the received character stream to make sure you receive it, say, at least 3 consecutive times, where the characters are identical to each other AND the data structure of bit/inverted-bit is obeyed. Activating parity can also give you an extra check.
I have used this with expensive 154 MHz transceivers and cheap 315 and 433 MHz Tx/Rx modules with great success.
HTH
Brian
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks