Print

[kaito83]

Hi Tom,

DEC strange noise and unaccuracy, its like wont go with desired speed. This is a custom board with mega 2560 with LV8729, everyhing is ok with fw 8.0.5!
 I tried 8.14 > 8.20 nothing change, pinmap ok just setted the same settings from fw 805.
EQMOD 2.00w
ASCOM latest
Tried with Arduino studio and Michrochip Studio - same issue.
Direction is ok on both AXIS, RA speed ok only DEC doing these strange issue, with 805 everything is super fine.
Updates:
- I tried out maybe some pin mapping problem like the pwm or estop pissing other pins, no luck
- Happend 1 time after 5min the mega disconnected.
Update 2022-12-06:
With Synscan Windows program: SynScan Pro App, Version 1.19.20 - works well with the newwer negative response like in the android app btw I wrote a little proxy app UDP-Bluetooth to transfer android app calls to bluetooth
Maybe eqmod bug?

Do You know any idea what cause this issue?

[TCWORLD]

Does it happen at all speeds, or just GoTo movements?
Do RA and DEC use the same or different settings?
If you plug the DEC motor into the RA output, does it move smoothly?

V8.05 is pretty ancient, and a fair amount of changes have been made in the mean time, so it might take a bit of head scratching to get to the bottom of it.

You say it works for something other than EQMOD? Could you try with EQMOD 2.00q as that is what I have installed. Wonder if they've made some changes.

[kaito83]

Its not hardware issue 100%, same settings its an eq6 mount, DEC on every manual speed or GOTO, a i tried with the latest eqmod 2.01b, its available only from https://groups.io/g/EQMOD/files same issue.
And also I checked your code, and I didnt see any problem the RA and DEC movement controlls are same.
Ill tried with GS server and its working fine, no DEC issues manuel move OK, goto completed well and accurate.

So it's probably eqmod issue!
Already openen a thread:
https://groups.io/g/EQMOD/topic/strange_issue_with_astroeq/95502094?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,95502094,previd%3D1670387537381587556,nextid%3D1664492562613143893&previd=1670387537381587556&nextid=1664492562613143893

Maybe if you have time you can try reproduce, I have mega2560 (tried with other boards / other motor drivers)

Other and FYI:  with the latest Windows program: SynScan Pro App, Version 2.1.11 or with the latest android app, cannot connect to any astroeq fw and the app says negativ  response.
I have a log from UDP > bluetooth
10:53:28 UDP 127.0.0.1:51759 >:e1
 BT
10:53:30 UDP 127.0.0.1:51759 >:e1
 BT
10:53:30 BT =340300
 > UDP127.0.0.1:51759
10:53:30 UDP 127.0.0.1:54551 >:q1010000
 BT
10:53:30 BT !
 > UDP127.0.0.1:54551
10:53:35 BT  > UDP127.0.0.1:54552
10:53:35 UDP 127.0.0.1:61434 >:X10002
 BT
10:53:35 BT !
 > UDP127.0.0.1:61434

Here comes the app error message

[TCWORLD]

Just a thought, I think your issue might actually just be that you are trying to move the DEC axis faster than it is capable of going.

The key difference between V8.20 and V8.05 is the microstep mode settings for the DRV8825 (and by extension the LV8729) changed.

In V8.05 I was using for 1/32 mode, "H H H" for low speed, and "L H L" for high speed. On the DRV8825 this works correctly. However for the LV8729 this is incorrect. "H H H" enters 1/128 mode, not 1/32 mode.

This means on the V8.05 firmware, your low speed was a factor of 8 slower than it should have been. Did you by any chance adjust the config settings to get it to track at the correct speed?

In V8.20 I changed the 1/32 mode setting to "H L H", which is 1/32 mode on both the DRV8825 and the LV8729. This means the low speed setting for the LV8729 is now the expected speed, but 8x faster than it would have been before. If your mount configuration was set up for it going at the previous incorrect speed, then now you are trying to move 8x faster.

Could you double check your config settings.

[TCWORLD]

As an aside, there is a new branch on the Github repo ('dev-cmdUpdate').

Could you try compiling this for your board and testing it with the SyncScan app to see if it connects now.

I've implemented handling for the :q command that it seems to be getting upset about.

Have no idea if it's correct because the documentation of the protocol is appauling. It doesn't even mention the existence of the :X command, so don't know what that is doing.

[kaito83]

Hi Tom,

Your are great, You solved the problem!
Ok with Synscan and ok with eqmod!

Big Thank You!!!