Random communication problems with EX-CommandStation ?

[Rotziboisseur]

When I use the throttle, I randomly encounter speed adjustment issues. When I want to slow down, the display of the notches behaves erratically and increases the speed instead of reducing it. For example, if I am on speed step 30 and want to reduce the speed to step 26 or 20, the display of the speed step indeed decreases but then, a fraction of a second later, it increases by the value I wanted to decrease and accelerates the locomotive. I have checked the quality of the encoder connections, and there is nothing to report on that front. When I use the JMRI throttle or WiThrottle on my phone (also via a wifi connection), I do not have this problem. Could this be a software issue? If so, how can I assist in resolving it by producing logs? Or could the encoder be defective (I do not have a spare part to test)?

Hardware used: DFRobot EC11 Rotary Encoder SEN0235 DFRobot FireBeetle 2 ESP32-E DFR0654-F

Command station V5.0.7-Prod

Otherwise, a huge thank you for this amazing project of great quality, which deserves to be better known!

[alex-code]

There is a potential issue I'm trying to diagnose and fix. I've read that there can be false triggers in certain scenarios on the ESP32 so the throttle thinks you're turning the dial clockwise.

Could you try adding this WiFi.setSleep(false); to src/main.cpp between lines #337 and #338 then compile and upload and see if that helps.

[Rotziboisseur]

I made the code modification, recompiled it, and uploaded it to the ESP32, but I do not see any change; the problem remains.

[alex-code]

One more quick thing to try would be commenting out line #397 in src/main.cpp. Just need to add a couple forward slashes // then re-upload.

This is the power check function that updates the battery icon.

[Rotziboisseur]

I've also made this modification, but unfortunately it doesn't change anything. Wouldn't that be an interrupt management problem? (I don't have the skills to analyze the code, so I don't know if it's multithreaded or not...)

[alex-code]

There's a bug in the ESP32 which can cause ghost interrupts in certain scenarios (typically on the 2 pins I used).

I'd read some people had success with WiFi.setSleep(false);.

Still testing for a fix but it's tricky to make reproducible.

[Rotziboisseur]

If I change the encoder connection on pins D2 and D3 of the Firebettle and modify lines 33 and 34 of src/main.cpp accordingly, could this help solve the problem?

[alex-code]

I think D2 and D3 are used by the GDI port for the display.

Managed to get a scope on pins 36(A0) & 39(A1) and I could see noise. One other possible solution I read about is adding adc_power_acquire which after doing that the noise on the pin didn't show so could be a fix.

In main.cpp you'll need to add #include <driver/adc.h> at the top then just after void setup() { add adc_power_acquire(); and compile and re-upload.

This will be part of the code in the next update.

[Rotziboisseur]

Unfortunately, these changes have not led to any improvements.

[alex-code]

I've done a test branch with different encoder code if you can try that. https://github.com/DCC-EX/EX-T3-WiFi/blob/encoder-test/src/main.cpp It's all in main.cpp so you'll only need to update that file then compile and re-upload.

[Rotziboisseur]

Thank you very much for your help, the situation has changed very favorably 👍 There are now no more erratic variations in the speed steps. After 10 minutes of maneuvers and driving, I still notice a new problem: Randomly, yet very frequently, the encoder stops responding for 2 to 4 seconds. Even when applying 5 or 10 pulses on the encoder, during this time nothing happens on the control. When the control starts responding to the encoder pulses again, there is no sudden change in the speed steps, so it seems that the encoder pulses are not accounted for at all during this period of time. I can make a short video if it can help understand the problem

[alex-code]

I might need to rethink the way it works but there can be a delay if the CS is busy.

When you rotate the encoder the throttle sends a command to the CS and won't send another command until it receives a response from the CS which can cause a delay while waiting. I did it like this for multi throttle support.

What board have you used for your CS?

[Rotziboisseur]

I use a Mega2560 + WiFi unbranded CS with an EX-MotorShield8874

[Rotziboisseur]

To ensure that the issue is not coming from the unbranded Mega + Wifi board, I ordered an official Mega board as well as an "official" EX-WiFiShield-8266.

My configuration is now: Arduino Mega 2560 + EX-MotorShield8874 + EX-WiFiShield-8266. The problem persists with this configuration.

I also had the opportunity to invite a friend who came to my layout with his TCS UWT-100 controller. When the EX-T3-WiFi controller is on and connected to the same locomotive address as the TCS UWT-100, the EX-T3-WiFi controller disrupts the operation of the TCS. Once the EX-T3-WiFi controller is turned off or with another locomotive address selected, the TCS controller works perfectly well with my hardware configuration.

[alex-code]

Is this the slowness issue? Not sure how to speed this one up yet without affecting multi throttle support.

Would you be able to create a new issue about the TCS throttle so it's easier to discuss.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stale for 7 days with no activity.