Linx RMX-433-LR problem

[Kasper]

Hi.

we have a board which uses a linx 433MHz receiver as part of a wireless link. It is hooked up to the first UART of a PIC 18F6620, where the code takes care of the odd noise spike by having a timer reset the byte counter after the time it takes for one character to be received, if no data has been received.
Now linx has made this new long range receiver, which they claim to be a drop in replacement, offering much longer range. Great I think and plop one on the board, only to find that it puts out random bits like mad. The below picture is the data out from their own evaluation board when nothing is being transmissed. ( in comparison the LR receiver, their old one, outputted a clean data line with the odd random bit, which was easily taken care off in software)



now can anyone suggest a way to make this work with a hardware uart, or do we need to do a new board layout and dedicate a controller to find the desired data in this mess?

I am open to suggestions

Kasper

[Guest]

Your figure shows the typical digital noise in wireless connections without transmission.
Usually you have to use at least a header just before your data bits. Much better to use a LAM (Look At Me) signal and a terminator stream, too.
I use something like this:
(Note that the header consists of 0xF8 characters, the LAM is 2-byte wide -B then an O- and the terminator stream is identical to header - so the header and the termin. drives the state machine into the "Wait for LAM" state)

#int_rda
void serial_isr()
{

char mit;

mit = getc();
if (mit == 0xF8) numF8++; // count the 0xF8
else numF8 = 0;
if (numF8 > LIMIT) { // reset state machine
smSerial = 0;
return;
}
if (smSerial == 0 && mit == 'B') { // first LAM chr
smSerial = 1;
return;
} else if (smSerial == 1 && mit == 'O') { // second LAM chr
smSerial = 2; // step into the true receive part
rdstr = 0; // reset the queue
bstr = 0;
return;
} else if (smSerial == 2) { // store the data byte
serpuffer[rdstr] = mit;
rdstr++;
rdstr &= 0x1F;
rbytes++;
}
}

Keep in mind that after completion (what is defined as "smSerial = 0 AND rdstr > LIMIT" what is true if we catched the terminator and we have at least one byte in the queue) the queue contains [RealDataLength + LIMIT] bytes. Additionally set the state machine's startup state to 0xFF in early main().