- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there a way to speed up re-association when powering up on the same network as used previously ??
I am thinking of a battery powered sensor that would wake up every ten minutes and transmit one UDP
packet then go back to sleep .... association tests we did using the console app show association times
running 5-10 seconds depending on the access point. This will run the battery down pretty quickly.
Can I cache all the connection state (WPA, etc) info in NVRAM and just resume where I left off when I powered down ??
(I was looking at the ping_deepsleep app but deep_sleep does not seem to be supported for any of the mass market platforms)
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. You can save all of the association information in the DCT and on boot use this to directly connect. However some of the aspects of this will include whether you use internal v/s external flash, DHCP v/s Static etc.
In general using internal flash in the STM MCUs you should be up and running on an network within 1s or so
Using external SFLASH will add another 400ms or so (this is with DMA enabled which is supported in the next SDK coming out)
deep_sleep is only supported on the 4390x family currently which is not yet released to community
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. You can save all of the association information in the DCT and on boot use this to directly connect. However some of the aspects of this will include whether you use internal v/s external flash, DHCP v/s Static etc.
In general using internal flash in the STM MCUs you should be up and running on an network within 1s or so
Using external SFLASH will add another 400ms or so (this is with DMA enabled which is supported in the next SDK coming out)
deep_sleep is only supported on the 4390x family currently which is not yet released to community
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I save the DCT and use it at power up how does the wiced stack know that I am trying to resume without re-assocating with the AP.
I assume if I just call "wiced_network_up" that will re-associate with the AP (which will take 5-10 seconds).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Saving information in the DCT saves you time for scan and instead you can associate directly
However it doesn't automatically restore functionality
wiced_network_up should not take 5 to 10s to complete. Something is going wrong here. If the AP is too slow to respond to DHCP perhaps
Which MCU are you using in this test?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your help.
I Have tried both BCM94343W_AVN and BCM943341WCD1.
Running test.console app built with 3.5.2 SDK.
Here is what I get running test_join console command to Juniper SSG5 router:
(Average join time is 7300 ms)
test_join guest wpa_tkip test 192.168.3.200 255.255.255.0 192.168.3.1 5
0 Joining : guest
Successfully joined : guest
IPv4 network ready IP: 192.168.3.200
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:B238:29FF:FE3D:3975
Time for successful join = 5947 ms
1 Joining : guest
Failed to join: guest
Joining : guest
Successfully joined : guest
IPv4 network ready IP: 192.168.3.200
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:B238:29FF:FE3D:3975
Time for successful join = 13005 ms
2 Joining : guest
Successfully joined : guest
IPv4 network ready IP: 192.168.3.200
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:B238:29FF:FE3D:3975
Time for successful join = 5849 ms
3 Joining : guest
Successfully joined : guest
IPv4 network ready IP: 192.168.3.200
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:B238:29FF:FE3D:3975
Time for successful join = 5851 ms
4 Joining : guest
Successfully joined : guest
IPv4 network ready IP: 192.168.3.200
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:B238:29FF:FE3D:3975
Time for successful join = 5849 ms
Join failures: 0
Leave failures: 0
Average join time: 7300 ms
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you do a packet capture over the air?
Something is not right. You are using static IP. A simple join to external AP should not take 7s especially from the console where the WLAN firmware is already loaded up
This should be much faster
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is the packet capture for two back to back associations. Siliconw_3d:39:75 is the wiced device and JuniperN_5c:b4:a2 is the Juniper SSG5
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sja@brightstareng.com wrote:
Thank you for your help.
I Have tried both BCM94343W_AVN and BCM943341WCD1.
Running test.console app built with 3.5.2 SDK.
Here is what I get running test_join console command to Juniper SSG5 router:
(Average join time is 7300 ms)
test_join guest wpa_tkip test 192.168.3.200 255.255.255.0 192.168.3.1 5
I think you can compare join time with:
test_join guest wpa_tkip test 192.168.3.200 255.255.255.0 192.168.3.1 5
and
test_join guest wpa_tkip test
to see if there is any difference in join time.
(To clarify if using static ip is faster or not.)