• AVR Freaks

Hot!WINC1500 Throughput

Author
Post
Essentials Only Full Version
jhellen
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2021/01/13 09:40:46
  • Location: 0
  • Status: offline
2021/01/20 05:03:18 (permalink)
0

WINC1500 Throughput

I’m having some serious trouble with the TCP/IP wireless throughput from the WINC1500 module to a simple Windows executable. I’m using the following setup:
  • WINC1500 module with firmware version 19.6.1
  • WINC1500 module is connected to STM32 NUCLEO64 board via SPI (clock set to 10 MHz)
  • WINC1500 module is setup as Access Point with a private class A IPV4 address set to 10.0.0.1
  • When I connect the windows machine the windows STA address becomes 10.0.0.100
I have a TCP port 6670 for streaming data to the windows application. The data is send in 50 msec packet chunks with the last packet in the chunk containing a sequence number.
The throughput should be around  56 kbit per second Total chunk size is around 334 byte every 50 msec.
Two questions:
1)      I have to send back an ACK from the windows application every time I receive a chunk of data. If I don’t do that than the round trip time is around 40 to 60 msec. Sending an ACK back (just 1 byte) will result in an implicit TCP/IP ACK with a round trip time of 0.1 msec. What causes the extreme RTT when not sending back an ACK every time I receive a chunk of data??? I notice that not sending back an ACK will also result in an extreme interval between the asynchronous send call and the notification that the transmission has finished by the callback with SOCKET_MSG_SEND
2)      Sending chunks of data is not stable in the sense that there various long intervals between the send call and the SOCKET_MSG_SEND callback, even when the Windows application returns implicit ACKS.  This is illustrated by the next plot where every blue pulse, when high,  is the time needed for the asynchronous send with a blue pulse interval depending on the SOCKET_MSG_SEND callback. The red pulses show the send start to SOCKET_MSG_SEND callback. I don’t have a clue why there are extreme long periods between the send and the  SOCKET_MSG_SEND callback. Does anyone have any idea.
 
All help would be really appreciated!
Thanks Wim

Attached Image(s)

#1

3 Replies Related Threads
    SerafimMerkulov
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2018/05/31 05:12:41
    • Location: 0
    • Status: offline
    Re: WINC1500 Throughput 2021/01/21 06:48:18 (permalink)
    0
    Hi, I've just finished testing ATWILC3000. And I have a question because you are using a similar module.
    - Is project with STM32 available on site?
    - Did you consider ATWILC*** as an alternative?
    - Please, post your throughput results after you finsih them.
    (I've chosen ATWILC3000 because it has higher uplink throughput, but it is not supported in last libraries).
    Regards, Serafim
    #2
    jhellen
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2021/01/13 09:40:46
    • Location: 0
    • Status: offline
    Re: WINC1500 Throughput 2021/01/21 08:20:05 (permalink)
    0
    The STM32 project is part of code being developed for a third party. It's not available on the web. Sorry for that. It basically follows the examples being part of the WINC1500 library tree(and API). Execution of the test code is done using a  NUCLEO64 development board (with a STM32L476 processor) with a Arduino Adafruit WINC1500 WiFi shield stacked on top. 
     
    I haven't considered using any other devices actually. Only need WiFi not bluetooth. 
    #3
    jhellen
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2021/01/13 09:40:46
    • Location: 0
    • Status: offline
    Re: WINC1500 Throughput 2021/01/28 02:48:32 (permalink)
    0
    Dear all, 
    I ran a couple of more tests an came to the conclusion that it definitely has something to do with the WINC1500 module, maybe in combination with 2.4 GHz HF interference or incorrect configuration by me. I have a transmit streaming buffer, capable of buffering a couple of seconds of data. I'm trying to send data with a throughput of 56 Kbit/s and a data size (segment) around 1000 byte.  Looking at the collected info in WireShark I notice the following:
     
    - Round trip time from WINC1500 to windows application and back is 50 ms on average. This is no problem. The max RTT I see is around 80 msec. That's OK too. 
     
    - Looking at the throughput I do see an average of 56 kb/s. However sometimes the throughput drops and recovers by a temporary increase of the the bit rate. Now the interesting part. The drop in throughput is caused by an excessive time gap (can be 1 second) between the asynchronous send to the WIN1500 (via SPI) and the SOCKET_MSG_SEND notification in the socket callback routine. The SOCKET_MSG_SEND notification for me is used as indication that the send is ready and that it is allowed to start another TCP transmit cycle. See Attachment for WireShark image
     
    I connected a oscilloscope monitoring two GPIO lines.  One, surrounding the  asynchronous send routine (blue channel) and the other activated prior to a send and deactivated when the SOCKET_MSG_SEND  is received (red channel). Notice that the gap can be as long as 1 sec (1 sec /div time base value). This is something I also see back in the WireShark data when the throughput drops. WireShark does not indicate loss of packets.  The order in which frames occur look perfectly alright. Accept for the gaps of course, See attachment
     
    Does anyone has any idea what could be wrong or what I am doing wrong. I'm pretty much stuck. 
     
    Any help would be really appreciated !!!!
     
    Best Regards,
    Wim
     

    Attached Image(s)

    #4
    Jump to:
    © 2021 APG vNext Commercial Version 4.5