Hi everyone. My question is.
when I send a bitstream at 19.2k in tx xbee chip802.15.4
the data is 000000FFFFFF000000FFFFFF000000…(repeat)
but from rx xbee , I received the data is 0000FFFF0000FFFF…(repeat)
XBEE Baud rate is 19.2k
so what’s the reason?
Why is the rx data different from tx data?
instead of a bit stream, show us what was in the bytes you sent.
Also, beware of PC terminal program, if that’s what you’re using, as it may be in an ASCII text mode and you are trying to send 8 bit bytes. Also watch the XBee setup, ASCII mode, where XON, XOFF and other ASCII characters get special processing.
this is code to transmit 8 bytes data repeatly. And I can see the data from PIC is right on oscillatescope. But when it is input into TX xbee, data from RX xbee is not correct.
and I see its rx data in xbee X-CTU and serial communication port assistant. yes .the data is ascii, but I also can choose hex format. But I think oscillatescope is more clear to see the data wave. so I use oscillatescope.
code in pic to transmit data.
list p=16F877 ; list directive to define processor
#include <p16f877.inc> ; processor specific variable definitions
; '__CONFIG' directive is used to embed configuration data within .asm file.
; The labels following the directive are located in the respective .inc file.
; See respective data sheet for additional information on configuration word.
; __CONFIG _CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _HS_OSC
; & _WRT_OFF & _LVP_OFF & _CPD_OFF
;C0 IS CLOCK INPUT
;C1 IS BIT DATA INPUT
;***** VARIABLE DEFINITIONS
w_temp EQU 0x7D ; variable used for context saving
status_temp EQU 0x7E ; variable used for context saving
pclath_temp EQU 0x7F ; variable used for context saving
;TempCounter EQU 0xBC
;BitCounter EQU 0xBB ; vairable address used for bit conter
ByteCounter EQU 0xBD ;address used for byte counter
;**********************************************************************
ORG 0x000 ; processor reset vector
goto Main ; go to beginning of program
;**********************************************************************
; isr code can go here or be located as a call subroutine elsewhere
ORG 0x004 ; interrupt vector location
movwf w_temp ; save off current W register contents
movf STATUS,w ; move status register into W register
movwf status_temp ; save off contents of STATUS register
movf PCLATH,w ; move pclath register into w register
movwf pclath_temp ; save off contents of PCLATH register
movf pclath_temp,w ; retrieve copy of PCLATH register
movwf PCLATH ; restore pre-isr PCLATH register contents
movf status_temp,w ; retrieve copy of STATUS register
movwf STATUS ; restore pre-isr STATUS register contents
swapf w_temp,f
swapf w_temp,w ; restore pre-isr W register contents
retfie ; return from interrupt
Main:
banksel TRISC
bcf TRISC,6 ;c6=0 as output
bsf TRISC,0 ;c0=1 as input
bsf TRISC,1 ;c1=1 as input
; UART module setup
banksel SPBRG
movlw 15 ; rs232 baud as 20k
movwf SPBRG ; Enable SPBRG register Baud Rate
banksel TXSTA ; Select memory bank for TXSTA SFR
bcf TXSTA,TX9 ; 8-bit transmission
bsf TXSTA,TXEN ; Enable Transmission
bcf TXSTA,SYNC ; Asynchronous mode
bsf TXSTA,BRGH ; High Baud Rate
banksel RCSTA
bsf RCSTA,SPEN ; Enable Serial port
bsf RCSTA,CREN ; Enable Receiver
; *******************save data in pic*******************************
SaveData
bsf STATUS,RP0 ;bank 1
movlw 0xFF
movwf 0xBF
movlw 0x00
movwf 0xC0
movlw 0xFF
movwf 0xC1
movlw 0x00
movwf 0xC2
movlw 0xFF
movwf 0xC3
movlw 0x00
movwf 0xC4
;*********************transmit data new ******************************
TransData:
MOVLW 0xBF
MOVWF FSR ; TO RAM
MOVLW 0x06
MOVWF ByteCounter ; ChannelCounter=6
GoOnTransData:
banksel PIR1
btfss PIR1,TXIF ;TXIF=1, TXREG is empty,skip
goto GoOnTransData ;wait for TXIF=1
banksel TXREG
MOVF INDF,0
MOVWF TXREG ; Move the data to the transmit register
INCF FSR,1 ; INDF address number moves next
BSF STATUS,RP0
DECFSZ ByteCounter,1 ; ChannelCounter-1
goto GoOnTransData ; go on
goto TransData
;FinishData:
;goto FinishData
END
;*********************transmit data finish******************************
No doubt, you have a good rationale for using assembly language rather than C.
Sorry, I don’t have the patience to pore over the asm code.
My question is the PIC output is correct,and I can see it. So I refer that the problem is in xbee chip. So I guess that maybe I didn’t use it correctly.
Hi Stevech,
“watch the XBee setup, ASCII mode, where XON, XOFF and other ASCII characters get special processing” Can you explain it for me? Your help is really appreciated.
stevech:
instead of a bit stream, show us what was in the bytes you sent.Also, beware of PC terminal program, if that’s what you’re using, as it may be in an ASCII text mode and you are trying to send 8 bit bytes. Also watch the XBee setup, ASCII mode, where XON, XOFF and other ASCII characters get special processing.
Obvious question: have you tried it at a slower baudrate?
You’re going at a fast rate, and while your receiver is getting data, those data aren’t right. If it works properly when you slow it down, you narrow down considerably the possibilities for the source of the problem.
thanks. I will try.then tell you results.
another question. can you explain xbee communicate theory? When it transmit data, it also can receive data? so when it receives data, the data it wants to send will be stored in buffer temporary? Then it received data is finished, then it will continue sending data.
sylvie369:
Obvious question: have you tried it at a slower baudrate?You’re going at a fast rate, and while your receiver is getting data, those data aren’t right. If it works properly when you slow it down, you narrow down considerably the possibilities for the source of the problem.
ceibawx:
thanks. I will try.then tell you results.another question. can you explain xbee communicate theory? When it transmit data, it also can receive data? so when it receives data, the data it wants to send will be stored in buffer temporary? Then it received data is finished, then it will continue sending data.
sylvie369:
Obvious question: have you tried it at a slower baudrate?You’re going at a fast rate, and while your receiver is getting data, those data aren’t right. If it works properly when you slow it down, you narrow down considerably the possibilities for the source of the problem.
see 802.15.4
buffering: this is written about in Digi’s technical manuals.
Buffering relies on flow control and that is also described by Digi: either XON/XOFF or CTS in hardware.
Finally I found some reasons.
Firmware should be 10CD. I downloaded it. Then it did work.
But now on pcb board, the RX XBEE doesn’t talk to TX XBEE.
Any body can help me?