Communcation between PIC's using wireless RS232

[homfray]

Hi there, I have searched the forum and although there have been lots of similar questions no one has actually ever posted the answer so I will atempt to make sure this thread is seen to its conclusion.

I have two PICs and they communicate to each other via wireless RS232 (Easy Radio ER400TRS). The talker is just sending a letter and a carriage return (although I would like to send 2 letters in the future). The Listner waits for kbhit() does an fgets and then prints it out. Unfortunately the output comes out like this

Rcv_String = └

instead of

Rcv_String = Z

It must be sort of working because the fgets receives the carriage return and obviously must recognise it as it goes to the next line

any help would be appreciated

TALKER CODE

[newguy]

I've never used those particular radio modules, but I have done lots of RF comms between pics using their built-in USART.

The first thing you should consider is a warmup/lockon time. When the transmitter is not transmitting, the receiver will try to lock onto the strongest RF signal in its frequency band and demodulate it. Even if it's noise, it will still try to demod the noise. This means the receiving USART is getting a constant stream of digital "hash" noise, which the receiving USART will try to dig through for "valid" data.

You need to do things like this:
1. Transmitter power up.
2. Send a preamble - just a set of "disposable" characters. Also known as a LAM (look at me) signal. The purpose of the preamble is to allow the receiver's USART to lock on to this valid data, in other words, be able to distinguish valid start & stop bits, and sync the data clock.
3. Send an ID - something unique that only your product "knows" or uses to avoid interference with other RF devices.
4. Send the data. You may want to include an error check such as a CRC or, a quick & dirty easy way out: send the data, then send the inverse of the data (i.e. data 0xC4, inverse 0x3B).
5. Turn off the transmitter.

The complete sequence would be: Power up transmitter, wait x ms for the transmitter output to stabilize, then send the LAM (I read somewhere on this board that sending hex BABEFACE works well, and it really does.) Now send your ID code, perhaps "HITHERE" (in reality, only 3 characters are really needed in the ID code), then your data, then power down the transmitter.

On the receiver side, you'd be better off going with an interrupt driven receive. Look here for a recent example discussing this: http://www.ccsinfo.com/forum/viewtopic.php?t=23870

Just remember that on the receive side, you DON'T look for the LAM signal, only the unique ID of the transmitter. Use a state machine to "unlock" the receiver as the ID is recognized, then accept the next character(s) after the ID as valid data.

Don't hesitate to ask more questions if this doesn't make sense.

[Guest]

Thanks for the reply newguy!!

Look I feel like a bit of a thicky but I don't quite see what your saying, is there some example code for tx and rx PICS as I am unsure how exactly the LAM works in the Tx code and how the interupt works in the RX code (the example.

In the long run I will have one Tx PICS and many Rx PICS all the Rx PICS will hear what the Tx is transmitting but included in the transmission will be an unique identifier for each Rx PIC

Thaks for your help newguy!!

[homfray]

So I have worked on my code and I have limited sucess using the code below I now get some of the data (Tx sends 'Dave Rocks') and some garbage. Included is a capture of some of the output


> COM Port : COM5
> Baud Rate : 9600
> Data Bits : 8
> Parity : None
> Stop Bits : 1
> Hardware Flow Control : None
> Software Flow Control : None

Connected to COM5...

