I am having a lot of trouble getting my RF-KLP-315 modules to work correctly. It’s driving me nuts and I need help! I have searched the forum high and low and it seems that a lot of people are having this problem but no one seems to have a fix. What I have is 2 pics setup as a transmitter and receiver. Basically it seems that if I hard wire my pic’s together everything is fine but if I replace the wire with the wireless modules I get nothing. I am using the receiver pic as a relay; once it receives data it will forward it back to the serial output and into my PC’s serial port for debugging.
Here is my transmitter code:
void main( void )
{
// configure USART for a 48MHz fosc
OpenUSART( USART_TX_INT_OFF &
USART_RX_INT_OFF &
USART_ASYNCH_MODE &
USART_EIGHT_BIT &
USART_CONT_RX &
USART_BRGH_LOW,
2499
);
baudUSART( BAUD_IDLE_CLK_HIGH &
BAUD_16_BIT_RATE &
BAUD_WAKEUP_OFF &
BAUD_AUTO_OFF
);
TRISAbits.TRISA0 = 0;
while(1) {
while(BusyUSART());
putcUSART(‘h’);
Delay10KTCYx(250);
};
CloseUSART();
}
and here is my receiver/relay code:
void main(void) {
// configure USART for 48MHz fosc
OpenUSART( USART_TX_INT_OFF &
USART_RX_INT_OFF &
USART_ASYNCH_MODE &
USART_EIGHT_BIT &
USART_CONT_RX &
USART_BRGH_LOW,
2499
);
baudUSART( BAUD_IDLE_CLK_HIGH &
BAUD_16_BIT_RATE &
BAUD_WAKEUP_OFF &
BAUD_AUTO_OFF
);
TRISAbits.TRISA0 = 0;
while(1) {
unsigned char c;
if (DataRdyUSART()) // check USART read buffer
{
c = getcUSART(); // read character
putcUSART(c); // echo it back
while (BusyUSART()); // wait until complete
Delay1KTCYx(4); // wait some more
}
};
CloseUSART();
}
Does anyone have any ideas of what I am doing wrong?
Substituting RF modules for directly connected uarts to achieve communciation between microcontrollers will not work reliably due to rf noise and “dc balance” issues with low cost rf modules. To overcome these, some form of software rf protocol incorporating manchester/scrambling techniques and error control (e.g. crc) have to be implemented. Not easy for a beginner, but doable if one persists.
Here are some links that will show you the way forward:
Thanks, Satz, for the references. An important point was raised in one of the documents about the difficulty using a HARDWARE UART because of the timing anomonies introduced by the receiver. This point has also been mentioned from time to time on this forum.
I use a PIC and a SOFTWARE (bit-banged) UART with great success. The hardware versus software UART issue slipped from my consciousness because I either use devices that don’t have a USART (12F675, etc.) or I reserve the hardware USART for PIC to PC communications. The software UART I use is the standard SERIN/SEROUT commands supplied by Proton (probably very similar to PICBasic Pro), but many other examples exist on the net.
Even if this module was very un-reliable I shoudl still be seeing something on the termnal right? I see nothing. They are about a foot apart. What I do not understan is when I wire the output from the rx on pin 3 (labeled as linear output/test) I see 1 singel character when the transmitter pic is reset. If I keep resetting the pic, I see 1 character. When the rx is wired up on pin 2 I see nothing.
I am really new to rf and I was really just looking for a drop in replacement for the wire. I see that sparkfun has a serial modem, would this be more reliable?
Both hardware or software uart will work just fine if you take care to keep within their specs. I prefer the hardware uart as it does not tax the processor as much. As a test to ensure you are able to send and receive over an rf link, follow the communication protocol suggested in the following link. Although it is meant for an AVR uC, it will work for a PIC.
FYI, I designed a radio packet controller that allows bidirectional rf communication among a group of robots and a base station using microcontroller hardware uart. The complete documentation is available at this link:
The reason why you’re not seeing any data is probably due to the way the uart works, assuming the usual 8 data bits, No parity bit, 1 stop bit (8N1) protocol:
The input line should be high when there is no data
When the input line goes low, the uart interprets this as a start bit
The uart then tests the state of the input line over the next 8 bit intervals to read in the 8 bits of the byte
Once its completes reading in the 8 bits, it expects a stop bit (high). If the input line is low, the uart interprets this as a ‘framing error’, resets its input buffer and waits for a start bit and the whole cycle is repeated. No data is output.
In your case, the uart is probably generating continuous framing errors and so you do not see any data.
As a test, set up your transmitter to send a continuous stream of Us (capital U) which is 55H. You should see a continuous stream of Us or the special character AAH at the receiving side.
If you are able to do this, you can be pretty sure that your electrical connections are correct. If not, check your circuit and retest until you can see the continuous data stream above. Once you can, you can proceed to the next stage, that is defining a protocol to read in ‘real’ data. See my previous post for a starting point.
I setup my transmitter to transmit a constant stream of U’s. Both the rx and tx are setup correctly. I have checked this against what is printed on the tx/rx and the sparkfun walkthrough.
The only way I am able to receive a ‘U’ is if I constantly reset my transmitter pic as fast as I can. In my terminal I will see a bunch of garbage and the occasional ‘U’ go by. I do not see anything when not resetting like this.
The only way I am able to receive a ‘U’ is if I constantly reset my transmitter pic as fast as I can. In my terminal I will see a bunch of garbage and the occasional ‘U’ go by. I do not see anything when not resetting like this.
Look at section 18.4.2 of the PIC Mid-Range Reference Manual.
What’s most likely happened is the PIC USART has registered an error which will lock up the receiver. The OERR bit must be cleared by clearing then setting CREN.
Something like:
/* reset receiver on error? */
if (OERR) {
CREN = 0;
CREN = 1;
}
Once this is fixed you’ll run into a different problem where the USART may not be able to synch up to the start and stop bits and/or other random bits will make it into your data stream. Search through this forum for answers…
I had thought that I was doing pretty well with my RF link without doing anything special other than sending a preamble string (without any regard to DC balance issues), but when I checked more closely, I found it was not really working so well…
Thanks to the recent posts by Satz and others, I re-did my protocol, and now I think it’s working great.
My setup is this:
Xmtr side is an 18F4620, 4800 baud, using the PIC’s UART. The xmtr module’s power is controlled by a 555 1-shot, so that the xmtr is automatically powered up when data is sent, and it powers down about 0.1 seconds after the last byte is sent.
Rcvr side is a 16F917, also using the PIC’s UART.
My preamble is 0x55 0x55 0x55 0xFF 0x33 0xCC. Each subsequent data byte is followed by it’s XOR, to maintain DC balance (neutral disparity).
I may need to change the 0x33 0xCC part - it seems to detect this sequence occasionally on random data (or somebody’s nearby garage door opener?).
When I get a chance, I’ll try doing 8/10 encoding instead of the simple XOR approach. It’s not that I really need the bandwidth, it just seems cool…