RS232 by Radio

[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.

[Bruce]

Hi Alain,

The RSSI output is definitely an option, but the difference in overall range has to be
considered. You can use this output for a squelch type circuit, and it's fairly reliable, but
it does have a significant impact on your overall wireless links range.

[Bill Legge]

Ioannis,
I have always thought that Thessalonika (sorry for dodgy spelling) was a wonderful name and was aghast at the ugly industrial developement around the place - how could you do that?

On to things Radio,

It seems to me that the views to date cover:

1. On a good link with high SNR, the SERIN command is OK for most purposes.
2. On a poor link, or at range limits, SERIN (even with 200, Lost_Signal and WAIT("!")) wont work.
3. Some communication systems overcome this by transmitting Data + Some additional bits to check the veracity and, in some case, provide error correction as well. For example CRC, Hamming code and so on.
4. In this case the receiver has to take all the received bits, find the start of frame, apply the checks - and take appropriate action.
5. This sort of complexity is now well known and used.

However, running SERIN2 RxPin, 200, Lost_Signal,[WAIT("!"), My_data] inside a stop-watch timed event would seem a simple and reasonably reliable way to overcome many radio link problems (the '200, Lost_Signal' achieves nothing unless the link is rock solid).

I think I will set up a radio loop and pass data around and run some tests:

1. Change the range to go from good to poor SNR.
2. Change data rates to determine BW issues.
3. Fiddle with the WAIT("XXXXXXXX").
4. Vary the stop-watch time.

And plot all this against error/error rates. I'll come back to you all in 2020 with the results - but I bet all this is already well tabulated somewhere!

Regards Bill Legge

[Acetronics2]

Hi Alain,

The RSSI output is definitely an option, but the difference in overall range has to be
considered. You can use this output for a squelch type circuit, and it's fairly reliable, but
it does have a significant impact on your overall wireless links range.

Hi, Bruce

I thought RSSI would be a nice info to enter a "strengthened check" routine , so that would not slow down the transmission into the "usable" range ...

Just used as a "Warning" info, if you understand me ...

Alain