RS232 by Radio

[Bill Legge]

Bruce,

Thanks, I've not yet tried out the code but it is exactly what I wanted. I note that you work at Renton - that's the place I get my LINX radio modules from - I am using the 433 MHz Long Range type - easy to use and reliable. Thanks

Melanie & Others

I am obviously not getting my point over. It would be a foolish person who claims an expertise in radio communications but I'm far from a beginner (but I am a relative beginner at PBP and Assembler stuff). I do understand data encoding, modulation, statistical nature of noise, error detection, error correction, CRC, Manchester encoding and lots of other aspects of telecommunication - it has been the area I've worked in for many years.

However, this does not make me right and you wrong but please, if you are interested, have a careful read of the following:

1. When in range my radio link works perfectly.

2. The code is SERIN2 RXPin, 200, Lost_Signal, [Wait(!), My_Data]

3. Now lets assume that the robot goes out of range.

4. The Rx module receives noise that causes the RxPin to leave the idle state.

5. The software now sits there and waits for a '!' and it will only arrive due to the random nature of noise (a very large number of monkeys typing away at random will, after a significant delay, accidentally type a '!'). The software grabs the gibberish that follows and some software can now deduce that it is gibberish and take appropriate action. For example using a Cyclic Redundency Check, look for some transmitted patern '101010' and so on.

6. But what I was looking for is a means of taking action BEFORE the noise makes a '!'

The cause of this difficulty is using the WAIT("!") approach and combinig it with the 200, Lost_Signal.

Lost_Signal is useful when there is a squeltch type noise suppression or the signal is way stronger than the noise and false triggers are not likely to occur.

WAIT("!") is useful to synchronise the Tx with the Rx.

I guess one just has to abandon the business of using WAIT("!") and instead grab everything the receiver gets and use error detection/correction to deal with the noise. Or use the stop-watch approach?

I was looking for anyone with experience in this area.

Regards Bill legge

[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