Jean-Luc replied to the topic 'Problems with AZ-GTI mount and PHD2' in the forum. 3 weeks ago

Had a more precise look to the logs, and immediately notice an unexplained variation of the DEC axis position as reported by the motor controller firmware. For instance during the calibration:

[2020-09-23T23:25:15.234 CEST DEBG ];EQMod Mount : "[SCOPE] Current encoders RA=8153754 DE=9502321 "
[2020-09-23T23:25:15.885 CEST DEBG ];EQMod Mount : "[DEBUG] Timed guide North 1250 ms at rate 7.52053  "
[2020-09-23T23:25:15.887 CEST DEBG ];EQMod Mount : "[DEBUG] SetDERate() : rate = 0.5 "
[2020-09-23T23:25:15.887 CEST DEBG ];EQMod Mount : "[MOUNT] SetMotion() : Axis = 2 -- dir=forward mode=slew speedmode=lowspeed "
[2020-09-23T23:25:15.900 CEST DEBG ];EQMod Mount : "[MOUNT] SetSpeed() : Axis = 2 -- period=1329692 "
[2020-09-23T23:25:17.181 CEST DEBG ];EQMod Mount : "[DEBUG] End Timed guide North/South "
[2020-09-23T23:25:17.290 CEST DEBG ];EQMod Mount : "[SCOPE] Current encoders RA=8153804 DE=9502334 "
[2020-09-23T23:25:18.478 CEST DEBG ];EQMod Mount : "[SCOPE] Current encoders RA=8153832 DE=9502332 "
[2020-09-23T23:25:19.455 CEST DEBG ];EQMod Mount : "[SCOPE] Current encoders RA=8153856 DE=9502342 "
[2020-09-23T23:25:19.601 CEST DEBG ];EQMod Mount : "[DEBUG] Timed guide North 1250 ms at rate 7.52053  "
[2020-09-23T23:25:19.604 CEST DEBG ];EQMod Mount : "[DEBUG] SetDERate() : rate = 0.5 "
[2020-09-23T23:25:19.605 CEST DEBG ];EQMod Mount : "[MOUNT] SetMotion() : Axis = 2 -- dir=forward mode=slew speedmode=lowspeed "
[2020-09-23T23:25:19.611 CEST DEBG ];EQMod Mount : "[MOUNT] SetSpeed() : Axis = 2 -- period=1329692 "
[2020-09-23T23:25:20.890 CEST DEBG ];EQMod Mount : "[DEBUG] End Timed guide North/South "
[2020-09-23T23:25:21.533 CEST DEBG ];EQMod Mount : "[SCOPE] Current encoders RA=8153907 DE=9502344 "
[2020-09-23T23:25:22.602 CEST DEBG ];EQMod Mount : "[SCOPE] Current encoders RA=8153934 DE=9502343 "
At the end at the first Timed guide pulse, the DEC axis changes by itself: 9502334, 9502332 then 9502342. Starting from 9502321, the first guide pulse is correct leading to 9502334 (~12-14 steps), then it moves by itself, and the second guide pulse is only 2 steps from 9502342 to 9502344. But 9502344 is almost correct starting from the beginning. Unless another application is moving the mount, I have no explanation. I did not go further, if I understood South guiding works correctly as you reported, I don't know why the firmware makes special corrections on the North axis. I don't own a STM32 dev board to debug the firmware and I suppose their ASCOM driver is closed source. Did you try with the ASCOM eqmod driver ?
It seems they did not solve the issue (or consider this is not a normal usage of the mount) (thanks @Gonzothegreat) What do they mean with 'telescope pointing forwards' ?
An explanation of the existence of these 2 motor firmwares (altaz and eq) may be that the handcontroller is altaz only and always send commands to the motor board as if it was in altaz mode. If the mount is on an eq wedge you then have to change the Dec axis speeds in the motor firmware and that may explain this issue. But not sure.

Read More...

Jean-Luc replied to the topic 'Problems with AZ-GTI mount and PHD2' in the forum. 4 weeks ago

