Is anyone having any luck with 900HPs in transparent mode? I’m using all the same configs as the old XBee-Pros and I’m getting 11x the bit error rate at 1/10 the throughput. Digi claims it’ll transmit 3x farther but I haven’t even tried range testing yet because performance on my bench is so horrible.
I could send blocks of 1040 bytes at 57600 with old XBeePros and get virtually flawless reception. But with these HPs, I’m having to break my 1040-byte packets into less than 512 bytes and add ten times as much delay between the packets, and even slowed down like that I’m still getting horrible bit error rates.
I would very much like to know if anyone has used 900HPs in transparent mode. Side-by-side with old XBeePros, I had to operate 900HP TEN TIMES slower and still got FIFTEEN TIMES as many bit errors as the old modules. As much as I would love the extra transmit distance, I consider these new modules to be unusable.
I went back and forth a dozen times with Digi tech support about this, they finally admitted that the new modules will have “slightly slower throughput” but they wouldn’t confirm or deny my 10x slower. I’m pretty sure that they never duplicated my setup nor did they do any other kind of bench testing of this issue. Overall very disappointing performance and tech support.
Hello Doug,
I would like to try what you are saying. Could you generate and upload the .pro files (“Save profile” in X-CTU’s Modem Configuration) that you are using in your modules? Also, how are you testing the transmission?
Best regards,
I pasted the .pro for the 900HP below. XCTU won’t upload my old XBee .pro because it can’t find the modem config file on Digi’s server for that version. But here’s the config string that I send to the old XBeePros, beginning with factory defaults: “ATID484F,CE0,RP0,NB0,SM0,RO0\r”
Note, steer clear of RO=0 on 900HPs, that makes a mess of the transmissions. Digi eventually fessed-up to that bug, works with RO=2;
To test the transmissions, I’m sending a known block of 1024 bytes. At the receiver (LabVIEW) I compare all 1024 bytes to what it should be. I can send thousands of these blocks with an old XBeePro and get no errors. When I send the same blocks with a 900HP using the same delays between blocks as the old XBeePro, only 7% of the blocks come through without errors. So then I start breaking-up the blocks of 1024 into smaller blocks, and adding longer delays between blocks, and it eventually becomes tolerable at 10x slower throughput, although still ~11x the BERR as the old XBeePros.
Huge huge thanks if you look into this, would very much like to hear of any results that you get.
XBP9B_8068.mxi
200
0
351
8068
0
[A]CM=FFFFFFFFFFF7FFFF
[A]HP=0
[A]ID=484F
[A]MT=3
[A]PL=4
[A]RR=A
[A]CE=0
[A]BH=0
[A]NH=7
[A]MR=1
[A]NN=3
[A]DH=0
[A]DL=FFFF
[A]TO=C0
[A]NI=
[A]NT=82
[A]NO=0
[A]CI=11
[A]EE=0
[A]BD=6
[A]NB=0
[A]SB=0
[A]RO=2
[A]FT=13F
[A]AP=0
[A]AO=0
[A]D0=1
[A]D1=0
[A]D2=0
[A]D3=0
[A]D4=0
[A]D5=1
[A]D6=0
[A]D7=1
[A]D8=1
[A]D9=1
[A]P0=1
[A]P1=0
[A]P2=0
[A]P3=1
[A]P4=1
[A]PD=7FFF
[A]PR=7FFF
[A]M0=0
[A]M1=0
[A]LT=0
[A]RP=28
[A]AV=1
[A]IC=0
[A]IF=1
[A]IR=0
[A]SM=0
[A]SO=0
[A]SN=1
[A]SP=12C
[A]ST=BB8
[A]WH=0
[A]CC=2B
[A]CT=64
[A]GT=3E8
[A]DD=B0000