How to improve data quality via Xbee

[Vizier87]

Hi guys,

I recently managed a rudimentary data transfer via Xbees, although with a hiccup here and there.

I transmitted 0xAA, a nice output stayed at the receiver via PORTD connected to eight LEDs.

But when I transmitted 0xBB, the receiver (LEDs lighting up) initially shows the data correctly for a few seconds, then somehow flickered and all the LEDs light up without responding to further transmission. It's like a "computer hang".

Anyway, here's the code (Transmitter: 16F877A, connected to a keypad, the polling is for the keypad switch)

while (1){

     if (rd3_bit==1 && trmt_bit==1){    
       txreg=0xaa;
     }
     
     if (rd2_bit==1 && trmt_bit==1){    
       txreg=0xbb
     }

   }

And here's the Receiver (18F4620, output at PORTD):

while (1){

    if (rcif_bit==1){
      portd=rcreg;  
    }
  }

Both of them are configured at a 9.6 kbps Baud.

Please advise, gurus?.

Thanks.
Vizier87

 

[Ian Rogers]

I am writing some code to "Manchester encode" the data before it is sent via RS232 and re-assemble at the other end... It's kinda finished... It works ok but when you use 0xAA for preamble its the same as "0" encoded... just needs a little work..... Do you want a "look see"

 

[Nigel Goodwin]

I am writing some code to "Manchester encode" the data before it is sent via RS232 and re-assemble at the other end

I thought Xbee did all that for you?, is he perhaps not setting it up correctly?.

 

[Ian Rogers]

Most possibly.... I use XRF modules (xbee format) and I get real good quality signals... I tend to go for 19200 baud.. I do get errors when I go at 115200..

 

[3v0]

I agree with Nigel. The data should be sent in packets complete with error checking. Any corrupted data is NAKed by the receiver and resent. You fellows are talking like you are using raw radio ?

 

[Ian Rogers]

No... I use packets and CRC's just like everyone else.. Start sequence.... data length... data... crc... Just a basic crc though.. I suspect Nigel's right about the OP not setting the modules up correctly.

 

[Nigel Goodwin]

No... I use packets and CRC's just like everyone else.. Start sequence.... data length... data... crc... Just a basic crc though.. I suspect Nigel's right about the OP not setting the modules up correctly.

If think you're missing the point?, why do you have to do that? - isn't Xbee an 'intelligent' system, and does all that for you, you just need to supply raw RS232 data.

I've never had any to play with, so I can't be sure - but I thought that was the idea of Xbee?.

 

[Ian Rogers]

I don't use xbee.. I use XRF modules.. The OP uses Xbee... I have used xbee in the past BUT there are two modes....AT mode where you must take the raw data approach and the API mode where the data is in a packet, and on a multi module net... the user must select the mode with the X-CTU program.

 

[cobra1]

I also use XRF modules, i find them a lot easier to use than the Xbee, so far i have no problems sending packets or raw data back and forth. maybe the Xbee is missing the data being sent somehow, the OP says its like a computer hang. If its missing data then it wouldnt get the whole command.

 

[Nigel Goodwin]

I don't use xbee.. I use XRF modules.. The OP uses Xbee... I have used xbee in the past BUT there are two modes....AT mode where you must take the raw data approach and the API mode where the data is in a packet, and on a multi module net... the user must select the mode with the X-CTU program.

As I said early on, it sounds like the OP isn't setting the module correctly - using raw mode, when he shouldn't be.

 

[binzer]

As I said early on, it sounds like the OP isn't setting the module correctly - using raw mode, when he shouldn't be.

From the XBee manual:
By default, the RF module operates in Unicast Mode. Unicast Mode is the only mode that supports
retries. While in this mode, receiving modules send an ACK (acknowledgement) of RF packet
reception to the transmitter. If the transmitting module does not receive the ACK, it will re-send
the packet up to three times or until the ACK is received.

 

[Vizier87]

okay thanks guys for the input. This'll take time.... okay here goes:

I am writing some code to "Manchester encode" the data before it is sent via RS232 and re-assemble at the other end... It's kinda finished... It works ok but when you use 0xAA for preamble its the same as "0" encoded... just needs a little work..... Do you want a "look see"

Thanks for the input. So do you suggest I increase the Baud as well?

I thought Xbee did all that for you?, is he perhaps not setting it up correctly?.

Which part does the Xbee configure? I thought the Xbee is just a direct on-off kinda thing without any processing capabilities?

I agree with Nigel. The data should be sent in packets complete with error checking. Any corrupted data is NAKed by the receiver and resent. You fellows are talking like you are using raw radio ?

So you mean "in packets" as in Manchester code or something right? This is something I need to delve deeper into.... Thanks for the input.

As I said early on, it sounds like the OP isn't setting the module correctly - using raw mode, when he shouldn't be.

By "setup" you mean it might be my circuit or the program? sorry, I do have some mixups here.

From the XBee manual:
By default, the RF module operates in Unicast Mode. Unicast Mode is the only mode that supports
retries. While in this mode, receiving modules send an ACK (acknowledgement) of RF packet
reception to the transmitter. If the transmitting module does not receive the ACK, it will re-send
the packet up to three times or until the ACK is received.

So what do you suggest that I do? Thanks binzer.


Thanks everyone for the input. Really appreciate it.

Vizier87

 

[Mike_2545]

I hope the OP knows X-Bee are 3.3 Volt modules.

 

[3v0]

Which part does the Xbee configure? I thought the Xbee is just a direct on-off kinda thing without any processing capabilities?

You are thinking wrong. Xbee has several modes. If you are doing peer to peer, default mode perhaps, what you put in one Xbee magically pops out the other.

But there is a lot more then a simple radio connection. It takes your data and encodes it and then decodes it on the other end.

All you have to do is provide raw data. Do not use manchester, error correction or packets in your micro controller code. Xbee does that for you.

Time to read the fine manual !

 

[Vizier87]

I hope the OP knows X-Bee are 3.3 Volt modules.

Yep I know that. I use regulators for that.

Anyway guys, call me Viz. OP sounds... urgh.

 

[Vizier87]

You are thinking wrong. Xbee has several modes. If you are doing peer to peer, default mode perhaps, what you put in one Xbee magically pops out the other.

But there is a lot more then a simple radio connection. It takes your data and encodes it and then decodes it on the other end.

All you have to do is provide raw data. Do not use manchester, error correction or packets in your micro controller code. Xbee does that for you.

Time to read the fine manual !

Alright man. Thanks for your info. The Manchester thingy sounds pretty "value addition-like" kinda thing... but oh well since you suggest I drop it. Anyway, it seems that the fluctuating power supply I made myself is probably the cause. Everything works fine now, Thank God.

Now I'm gonna do some data logging with these. Will come back soon if I have anything else.

Thanks, Folks!!!!

Vizier87.

 

[RichTheDude]

Glad to hear you have got it working

One thing I have noticed, is that you have no apparent de-bouncing on your input keys (unless you have done so in hardware with an RC and a 7414 or something).

Also I thought Xbee as already stated handles all the error correction and resending for you in the default peer to peer mode.

 

[Vizier87]

Glad to hear you have got it working

One thing I have noticed, is that you have no apparent de-bouncing on your input keys (unless you have done so in hardware with an RC and a 7414 or something).

Also I thought Xbee as already stated handles all the error correction and resending for you in the default peer to peer mode.

Yeah, I suspect the keypad button might have some "kickbacks" like you said. But only one button though.