Home/Support/Support Forum/Maximizing Throughput For XBee Pro 900 HP

Maximizing Throughput For XBee Pro 900 HP

0 votes
I have two XBee Pro 900 HP modules (one with a dipole antenna and the other is the wire whip version) that I would like to configure to be able to communicate at the maximum data rate (which looks to be 105.5 kbps). Currently I am only able to achieve 50 kbps using XCTU in a unidirectional, infinite loop throughput test.

Hardware/Firmware info

Firmware Version: 8074
Hardware Version: 2346 (wire whip), 2347 (dipole antenna)
Hardware Series: 301

Current non-default configurations

Unicast Retries: 0
Baud Rate: 115200


What else should I be changing in the configurations?
asked Apr 6, 2016 in DigiMesh Proprietary Mesh Networking by danterp New to the Community (6 points)
I tried different modules S3B S1 S3B , the best I ever got is 20 kbps with s3b.

What can be the reason it is so bad?

What I really miss here is a possibiltiy to upload screenshots and profiles of the module to verify by others.

I was told  I could get 30 kbps wen I get 8 kbps with Zigbee modules, 91 kbps when I get 20 kbps with Digimesh. All tested with good antennas, modules ( baud 115200) close to each other , 1 way unicast, and XCTU latest version.

There must be a reason these figures not match right?

The Xbee's should be an easy way to communicate, but as long as speeds are so low we can not use it propely in our home automation products.

So is there a way to email profiles and screenshots to a digi support line to analyse what goes wrong?

Kr

Wim
Did you try what I suggested on your own post?

http://www.digi.com/support/forum/54972/throughput-test-unidirectional-kbps-for-xbee-s2c-why-so-low

If you sharing such little information about your modules, setup, and environment how do you expect anyone to help you debug your issue? Open XCTU and look-up your hardware version, what is it?  What firmware do you have? Is it the latest version?  What are your other configuration options? Are they all default or have some of them been changed?

Please log in or register to answer this question.

7 Answers

0 votes
I was able to achieve an Average Transfer Ratio of 91.35 kbps by simply increasing the size of the Packet Payload from default 1,000 bytes (1 kB) to 100,000 bytes (100 kB). Note, this also required increasing the Transmit Timeout. I increase the timeout from 5,000 ms (5 s) to 10,000 ms (20 s).
answered Apr 9, 2016 by danterp New to the Community (6 points)
I am confused by this message, is the maximum payload per message not limited to just a few bytes ( 256) ?  Default in XCTU hey write maximum payload size is 256 bytes. Or are we talking about something different?
Can not make the payload longer then 256 byts, error="packet payload is to long, limit is 256 bytes"
Put both devices in Throughput mode.  Right now you must have one or both in API mode.
0 votes
I love to share all, just miss a file upload option at this forum. Can not upload a screenshot, a profile file etc.
Most forums offer this, maybe someone scared to see the reality here :-)

The truth is that I really tested weeks and weeks with AT,API,Brodcats,Unicast S1 S2 S2C S3B , all kind of antenna's from PCB to wire, to dipole, whatever I tried the speed remains low , even between 2 modules with 1 sending data to the other one ( max 20kbps). At the moment it looks S3B gives the best result 20 kbps in XTCU throughput test if no hops just first module to second module.
XBP9B-DM XBEE PRO 900HP 200K fw 8074 CM=00FFFFFFFFFFF7FFFF

You recommend me to increase the payload? I can test and change everything, but at the end what I need is to send small strings as fast as possible from main homeautomation unit to several rooms.
Our string is for example $@13/ZZZZZZ/1/C1/DIM/52/3E@$
I hoped I could update the DIM and RGB value at several (5) rooms with a speed of 20 Hz.
This seems not possible although it means the actual useful data is only 28 * 5 / 20 = 2800 Bytes or 2.8 kbps
At the end I even consider to put the main module in the middle to reduce hops although that is difficult , not flexible and means more then 1 network instead of one.

Broadcast is in all tests slower then multiple unicast. We never need to send 1 message to all rooms but often to several rooms.

Forgive me for asking again, but what throughput I can get from module to module if I send strings like $@13/ZZZZZZ/1/C1/DIM/52/3E@$, and what if 1 ,2,3 hops? IS there a way to calculate, estimate?

KR

Wim
answered Apr 11, 2016 by smart alarm co ltd New to the Community (8 points)
0 votes
sorry 28 * 5 * 20 = 2800 or 2.8 KByte is 28 kbps .. but not possible to get this speed continiously
answered Apr 11, 2016 by smart alarm co ltd New to the Community (8 points)
–1 vote
I would not use the Loop back test. Use the Throughput test instead.

You need to set the TO command to 0x40 and set the BH to 0 as well.
answered Apr 6, 2016 by mvut Veteran of the Digi Community (11,300 points)
I am not sure what you mean.  As stated above I am using the Throughput tool, with throughput type set to unidirectional and duration set to infinite loop.  Both modules have API Enable (AP) set to Transparent Mode (default).

