RX TX modules - intermitent communication

Hi guys,

I'm starting to play with Rx/Tx modules.
I've bought a couple of Cy2198TR-a modules ( http://www.sure-electronics.net/rf,audio/GP-GC010.pdf ) and connected them to a couple of 16F88 pics.
I was able to communicate from pic to module, choose the channel and when transmitting/receiving i can see the Busy led on on both of them.

The transmitter is sending a simple message ( a 4 digit value ) every second.
The problem is the receiver side.
Sometimes skips messages, sometimes shows the entire message ( 4 digit value ), sometimes shows just on or two digits of the message.

Here is the code for the RX and TX:

RX

Code:

CCP1CON = %00000000 ' Disable CCP SSPCON.5 = 0 ' Disable SSP Module CMCON = %00000111 ' comparator off TRISA=%00010001 TRISB=%00000111 '***************************************************************************** 'DEFINEs '***************************************************************************** @ DEVICE PIC16F88, HS_OSC @ DEVICE PIC16F88, MCLR_OFF @ DEVICE PIC16F88, PROTECT_OFF DEFINE OSC 8 @ DEVICE PIC16F88, CPD_OFF @ DEVICE PIC16F88, LVP_OFF @ DEVICE PIC16F88, BOD_OFF @ DEVICE PIC16F88, PWRT_OFF @ DEVICE PIC16F88, WDT_OFF @ DEVICE PIC16F88, CCPMX_OFF '***************************************************************************** 'ADC DEFINE ADC_BITS 10 ' Set number of bits in result ( 8 or 10 bits ) DEFINE ADC_CLOCK 3 ' Set clock source (3=rc) DEFINE ADC_SAMPLEUS 50 ' Set sampling time in uS '***************************************************************************** ANSEL=%00000001 ADCON1=%10000000 'no Vref - Right Justify ADCON0=%11000001 '***************************************************************************** ' DEFINE LCD pins DEFINE LCD_DREG PORTB DEFINE LCD_DBIT 4 DEFINE LCD_RSREG PORTA DEFINE LCD_RSBIT 3 DEFINE LCD_EREG PORTA DEFINE LCD_EBIT 2 DEFINE LCD_BITS 4 DEFINE LCD_LINES 4 DEFINE LCD_COMMANDUS 2000 DEFINE LCD_DATAUS 50 '***************************************************************************** 'debug defines INCLUDE "modedefs.bas" DEFINE DEBUG_REG PORTB DEFINE DEBUG_BIT 3 DEFINE DEBUG_BAUD 19200 DEFINE DEBUG_MODE 1 DEFINE DEBUGIN_REG PORTB DEFINE DEBUGIN_BIT 2 DEFINE DEBUGIN_BAUD 19200 DEFINE DEBUGIN_MODE 1 '***************************************************************************** 'PINS adc var PORTA.0 'analog input in var PORTA.1 'n/a A2 var porta.2 'lcd A3 var porta.3 'lcd A4 var porta.4 'n/a pgm var porta.5 'n/a RsBit var porta.6 'xtal EBit var porta.7 'xtal BUT1 var portb.0 'button stat var portb.1 'reserved for buSY led2 var PORTB.2 ' in nc var PORTB.3 ' out lcd4 var portb.4 'Data pin for LCD lcd5 var portb.5 'Data pin for LCD lcd6 var portb.6 'Data pin for LCD lcd7 var portb.7 'Data pin for LCD '***************************************************************************** 'variables media var WORD 'average ME var WORD ' ps4 var WORD ' value var WORD 'value received ra var word MYDATA var word 'contants Row1 CON 128 'constant for LCD line1 Row2 CON 192 'constant for LCD line2 Row3 CON 148 'comstant for LCD line3 Row4 CON 212 'constant for LCD line4 cl con 254 'constant for LCD clear line clear '***************************************************************************** INCLUDE "lcdbarIN.bas" DEFINE LCD4X20 1 '*********************************************************** INIT: pause 400 lcdout $fe,1," TX demo " lcdout $fe,$c0," ... " pause 1500 debug $55 if but1=1 then goto chann endif man: high pgm me=0 for ra=0 to 15 adcin adc,value pause 50 me=me+value next ra me=me/16 media=me media=(media*/5000)>>2 lcdout cl,row1," adc ", dec value lcdout cl,row2," average ", dec media transmit: lcdout cl,row4,"transmiting - ",dec value ," "'change B1 for B2 debug $55,"ok", dec value dig 3, dec value dig 2, dec value dig 1, dec value dig 0 goto man chann: low pgm pause 50 while but1=1 debug $af, $00 wend goto man end

and the RX

Code:

