[mc1322x] Can a Raven stick receive at 250Kb/s?

[Jon Smirl]

On Mon, Dec 28, 2009 at 12:55 PM, Umberto Manzoli <ruytenburch at gmail.com> wrote:
> Hi Jon,
>   we had some problems with the Raven stick, as its usb-to-ethernet stack
> was not very smart.
> The AT86RF230 from Raven sticks behaves very well. Some problems (and
> delays) arise when the mac layer has to be interfaced with the fake-uip
> process, in order to forward packets to and from the host pc. Moreover, you
> have to notice that most of Contiki uIP stack output functions (ethernet
> and/or slip and/or ppp) perform a blocking loop, while waiting for an
> interrupt to signal that data transmission has terminated. Meanwhile, the

I switched that type of block around in the mc13224 code. I let send()
exit immediately and then looped at the front of send() waiting for
xmit to finish instead of the end. That lets me overlap packet
construction with transmission and things got way faster.

> MAC could loose some frames...

The Ravenstick appears to need to process the the completed TCP packet
before reposting the receive.  When the TCP window is open for
multiple packets, and the packets are being fragmented, the Raven
stick almost always drops the first fragment of the second packet.
That implies that a new receive buffer wasn't ready.

I have rewritten the mc13224 code to support multiple receive buffers.
If the UIP stack isn't ready I just hold the packets down in the
driver. Reception into the driver buffers is totally interrupt driven.
So there is always a receive posted unless we are in an xmit.

More testing should determine if the Contiki TCP stack can figure out
that the Ravenstick can only handle a single packet window and then
reduce the window size.

>
> Keep in mind that IEEE 802.15.4-2006 mandates for a minimum LIFS equal to 40
> symbols (IEEE 802.15.4-2006 - par. 6.1.3) for the 2450MHz PHY. The 2450 MHz
> PHY symbol rate shall be 62.5 ksymbol/s. (IEEE 802.15.4-2006 - par. 6.5.3.2)
> (16 us x symbol).
> If you use acknowledged transmission, IEEE 802.15.4-2006 - par. 7.5.1.3
> shows the main concept, i.e. you have to wait about 3 ms before triggering a
> transmission of new data.
> In case these framing gaps are not respected, the receiver could drop some
> packets, especially latest transceivers with embedded MAC accelerator, where
> 802.15.4 constants are sometimes burnt into silicon.

I haven't tried using acked transmissions. I wasn't sure if the Raven
stick could handle them.

Best xmit throughput I am able to get from the mc13224 is 224Kb/sec
including all packet bits. The missing 26Kb/sec is the interframe
spacing and a little bit of interrupt latency. I believe the mc13224
hardware enforces the proper packet spacing.

>
> Bye,
>   UM
>
> 2009/12/28 Jon Smirl <jonsmirl at gmail.com>
>>
>> Has anyone verified that the Raven stick can receive data at the full
>> 250Kb/s channel speed? My new mc13224 code can transmit at the full
>> 250Kb/s (minus needed framing gaps). I had to insert delay loops to
>> lower it down to 190Kb/s in order to talk the the Raven sticks.
>>
>> You hit these speeds on fragmented packets. A maximum TCP packet turns
>> into multiple back to back 802.15.4 packets. I'm using interrupts to
>> overlap the construction of the fragments with their transmission to
>> achieve the full 250Kb/s speed.
>>
>> TCP retransmission won't recover from this problem. If I blast a full
>> speed fragmented packet at the Raven stick it seems to drop at least
>> one packet every time. There is no way to recover other than lowering
>> the TCP frame size.
>>
>> The Raven stick transmits fragmented packets at 134Kb/sec.
>>
>> --
>> Jon Smirl
>> jonsmirl at gmail.com
>>
>> _______________________________________________
>> mc1322x mailing list
>> mc1322x at devl.org
>> http://devl.org/cgi-bin/mailman/listinfo/mc1322x
>
>



-- 
Jon Smirl
jonsmirl at gmail.com