PDA

View Full Version : RX TX modules - intermitent communication



ruijc
- 8th June 2009, 18:29
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



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



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

dhouston
- 8th June 2009, 18:39
See my response in this thread http://www.picbasic.co.uk/forum/showthread.php?t=11285.

ruijc
- 9th June 2009, 16:29
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

dhouston
- 9th June 2009, 17:16
@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

ruijc
- 9th June 2009, 18:24
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 ;)

dhouston
- 9th June 2009, 20:10
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

ruijc
- 10th June 2009, 00:46
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


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


RX


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

dhouston
- 10th June 2009, 02:45
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.

dhouston
- 10th June 2009, 11:56
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.

ruijc
- 10th June 2009, 12:17
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 ;)


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


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



RX


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.

dhouston
- 10th June 2009, 12:34
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.

ruijc
- 10th June 2009, 13:29
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?



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 ?

dhouston
- 10th June 2009, 14:50
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.

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.

ruijc
- 11th June 2009, 00:13
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 :(