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!

Read More...

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.

Read More...

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.

Read More...

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):



Read More...

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.

Read More...

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.

Read More...

Jon,

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:


Read More...

Jon,

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!

Read More...

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

Connectivity

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 192.168.4.1, 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).

Read More...

Also the network connectivity is vrey well documented on the AzGTi driver's page. Everything written there also applyes here. So mybe we should just link to there.

There are a lots of things (like site management or motion control) that is documented on many driver page, which are the same, as these are the services of the indi_telescope base class. Maybe these should be collected to a central document, and every driver should just link to that.

Read More...

Oh, I see there are 6 different driver documentation for skywathcer mounts. I think here is due some consolidation.
At least your "SkyWatcher Alt/Az (Dobsonian) " and "Skywatcher Virtuoso (Alt/Az)" documentatin should be merged, as these are about exactly the same driver. I think only the softPEC portion of the Virtuoso documentation should be kept, as these is the only extra information there.

The "Connection" section needs some improvements. It is too complicated, and sometimes technically not so precise. For ex: the cable is not FTDI-to-USB, it is TTL serial-to-USB. FTDI is a maker of one type of such chipset, but there are others too. The device file /dev/ttyUSB0 does not identify the USB port, it identifies the device (cable with converter chip in it in this case). It is not change if you plug the cable into a different USB port. It changes if you pull and plug other Serial-to-USB cables, as these are (by default) numbered in the order enumerated by the kernel. But if you have only one such device (one cable connected) it will always /dev/ttyUSB0, unles some error occure and some yet.-non-existent device stuck in the mind of the kernel. Also there are methods to lock the device name to a particular cable (by serial number), but these is clearly out of the scope of this documentation.
Actually the connection needed for our driver is exactly the same as the eqmod driver, so we can take merit from the eqmod documentation. For example there the cable needed is named "EQDirect cable", we should stick whit that.
Also you menion that one can connect through the handcontroller, but you does not mention that is must be done in "PC direct" mode. It is important, otherwise it will not work.

I will try to come up some replacement text suggestion, just need a bit of time for that.

I think trackin should be ON during plate solving. Otherwise how can you utilize the result? The solve tells you where the mount was pointing at the time of the picture taken. But not any more...

I have tried guiding recently (on 26 dec, I think). I don't think anything has changed in the code that involves guiding. Jasem explicitly said: "the guiding code is a mess, leaving for an other time". Has that other time arrived yet?
I don't think slew rate impacts guiding. In my understanding these are totally different things.

I have just realized what SoftPEC is, it is disabled in my setup, I will try to experiment with that.

Read More...

I don't fully understand the intended working of the sync TAB in EKOS, but there are three choises: "sync to target", "slew to target" and "do nothing".
I think "sync to target" should tell the driver where the scope is actually pointing, and the driver should update it's position so that the crosshair points to the newly learnt position and keep tracking that position.
In my understanding the "slew to target" should do the same, but affter that it should issue a goto to the original target.

The "AltAzSimple" driver behaves something like that. But the APIMount driver does not. After a "sync to target", it updates it's internal knowledge about the scope actual position but leaves the tracking target at the original position so the tracking code feels a tracking error and corrects. Effectively getting the same result as the "slew to target".
I have come to the conlusion that the difference lies in that the APIMount driver keeps the tracking target in Ra/Dec coordinates but the Simple driver keeps it in AltAz coordinates. At sync operation the Ra/Dec coordinates of the scope gets updated, but the AltAz coordinates remains the same (the sync operation updates the Alt/Az -> Ra/Dec mapping), so the driver keeps tracking the same point.

To answer to your question: sometimes plate solving fails for me without any real good reason (there seems to be enough stars on the taken image, the actual target is close enough, no good reason), sometimes later (maybe after moving the scope a bit) the plate solve just succeds.Also sometimes I got the error (after succesfull solve) "sync failed". I have no idea about the reason. Seems random to me, but maybe I just dont see something.

I have no real success with guiding. I have succeeded the calibration a few times (most often than not, just calibration fails). But after start tracking it tracks very rudely, much worse than without tracking. I have given a try to PHD but no success. After calibration it has strated tracking but it just diverged instead of tracking.
So I do multi-hundreds of short (10 sec or so) expos by splitting it apart, say 50 picture at a time, the re-center the target and shoot an other 50. When it drifts so much that the target drifts away in 50 shots, the individual pictures will be bad qualtiy (due to poor tracking) anyway. And as you said, image rotation is inevitable for AltAz mount so one must have enough headroom on picture framing anyways.

Read More...

I maybe missing something, but where can I find this draft?

Read More...