RS232 by Radio

[Bill Legge]

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

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

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

[Bill Legge]

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

[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

[Ioannis]

What happens when leaving the idle state without Tx sendind?

Do you have any data in your variable?

Ioannis

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