RF garbage on soft RS232 - 16f877

[Castle Buff]

Unsafe at any speed (9600 down to 1200)

trying to push a balanced stream of aa (10101010) 8 times always returns 7 bytes of 35 4d 53 aa 35 4d ff.

using putc, and getc on rentron 433 rf modules.

The receive routine is below:

#use rs232 (baud = 1200, xmit = PIN_B1, rcv = PIN_B0, invert)

#INT_EXT

void ext_isr()
{

byte temp1;

in_count++; // count hits to routine

temp1 = getc(); // get byte

ext_buffer[ext_buffer_next_in] = temp1; //stuff byte into buffer
if(++ext_buffer_next_in == BUFFER_SIZE) ext_buffer_next_in = 0; // check for buffer OF.

}
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516974

[Castle Buff]

PS - scoped RX and TX on both sides and got a beautiful match all the way up to 9600.
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516975

[Dale Botkin]

1.) Are you seing this on receive or transmit? The code you posted is for receive, what's doing the transmitting?

2.) What is your clock source and speed?

3.) Are you using *ANY* other interrupts?

Dale
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516976

[Castle Buff]

:=1.) Are you seing this on receive or transmit? The code you posted is for receive, what's doing the transmitting?
:=
:=2.) What is your clock source and speed?
:=
:=3.) Are you using *ANY* other interrupts?
:=
:=Dale

1. Using two identically wired transceivers, rx tx modules on both side. Results are identical both ways. The transmit code is a simple series of putc's. I tried adding delays between the putc's but the results didn't change at 1 ms and 100 us delays.

2. using external 20Mhz clock

3. also using the int_rb for button tests on rb4-7.

:)
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516977

[Castle Buff]

Here is the transmit code snipet ...

disable_interrupts(INT_EXT);
disable_interrupts(GLOBAL);

send = false;

printf(lcd_putc,"\f");
putc(0xaa);
// delay_us(100);
putc(0xaa);
// delay_us(100);
putc(0xaa);
// delay_us(100);
putc(0xaa);
// delay_us(100);
putc(0xaa);
// delay_us(100);
putc(0xaa);
// delay_us(100);
putc(0xaa);
// delay_us(100);
putc(0xaa);
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516979

[Dale Botkin]

:=1. Using two identically wired transceivers, rx tx modules on both side. Results are identical both ways. The transmit code is a simple series of putc's. I tried adding delays between the putc's but the results didn't change at 1 ms and 100 us delays.
:=

Ah.

I have used RF modules before. Despite what I had read, sending data with the UART was useless at any speed I tried, which meant anything under 9600. I had to go to Manchester encoding, which worked extremely well. Don't know about the ones you have, but if they want a balanced data stream (as most do) you may just not have much luck with sending NRZ serial data like you get with #use rs232. My vendor said you could do some oddball serial character strings too, but I could never get it to work with any sort of reliability. Manchester was rock solid though.

There's a Microchip app note concerning the Keeloq system that has a very good explanation of Manchester encoding and what it takes to send and receive it. Sending is dead simple. Receiving well, with tolerance for noise and stuff, is Really Hard(tm). I spent a couple of weeks writing an interrupt driven, half duplex Manchester transceiver that I'd love to be able to share but can't.

:=2. using external 20Mhz clock

That's good.

:=3. also using the int_rb for button tests on rb4-7.

Shouldn't be a problem. I was afraid you were going to say you have a TIMER0 interrupt every 256uS or something... 8-)

Dale
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516980

[Castle Buff]

Thanks for the response ...

I have actually written a Manchester encoding scheme that I hav ebeen trying to debug, but when I realized I couldn't even send aa (10101010) I realized encoding by itself wouldn't solve the problem.

I was hoping there was a magic setting for the RS232 signal (parity, stop bits, start bits).

I didn't seem to have any problem until I moved to the interrupt driven routines. My first pass using straight rs232 worked, but wasn't going to be acceptable for my application.

I have a need to manage multiple rs232 connections - one by wire, one by rf, and one by ir.

Still stuck I guess ... ;)
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516981

[Dale Botkin]

:=I didn't seem to have any problem until I moved to the interrupt driven routines. My first pass using straight rs232 worked, but wasn't going to be acceptable for my application.

So have you scoped the Tx and Rx sides with a dual-trace to see if the data is arriving intact? I looked at the data sheets for some of the Linx UHF modules, they don't look like they would *require* Manchester for short bursts anyway. I missed the part about it working before you changed to an interrupt... that's interesting. I don't think I have ever used an interrupt driven software UART. Check this out:

<a href="http://www.pic-c.com/forum/general/posts/144516369.html"> <a href="http://www.pic-c.com/forum/general/posts/144516369.html" TARGET="_blank">http://www.pic-c.com/forum/general/posts/144516369.html</a></a>

Dale
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516985

[Castle Buff]

Scoped it up, down, side-ways, inside out, ...

Scoped from 1200 to 9600, and in both directions.

Before the Manchester rountine there were definately some issues with the signal getting corrupted, but it seemed like the first few bytes would sneak in okay. Now that I am balancing the transmissions the signal looks clean both ways, very clean.

So the signal is getting to the PIC okay, but the soft RS232 isn't handling it well. Looks like I may have to start digging through the list file. Assembly isn't my strong suit but I am running out of options.

8^)
___________________________
This message was ported from CCS's old forum
Original Post ID: 144516989