working4: rx_buffer[rx_wr_index]= €[
4: rx_buffer[rx_wr_index]= T¢
4: rx_buffer[rx_wr_index]=
4: rx_buffer[rx_wr_index]=
4: rx_buffer[rx_wr_index]= ÿ
4: rx_buffer[rx_wr_index]=
ave Rockser[rx_wr_index]= Dave Rocks
4: rx_buffer[rx_wr_index]=
4: rx_buffer[rx_wr_index]= €Á[
4: rx_buffer[rx_wr_index]= ’!!‰# @”À
4: rx_buffer[rx_wr_index]=
4: rx_buffer[rx_wr_index]=

@
ˆ`kser[rx_wr_index]=
4: rx_buffer[rx_wr_index]=
4: rx_buffer[rx_wr_index]=

ave
ˆ`ffer[rx_wr_index]= e Rocks

: rx_buffer[rx_wr_index]= Dave
ˆ`

ave
ˆ`ffer[rx_wr_index]= e Rocks

: rx_buffer[rx_wr_index]= Dave
ˆ`

ave
ˆ`ffer[rx_wr_index]= e Rocks

: rx_buffer[rx_wr_index]= Dave
ˆ`

ave
ˆ`ffer[rx_wr_index]= e Rocks

ave
ˆ`ffer[rx_wr_index]= e Rocks

: rx_buffer[rx_wr_index]= Dave
ˆ`

ave
ˆ`ffer[rx_wr_index]= e Rocks

: rx_buffer[rx_wr_index]= Dave
ˆ`

ave
ˆ`ffer[rx_wr_index]= e Rocks

: rx_buffer[rx_wr_index]= Dave
ˆ`

ave
ˆ`ffer[rx_wr_index]= cks

: rx_buffer[rx_wr_index]= Roc
ˆ`

ave Roc
ˆ`[rx_wr_index]= cks

: rx_buffer[rx_wr_index]= Roc
ˆ`

ave Roc
ˆ`[rx_wr_index]= cks

: rx_buffer[rx_wr_index]= Roc
ˆ`

ave Roc
ˆ`[rx_wr_index]= cks



Connection closed...

As you can see it is obviously picking something up.

Again any comments would be appreciated as I am not quite sure what newguy's clever code does completely

RECEIVE CODE

[Humberto]

homfray wrote:

[Guest]

Cheers Humberto

tried to add the Manchester encode/decode thingy and it has stopped givng me crap, it now gives me nothing. I suppose that is a noise improvement.

OK I am a bit of a newbie having never done anything like this before and wondered if anybody had any example code, the links you kind people are sending me are actually confusing me more than helping.

If I could just see an example of some code I could try to fathom what is going on.

What I really would like to do is the following

TX PIC: send two characters, i.e printf("XY\r")
RX PIC: listen when kbhit or #int_rda then receive those two characters on wireless rs232 stream and printf those characters to the screen using another stream

If I could just see a little code then maybe I can begin to understand whats happening, I would really appreciate any help.

thanks

dave

[Humberto]

Hi homfray,

Just copied and pasted -in blue- the following paragraph of my previous post to introduce you what I mean:

Lower AM transceivers requires a balanced signal. Sending unbalanced signals as ASCII chars, the demodulator (in the received side) would get biased improperly and blocked until another string of chars of oposite polarity would recover such situation.

The "clue" is that the "weight" of the equivalent '1' and '0' of your string must be equal. Sending binary ASCII signals over the RF link obviously won´t meet this requeriment.

A) Rigth way to solve this is using Manchester encoding. Not so easy for begginers.

B) A "dirt" an easy solution -if your packet is very short- is to send each ASCII chars precedded by an "balanced" char like 'U' whose binary equivalent is 0b01010101 in this fashion :
Your packet: "G021D"
Sending: "UUGU0U2U1UD"



If you want to send a short packet of bytes, (being short packet < 10) then you can use the "dirt or tricky way".
Start sending a burst of balanced char 'U' (0x55) as a preamble and to " biasing wake up" the RF receiver module.

[newguy]

Homfray,

Can't type long - the wife is bugging me to go somewhere. I didn't compile this code to see if it works - there may be some missing declarations & such, but I hope you see what I am doing. Try it, see if it works.

Transmitter code:

[homfray]

your a bloody good 'un. Let me try that tomorrow and will come back

Thanks newguy!!!!!!!!!!!
_________________
Nice!!!

[homfray]

Thought I would change the title to make it more appropriate

Guys, thanks, I really appreciate everything you have done, the code works perfectly and I can transmit on one device and recieve on the other. With this code it appears to be fairly easy to add extra recievers giving them individual addresses. Although I may have to use more standard names and data instead of 'dave rocks'.

The code below is only slightly different from newguys with a few minor errors corrected.

Thanks everyone for all your help I really appreciate the fact that you took your time to help someone you don't know!!!!


Transmitter Code:

[Guest]

I don't understand what u mean by unbalanced signals

[Ttelmah]

Visualise the letter 'A', coded in ASCII. The representation, is 0x41, and in binary 01000001.
There are two 1's, and six zeros. This is an 'unbalanced' signal. Unfortunately, if this is sent over simple radio systems, using direct signal transmission (rather than sending 'tones' to represent the bits), this results in the bias levels in parts of the recovery circuit shifting, and the radio becomes unable to correctly recover the data after a few such characters. Some characters are inherently 'balanced'. The pair that are balanced with the shortest period, are heximecimal 0xAA, and 0x55. The latter is ASCII 'U', which is why Humberto selected this. In general, most systems can handle a certain number of bits imbalance before it becomes a problem. If the radio can handle 8 bits without a problem, then you can use the trick of adding balanced 'padding' characters. You can also get the same effect, by sending each character twice, and inverting the second copy. So you send 'A' as 01000001 101111110. Unfortunately all these approaches waste a lot of signalling bandwidth (you are only receiving one character for each pair sent in either case). Manchester encoding, is a much more efficient way of doing this, but is fairly processor intensive, to code/decode.

Best Wishes

[Humberto]

[GUST1]

So is an unbalanced signal a physical problem or is it a software problem?
I'm still not clear. To make a balance signal, you would need the same number of 1's and 0's? I still don't see why having more 0's than one can cause a problem.

[david90]

i'm the same guy posted above. I was too lazy to log in.