Just received a pair of Wixels, and started playing. No problem implementing the wireless serial app – but have run into speed issues. My goal is to stream data bidirectionally to a robot: 22byte packets to, and 22bytes back at 100Hz – sounds like 4.4Kb/sec to me. This should be within Wixel capability, but so far I’m getting a max of ~50Hz in my system. Everything works as expected (100Hz or better) when I send the stream directly into the robot-attached Wixel, via USB cable. I realize there may be a number of potential bottlenecks, but before I start going through all the possibilities, are there any obvious sticking points I should be aware of?
System details: stream “host” is Win7 computer feeding Wixel via USB (virtual com port) / stream “client” is PIC-32 (ChipKit UNO) UART set to 115200. Both Wixels set to 115200. Thanks for any/all input.
I’m glad you were able to get your system running.
I think you meant to write 4.4 KB/sec (kilobytes per second) instead of 4.4 Kb/sec (kilobits per second).
When I tested the wireless serial app and achieved 10 KB/s, I was only doing one-way communication over the radio. I was sending a stream of data from the computer to the Wixel as fast as possible, but the computer was not reading any data from the Wixel. As a result, all of the Wixel’s buffers for data from the computer were full, so every packet that got transmitted on the air (except acknowledgments from the other Wixel) contained a full 18 bytes (this limit is imposed by our software, not the CC2511 itself). Since you are doing bidirectional communication, that might explain the difference in data rates you are seeing.
I’m wondering how your client and host are programmed: does each one just send data continuously or does one of them wait to receive a packet from the other before sending its own packet?
Yes, I did mean 4.4KB(ytes)/sec – and understand why the “10KB/s” you were able to get with wide open unidirectional flow does not necessarily apply to bidirectional cases such as mine. My protocol, which is early in development and has a good deal of inefficiency (like using text for easy debugging instead of binary) starts with the host sending a 22B packet, then waiting for a return packet (for error checking). The client gates the stream rate via an ISR which processes the packet and sends the return packet after 10msec. I can see on the scope that with wireless comm. it’s not getting through every “gate” – closer to every-other.
I tested decreasing packet size down to 7B-- but no change. I conclude the bottleneck is more related to bidirectionality than payload size. I’ll continue to mess with it (like sending more than one packet at a time), but a 50Hz stream will likely be adequate for my needs. Just wanted to make sure I wasn’t missing something simple. Thanks again for the quick response!
Bruce
ps-- I’m relatively new to micros, with the ChipKit being my first introduction. So far my experience with the Wixel environment has been first rate. I’m assuming you had a hand in its development – kudos!
Thank you for the details on your system; I think it explains why you weren’t getting the speed you were hoping for.
Instead of measuring the throughput, I think you are measuring the latency between the computer and the remote Wixel. Roughly speaking, the latency is a sum of many things, including: how quickly computer software can respond to input from a USB device and produce output (a few milliseconds in my experience on MS Windows), how long it takes for the PC’s Wixel to transmit the data to the remote Wixel (several milliseconds or more depending on how many radio packets are lost), and how long it takes your microcontroller to receive the serial data and send a response (best case is 2*(7 B)*(10 b/B)/(115200 bps) = 1.22 ms but you have an extra delay of 10 ms).
I am glad that you are enjoying your experience with the Wixel and good luck on your project!
I’m also interested in absolute substained maximmum speed of wixel. I plan to do real time telemetry (robot->pc). I need data every 1ms (1000Hz). I do not have an exact number of bytes yet defined, minimum may be 5, the more I can send the best.
Will wixel suite to may whishes?
What parameter should I config the wixel to get best performance?
If output buffers are 18 bytes, what happens when I only send 5 or 9 bytes? Are them sent inmediatly or it waits until buffer is full? So, to send 18 bytes (in my case) in 9 bytes, will take 2ms? If I send in 5 bytes, will it take 4 ms?
To achieve sustained full speed I “must” use SPI or is it relliable with Serial? I heard of modules loosing syncro over some minutes of work if frecuency on micro and module are not exactly same. My micros will be microchip dspics (may be also some arduino nano or uno).
If you’re hoping to receive a new piece of data from your robot Wixel every millisecond, that is not going to work. It takes around a millisecond to send a radio packet so if one packet gets lost then you are already off schedule. However, if you are just hoping to get on average 5 bytes per millisecond (5000 bytes per second), that will probably work. When I tested the Wixel’s wireless serial app I was able to get about 10240 bytes per second, and this was over a lossless communication channel provided by the Wixel’s radio_com library, so if a packet wasn’t acknowledged by the receiver it had to be resent.
You should think about whether you want a lossless communication channel like that or whether you want to just make a stream of packets and accept losing some. The lossless channel is probably easier to do because you can just use the Wixel’s existing Wireless Serial App and you don’t have to write your own app. But if a packet fails to be received, is it really worthwhile to send it again or should you just always send the latest data?
I’m not sure what Wixel app you want to use/create so I cannot give you any advice on parameters yet.
This depends on how you program your Wixel, or which app you use. Is there are particular Wixel app or Wixel library you want to know about? The Wireless Serial App and the radio_com library which it uses will transmit data as soon as it is available; it doesn’t wait for you to fill up a packet, but it does make an attempt to fill up packets when there is a lot of data queued up to be sent.
It seems to me that serial would be more reliable because the sender can reliably reset the state of the receiver by just leaving the line idle for 10 bit times or more. With SPI, if the receiver somehow misses one of the edges of the clock line or sees an edge that wasn’t there, I’m not sure how you can recover.
