[Ovmsdev] Time for 3.2.003? / Issue #241

[Michael Balzer]

Steve,

I meanwhile use toolkit -98 along with the new libs provided here:  https://github.com/espressif/esp-idf/issues/2892

…plus the (not yet checked in) volatile patch described here: https://github.com/espressif/esp-idf/issues/2892#issuecomment-525697255

To use the new libs I replaced (symlinked) the respective files in xtensa-esp32-elf/sysroot/lib/esp32-psram by those from the zip.

Then checkout and build on our branch "spiram-fix-test".

Regards,
Michael


Am 04.09.19 um 07:04 schrieb Stephen Casner:
> Michael,
>
> I have not built the OVMS software in a while, so I need to update to
> the current esp-idf, which I have done by the steps you prescribed a
> while back.  But you also recommend the -93 toolchain; I currently
> have -80 installed.  Where can I find the -93 tarball?  Google didn't
> answer that question.
>
>                                                         -- Steve
>
> On Tue, 3 Sep 2019, Michael Balzer wrote:
>
>> Everyone,
>>
>> I've pushed a change that needs some testing.
>>
>> I had the issue myself now parking at a certain distance from my garage wifi AP, i.e. on the edge of "in", after wifi had been disconnected for some hours, and
>> with the module still connected via modem. The wifi blob had been trying to connect to the AP for about two hours.
>>
>> As seen before, the module saw no error, just the server responses and commands stopped coming in. I noticed the default interface was still "st1" despite wifi
>> having been disconnected and modem connected. The DNS was also still configured for my wifi network, and the interface seemed to have an IP address -- but
>> wasn't pingable from the wifi network.
>>
>> A power cycle of the modem solved the issue without reboot. So the cause may be in the modem/ppp subsystem, or it may be related (in some weird way) to the
>> default interface / DNS setup.
>>
>> More tests showed the default interface again/still got set by the wifi blob itself at some point, overriding our modem prioritization. The events we didn't
>> handle up to now were "sta.connected" and "sta.lostip", so I added these, and the bug didn't show up again since then. That doesn't mean anything, so we need to
>> test this.
>>
>> The default interface really shouldn't affect inbound packet routing of an established connection, but there always may be strange bugs lurking in those libs.
>>
>> The change also reimplements the wifi signal strength reading, as the tests also showed that still wasn't working well using the CSI callback. It now seems to
>> be much more reliable.
>>
>> Please test & report. The single module will be hard to test, as the bug isn't reproducable easily, but you can still try if wifi / modem transitions work well.
>>
>> Mark, you can check your server logs for history messages with ridiculous time offsets:
>>
>>     [sddexter at ns27 server]$ cat log-20190903 | egrep "rx msg h [0-9]+,-[0-9]{4}" | wc -l
>>     455283
>>
>> The bug now severely affects the V2 server performance, as the server is single threaded and doesn't scale very well to this kind of bulk data bursts,
>> especially when coming from multiple modules in parallel. So we really need to solve this now. Slow reactions or connection drops from my server lately have
>> been due to this bug. If this change doesn't solve it, we'll need to add some reboot trigger on "too many server v2 notification retransmissions" -- or maybe a
>> modem power cycle will do, that wouldn't discard the data.
>>
>> Thanks,
>> Michael
>>
>>
>> Am 03.09.19 um 07:46 schrieb Mark Webb-Johnson:
>>> No problem. We can hold. I won't commit anything for the next few days (and agree to hold-off on Markos's pull). Let me know when you are ready.
>>>
>>> Regards, Mark.
>>>
>>>> On 3 Sep 2019, at 1:58 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>
>>>> Mark, please wait.
>>>>
>>>> I may just have found the cause for issue #241, or at least something I need to investigate before releasing.
>>>>
>>>> I need to dig into my logs first, and try something.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 02.09.19 um 12:23 schrieb Michael Balzer:
>>>>> Nothing open from my side at the moment.
>>>>>
>>>>> I haven't had the time to look in to Markos pull request, but from a first check also think that's going too deep to be included in this release.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 02.09.19 um 04:15 schrieb Mark Webb-Johnson:
>>>>>> I think it is well past time for a 3.2.003 release. Things seems table in edge (although some things only partially implemented).
>>>>>>
>>>>>> Anything people want to include at the last minute, or can we go ahead and build?
>>>>>>
>>>>>> Regards, Mark.
>>>>>>

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26