Outdated libraries may cause all sorts of problems, for sure. But as far as I understand, these are a separate issue, with gphoto. I'm not sure if it was fixed upstream. What I was referring to is an issue (or rather a new feature) in libraw, which was  fixed (or one can say added) in upstream years ago, we were just waiting for the Raspbian to be updated. This finally happened, so atroberry should be updated too. I understand that this is a lot of work, but it has to be done as soon as possible, since it could fix a lot of issues outstanding since years.


Hmm, that is a pity.
Buster is seriously outdated. Not only the wpa supplicant has problem, but libraw too. The version in Buster does not support CR3, the raw format used by Canon cameras since a few years. So you need to compile libraw, Kstars, EKOS and the gphoto indi driver too from source to support any semi modern Canon camera.


Does anyone have any experience (good or bad) using Canon M200 with INDI?
libgphoto2 lists as fully supported, but does it mean it is usable in practice with INDI?

Thanks for any opinion here!


Hmm, I can set gain up to 400, but at that gain it generates soo much noise, I don't it is usable, at least i would need several thousands of light framses to avarage that out.

Do not beleave in any "magical" algorithm that removes noise with dark or flat or anithing else. Dark is removed from every frame, right? No random noise (in the light frame) can be eliminated by removing a static "dark" frame! It can eliminate anything that is permanent on your sensor, such as hot pixels. But nothing that is random in nature. Similar storry with light frames. It can eliminate faults like pathces from dust on the sensor or vignetting, but not random noise.
I have experimented with dark and flat frames but i don't see that dramatic effect.

Rotation is an inevitable issue, I agree, and there are parts of the sky where it is more paiful (zenit) and there are parts where it is not so painful (lower part at the southern sky). I deal with it by crop. Just as with the migration during tracking. And as we anyways need to crop to the middle of the frame, vignetting is not as much an issue.


I don't think dark or flat helpson noise. Darks helps on hot pixels or other permanent sensor faults, but do not help on random noise. Flat helps on uneven field, which may help when you try to supress the noise floor, but not on the noise itself. These ones are made without dark or flat. The old one was ISO6400, the new one is gain 200. I think 200 is the max usable gain with this camera, as you can see the raw images are quite noisy. The only thing helps on noise is having many many pictures. 100 at minimum, but more is better. I usually make 200, but not all usable.


This horshead is by FAR better than the best I was ever able to make.

For the FOV: I used a small scope, 250mm focal length (not diameter, that is 50mm), so this is small magnification. But this camera has small pixel pitch, but relatively large sensor (as being 6 MP), so I get nearly the same FOV as I get with the large scope, and a DSLR.

Here is the same M42 from a year ago, with the large scope, and a Nikon D7000 DSLR, 106 times 4 sec expo (I cannot remember, but most probably it was tracked by the Synscan handcontroller):


And one more thing: all this misalignments does not explains the phenomea I have had last time (and many times before): after having a good tracking something goes wrong and starts to drift in a direction. The direction and drift speed seems to be random, and changing in time.
I think having the scope not perfectly level or otherwise badly aligned should cause a constant drift at a given target on the sky, at least for a while (which 'while' is measured rather in hours then minutes...)
No explanation.


Obviously tracking with Alt/Az is inheritelly much more complicated than tracking with EQ.
For an EQ mount you have polar alignment, and if it is right in theory you only need to rotate the RA axis at a correct speed, right?
For Alt/Az there is no equivalent thing. You have to have your mount level (Az axis vertical, and Alt axis horizontal) in the first place, but still the tracking software (be it the INDI driver or Synscan) still have to consider your exact position on the globe and the exact time. Any inprecisity in that would cause poor tracking.
So far I thought that the alignment procedure is for comensationg for these inperfectments. So by syncing to many stars it could deduce how much the Alt and the Az axis is inclined to the perfect direction (which is maybe the same as having an error in your geo location, I bet). I have a feeling that I could have read these estimated angle errrors from the driver somehow, but I cannot find it anywhere. All I see is that a sync operation adds an offset to the coordinates around the part of the sky it is made. But it will be not enough I'm afraid.



I don't really understínd what do you mean by "Java point and sync driver", can you elaborate it a litle bit more detail?

A few days ago I had a clear enough night to take some pictures, targeted M42. I've used my small Virtuoso mount with a SW50ED mini scope (250mm focal length), and the ASI178MC camera.
First I've followed the normal alignment procedures: solve&sync to different parts of the sky. Starting around Polaris (as always), solve one to the east, then gradually going to south (Orion is at the south meridian this time). At first the tracking was terrible, even 1 sec expoes had star trails.
Then I have disconnected EKOS and INDI and restarted the driver. After reconnect (thanks to the latest modification in the driver) it take on the correct position of the scope on the sky, Kstar has shown the scope just where it was before the driver restart (of course idle, not tracking now), so I just issued a goto (small movement, but start tracking) and done solve&sync. The sync issue come up at the second or third solve as usual, but I had M42 in the FOV enough, and this time I got rather good tracking. I was able to capture 20 sec exposures.
I started imaging with 20 sec expos. Some images were almost perfect, others not so good. After a while it started to drift in some direction leaving star trails. Sometimes it stopped or even reversed, drifting in the other way.
So I did a disconnect and restart again. The same result. All in all I was able to get 138 of 20 sec good enough pictures (before M42 went behind the house) with 3 or 4 restarts.
So it seems that only one solve&sync after a fresh driver restart gives better tracking than taking many all over the sky. It is not clear why it is so. In theory the tracking should be more and more precise after taking more and more syncs. But it does not appears to be so.
It is also unclear what causes a good tracking to start slowly drift in a random direction. But it seems the SoftPEC procedure as written on the Virtuoso driver page is not helping, the tracking is not precise enough to even make the measurement procedure written there (I did this imaging session with SoftPEC disabled).

