knro wrote: However, I never had issues myself guiding with EQMod using either ASI120 on a 50x300 guide scope or directly via the QSI583 OAG. Subframing shouldn't be used, binning 2x2 or higher, exposure time 1-2 seconds. Been getting less than 0.5 RMS on my EQ8.
geehalel wrote: Hi,
I looked at the log and considered a guide pulse (line 38858) 1000ms@0,5x):
- it starts at 22:20:50:556, and the actual track speed modification occurs at 22:20:50:656. There is a 47ms delay between the two first log messages, 0ms between all the others, but the last, with a 53ms delay which may be due to the real serial comm occuring here.
- the end of the pulse occurs at 22:20:51:715 (line 38897) after the end of a mount probe started at 22:20:51:372, The actual speed modification occurs at 22:20:51:832.
I have thought serial comm could be the problem but in the first part, a ':f1' serial command gets its response in the same millisecond, but the same command in the second part took 50ms. I believe the timestamps in log messages are added by the indi framework and thus we see when they have been processed, not when they have been queued. Furthermore the indi-eqmod driver uses the timer callback mechanism of the indi framework too, that explains why they may be delayed by the normal mount probe processing. I think we have to look at the eventloop of the indi framework as the timer callbacks are managed with select timeouts. Anyway a first idea would be to delay the ReadscopeStatus callback while pulse guiding.
Now none of this happens when you use ST4 guiding, you could do that with your ASI120MM and your AZ-EQ5.