SPWF00xx Poor Wi-FI Peformance - Switching Between AT Data and Command Modes

[Jon Lamborn]

Posted on January 30, 2017 at 23:57

We are trying to reach real-time 50mS per round trip of 20 byte TCP messages of receive and then send response. I'm actually seeing closer to 150mS round trip time. Much of this time is taken up in switching between data and command mode. Our measurements indicated 88mS or 44mS per side. Switching to command mode requires the following characters Tx:'at+s' and Rx:'+WIND:59:Back to Command Mode'. At 115,200 bps that's 0.00295sec at 10 bits per char which is 6.8% of 44mS delay. What is the other 93.2% of the delay time? How long should it take to switch from data mode to command mode? This appears to be putting excessive overhead on our message traffic?

[Gerardo GALLUCCI]

Posted on January 31, 2017 at 19:04

Hi,

are you using 

XNUCLEO-WIFI firmware library for STM32?

Ciao

j

[Jon Lamborn]

Posted on January 31, 2017 at 19:40

Yes, it is the same ST Middleware used for

XNUCLEO-WIFI.

The X-CUBE-WIFI1 software package is an expansion for STM32Cube. This software provides software APIs running on STM32 for STM's X-NUCLEO-IDW01M1. It is built on top of STM32Cube software technology that ease portability across different STM32 microcontrollers.

X-CUBE-WIFI1 software features:

Complete middleware to build applications using the Wi-Fi module (SPWF01Sx). 

 Easy to use abstract APIs to configure and use SPWF01Sx. 

 Easy portability across different MCU families thanks to STM32Cube. 

 Sample applications that the developer can use to start experimenting with the code. 

Free user-friendly license terms. 

Examples implementation available for X-NUCLEO-IDW01M1 STM32 expansion board plugged on top of one NUCLEO-F103RB, NUCLEO-F401RE or NUCLEO-L053R8.

[Gerardo GALLUCCI]

Posted on February 01, 2017 at 18:53

Ok, understood.

I think 'SPWF00xx Poor Wi-FI Peformance - Switching Between AT Data and Command Modes' is not related to SPWF01S itself.

Module's side, I can suggest to reduce sockd_timeout to detect escape sequence, but this is not the solution to your point.

Host's side, check UART management, and improve it eventually. Which interrupt are you using four your application? DMA? etc...

[Jon Lamborn]

Posted on February 02, 2017 at 17:02

The sockd_timeout=5 for traffic as the message sizes are only 20 bytes. At 115.2K the factory default rate is adequate for this application. Raising the baud rate would have a negilable effect on performance as the messages are small. The interrupt timing is specified by the ST middleware, but, in answer your question the event handler is TIM3 and Process_ISR is 1mS ISR. The serial Tx/Rx character interrupts happen on USART1 and not DMA enabled. It might be possible the character interrupts are blocking the event timer or process ISR. Have you every measured the data/command mode switch time on the SPWF?