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

Communication problem with newer firmwares #9

Open
mdjurfeldt opened this issue Jan 15, 2023 · 11 comments
Open

Communication problem with newer firmwares #9

mdjurfeldt opened this issue Jan 15, 2023 · 11 comments

Comments

@mdjurfeldt
Copy link

mdjurfeldt commented Jan 15, 2023

I am experiencing the problem that you refer to in the README where you recommend Unisofts firmware due to some change in newer stock firmware. This is on an RD6012P running fw 1.46.

For me, trying to create the Riden object hangs. (This doesn't happen on my RD6018 running some pre 1.40 fw.)

Do you have any idea of what they changed? Are you aware of anyone having succeeded to talk to these newer fw:s using custom software?

@bluecube
Copy link
Contributor

I'm not sure if it's the same problem, but with stock FW 1.42 I had to increase the modbus timeout before the library starts working for me:

diff --git a/riden/riden.py b/riden/riden.py
index 24a7fde..7af6f4b 100644
--- a/riden/riden.py
+++ b/riden/riden.py
@@ -32,7 +32,7 @@ class Riden:
 
         # Fixes "Response length is invalid 0" error
         # If you experience this error, try changing your baudrate
-        self.master.set_timeout(0.05)
+        self.master.set_timeout(0.5)
 
         # Windows requires opening/closing the com port after each call
         # This is a workaround that will drasticly reduce performance

(following the instructions in the comment)

I did this to get it working, but didn't investigate any further.

@mdjurfeldt
Copy link
Author

I tested this, and communication now works.

@ShayBox
Copy link
Owner

ShayBox commented Jan 15, 2023

If this is the case the timeout value can be exposed optionally in the constructor and a default minimal value that still works with this firmware version

@mdjurfeldt
Copy link
Author

@ShayBox Sounds like a good idea. I'll find out (binary search) what that value is tomorrow and report.

@mdjurfeldt
Copy link
Author

@ShayBox @bluecube Hi again,
It seems like a timeout of 0.15 does not work while a timeout of 0.16 works. I tested this both over USB and over Wifi (socat + telnet to a reprogrammed and physically patched Wifi module connected in TTL mode). This was on an RD6012P running firmware V1.46. So, to have some margin, perhaps 0.2 is a good value?

@ShayBox
Copy link
Owner

ShayBox commented Jan 16, 2023

Seems good to me 👍

@bluecube
Copy link
Contributor

For me it's about 0.3s, which feels ridiculously long. I might look at the reason and try to figure out some non-parametric way of handling the timeouts later when I have a bit more time. (but don't wait for that, it will be at least a few weeks from now)

@mdjurfeldt
Copy link
Author

Try it out with stock V1.46. They state that they did optimizations of communication.

@bluecube
Copy link
Contributor

bluecube commented Feb 3, 2023

@mdjurfeldt I wasn't able to find the firmware anywhere. The website seems to be just a static image.... Do you have a link to the firmware please?

Sorry for spamming the issue :)

@mdjurfeldt
Copy link
Author

mdjurfeldt commented Feb 3, 2023

@bluecube Hi! Here are directories with firmware for different models:

http://www.ruidengkeji.com/rdupdate/firmware/

@bluecube
Copy link
Contributor

bluecube commented Feb 5, 2023

Try it out with stock V1.46. They state that they did optimizations of communication.

Can confirm, 0.2s worked with the newer firmware.

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

No branches or pull requests

3 participants