- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am looking into speeding up the time it takes for my device to connect to an AP. A network packet capture is showing a delay of about 2.2 seconds between the active probe response from my AP, and the device sending the Authentication packet to start the connection process.
My device uses an STM32F412 MCU + CYW4343W Wi-Fi/BLE chip, and application is built using WICED Studio 6.6.1 with ThreadX/NetX Duo.
The application performs a Wi-Fi scan, finds the proper AP, updates the DCT with the appropriate channel, BSSID, security for the AP, and then calls wiced_network_up().
I have added debug to WICED, and narrowed down the delay inside of wwd_wifi_join_specific(). The delay is encompassed in the process of sending the JOIN command to the chip and waiting for it to finish –
Call to wwd_sdpcm_send_iovar( SDPCM_SET, buffer, 0, interface ) (where the buffer points to ext_join_params)...
to...
wwd_wifi_join_wait_for_complete( &join_semaphore, interface ) returning success.
I tried changing the parameters for dwell times (to very small values) and number of probes (to 1) in ext_join_params as they were set to use the default values, but this didn’t seem to change behavior.
I captured a network sniff from my Google Pixel of the same process and saw next to no delay between PROBE and AUTHENTICATE, so the delay doesn't seem to be required.
I don’t see where the PROBE to AUTHENTICATE is controlled anywhere in the WICED SDK, so I am assuming this is somehow baked into the chip/firmware?
Am I missing any type of configuration that would speed this up? Is there anything I can change in the SDK, or is this process controlled by the chip/firmware?
My network sniff can't see what is happening on all the channels. Is it possible that the process of traversing the channels during the active probe is the cause of the delay? Does anyone know if the channel traversal stops once it gets a probe response? In my case, the channel has either been 2 or 3. I can try changing this to a higher number to see if it changes the timing at all.
- Labels:
-
WICED Studio Wi-Fi Combo
- Tags:
- cyw4343w
- wiced studio
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Are you using any default application present in Wiced SDK or a custom application that you've created?
In case if it's a custom application, kindly use default application like "snip.httpbin_org" and let me know if the same delay is still observed.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are using a custom application. Our application is using 2-way SSL and it appears that "snip.httpbin_org" is using 1-way SSL, so I'm not sure if this will provide an accurate comparison.
My apologies for leaving out some details. Our application is using an AWS/MQTT TLS connection. Should I try one of the "demo/aws/iot/*" default applications, and report back?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Yes, you can use one of the default applications and let me know the result of your testing.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the confusion about the SSL handshake. I am looking at something else related to SSL and got it mixed up with this thread.
I ran the default "snip.httpbin_org" application and a network sniff shows the same delay from PROBE to AUTHENTICATE. The sniff I captured shows a delay of about 2.53 seconds.