CCP1CON = %00000000 ' Disable CCP SSPCON.5 = 0 ' Disable SSP Module ANSEL = %00000000 ' digital mode CMCON = %00000111 ' comparator off TRISA=%00111100 TRISB=%00000111 '***************************************************************************** 'DEFINEs '***************************************************************************** @ DEVICE PIC16F88, HS_OSC @ DEVICE PIC16F88, MCLR_OFF @ DEVICE PIC16F88, PROTECT_OFF DEFINE OSC 8 @ DEVICE PIC16F88, CPD_OFF @ DEVICE PIC16F88, LVP_OFF @ DEVICE PIC16F88, BOD_OFF @ DEVICE PIC16F88, PWRT_OFF @ DEVICE PIC16F88, WDT_OFF @ DEVICE PIC16F88, CCPMX_OFF '***************************************************************************** ' DEFINE LCD pins DEFINE LCD_DREG PORTB DEFINE LCD_DBIT 4 DEFINE LCD_RSREG PORTA DEFINE LCD_RSBIT 1 DEFINE LCD_EREG PORTA DEFINE LCD_EBIT 0 DEFINE LCD_BITS 4 DEFINE LCD_LINES 4 DEFINE LCD_COMMANDUS 2000 DEFINE LCD_DATAUS 50 '***************************************************************************** 'debug defines INCLUDE "modedefs.bas" DEFINE DEBUG_REG PORTB DEFINE DEBUG_BIT 3 DEFINE DEBUG_BAUD 19200 DEFINE DEBUG_MODE 1 DEFINE DEBUGIN_REG PORTB DEFINE DEBUGIN_BIT 2 DEFINE DEBUGIN_BAUD 19200 DEFINE DEBUGIN_MODE 1 '***************************************************************************** 'PINS a1 var PORTA.0 'lcd a2 var PORTA.1 'lcd led var porta.2 'n/a A3 var porta.3 'n/a A4 var porta.4 'n/a pgm var porta.5 'frequency RsBit var porta.6 'xtal EBit var porta.7 'xtal BUT1 var portb.0 'button1 stat var portb.1 'reserved for buSY led2 var PORTB.2 ' in nc var PORTB.3 ' out lcd4 var portb.4 'Data pin for LCD lcd5 var portb.5 'Data pin for LCD lcd6 var portb.6 'Data pin for LCD lcd7 var portb.7 'Data pin for LCD '***************************************************************************** 'variables media var WORD 'average ME var WORD ' ps4 var WORD ' value var WORD ' ra var word MYDATA var word 'contants Row1 CON 128 'constant for LCD line1 Row2 CON 192 'constant for LCD line2 Row3 CON 148 'comstant for LCD line3 Row4 CON 212 'constant for LCD line4 cl con 254 'constant for LCD clear line clear '***************************************************************************** INCLUDE "lcdbarIN.bas" DEFINE LCD4X20 1 '*********************************************************** INIT: pause 400 lcdout $fe,1," RX demo " lcdout $fe,$c0," ... " pause 1500 if but1=1 then goto chann endif man: high pgm me=0 lcdout cl,row1," adc ", dec value lcdout cl,row2," media ", dec media rec: debugin [wait ("ok"),dec4 MYDATA] lcdout cl,row4," " lcdout cl,row3," " lcdout cl,row4, "received - ",DEC MYDATA goto REC chann: low pgm pause 50 while but1=1 debug $af, $00 wend goto man end

Any ideas for this to occur ?

I thank in advance

See my response in this thread http://www.picbasic.co.uk/forum/showthread.php?t=11285.

Greetings dhouston,

thanks for the help!

I read your article and the Demo code.
To be honest i didn't understood some of the lines in the code and a bit of the article( being English as NOT my native language and just starting to learn comm/protocols and stuff...doesn't help ).

In your demo code you use Pulsin instead of Debugin or Serin and this makes me get confused.

I was looking for a simple approach where i could use the debugin/HSerin instructions.

Is there any other way for this to work ?

Thanks

@ruijc

I have added examples that use SerOut2 and SerIn2 but I have not tested these as I'm rather busy with a project of my own right now. They should be easier to follow.

The problem with using $55 or $AA (or a string of several) is that the receiver has difficulty distinguishing them from the normal noise it sees in the absence of a signal. Using a long pulse followed by a space (about half the length of the pulse) sets the receiver AGC and gives the receiver an easy to distinguish marker for the start of a transmission. Keeping communications packets short will help maintain DC balance

Thanks dhouston,

The Serin/Serout version looks good :) thanks

I understand your explanation for the Pulsout.

If i understood correctly... the problem is for the RX module distinguish the Data from noise, correct ?