HI,
I checked the guiding pulse in the INDI logs: the DEC axis has 2073600 steps, which is roughly 24 steps per second for sidereal rate, and the 1.250 North guiding pulse at 0.5x shows a difference of 13 steps which seems correct. From the driver point of view, it can't do more.
I noticed in your first PHD2 logs some problems while calibrating. In the RA case, East/West moves seems ok (8 west moves, 4 east moves:

01:04:15.864 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:21.199 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:26.560 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:31.903 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:37.187 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:42.493 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:47.788 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:53.049 00.000 3013644336 MoveAxis(W, 1250, -)
01:04:58.320 00.001 3015503888 WEST calibration completes with steps=8 angle=-178.7 rate=2.618 parity=1
01:04:58.344 00.000 3013644336 MoveAxis(E, 2500, -)
01:05:04.945 00.000 3013644336 MoveAxis(E, 2500, -)
01:05:11.547 00.000 3013644336 MoveAxis(E, 2500, -)
01:05:18.100 00.000 3013644336 MoveAxis(E, 2500, -)
For the DEC axis, North/South moves are problematic (22 North, 6 south):
01:05:24.634 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:29.857 00.000 3015503888 Backlash: Rejected small move of 0.7 px
01:05:29.858 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:29.886 00.028 3015503888 Backlash: Limpiando paso de backlash   2, Last Delta = 0.72 px, CumDistance = 0.72 px
01:05:35.109 00.001 3015503888 Backlash: Rejected small move of 0.8 px
01:05:35.109 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:35.136 00.027 3015503888 Backlash: Limpiando paso de backlash   3, Last Delta = 0.83 px, CumDistance = 1.53 px
01:05:40.438 00.001 3015503888 Backlash: Rejected small move of 0.8 px
01:05:40.442 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:40.470 00.028 3015503888 Backlash: Limpiando paso de backlash   4, Last Delta = 0.77 px, CumDistance = 2.08 px
01:05:45.789 00.000 3015503888 Backlash: Rejected small move of 0.6 px
01:05:45.790 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:45.820 00.030 3015503888 Backlash: Limpiando paso de backlash   5, Last Delta = 0.58 px, CumDistance = 2.66 px
01:05:51.144 00.001 3015503888 Backlash: Rejected small move of 0.7 px
01:05:51.144 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:51.169 00.025 3015503888 Backlash: Limpiando paso de backlash   6, Last Delta = 0.74 px, CumDistance = 3.32 px
01:05:56.380 00.001 3015503888 Backlash: Rejected small move of 0.8 px
01:05:56.380 00.000 3013644336 MoveAxis(N, 1250, -)
01:05:56.407 00.027 3015503888 Backlash: Limpiando paso de backlash   7, Last Delta = 0.84 px, CumDistance = 4.08 px
01:06:01.720 00.000 3015503888 Backlash: Rejected small move of 1.4 px
01:06:01.721 00.001 3013644336 MoveAxis(N, 1250, -)
01:06:01.750 00.029 3015503888 Backlash: Limpiando paso de backlash   8, Last Delta = 1.39 px, CumDistance = 5.46 px
01:06:07.013 00.000 3015503888 Backlash: Accepted clearing move of 4.5
01:06:07.014 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:07.040 00.026 3015503888 Backlash: Limpiando paso de backlash   9, Last Delta = 4.49 px, CumDistance = 9.62 px
01:06:12.339 00.001 3015503888 Backlash: Rejected small move of 1.4 px
01:06:12.340 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:12.365 00.025 3015503888 Backlash: Limpiando paso de backlash  10, Last Delta = 1.43 px, CumDistance = 11.05 px
01:06:17.627 00.000 3015503888 Backlash: Accepted clearing move of 2.3
01:06:17.628 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:17.653 00.025 3015503888 Backlash: Limpiando paso de backlash  11, Last Delta = 2.28 px, CumDistance = 13.26 px
01:06:22.931 00.001 3015503888 Backlash: Rejected small move of 1.8 px
01:06:22.931 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:22.959 00.028 3015503888 Backlash: Limpiando paso de backlash  12, Last Delta = 1.81 px, CumDistance = 15.07 px
01:06:28.229 00.000 3015503888 Backlash: Accepted clearing move of 3.0
01:06:28.229 00.000 3015503888 Backlash: Got 3 acceptable moves, using last move as step 1 of N calibration
01:06:28.229 00.000 3015503888 Backlash: North calibration moves starting at {1986.6,1533.0}, Offset = 18.7 px
01:06:28.229 00.000 3015503888 Backlash: Total distance moved = 21.2
01:06:28.229 00.000 3015503888 Backlash: Falling Through to state GO_NORTH
01:06:28.254 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:33.642 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:38.988 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:44.318 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:49.648 00.000 3013644336 MoveAxis(N, 1250, -)
01:06:54.989 00.000 3013644336 MoveAxis(N, 1250, -)
01:07:00.329 00.000 3013644336 MoveAxis(N, 1250, -)
01:07:05.650 00.000 3013644336 MoveAxis(N, 1250, -)
01:07:10.961 00.000 3013644336 MoveAxis(N, 1250, -)
01:07:16.247 00.000 3013644336 MoveAxis(N, 1250, -)
01:07:21.530 00.001 3015503888 NORTH calibration completes with angle=87.4 rate=1.822 parity=-1
01:07:21.563 00.000 3013644336 MoveAxis(S, 2500, -)
01:07:28.130 00.000 3013644336 MoveAxis(S, 2500, -)
01:07:34.708 00.000 3013644336 MoveAxis(S, 2500, -)
01:07:41.267 00.000 3013644336 MoveAxis(S, 2500, -)
01:07:47.803 00.000 3013644336 MoveAxis(S, 2500, -)
01:07:54.360 00.000 3013644336 MoveAxis(S, 1250, -)
01:07:59.615 00.001 3015503888 Omitted calibration alert: Advisory: Calibration successful but little south movement was measured, 
so guiding may be impaired.
Afterwards, there are many North guide pulses before the DEC axis starts to diverge, that does not occur at the first North guide pulse (even if they don't seem to be very effective). I will try to look what happens when the DEC starts diverging.
At first sight, I would think of a weight balance issue, or a loosen axis clutch. Or there may be a bug in the motor controller firmware as suggested by @Gonzothegreat, which the ASCOM driver is aware of ?
Maybe a log from an Ascom/PHD2 session would be helpful here. I'm also thinking to the SideofPier property, which seems to be used by some guiding software to use the correct axis direction.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

I've played a little yesterday evening with the skywatcherAltAzMount driver. I've used the AZEQ5, 150/750 scope with a DMK41 and a 50/206 guider with a ASI120mm. Nothing aligned. Capture/solve/slew to target works great with the ASI120@206 in 4/5 iterations, but strangely with DMK41@750 it solves but does not slew at all. I suspect a problem with V4l2 devices as the laptop also has a webcam. Sync is not working, there were 3 sync points that I tried to delete, but then tracking became weird. Looking at the code, Sync is only allowed when the mount is parked. I made some images of Dumbbell @10, 30, 60 and 120 seconds to observe star drift/rotation. A silly question, I wonder if the field rotation axis is always centered with the sensor center, or is actually the scope axis. By the way I also noticed regular jumps as depicted by @Federico. I suspect the Aux encoders which are not disabled on AZEQ, and/or the tracking algorithm which updates its data every minute. Lastly I tested guiding, when calibration succeeds (I suppose RA/Az axis does not move enough at ~50° altitude using standard guiding rates), those jumps disturbed the algorithm too much (added to field rotation as the guide star was selected on an edge of the image). Guiding in AltAz mode is quite silly, however the guide tool shows the drifting graph (see the jump @45s) and almost every points are in the upper right corner (field rotation presumably, I did not make the calculations). I may use that to test Alt/Az tracking, selecting a centered star as guide star.
Thus I've learned a little more, and your posts also help me to understand what were your concerns and what you would need. As I understand it, alignment is not primordial as long as Capture/Solve/Slew is working, guiding is of no use as your setup does not have a guider, and you only really need a smooth tracking. What I have in mind as a first step is to create a new driver out of the existing indi repos, hence astroberry users may compile it without disturbing their installation. I will derive it from indi-eqmod and/or indi-skywatcherAltAzMount and then concentrate on the tracking feature. I'll keep you informed when that will be initiated and when I will need you to perform tests.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

@Dirk Thanks for giving more explanations about your concerns. I don't know either why handcompiling indi in astroberry does not work, I have looked for the repo to inspect package contents, but did not find them. I may directly inspect the image, but it would be better to ask to astroberry's maintainer. If you want to help in testing, that will be mandatory anyway. I agree with your remarks concerning setup time needed when you don't have an observatory. In my backyard I can't even see Polaris, that reduces polar alignment time, just aligning on three stars and pointing inside that triangle. That's enough for my use, I don't know if that would work for faint objects.
@Federico I made an error in my previous post, after looking at the skywatcherAltAzMount driver code, the current implementation consists in speed adjustments made every seconds. It decided me to test indoor with my AZEQ5 and the CCD simulator. I have been able to track a star, take a shot and sends it to astrometry.net (Capture and Solve). It did not resolve unfortunately, the CCD image having two big circles with no stars inside it, only two or three dozens around, and a double star just in the center (I pointed Arcturus!). I must have missed something. Anyway Ekos did not complain at all with the AZEQ5 while it was tracking, Should have a try on real sky when possible.
I really believe the skywatcherAltAzMount driver is the best option for the moment. And don't understand why you would like I make two drivers in one with indi-eqmod. And don't have plans for that before at least months.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

The slews you see in AltAzSimple/AltAzMount drivers come from the way Roger (who wrote those drivers) implemented tracking: every second, perform a goto to the foreseen position. It was mainly aimed at visual observing. It explains why plate_solving alignment aborts as it detects these gotos.
Now the question is what usage for an altaz skywatcher driver (driving AZGti, AZEQ, virtusoso and all other altaz mounts I don't know of) ?
- visual: should be ok, but never heard a report here from users if any;
- planetary imaging: did not test myself, @Dirk tried to do so, but it seems he has serial port communication issues and I can't help him here. I'm not sure you need plate solving for planetary imaging, even 'tracking' is usually performed when you stack the images, but I am not used to planetary imaging;
- deep sky imaging: there you need everything, as you state in your post.
As I already said, I won't add a button in indi-eqmod for alt-az mode: first it's risky for users, and it will actually add a bunch of if/then/else in the code. It is not as simple as adding a layer between alt/az and ra/dec. Tracking would use variable speed adjustments, and you have to compute period values and make timer callbacks at a rate which depends on the stepper resolution of your mount. And you may have zero period sometimes (infiinite speed at zenith or pole, I don't remember), hence what to do there ? In Equatorial mode, tracking is just starting the RA motor... Concerning guiding I don't know if guiding programs may use Alt/Az axes, hopefully they do.
In other words, this represents a huge amount of work, refactoring indi-eqmod code first to split it into eq and altaz mode, refactoring alignment too, and then testing all that new stuff, which is at least half of the work. I still have a pair of pull requests waiting for users to confirm. AzGTi snap port is one of them, on my side I only use simulator mode, put A5 as mount code, see the snap button appear in the control panel and toggle it, but I still don't know if that actually works in real. What I mean is that I need testers, merging a 3 or 6 month branch may be time consuming (or not). And sometimes users simply vanish (that was the case for snap ports in indi-eqmod, I made the work twice).
Thus my point of view is that I don't plan to invest time to develop an altaz driver as there may be other solutions (which may need tweaking, but without testers...). And why not using an equatorial wedge if you want to plate solve? I don't know when does field rotation appear in altaz mode, but plate solving may also fail in altaz mode for that reason, even with a perfect smooth tracking. Or am I wrong ?

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

I updated the driver, you can refresh your clone:

cd ~/Projects/indi
git pull
and rebuild/reinstall. And retry. Beware of USB extension cable, I also had connection issues while testing, just reconnect them and that was ok.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

At least one of the driver has succeded in opening and writing to the mount:

[2020-09-11T13:18:05.060 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[DEBUG] Connecting to /dev/ttyUSB0 @ 115200 "
[2020-09-11T13:18:05.061 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[DEBUG] Port FD 3 "
[2020-09-11T13:18:05.061 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[DEBUG] Connection successful, attempting handshake... "
[2020-09-11T13:18:05.061 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[SCOPE] SkywatcherAltAzSimple::Handshake "
[2020-09-11T13:18:05.061 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[SCOPE] InitMount "
[2020-09-11T13:18:05.062 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[SCOPE] CheckIfDCMotor "
...
[2020-09-11T13:18:06.415 CEST DEBG ][           org.kde.kstars.indi] - Skywatcher Alt-Az Wedge : "[DEBUG] Handshake failed. "
[2020-09-11T13:18:06.532 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2020-09-11T11:18:06: Driver indi_skywatcherAltAzSimple: SkywatcherAltAzSimple::ISGetProperties"
`CheckifDCMotor` sends a ':' which is not a valid command for AZEQ5/6 mounts, and they return '!1'. This is what I test, exactly '!1' as this is what my AZEQ5 replies. Maybe the AZEQ6 returns another error code and the function returns false. You may test that using picocom if you have it installed: `picocom -b 115200 /dev/ttyUSB0`, hit ':' followed with ctrl-M (there is no echo), and look at the reply. You may close picocom with ctrl-A then ctrl-X. Don't send other commands if you are not sure of what you do (never send ':Q'....).
Concerning EQMod, as we change the indi core library without recompiling it, it may explain the connection issue. But usually this implies a crash when the API has changed and the dynamic loader fails and aborts. Otherwise EQMod should be able to work as usual. I wonder if you actually run the hand compiled binaries. May you try to check if they have been installed in `/usr`:
ls -l `which indiserver indi_eqmod_telescope indi_skywatcherAltAzMount`
If their date are correct, you may try to launch them by hand and connect kstars directly to that indiserver (on localhost port 7624):
indiserver indi_skywatcherAltAzMount
Actually I don't exactly know your setup.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

Maybe you could try to connect using the USB port for testing as long as we develop the driver. I've looked at the AltAzSimple driver source, it does not have the Alignment stuff, just normal syncs. So it should work as well.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

Skywatcher Alt-Az Wedge : "[DEBUG] Connecting to /dev/rfcomm0 @ 9600 "
I did not test with the skywatcherAltAzSimple dirver but with skywatcherAltAzMount, I don't know how they differ. Shouldn't the serial speed be 115200 in place of 9600 ?

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

Sorry, the depth -1 only gets the master branch... Try with

git clone --depth 1 https://github.com/geehalel/indi.git --branch azeqaltaz
The `git checkout azeqaltaz` is no more needed in that case.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

Not a dumbee question, it's not easy if you never compiled software. You may refer to the libindi/indi github page where the building process is explained. You only have to change the repository with my repo and use my azeqaltaz branch ("Get the code" paragraph):

cd ~/Projects
git clone --depth 1 https://github.com/geehalel/indi.git
cd ~/Projects/indi
git checkout azeqaltaz
That will replace your current indi-core installation, but it will be restored at the next software update from ppa.
If you don't succeed I may ask a pull request so that will be available in the next ppa update.

@Jasem: thanks for the info, I did'nt know the drivers.xml file, will have a look. I realize that my sentence concerning home position is quite silly, this was after I read the manual which states:
"The telescope should be mounted in a way so that it is on the right-hand side of the mount when it points forward." Still not sure what that means.

Read More...

Jean-Luc replied to the topic 'Alt-Az mode for EQmod' in the forum. 1 month ago

I have made an azeqaltaz branch on my forked repo of libindi to add support for AZEQ5 and AZEQ6 in the indi_skywatcherAltAzMount driver.
I have only tested with that driver and my AZQE5 (in my home office): mount connects as expected, moves, gotos and tracking are functionnal. Only slew speed seems to be always high speed,
and I am not sure what is the home position (telescope pointing North horizon, on the east side of the pier?). East/West direction may also be inverted in my case, North/South is correct.

@Jasem thanks for making the AZGTi update, it has helped me. I don't understand what you mean with 'added a new entry...': where did you add it ?

@Dirk May you test using my above repo ? You would have to recompile the indi core library. Concerning the rfcomm, it may have changed in /dev. I use picocom to make connection tests, just sending the :e1 command (end with CTRL-M).

Read More...