Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated code for inbound wifi data buffering #232

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

markmuzzin
Copy link

No description provided.

@markmuzzin
Copy link
Author

markmuzzin commented May 3, 2022

tl;dr Tried to fix constant drops on my HW, ended up changing more than I wanted to.

So I went down the rabbit hole with this change., and I'm not sure if it's even needed since quite a few people have not had issues with WiFi (specifically for the Mega256+esp8266). The problem I was seeing was a frequent mismatch between the CIPSEND command and the corresponding data which caused the WiFi to stall and drop. This issue was likely exasperated by my network, so I wanted to see if I could synchronize the CIPSEND. I wasn't able to do what I wanted with the current implementation, so I needed to change quite a bit. Hopefully, something similar can be done with the original code if this change is too involved.

I added a 32 byte buffer to parse the incoming messages. Those messages are grouped as either ending in /r/n, start with '>' or are +IPD messages. All messages are read into the staging buffer one at a time. The exception is the +IPD message which is read up to the ':" to get the data length, then the rest of the data is written to the inbound ring buffer directly. This just let me control which message I was dealing with easier. From that, I also added some synchronization to trace the CIPSEND from start to SEND_OK/FAIL.

Tested with the Engine Driver App and Cab Engineer apps. My board was terrible before, could not click more than a few buttons before dropping out. On my setup, its very stable now, can also switch between the apps.

This was only tested on one board, so it needs to really be vetted on more hardware with users who are familiar with the functionality.

Also, AP mode is terrible on my HW so no app I ran (even test apps) seemed to work very well. My testing was mainly using STA mode.

@markmuzzin
Copy link
Author

markmuzzin commented May 4, 2022

One thing I noticed with the Engine Driver app is after a dropout, it seems like the rate of message sending increases (heartbeat?). The controller can usually keep up, but it can lead to more dropouts. I think this -may- be the app, because when I shut it down I can see the proper quit message (<* Q\n\0 *> 0,CLOSED\r\n), then if I restart the app, the rate returns to normal and the app reports the correct button statuses.
EngineDriverApp_dropout.txt

- Added timestamps for CIPSEND and +IPD tracing
@markmuzzin
Copy link
Author

Added a flush for the esp8266 data receive buffer if the link drops
Added timestamps for CIPSEND and +IPD tracing

@markmuzzin markmuzzin requested review from Asbelos and FrightRisk and removed request for Asbelos and FrightRisk May 4, 2022 17:15
daniviga pushed a commit to daniviga/CommandStation-EX that referenced this pull request Mar 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant