Announcements

Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MuOr_1658816
Level 4
Level 4
First like received

Interesting observation.

We have a WICED development board configured to connect to an AP with DHCP. Before network up, app registers for link and ip change events. After successful connection, the application stays idle. The AP is D-Link DAP-1350.

After an hour or so being idle, it keeps cycling periodically from link down, ip change, link up, ip change states. It keeps cycling until it stops getting the ip change and stops. No other device on this AP is experiencing this behavior, as far as we can tell.

Any suggestion is appreciated.

0 Likes
1 Solution
MuOr_1658816
Level 4
Level 4
First like received

FYI. we figured this out. You need to turn on WiFi keep-alive when it is just sitting idle. For some reason, it works fine without keep-alive when joined to an Apple AP, but the rest seem to require it.

View solution in original post

5 Replies
MuOr_1658816
Level 4
Level 4
First like received

FYI. we figured this out. You need to turn on WiFi keep-alive when it is just sitting idle. For some reason, it works fine without keep-alive when joined to an Apple AP, but the rest seem to require it.

I am going to try this.  We are spontaneous link down and deauth events at no specific time interval.  It can be anywhere from 5 minutes after connection to 2 hours after connection.  If it resolves our issue, I will post.

0 Likes

It did not resolve our issue since we were never idling.

0 Likes

Bummer. Our experience has been pretty good after adding keepalive.

I am interested in the final solution for your project, just to make sure we don't release a final product that has issues.

0 Likes

Our issue was caused by stalling the socket.  The reason for the stalls was because we had 2 tasks in our OS operating on the same socket at once.  One task sent data and one received asynchronously.  We've moved to a windowing scheme that pushed all the data out, then attempts to receive before finally turning low power back on.

This seems to have resolved our issue (at least in 99% of observed cases)

0 Likes