Communication problem with newer firmwares

[mdjurfeldt]

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]

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]

I tested this, and communication now works.

[ShayBox]

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]

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

[mdjurfeldt]

@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]

Seems good to me :+1:

[bluecube]

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]

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

[bluecube]

@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]

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

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

[bluecube]

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

Can confirm, 0.2s worked with the newer firmware.