RX TX modules - intermitent communication

[dhouston]

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]

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]

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]

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]

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]

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]

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 ?