Since the RX module will "see" the data transmition with the pulsout trick and grab it, after processing internally, it should give the message correctly to the pic.

Then why the Receiver pic needs to "Pulsin" the RX module?

I'm looking forward to test the SerIn version tonight ;)

Quote:

Originally Posted by ruijc

Then why the Receiver pic needs to "Pulsin" the RX module?

In effect, the receiver code waits for a pulse of sufficient length then calls SerIn2 to catch the message that follows the intervening space. IOW, the pulse is seen as a "start of transmission" marker by the receiver

Thanks for your time dhouston.

I've tryed the Serin2/Serout2 version but i couldn't receive any message :(

Since my modules work at 19200 i changed the code like ( the rest is the same as you posted ):

TX

Code:

SerOut2 tx,16416,["HELLO",10]

RX

Code:

SerIn2 rx,16416,[STR msg\5\10] lcdout cl,row4, "received - ",STR msg\5

I guess I should have looked at the datasheet for your modules but, based on your code in the first post, assumed they are ASK - they are FSK which changes things a bit. See Data Reception on p5 of the link you gave.

Since this is an FSK module that automatically outputs any valid RF input, there is no need for a sync pulse (or sync byte such as $55). However, you really need the first bit of each reception to trigger an interrupt to assure that you catch each byte. I haven't tried to keep up with the threads on Darrel's Instant Interrupts but you might find some example code there that will help you. Here's a link to an assembly language tutorial on interrupt driven RS-232 on a PIC. http://www.winpicprog.co.uk/pic_tutorial7.htm

The simplest route might be to use an MCU that has interrupt driven RS-232 built in. The ZX-328n (28 pins) from ZBasic <http://www.zbasic.net/> has a hardware UART as well as interrupt driven software UARTs (up to four, depending on speed - since you need 19200, it can only support one). It will handle all of this in the background, buffering the inputs automatically so that you do not miss any should they occur while your code is busy with something else.

The ZX-328n costs $10 although shipping cost may be significant if shipped outside the USA. The ZBasic compiler is free so the only additional cost is for a crystal and the components needed for the main RS232 interface (e.g. MAX232) needed for downloading the application code.

Since your modules are transceivers, another approach would be for the 'receiver' to send a signal to the 'transmitter' telling it to send the data. That way it doesn't arrive at random times.

Hi dhouston,

You are correct, these are FSK modules and they output automatically the data, that's why i had those questions made about the pulsin ;)

Quote:

However, you really need the first bit of each reception to trigger an interrupt to assure that you catch each byte.

True, but in this case i'm starting with a very simple Loop ( both RX and TX ). For now i'm not thinking Interrupts. Just need to get the data flowing correctly first and therefor i'm using just this :

TX

Code:

tx: debug "ok", dec value dig 3, dec value dig 2, dec value dig 1, dec value dig 0 gosub getvalue goto tx:

RX

Code:

rec: debugin [wait ("ok"),dec4 MYDATA] lcdout cl,row4, "received - ",DEC MYDATA goto REC

Still, i get the same simptoms...sometimes receive all digits, sometimes none, sometimes just one or two

Thanks again for all your help.

The $55 in your original code led me to think ASK. Using a pulse is better than $55 or $AA as sync bytes.

You will miss data that arrives while you are servicing the LCD. Another possibility is that the RF signal strength is marginal. leading to sporadic reception.

Quote:

You will miss data that arrives while you are servicing the LCD.

since the TX will jump to a label "value" to get ADC values,calculating average from 16 readings, could this compensate the lcd servicing you mentioned?

Quote:

Another possibility is that the RF signal strength is marginal. leading to sporadic reception.

Maybe i'm wrong here, but i'm starting to think of the possibility that having BOTH RX and TX modules on the same experiment board and having both antenas side by side is NOT the best idea.

Could this be an issue having them so close to each other ?

Quote:

Originally Posted by ruijc

since the TX will jump to a label "value" to get ADC values,calculating average from 16 readings, could this compensate the lcd servicing you mentioned?

Maybe - you might try adding a delay after TX to guarantee enough time. You might also limit LCD writes to only update the display if a value changes.

Quote:

Originally Posted by ruijc

Maybe i'm wrong here, but i'm starting to think of the possibility that having BOTH RX and TX modules on the same experiment board and having both antenas side by side is NOT the best idea.

Could this be an issue having them so close to each other ?

Possibly - it's difficult to generalize without technical details but the I have had problems sometimes when TX & RX were too close.

I've tryed both but had no positive results.

What bugs me is that i connected the busy output of both modules to a LED.

The receiver module's LED blinks the same as the TX module indicating that is receiving valid data...however the pic only displays sometimes some of the sent values digits :(