First run at implementation is in wifirefactor branch. I am testing now. Seems stable, but no improvement in initial connection issues I was having (will know about long term stability in a couple of days). I am adding more debug output to show the detailed reasons for individual wifi state transitions - that should help us narrow down the cause of these sorts of issues. Regards, Mark.
On 22 Mar 2018, at 1:42 AM, Greg D. <gregd2350@gmail.com> wrote:
Also, there's really no loss of function, since 'power wifi off' does release the memory.
Greg
Stephen Casner wrote:
That would avoid having the initial wifi task being one of the ones that own heap allocations after being killed.
Seems like a reasonable plan to me, in part because I will always want to have wifi running.
-- Steve
On Wed, 21 Mar 2018, Mark Webb-Johnson wrote:
I’m seeing problems with our wifi driver. If I stop, start, change modes, etc, etc, after a while it just seems unwilling to connect to access points. Even ‘wifi scan’ seems to stop working. A ‘module reset’ resolves the problem.
I think the issue may be our use of init/deinit to continually load and unload the driver (and the associated two tasks), in a similar way to the mdns issues we had.
I suggest to change as follows:
Use the power control not-off / off to init / deinit the driver. Whenever the wifi mode is set (client, ap, scan, etc), power it on automatically. But don’t stop it unless explicitly told to by the user (power wifi off). Even ‘wifi mode off’ won’t unload the driver.
Then use the existing commands ‘mode, scan, client, apclient, ap, etc’ to start / stop the actual wifi.
This will mean that we will take a memory hit when we first start the wifi, and even ‘wifi mode off’ won’t free that memory. You would need to do a ‘power wifi off’ to do that. But, the upside is that we won’t be continually loading and unloading the wifi driver (which seems to be causing the issues).
I’ll try it tonight, as my home is one of the areas I’m having the most problems with wifi. If it looks like it might break things, I’ll put it in a branch.
Any comments / suggestions are welcome.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev