RS232 by Radio

Printable View

- 2nd March 2009, 06:24
Bill Legge

RS232 by Radio

I'm passing data in RS232 format by 433MHz radio modules.
All is working OK but I need some advice on handling lost communications.

My code is:

SERIN2 RXPin,16780,200,Lost_Signal,[WAIT("!"),HEX2 My_Data]

And it works OK from PIC to PIC by wire:
1. Unless RXPin changes from the idle state in 200mS, the code at Lost_Signal will execute.
2. The data always starts with ! so the transmitter and receiver get synchronised.
3. The transmitter repeats it's message every 50mS so the receiver will
wait until 4 messages have been missed before executing Lost_Signal.

However, it does not work when passed by radio:
1. The receiver, even when the transmitter is turned off, receives noise.
2. The noise causes the code to leave the idle state.
3. But the ! is not received because the transmitter is off.
4. The receiver is supposed to work like this.

I'm using a PIC877 and think I need a 'background clock' and some interrupt routine? Can I use TIMER0, TIMER1 or TIMER2 - or are these used by the PBP is the SERIN commands?

Any advice please

Regards Bill Legge
- 3rd March 2009, 00:20
Squibcakes

Bill,

You may want to try sending a repetitive bit stream at the start of every sentance, eg AAAAAAAAAAAAA0000h to 'wake' the receiver up. Then send the !sentance.

Just have the receiver sit in a loop waiting for the sync stream before grabbing the actual !sentance.

Code:

Lost_Signal: SERIN2 RXPin,16780,200,Lost_Signal,[WAIT("A000"),HEX2 My_Data] SERIN2 RXPin,16780,[WAIT("!"),HEX2 My_Data]

Play around with the length no of bytes in the sync stream to fine tune the timing.

Squib
- 3rd March 2009, 02:49
Bill Legge

RS232 by Radio

Squibcakes?

Thanks for your reply. I don't think it will solve my problem because:

1. My problem is not achieving reliable communications but achieving a reliable alarm on LOSS OF COMMUNICATIONS.

2. The radio receiver is on a robotic vehicle and the aim is to ensure that the motors are turned off on loss of radio contact.

3. Whilst in radio range my current simple SERIN and WAIT "!" work fine.

4. But when it's out of range the radio receiver passes noise to the PIC and so the RxPin leaves the "idle state" and the "Lost_Signal" code is never activated. And the SERIN command just hangs waiting for a "!" transmission.

A solution would be to:

1. Start TIMER1 and enable interrupts.
2. Wait for a "!" then grab the message then disable interrupts.
3. If TIMER1 overflows and the interrupt occurs - execute the "Lost_Signal" code.

All this is a guess on my part and I'm trying to see if anyone has had some success with reliable "lost communications" routine when the receiver passes noise to the PIC.

If I have misunderstood your suggestion - sorry?

Regards Bill Legge
- 3rd March 2009, 06:47
Squibcakes

So why not have the transmitter send a '!do_nothing' type command continuously while not under command? This will cut out the noise when in range.

If the robot is out of range, it wont pick up this '!do_nothing' command and then just stop the motors in your out of range sub.

Then keep looping around your out of range subroutine waiting for the '!do_nothing' command to come back.

Try and keep things really simple. Adding timers + interrupts just add another layer of crap that make things more complicated then they need to be.

Cheers
Squib
- 3rd March 2009, 08:45
Ioannis

What happens when leaving the idle state without Tx sendind?

Do you have any data in your variable?

Ioannis
- 3rd March 2009, 09:12
Melanie

Radio Communications is a big subject.

You can't just get a Radio Module and squirt Async Data into the IN pin of a Transmitter and expect it to fall out of the OUT pin on the Receiver. If you are doing that, then you're already on the losing team.

AM is worse for Data than FM (just figure the way the Modulation works to discover why it is more susceptible to noise). If you're simply keying the carrier (CW) then again you're on the losing team for Data transmission.

Our ancestors discovered this and invented FSK, AFSK, PCM etc etc along with all kinds of packet protocols to ensure long-range Data integrity. So what are you using? Open up an RS232 Wireless Data Modem and you will find it stuffed full of filters and additional Modulation Hardware. I would lay money on the fact you've got a PIC, a Transmitter Module (and the opposite at the Receive end) and very little else in your design.
- 3rd March 2009, 09:43
Ioannis

It is obvious Melanie that there is no data integrity check of any kind there,

So it is obvious too, that Bill needs a lot of reading and experimenting onthe subject, which is difficult by default.

Bill, these modules needs DC balancing. This is what Melanie is telling you. If you don't know or want to do that then choose any other module that is doing it inside the can box. There are some for treu RS-232 communication.

