RS232 by Radio

[Ioannis]

Hi Bruce. In your idea, step 2, I believe he will still have the sam problem, as the Serin2 command waits for he "!" character. If receiver is out of range then this "!" maybe will never come, only static. So, the timer may have overflown but the Serin2 still waits for then never coming character.

Ioannis

[Acetronics2]

Hi, Bill

In some µP PPM R/C decoders, there's only an 8 bit sequence ( a number ) placed just before the data sequence.

If number is the good one, data is considered valid ...if not, the Fail safe sequence is launched.

so, the receiver analyses all incoming data, not being locked on HARDWARE waiting for the "!"

Alain

[Melanie]

Uhhhh... then why not just make the Qualifying character more complex? Instead of just "!" which gives you a 1:256 chance of random 'monkey typo' hitting the jackpot, make it "Coffee!" which now makes it a 1:72057594037927936 chance.

Lets face it... there's ALWAYS going to be junk comming in from the Receiver at the extremes of range. Now you either kill it via additional Hardware, or by Software, or a combination of both.

I personally hate SERIN. It's a command that cuts corners to provide complex functionality for folks who don't know any better. It's not a professional solution (just search this forum to see how many people have posted their woes with it's usage). It's biggest downfall is that it is designed for 'perfect' communications (which only happens in a nice perfect wired environment). As soon as you go into the real world, and go wireless, the deficiencies in SERIN causes it to fall apart (which is what you are experiencing). My recommendation is to use the Hardware USART and read-in byte-by-byte, handling the Qualifier and Data integrity through your own routine. Using the Hardware USART route, your PIC isn't bogged-down with software timing for the arrival of individual bits... leave that to the USART and just pick-up the byte when it's finished and ready in the buffer. If it's junk, and timing and bits are all over the place (like random noise), then the USART won't act on a lot of it, and the gibberish that does come through will be handled by your Data integrity routines.

[Ioannis]

Well with all the respect Melanie, i think his problem is to just get out of the 200msec of waiting for the ! or whatever this string will be.

If there is a continues noise in the receiver output, either Serin or Hserin will be constantly triggered, and never will get this lost_signal flag.

The problem is before the reception of any characters, not after!

Ioannis

[Melanie]

I know, that's why I said use the USART and pick the byte up after it appears in the buffer. HSERIN is no better than SERIN, SERIN2 or DEBUGIN, it just uses the Hardware, but as for the rest, has the same disfunctionality with noisy reception.

Using FM instead of AM helps at the extremes of range, but the real answer is don't operate at the extreme edge! If you're operating your robot (or model boat or plane or Mars Lander) right at the edge of reliable communications, then it's time you upgraded to a better Radio Link otherwise you'll lose your boat or plane or Martian explorer. Get a better receiver, one with a better signal-to-noise ratio, up the power of your transmitter, improve your aerials, do I need to go on and state all the obvious choices?

[Ioannis]

Hmm, isn't it the right time to advertise my receiver with almost zero noise at the output? :-)

Ioannis

[Acetronics2]

Hi,

I catched that on Bruce's site ...

NEW The new LR series receiver includes an RSSI (received signal strength indicator) output. See datasheet below for details.

RSSI output ... here is the solution !!!

Alain

[Bruce]

almost zero noise

Linx had an LC series, which were incredibly easy to use due to the receivers data output
being very stable in the absence of the RF carrier.

The trade off, of course, was range. They have since dropped the LC series in favor of the
LR (LR stands for Long-range), which now offer 10 times the range of the LC series due to
the increased sensitivity of the newer LR series receiver.

The trade off here is that the newer LR series receivers output random noise. This is what
he's now having to deal with.

If you toss a pair of simple encoder/decoder ICs into the mix, this noise is no longer a factor
since the decoder IC will validate the inbound data several times before changing the logic
on the decoders output.

Ioannis;

What's the sensitivity of your receiver in dBm? If it's anywhere near the Linx LR receivers
sensitivity, we might be interested in stocking your receivers.