433MHz RF PIC2PIC connection

I'm using a 18F452@20MHz to collect data from several sources.
Once a "full data-set" has been collected it is transmitted via a standard 433MHz TX-Module.

The "Remote-PIC" (18F252@20MHz)) is connected to a 433MHz RX-Module
and picks up the data to display it on an LCD.

I have got the Manchester Encoding/Decoding, Timing, Balancing and CRC working.

With a simple lambda/4 antenna I get the required range
and at the given Bandwith of the RF-Modules
I get a reliable communication at 1200 Baud.

The Problem:

The RX-Module Data output pin idles LOW, so Im using TRUE polarity (Mode $432D).

As long as my transmitter sends data continuously I receive the data errorfrree on the remote PIC.

If the transmitter does not send data for about a minute or more the Receiver hangs
(sitting in the SERIN2 Statement)

-------------------
Serin2 Rxpin,Baud,TimeOut,NoInput,[Wait(Synch),STR RX\50\13]
-------------------

To me it looks like RF noise is causing that problem.
With no noise (RX data pin low) the SERIN2 Timeout works fine
and the Program does what it is expected to.

As there will always be noise on 433MHz I verify the received data
using CRC and discard invalid telegrams.

If a random sequence of bits (Noise) is received it hangs and only a MCLR helps to restart it.

How to solve that "hanging problem"?

regards:

Ralph

In the meattime I have tried exactly the same code on a 16F876A (same PCB) and it works just fine.

It looks like I have discovered yet another "Feature" of the 18F252.

Has anyone experienced similar SERIN2 problems on the 18F252?

regards

Ralph

>>I have got the Manchester Encoding/Decoding, Timing, Balancing and CRC working.


I have tried something similar but without Manchester coding. How does this coding work with these kind of wireless application?

I used a 16F877A to send out data to a 628. Used Laipac TLP-916 RF modules. Works at about 14400 baud rate. At least thats what I think I have set it to. But here is the problem. Every once in awhile, I lose my data and it will stop at what was displayed earlier then continues with the reading when it gets signal.

Will Manchester coding help solve this problem? I would like to try this coding to see if there is any different.

Hi Ralph,

> The RX-Module Data output pin idles LOW, so Im using TRUE polarity (Mode $432D).

$432D or 17197d is actually inverted mode, but that's what you want anyhow if the receiver output idles low.

The problem with using inverted mode with SERIN2 and the timeout/label options is that positive going noise spikes on the serial input pin will *reset* the timeout period, and execution never jumps to the timeout label since there appears to be valid serial data inbound before the timeout period can expire.

I find sometimes just adding a 100K pull-down resistor to the receiver output helps reduce noise to a level that allows the timeout period to expire. If this isn't enough I may shift to an input pin on portc with Schmitt trigger input buffers to help cancel the noise spikes output by the receiver.

The input pin with the Schmitt trigger buffer is less suceptible to noise than TTL inputs. Most PIC peripherals like RB0/INT, CCP, and several others are Schmitt trigger buffered inputs to keep noise from triggering the peripheral functions.

You don't mention which pin you're using on the 18F or 16F parts, but that may be why it works on one, and not on the other?

Quote:

---

Originally posted by actionplus
. . . used Laipac TLP-916 RF modules.

---

I got my tramsmitter and receiver modules out of a $5 Euro wireless doorbell.

To get a reliable data-transfer you should manchester encode your data.

Manchester Coding has already been discussed, see:
http://www.picbasic.co.uk/forum/show...ght=Manchester

You should also send a "Preamble" before you start data transfer.
$55 or $ AA 5 to 10 times before your Data is transfered.
$AA is %10101010, $55 is the inverse.

this allows the receiver to "settle"

Choose someting similar for your "SYNC" String or Character
($6A, %01101010 or $D5 %11010101)

