Hi,
I’m working on a distributed control algorithm for quadrotors. From Xbee’s (S2) spec sheet, it is noted that they can handle 250kbs. But is that per frame? The question I’m interested is how many packets can you write per second. If I have 200 bit frames can I write that say (approx) 1000 times a second to the Xbee? Can Xbee supprot 1000HZ on the serial port?
To be more clear. Say I’m sending a sinusoidal signal from A to B. At A I’m sampling the signal at 1000Hz (and assuming the signal value is a float (4bytes=32 bits). Can I reconstruct that signal at receiving end B with minimal latency and package loss?
If not, in your experience have you come across something that can handle this sampling rate?
I don’t think this will work for you. Xbee/802.15.4 isn’t designed to be a low latency wireless protocol. It’s supposed to be battery friendly with advanced routing abilities.
since your sampling 200 bits at 1000/second = 200,000 which is already 80% of the maximum throughput of the spec! You’ll never get that to work.
Incidently, the highest throughput I’ve ever heard of on S2 was 30k. and that was in a tightly controlled lab enviornment.
Keith,
thank you for showing interest in my question. A few things on your comment.
(1). So if I am at 80% throughput that means I’m within specs - why is that a problem? My first question though, is when they quote 250kbs do they mean to a single packet, or multiple ones? (by they I mean spec sheet)
(2). “the highest throughput I’ve ever heard of on S2 was 30k.” here 30k stands for … ? Where did you get this number from? Do you know if there is a technical/official rate that digi quotes.
250k is the maximum number of bits that can be sent in 1 second using the specification. Keep in mind that most of that is overhead (50-99%), which is data that keeps track of the actual data you send: ‘hello world’ for example.
Here’s an example:
Let’s say Node 1 wants to send ‘hello’ to node 4. Let’s assume that it travels over node 2 and node 3 to get there:
node 1 -> node 2-> node 3-> node 4
Node 1 will send the ‘hello’ to node 2. Node 2, if it receives it will have to send an acknowledgement. If node2 doesn’t get the message node 1 will resend the message up to 3 times.
The above process must occur for every ‘hop’: node 1 to node 2, node 2 to node 3, etc. Also, node 4 will send a final ack message. So you can see this can easily be up to 10 packets or more. That’s about 80bytes a packet. So you’ve already consumed 800 bytes (6400 bits) in this example.
this is assuming that node 1 has the routing information to get to node 4. It may not. In that case it would have to do a network discovery. It would send a broadcast out and all nodes would have to answer. that’s several more packets that would all come back. That’s additional overhead.
Your also assuming no other nodes are sending or receiving. Zigbee has a lot of additional overhead. This is to support those neat mesh network features and sleep features.
If you really want to understand why data rates are so low read the specification in detail and get a zigbee network sniffer. You will then see how it’s easy for 1 transmission to generate 100 or even thousands of packets.