By the way, during this session I used the EKOS mount control pad to put my target in the center of FOV (when the solve&sync was unable to do so), and it worked, no strange issues occured.
Actually the EKOS mount control pad uses the same method to control the driver as the joystic does. So don't expect the joystic to do any better job than the EKOS pad. These are exactly the same. It is just that sometimes the joystic is more convinient to use, especially during visual inspections. My advise is that don't spend on an expensive joystic, just by the cheapest game pad you can find. It will do the same as INDI does not take andvantage of the precisity of the joystic, it just basically use it as a 4 way hat switch.

Here is a bad one:

Here is a good one:

And here is the final stacked (corped) version:



I'm sorry I missed to reply to your joystick question.
So my original fix for the EKOS conrtol pad and joystick control is in the master trunk since months, so it is as good as it can be according to the 'state of the art' code. It has some overshoot and retrack back like behavior, but imho mostly usable. I have a plan to further tweak it but I'm not sure how much it will help.
The joystick is of course easier to use than trying to push button with a mouse, aspecially when you are sitting next to the scope and trying to look into the eyepeace. So i recomend using a joystick, or even more practiacally a game pad. The game pad has two sticks, one is moving the scope, with the other you can change the speed. The only drawback is that you still have to have the EKOS mount control pad open, to see the actual speed setting, as it is sometimes it skips 2 or 3 steps when setting with the joystick, and I don't know any other means to know it.

Last night it was a sort of clear sky, and I have experimented with the SoftPEC. @krno, with the recent code cleanup you have removed the softPEC code, as it was surrounded with "if (virtuoso()) {}" code, but imho the softPEC the way it is implemented in the code now maybe useful for any kind of mount. It is right to have it disabled (on the settings) by default, but it should be allowed to be enabled, regardles of the mount code. Also I would put the same for the other (Az) axis too.

So during experimenting with this I have done a lot's of solve&sync operation, and it seems that the "sync failed" comes when I successively do solve&sync, and the error goes below some threshold. Afther that the "solve & do nothing" still works, and if I slew to a slightly different target, the "solve & sync" works again. Even worked sometimes for the same target after a while (the mount has drifted away meanwhile". But this "close enough" is still a few hundreds of arcsecs which is obviously not "close enough" for some practical purpose, so something should be done about it.

Jon, I don't understand what do you mean by the "simulated mount has been stabilized" thing!


My proposal for the Connectivity section (please proof read it and correct it when I fail to write correct english!):


There are basically two way to connect your mount to your computer (PC or Raspberry PI/Stellar Mate): direct serial cable or Network. In either case you are directly connecting to the motor controller of the mount, the driver does not utilize the services of the Synscan Handcontroller or Synscan app.

1. Cable Connection
You are connecting the serial potr of the mount (motor controller board) to your computer, this is usually done through a USB port on the computer. The motor controller on the mount has TTL level serial connection (0V and 5V, this is very much different from the standard serial port levels, +/-9V which can be found on some older hand controllers!), so you need a Serial TTL-to-USB cable, also known as EQ Direct USB cable (see EQDIRECT interface). Many vendors sell USB to RJ45/DB9 EQDirect-compatible cables and adapters. You connect the USB to your computer or embedded device running INDI and then use the driver to control the mount.
The EQMod driver can also be used with the Synscan controller if PC Direct Mode is enabled in the handset. However, this approach can be problematic and generally not recommended (please be careful here, as the handcontroller's serial port uses RS232 levels, which is different from the TTL levels of the motor controller. Also the pinout of the RJ12 connector on the handcontroller is different!). For wired connections, using EQDirect cable is recommeneded.

Once the EQDirect cable is connected to your computer, it wil be recognised by the linux kernel as a USB Serial device, and a device file is created for it in the /dev directory. You can check that with the "ls -l /dev/ttyUSB*" command. If more than one USB-serail cable is connected (for example one for the external shooter relase of your DSLR) than you will see more than one such file (/dev/ttyUSB0, /dev/ttyUSB1, etc...), you will need to identify which one is which. They are by default numbered in the order they connected or in the order the linux kernel enumerated them.
That device file name must be written in the "Ports" field on the "Connection" tab.

You may also try connecting your USB cable and allowing the system to scan for candidate ports. USB port detection is effective on a number of operating systems.

The BAUD rate is the data rate and must be set to the baud rate of your mount (please refer to the documentation of your mount), most of the SkyWatcher devices operate at 9600 baud. Changing this number will result in a failure to comnunicate unless at some point SkyWatcher changes the firmware settings in their hardware.

2. Network connection

It is OK as it is, but I would put a screenshot showing, as this is the most common case. I would also link to the Az GTi documentation as there are very nice diagrams detailing the different cases (100% applies to our case).