All this is required because we are using the most simple way of RF transmission to asynchronuosly transfer data.
(By simply turning the transmitters carrier ON for a logical "1" and OFF for a logical "0"

Guess what a $FFFF or $0000 would result in

regards

Hello Ralph,

Its great to see you back.. Hope you had a safe and pleasant sail...

Ralph>>I got my tramsmitter and receiver modules out of a $5 Euro wireless doorbell.<<

Oooohh... I LIKE that.. I could use one of those myself... Which one?

Dwayne

>>... Hope you had a safe and pleasant sail...

Thanks, I had.

And while sailing I thought it would be nice to have a wireless (waterproof) NMEA Data Repeater.

Ralph>>I got my tramsmitter and receiver modules out of a $5 Euro wireless doorbell.<<

>>Oooohh... I LIKE that.. I could use one of those myself... Which one?

I'm almost sure all those cheap wireless doorbells made in Hongkong use the same standard 433MHz RF Modules.

Best regards:

Ralph

BRUCE,

thanks for your reply.

You are right, $432D is INVERTED but anyway this is correct with the RF Module (IDLE LOW).
(I always mix the definitions up)

I have the RF Receiver connected to PortC.4 and I have a 4k7 PullDown on that Port.
(I have tried different Chips and different Ports)

The TimeOut is set to 1000ms.

It doesn't seem to be an issue of the Timer being reset, I have a scope on the TTL Output of the RF-Module and the Port stays low for more than a second so that the timer should expire and it should jump to the TimeOut Label.
Once the PIC "hangs" I can even disconnect the receiver, and Pull C4 permanently LOW, it still hangs. I really have to "RESET" the device.

Program execution stops always after a few Bits from other RF devices have been received during the time my transmitter is idle.

i.e. people locking/unlocking their vehicles.

If I let my transmitter transmit data continously the 18F works fine.
(worst case I get some CRC errors if there was "noise")


The strange thing is that exactly the same configuration works perfect on a 16F876.

I would move to the 16F876, but I need the memory of the 18F252.

regards:

Ralph

Hi Ralph,

I know the 18F series are pretty suceptible to noise in general, so that may be what's happening. Are you using 0.1uF caps from the PIC Vcc & gnd pins with the cap located as close as possible to the pins? Is your power supply clean & stable?

A while back several other folks mentioned similar problems when migrating from 16F parts to 18F parts. I have never had this problem with any 18F parts, but you're definitely not alone.

Bruce,

sure I have 100n Caps next to the Chips and the Powersupply is as clean as it can be.

I don't think it is a "noise in general" problem, if I leave the hardware setup as it is and just comment that "SERIN2" line out the 18F never stops.

I have had some problems when I did my first migration from 16F876 to 18F252.
After I had sorted that out I felt the 18F is a nice pin-compatible replacement for the 16F.

But it looks like if you want your product to be robust and reliable stay away from the 18F's.


regards:

Interesting. Just out of curiosity, have you tried something like this?

Leaving everything pretty much as-is, create a short sub-routine and use any available I/O-pin to just blink an LED in an endless loop.

Leave the RF receiver connected, send data with your transmitter just like you were before, but on the receiver side just jump around the SERIN2 routine directly to the LED blinking loop.

Inbound data will still be banging on the serial input pin, and creating in-circuit noise.

Does it lock-up or hang in the LED blink loop requiring the hard reset on /MCLR?

Now try the same thing, but without the the receiver in the circuit. Does it hang in the LED blink loop after removing the RF receiver?

Bruce, what I have just tried is:

I disconnected the data pin from the receiver and transmitter
and replace the RF-link with a wire.
I turned the transmitters power off.

And guess what: Still the same problem.

I will now try the things you mentioned.

thanks for your help !

Bruce,

jumping around the SERIN2 statement has the same effect as commenting it out.
(It will not be executed)

and all available ports are blinking LEDs on and off nicely.
(Even with the RF transmitters antenna bound around the 18F)
(I can't produce much more RF noise on the 18F, can I)

It is SERIN2 that is causing a problem on the 18F, not RF or any other noise.

This is probably the time to start a new thread: "18F252 SERIN2 problems"

Hello Ralph,

this may seem off the wall, but Have you tried changing your SERIN2 "Filtercheck" to something different?

Dwayne

Dwayne,

I have tried almost everything, starting from a single Byte up to 32 Bits (different patterns).

And I have run all examples on the 16F as well as on the 18F.

They have all been working fine on the 16F but not on the 18F.

regards

Ralph

> jumping around the SERIN2 statement has the same effect as > commenting it out.
> (It will not be executed)

Of course it won't be executed either way, but commenting out the SERIN2 line significantly reduces your compiled code size.

> and all available ports are blinking LEDs on and off nicely.
> (Even with the RF transmitters antenna bound around the 18F)
> (I can't produce much more RF noise on the 18F, can I)

Definitely rules that one out..;o]

> It is SERIN2 that is causing a problem on the 18F, not RF or any > other noise.

That's what I was curious about. It sounds like you've already isolated it to SERIN2.

> This is probably the time to start a new thread: "18F252
> SERIN2 problems"

Not a bad idea. I have an 18F252 Flash-Stick setup with an RF receiver, but it's coded in C. I'll switch to PBP using SERIN2 and see if I can force the same problem.

Hi Ralph,

I've tested this routine on 3 controllers, and SERIN2 works equally well on 16F or 18F parts.

PBP v2.45a
20MHz
PIC16F876A
PIC18F252
PIC18F452

X VAR BYTE

MAIN: ' 9600 bps INVERTED
SERIN2 PORTB.2,16468,1000,Loop,[WAIT("A"),X]
GOTO Main

Loop:
HIGH PORTB.0
PAUSE 250
LOW PORTB.0
GOTO MAIN

No serial input on RB2. Pull RB2 LOW -- the LED on RB0 blinks. Pull it HIGH -- the LED never blinks.

I get the same results with any timeout value.

Hi Bruce,

could you define X as VAR BYTE(32)
and try to read a String of 32 bytes in the SERIN2 statement?

I haven't had any problems reading a single byte,
it looks like reading a string to an array of bytes causes the problem.

thanks again for your effort.

I will re-arrange my hardware tomorrow and try HSERIN.

ragards

Ralph

Hi Ralph,

Done. Works perfectly.

Receiving on 18F452

DEFINE OSC 20
DEFINE LOADER_USED 1
myVar VAR byte[32]


BEGIN:
SERIN2 PORTB.0,16468,1000,TIME_OUT,[STR myVar\32\13]
HSEROUT [STR myVar\32,13,10] ' Display result
CLEAR ' Clear array
GOTO BEGIN

TIME_OUT:
HSEROUT ["Time Out",13,10] ' Indicate timeout
GOTO BEGIN

Sending with 16F876A

DEFINE OSC 20
DEFINE LOADER_USED 1

BEGIN:
SEROUT2 PORTB.0,16468,["-- Hello there this is a test --",13]
PAUSE 1000
GOTO BEGIN

18F452 connected to PC serial port returns the following in MCS+ terminal program: -- Hello there this is a test --

Dissconnect 16F876A from 18F452 serial input, ground 18F RB0, returns Time Out. Float or take RB0 HIGH, sit & spin in the SERIN2 line.

Tried similar routines via RF. Still works flawlessly. Tossed in a few bytes to DC balance the receiver data-slicer, but I get similar good results.

Ran same tests with the WAIT modifier. Same results.

' RX
DEFINE OSC 20
DEFINE LOADER_USED 1
myVar VAR byte[32]

BEGIN:
SERIN2 PORTB.0,16468,1000,TIME_OUT,[WAIT("X"),STR myVar\32\13]
HSEROUT [STR myVar\32,13,10]
CLEAR ' Clear array
GOTO BEGIN

TIME_OUT:
HSEROUT ["Time Out",13,10]
GOTO BEGIN

' TX
DEFINE OSC 20
DEFINE LOADER_USED 1

BEGIN:
SEROUT2 PORTB.0,16468,["X-- Hello there this is a test --",13]
PAUSE 1000
GOTO BEGIN

I suspect something else may be causing your headaches.

Hi Bruce,

first of all many thanks for all the time you have spent to help finding a solution to the problem!

After I had cut down my code to the absolute minimum I have solved the problem.

It was just a few lines of stupid code.

Here ist a short code example that forces a lock-up of the 18F252 after 29 successful loops.

' 8< ---------- snip
DEFINE LOADER_USED 1
DEFINE OSC 20

Loop:

gosub Test

Test:
HIGH PortA.0
Pause 300
low PortA.0
pause 300
goto loop
RETURN

END
' snap ---------- >8

It is calling a subroutine using GOSUB and jumping out of that subroutine using GOTO before the end (RETURN) of the subroutine is reached.

But there is still the question why there is no problem with this code on the 16F876.

regards

Ralph

Hi Ralph,

Using GOSUB to call a sub-routine that returns to the calling routine with a GOTO VS a RETURN eats up your stack since there is no RETURN instruction to POP the return address back from the stack. You end up with stack over-flow.

On the 16F series you have an 8 level deep stack, and once it's filled up, it starts being over-written (circular type buffer) by further return addresses pushed onto the stack from top-to-bottom.

While your program may or may not work on a 16F part when doing this, it can still cause trouble depending on how many consecutive calls you have before returns start (referred to as nesting) popping addresses back off the stack.

You have return addresses being pushed onto the stack by PBP library functions + your own code. With the 16F's circular type stack buffer, you're getting by with the boo-boo because return addresses are still being pushed on the stack (simply overwritting previous contents), and all's well if you're not nesting calls too deep.

One the 18F parts you have a 31 level stack, BUT, it's not the circular type buffer like you have with the 16F. Once you get to location 31 the 32nd return address simply overwrites location 31,
and it's sit & spin at location 31 from there on.

I.E. you're now stuck at the last stack level, and nothing else can be pushed onto the stack leaving you with only "1" stack position where a return address is stashed to any caller.

Your program gets shot-off into la-la land somewhere, and goes haywire. Basically, it goes like splat...;o]

>>forces a lock-up of the 18F252 after 29 successful loops<<

That's why the above happens. You're OK until you hit that magic number on the 18F.

TIP:
You can use the STVREN config bit on the 18F series to help you find bugs like this, and force a device reset on stack overflow/underflow conditions.

Hello Ralph,

Can You Please Share Ur Code For The 16f Series Mcu. I Am Facing Some Problem In Rx Data Over Rf Using 2400.

Would Be Grateful If You Could Include Your Manchester Coding Bit As Well.

Thanks