Otherwise you must have to do that using Manchester encoding-decoding along with some kind of error check code.

Start slowly, searching the forum. All are there. But give some more details on the project.

Ioannis
- 3rd March 2009, 18:14
Bruce

Quote:

A solution would be to:

1. Start TIMER1 and enable interrupts.
2. Wait for a "!" then grab the message then disable interrupts.
3. If TIMER1 overflows and the interrupt occurs - execute the "Lost_Signal" code.

That approach works. I've done this in an old project for a momentary RF decoder.

This is just a small chunk, but it shows enough to get the point across...;o}

Code:

ASM RESET_VT movwf wsave ; Save W swapf STATUS,W ; Swap STATUS to W (swap avoids changing STATUS) clrf STATUS ; Clear STATUS movwf ssave ; Save swapped STATUS movf PCLATH,W ; Move PCLATH to W movwf psave ; Save PCLATH movf FSR,W ; Move FSR to W movwf fsave ; Save FSR ; Do interrupt stuff here bcf T1CON,TMR1ON ; Stop Timer1 clrf TMR1L ; Clear low byte clrf TMR1H ; Clear high byte bcf PIR1,TMR1IF ; Clear Timer1 interrupt flag bit clrf GPIO ; Clear outputs on button release clrf MATCH ; Clear match variable ; Restore FSR, PCLATH, STATUS and W registers movf fsave,W ; retrieve FSR value movwf FSR ; Restore it to FSR movf psave,W ; Retrieve PCLATH value movwf PCLATH ; Restore it to PCLATH swapf ssave,W ; Get swapped STATUS value (swap to avoid changing STATUS) movwf STATUS ; Restore it to STATUS swapf wsave,F ; Swap the stored W value swapf wsave,W ; Restore it to W (swap to avoid changing STATUS) bsf T1CON,TMR1ON ; Re-enable Timer1 before exiting interrupt handler retfie ; Return from the interrupt ENDASM MAIN: ' Fire up Timer1 before entry to serial input routine T1CON.0 = 1 ' at 4MHz Timer1 overflows in ~65.5mS if no Synch byte ' and serial data arrive before over-flow. ' Wait for Synch byte, then get new inbound data & checksum SERIN2 D_IN,BAUD,[WAIT(Synch),DAT_IN1,DAT_IN2,CHK_SUM] T1CON.0 = 0 ' Stop Timer1 once data has been received TMR1L = 0 ' Clear low byte TMR1H = 0 ' Clear high byte ' / **** Begin data validation **** /

You'll want to use an assembly interrupt since on interrupt would hang waiting for the
SERIN2 routine to finish.
- 4th March 2009, 07:28
Bill Legge

RS232 by Radio

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
- 4th March 2009, 08:20
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
- 4th March 2009, 10:00
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
- 4th March 2009, 10:16
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.
- 4th March 2009, 12:33
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
- 4th March 2009, 14:15
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?
- 4th March 2009, 16:22
Ioannis

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

Ioannis
- 4th March 2009, 16:38
Acetronics2

Hi,

I catched that on Bruce's site ...

Quote:

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
- 4th March 2009, 16:54
Bruce

Quote:

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.
- 4th March 2009, 17:11
Bruce

RSSI output

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.
- 5th March 2009, 01:21
Bill Legge

RS232 by Radio

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
- 5th March 2009, 09:01
Ioannis

Quote:

Originally Posted by Bruce

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.

The purpose of the modules was to replace the ones I used to get from Aurel or other pin compatible from Asia. I managed to make it cheaper and equally sensitive fore the use onGarage door openrs or other similar short range devices. Freq. is 433.92MHz and sensitivity around -105dBm for 4KHz BW or -109 for 1KHz. Including the SAW filter in the antenna path. Chip used T5744 and on the newer ones TDA5200 with 3db less.

Quote:

Originally Posted by 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?

Well, I still believe it is one of the best cities for the advatage of combining Sea and Mountain in the reach of your hand. Unfortunately, people deserve the leaders they vote for...

Now on the subject, I think you must give a try to the easier Darrel's Instant Interrupt and when interrupt happens, go there and see if the character was the ! or any other usefull data.

In this case you need the USART of he PIC and the Hserin command. The code will not spend much of the time waiting for the character as Melanie stated, it will be done on the background leaving the main routine to do what is supposed to do.

Ioannis
- 5th March 2009, 09:35
Acetronics2

Why do it simple, eh ????

Quote:

Originally Posted by 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.

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
- 5th March 2009, 15:16
Bruce

Hi Alain,

Quote:

I thought RSSI would be a nice info to enter a "strengthened check" routine

You're 100% right. It does.

Ioannis,

Thanks. I'll have to snoop around on your website....;o}