Voice over ZigBee with CC2530 in Z-stack?

I think that transmitting voice over ZigBee is something that many of us have dreamed about sometime. I (and maybe others too) would really appreciate a detailed explanation of why something like Purepath is really needed to transmit audio data packets at a rate of a few Kbps (ZigBee apparently should be enough for that).

Sorry for my ignorance, but I am very curious on this... Where is really the problem? Why are analog audio links (like pop singer's wireless mics on stage) so reliable with almost no latency (i.e.: no buffering nor packet retransmissions) and digital wireless links seem to be so unreliable even when carrying far less information? Is the problem on the crowded 2.4 GHz band? If so, would it be possible, for example, to use the same frequencies and bandwidths that analog RF links use, in order to design a reliable digital audio link? In such a case, is there a TI solution that would allow for the custom design of both the RF modulation and transmission protocol and the audio signal processing involved (ADC,coding,packetizing, etc.)?

Thanks!

Dirty Harry said:

Do you know about the TI product specifically for voice over 2.4 GHz - PurePath Wireless for audio - it is dedicated h/w and s/w just for voice.

Otherwise, I don't think that you will ever come close to full duplex voice with ZigBee. You might try half-duplex (i.e. press-to-talk) only voice over MAC only, no ZigBee.

 

Thanks a lot for attention and suggested device, but it isn't a ZigBee (or I'm mistaken?), we exactly want to use ZigBee devices in our project. 

As for half/full-duplex transmitting over ZigBee - of course, I know about this transmitting structure, and understand, that this SoC works in half-duplex in fact, but, according to 802.15.4/ZigBee standard it's provided time-slot technique(CAP and CFP slots), which allows possibility to transmit by turns (now we're talking about data exchange between two devices). If my programs (two copies of one program in two PCs) transmit data in full-duplex with speed is about 20 Kb/s in both directions, then  why CC2530 chip or ZigBee can't to provide required speed, although declared data rate of chip is 250 Kb/s? Could you explain me? May be, I'm wrong somewhere.

Despite on troubles with duplex, the main problem aren't connected with it, and usually appears during data exchange in simplex mode on high speed(22 Kb/s and higher). If I continue increase speed later, I have data bursts loss. I've already enabled RS-232 flow control in my program on PC (in "SerialApp" in Z-stack it was enabled by default). Every time, in my program, before transmission it waits, until CTS bit is set in "true", and then transmission begins. That's all. Probably, I'm doing something wrong, or miss some important details(that's why I was interested in DMA, MAC superframe settings etc). 

Hope, you'll help me. Thanks for attention.

Best regards, Egor. 

Dears,

I have the same question either. In my environment, I never have the data rate more than 10K bits per seconds running Zstack on CC2530. Could any TI employee give some explanation about the data rate mismatch so much with the spec?

I think the expectation of 250 kbit/s from a ZigBee network  is too optimistic. 

The 802.15.4 spec gives the rate of 256 kbit/s assuming the PHY level only. The chip rate is 2048 kchip/s, each symbol is spreaded by 32-chip sequence, so the symbol rate  is 64 ksymbol/s. As the QPSK modulation is used, a symbol carries 4 bits and the bit rate is 256 kbit/s.

The PHY level packet consists of 133 octets but only 127 of them is useful payload. Considering the ZigBee spec, one can see that at the APS level only about 100 bytes of data (without any security) may be send to another node within the single message. Therefore, the overhead is 25% min.

Other important factor to consider is the simplex nature of the 802.15.4 PHY level. The node cannot spend all the time on transmitting but must switch to the reception from time to time. Taking into account that the MAC level implies an acknowledgment after every packet, the bit rate reduction (the additional overhead) can be significant. If the retransmission due to the bad propagation conditions occur, the overhead can be 75% or higher.

In the real Zigbee network consisting of many nodes the overhead becomes higher as there are a lot of control packets without any useful load (from the application point of view). The relaying and the usage of CSMA/CS mechanism also decrease the overall data rate.

Thus, the overhead which is higher than 90% (the real data rate is 10kbit/s with the nominal data rate equals to 256 kbit/s) seems possible.

regards,

Ilya

Ilya, thanks for taking part in our discussion. I think it's good explanation of so slow data rate in fact. I'll investigate total speed on all layers soon.

But it still doesn't explain the problem with data loss on high speed. As I wrote sooner, I enabled flow control in my PC program to avoid data loss. It has visibly decreased, and data transmitting from PC program has become to pause, if some jams appears somewhere, but losses haven't disappeared at all. 

So, to check data exchange over serial port, I set SERIAL_APP_LOOPBACK param in SerialApp.c, which locates in "SerialApp" project, on TRUE. Thus, I got send-receive system over the serial port on one PC. My program send data to device, then data is read from DMA receive buffer in chip and, finally, it's written in DMA transmit buffer, where data is returned to my program.

The maximum speed I got, using such system - is about 43 Kb/s. If I continue to increase data rate from PC program - data is lost again. Can anyone explain me this trouble?

Thanks for notice, br, Egor

Hi Egor,

I understood your question - you don't try to communicate with another ZigBee node but you create a local loop at the APS level...

TI's Z-stack functionality runs over some kind of OS called the OSAL. The APS level tasks have the lowest priority compared to NWK and MAC levels. I suspect that the intensive data exchange over the UART just runs out of the controller performance. But of course, some bugs(features) in TI's implementation are possible.

regards,

Ilya

Ilya, no-no, you understood me some wrong. I've set connection between two devices - coordinator and router. But maximum speed  I've got - is 24 Kb/s in simplex mode, and 10-14 Kb/s in duplex mode. I wrote about it in my first post.  I have data loss on higher speed.  I'm trying to find the place, where data usually lose. That's why I decided to make local loop, and check how correctly DMA process incoming and outgoing data. Data loss haven't disappeared...

br, Egor. 

Hi Egor,

ok, you've got two results:

test1 - the connection between two nodes with the max data rate equal to 24 kbit/s

test2 - the loop connection with the max data rate equal to 45  kbit/s.

The results of test1 are affected by many factors so the overall rate of 24 kbit/s subject to the UART rate of 45 kbit/s may be quite reasonable value. However, test2 shows that with a high probability the UART (APS) functionality is the bottleneck of data exchange. I think TI's support can give the precise answer what the local loop data rate can be achieved assuming the full time load of the UART. From your results it seems to be about 45 kbit/s.

regards,

Ilya

have you solve it out ? i meet it .