API mode doesn't work correctly

Hi, I’m using a PIC (16F628A) with UART module which communicates with the Xbee-pro (802.15.4-Version 10CD) module (mode API enabled).

SETTINGS MODULE XBEE-PRO

Radio 1 (NI=BASE) Radio 2 (NI=REMOTE)
AP = 1 AP = 0
DL = 5001 DL = 5000
MY = 5000 MY = 5001

  • other settings default

ASSEMBLE PACKET

7E 00 0A 01 01 50 01 00 48 65 6C 6C 6F B8

CODE ASSEMBLER (routine transmission)

SEND
MOVLW 0x7E
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x0
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x0A
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x01
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x01
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x50
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x01
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x0
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x48
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x65
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x6C
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x6C
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0x6F
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS
MOVLW 0xB8
MOVWF TXREG
MOVLW .2
CALL DELAY_MS ; ROTINA PARA 2MS

	RETURN

PACKET RECEIVED BY ANOTHER MODULE XBEE-PRO (NI=BASE)
Connected to serial and read with the program X-CTU terminal.

7E 00 13 81 50 01 33 00 7E FE 3F FE FE EF FE FE DB F6 B6 B6 6F EE BE

I think this is the correct package:

7E 00 0A 81 50 01 24 00 48 65 6C 6C 6F 15

Data ASCii: “Hello”

I looked for it at forum but I have no idea about what is the problem. ¿Any idea?

What is wrong? Somebody help me?

Thanks very much!

I’ve spent some time staring at this, and I can’t work out what’s going wrong. Your original packet looks fine, and I see nothing obviously wrong with your source code.

My feeling is that whatever the problem is, it’s not showing up in the details you’ve given. Well, not to me anyway.

If it were me doing this, I’d try to set up the XBees to both be connected to PCs running X-CTU, and send the sample packet that way. By doing that, you’ll be able to see exactly what happens at both ends. If that setup works (and I would expect it to work unless there’s some problem with the device parameter settings), and if bad things still happen when the PIC is used, then it would look like a PIC-related problem rather than an XBee-related one. Either way, the experiment should reveal more in the way of clues.

SETTINGS MODULE XBEE-PRO

Radio 1 (NI=BASE) Radio 2 (NI=REMOTE)
AP = 1 AP = 0
DL = 5001 DL = 5000
MY = 5000 MY = 5001

  • other settings default

hello,
I think that both base and remote must be in API mode. In your parameter configuration you have base in api mode and remote in transparent mode

Hi John! I have not done this test. PC (Xbee) - PC (XBee) because I don’t have other conector module RS232.

Below the tests made:


Test 1 (API mode)


Radio 1 (NI=BASE) Radio 2 (NI=REMOTE)
AP = 1 AP = 0
DL = 5001 DL = 5000
MY = 5000 MY = 5001

  • other settings default

sent: 48 65 6C 6C 6F
Received: 7E 00 0A 81 50 01 31 00 DB F6 B6 B6 6F 50


Test 2 (AT - Transparent mode):


Radio 1 (NI=BASE) Radio 2 (NI=REMOTE)
AP = 0 AP = 0
DL = 5001 DL = 5000
MY = 5000 MY = 5001

  • other settings default

sent: 48 65 6C 6C 6F
Received: DB F6 B6 B6 6F


Test 3 (API mode)


Radio 1 (NI=BASE) Radio 2 (NI=REMOTE)
AP = 1 AP = 0
DL = 5001 DL = 5000
MY = 5000 MY = 5001

  • other settings default

sent: 7E 00 0A 01 01 50 01 00 48 65 6C 6C 6F B8
Received: 7E 00 13 81 50 01 33 00 7E FE 3F FE FE EF FE FE DB F6 B6 B6 6F EE BE

PS: All tests were made with 2 different PIC


Check below the routine of setting UART:


;setting send UART
BANK1
MOVLW B’10100100’ ;SELEÇÃO DE MODO ASSICRONO EM 8
MOVWF TXSTA
MOVLW .25 ;SELEÇÃO DE VELOCIDADE
MOVWF SPBRG
BANK0
MOVLW B’10010000’ ;UART HABILITADA
MOVWF RCSTA


do not really know what’s wrong!

thanks for answering!

Vitor

One more test

PIC connected to a PC. I sent “Hello” and received “Hello”.

Test successfully!

Packet sent: 48 65 6C 6C 6F
Packet receive: 48 65 6C 6C 6F

Concludes that the assembler code is correct! The problem is in XBee-pro.

Vitor Farias

Message was edited by: vmfarias

Well, I’m still puzzled. The data seems to be getting corrupted quite reapeatably. I did wonder about a baud rate mismatch, but I can’t see how that could happen while still leaving the checksums correct.

I guess what I’d suggest now is a nice note to the good folks at Digi support, referring them to this thread and asking whether there are any known issues with this firmware in this area.