Tom from AstroEQ has already posted an update that seems to fix the problem by updating :f when receiving :G only if the axis isn't moving.

www.astroeq.co.uk/forum/index.php/topic,...msg1979.html#msg1979

Read More...

I found a bug caused by miscommunication between the INDI EQMod driver and the AstroEQ firmware. During initialization, the INDI EQMod driver sets the slew speed to the Custom Rate value, which sends a :G[axis]30 command to the AstroEQ which sets highspeed, forward mode (or at least for me, my Custom Rate is x662). However, INDI EQMod never sends the :J command after the :G command, so the AstroEQ doesn't update the :f value to reflect that it is ready to change to highspeed mode.

"[DEBUG] SetRARate() : rate = 662 "
"[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=slew speedmode=highspeed "
"[SCOPE] CheckMotorStatus() : Axis = 1 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[MOUNT] StopWaitMotor() : Axis = 1 "
"[COMM] dispatch_command: \":K1\", 4 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "
"[COMM] dispatch_command: \":G130\", 6 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
"[MOUNT] SetSpeed() : Axis = 1 -- period=7 "
"[COMM] dispatch_command: \":f1\", 4 bytes written "
"[COMM] read_eqmod: \"=101\", 5 bytes read "        <----still shows 101 (lowspeed, forward, slew, not moving, initialized)
"[COMM] dispatch_command: \":I1070000\", 10 bytes written "
"[COMM] read_eqmod: \"=\", 2 bytes read "
Then, when you unpark the mount and try to perform a low speed movement in the same direction, INDI EQMod thinks that AstroEQ is already in lowspeed, forward mode because of the response to :f not having updated yet, and therefor doesn't send another :G command. INDI EQMod then sends the :J command to start moving, which causes AstroEQ to finally switch over to highspeed mode.

The bug only affects the very first slew command for an axis, and only if the slew command is at lowspeed and forward. The result is a highspeed ticking motion, but the ticking is only because of the proper :I value being set for what should be lowspeed. The bug also affects tracking (tracking = lowspeed forward slew), if you enable it immediately without slewing RA before hand to work around the bug (by sending a :G then :J, to clear out the :G that was sent without a :J).

There are a few ways I thought of to fix this:
  • AstroEQ could update :f after receiving :G or :I (might cause problems if already moving)
  • INDI EQMod could always send a :G before a :J (might slow down guiding)
  • INDI EQMod could avoid initializing the Custom Rate and sending the first :G without a :J

I have also posted this on the AstroEQ forum.

Read More...

Jeff Slight replied to the topic 'Astroberry Server' in the forum. 4 years ago

Kaczorek wrote: Due to increasing security constraints in majority of browsers this issue will persist. To address This ssl will be disabled by default in the new version. I would recommend using a VNC viewer to access Astroberry Server if you have problems with accessing it with a browser.


Firefox seemed to allow successful access to the site after adding an exception for the certificate error. I have my own private Certificate Authority and was able to generate a new certificate that works fine in all browsers. I believe the issue with your certificate is that the CA cert and Web Server cert share the exact same Common Name. This causes the Subject and Issuer fields of the Web Server cert to be the same which should only occur with self-signed root certificates (the CA cert). When a browser sees this, it tries to verify that the digital signature coincides with the Issuer's public key; in this case, it checks against the Web Server's public key instead of the CA's public key, causing it to fail.

I believe that simply adding something like an OU to the Common Name of the Web Server cert will fix this (requires generating new certificate of course).


P.S.
@admins: Speaking of certificates, where is the one for indilib.org???




Read More...