Broadcast Hops (BH) is zero by default, and I have already tried the Transmit Options C0, C1, 40, and 41.
What are you DL and DH set to on the transmitter?

Also what is your CM parameter set to on both?
The Destination Address High (DH) and Destination Address Low (DL) were at the default values of 0 and FFFF respectively, for both modules.  I have also tried a throughput test with DH_1 = SH_2; DH_2 = SH_1; DL_1 = SL_2; DL_2 = SL_1.  This had no effect.

The Channel Mask (CM) is set to default (FFFFFFFFFFF7FFFF) for both.
You need to use the Unicast addressing over the Broadcast address.  You also need to adjust the CM so that you are using every other channel.
"you need to use the Unicast addressing over the Broadcast address" - I'm not sure what you mean by this.  What configuration changes does this entail?
Every other channel would be repeated hex A (binary 1010) or 5 (binary 0101).  I tried using 5555555555555555 for the Channel Mask (CM) on both modules.  This yielded no significant throughput increase (51.5 kbps)
–1 vote
How did you get even 50 kps? And how you can use Transparant mode?

I was told I need to use API mode at sender, and I get only 20 kps where I expected 200 kps as mentioned in the datasheet.

When I use transparant mode I can not select destination in the througput window.
answered Apr 7, 2016 by smart alarm co ltd New to the Community (8 points)
Antenna <--1--> ADF7023 <--2--> Cortex-M3 <--3--> PC

(1) The ADF7023 Transceiver is set to a RF data rate of 200kbps in the firmware (though the IC itself supports up to 300 kbps).  

(2) The ADF7203 communicates through SPI to the Cortex-M3 EFM32G230. I assume the ADF7203 is the slave and the Cortex-M3 is the master. Given the Cortex-M3 is operating at 28MHz, I would imagine it is pulling the data off the ADF7203 as fast as it arrives.

(3) The Cortex-M3 supports UART/SPI/I2C.  The XBee was configured to use USART, so only UART and SPI are available. I assume the AT command ATBD sets the baud rate for the USART.  The maximum ATBD setting is hex 6ACFC0 which is decimal 7,000,000 (7 Mbps).
mvut,

Are you saying there is some absolute limit of 50kbps that I am unaware of (which honestly wouldn't make sense to me given the datasheet claims otherwise)? Or are you saying that for my circumstance the throughput is likely limited to 50kbps because of data loss?
This baud rate calculator is pretty interesting. (It's intended for AVR, so it might not apply well)

http://goo.gl/WeKUo0

It indicates why 230 kbaud doesn't work (high error). Also 250 kbaud seems to have less errorbetter than 115 kbaud.
What I am saying is that you are probably running into interference that is resulting is dropped packets.
I fail to see how that comment is helpful to myself or anyone else genuinely seeking aid from the Digi community.  Not only do you have no data to support your hypothesis, but given you are not privy to any information about my environment or set-up your assumption can't be taken seriously.

The RF environment is not a problem according to XCTU.  I have performed a spectrum test with both modules.  The noise floor is below -95 dBm for one and -100 dBm for the other.
–1 vote
I am testing in Thailand, at 920 MHz,while mobiles phone network 900 MHz and 850 MHz.

How can I get 91 kps? Now only 20 kps, and 2 modules only 1 meter away from each other.
answered Apr 7, 2016 by smart alarm co ltd New to the Community (8 points)
You are not going to.  The 900 HP and your Cell band conflict with each other.
Wouldn't a spectrum test be worth performing to confirm that hypothesis?
–1 vote
Thank you for all feedback and advice.

Still not understand why 900 MHz far away would interfere more with XBEE 920 MHZ ( wse use XBEE 920 not 900 ) then WIFI with XBEE 2.4GHz.

Is there a way to select the normal baudrate of 256000 at the XBEE's?

At the moment the question remains how to get the best results. I will try today again to reach 91 kbps

KR

Wim
answered Apr 7, 2016 by smart alarm co ltd New to the Community (8 points)
Dude, click "comment" not "answer".

What do you mean you use XBEE 920 not 900? This XBee uses many frequencies between 902 and 928 MHZ  (the 900 MHz ISM band). The default setting uses 19 different frequencies.
My supplier told me I have a special version that works on 920 instead of 900 MHz. I will ask them for more details and update you.
The XBee Pro 900 HP uses Frequency-Hopping Spread Spectrum (FHSS), which means it uses multiple frequencies.

https://en.wikipedia.org/wiki/Frequency-hopping_spread_spectrum
That product is not approved for use in Thailand.

Yes, a spectrum print would be a good idea. But you can know which version you have by simply looking at the AF command.  It lists what channels are available for you to use.
The highest throughput I can achieve with the 868 LP was 32kbps.  That was done using Unicast addressing, TO 40, NH, BH, RR and MT all set to either 0 or 1.  I also set the CE to 2 on one and 3 on the other.

On the 900 HP that highest is 53.3kbps.
...