Rob Lancaster replied to the topic 'Mount model' in the forum. 6 hours 50 minutes ago

Yes that is correct, there is a "Mount Model" button in the Align Tab in Ekos. I wrote that feature about a year ago. First, you set up a series of targets to plate solve on, and it will run through each target, plate solving on each one. It has several features that will let you select certain deep sky objects, stars, or grid patterns to include in your target list, as well as a feature that will sort the targets so the telescope has to slew less to finish the whole set. It also lets you visualize the plate solving plan on the skymap so that you can ensure that your points are spread nicely around the sky.

There are two reasons you might want to use this Ekos feature. One of them is to build a pointing model for a mount that can build complex models such as the Losmandy Gemini System or the Eqmod system. Another reason is to analyze the quality of your pointing model (note that to do this you need to select "Nothing" in "Solver Action"). If you are analyzing the quality of your model, you would probably want to output the data to a spreadsheet file so that you can crunch the numbers.

Please note, this feature is not for everyone. There are mounts that can build complex models with numerous alignment points and the model gets better with each additional point (like my Losmandy). But there are also mounts that can only use a maximum of 3 or 4 points and don't try to correct for too many variables (like my Meade Autostar). Also, even if your mount can build a complex model, you might not really care about doing so, as many people just want to do a couple of plate solves at random locations around the sky and when their slews get close to the target, they find that acceptable.

But if your telescope can build a complex model, it can be really nice to spend a few extra minutes building a nice model to get excellent pointing accuracy, especially if you have a permanent observatory and the pointing model can be reused from night to night. This tool is meant to make that easier by helping you plan out and visualize a series of points that are spread out nicely around the sky since that is really necessary for a good pointing model. It also is intended to make the actual pointing model building process easier by automating it.

Unfortunately for Stephane's original question), I don't know that much about the EQMod mount and the INDI control panel settings for complex pointing models. But my understanding is that the EQMod pointing model that he is thinking of building is capable of a really LARGE number of alignment points.

Thanks and hopefully this helps a little,

Rob

Read More...

Rob Lancaster replied to the topic 'satellite or plane...' in the forum. 8 hours 15 minutes ago

You just need the aircraft removal filter on your telescope. . .

Read More...

Rob Lancaster replied to the topic 'guiding: via guider or mount?' in the forum. 3 days ago

Hmm that pattern in the guide drift plot looks interesting. Mine usually looks like a random circular distribution with a concentration in the center and just a few points outside the green circle. It looks like yours is preferentially favoring certain directions. That diagonal spike is most interesting.

Read More...

Eric thanked Rob Lancaster in topic Re:satellite or plane... 5 days ago
Rob Lancaster replied to the topic 'Re:satellite or plane...' in the forum. 5 days ago
Rob Lancaster replied to the topic 'Re:satellite or plane...' in the forum. 5 days ago

I have lots of astrophotos of planes going by . . .

Read More...

Rob Lancaster replied to the topic 'Re:satellite or plane...' in the forum. 5 days ago

I would say that is an airplane. the 3 streaks are the 3 different lights, the two on the wingtips and maybe one on the front. One is brighter than the other because it is the color of your exposure and thus the others are dim since they are being filtered out.

Read More...

Rob Lancaster replied to the topic 'guiding: via guider or mount?' in the forum. 7 days ago

I would recommend trying both methods to see which one works best for you. If you want to guide using an st4 cable through the auto guide port that is using “via qhy” but if you want to guide using pulse commands and avoid the st4 connection that is “via mount”

For almost 10 years (including the time before I used KStars), I was using the “via mount” method of sending guide commands through the mount connection since I figured since it’s already connected, why would I need another cable?

But then I did a side by side test where I tried calibrating and guiding using each method. I found that with my mount and my setup that it seemed to be more responsive and guided with less error using ST4 instead of pulse commands. But it was not a scientific carefully controlled test and it was just testing my setup. So I would recommend trying each yourself

Read More...

Rob Lancaster replied to the topic 'INDI on MacOS X and Homebrew' in the forum. 3 weeks ago

I did a bunch of work this summer and just about every INDI driver available on Linux in the main INDI repository and the 3rd party drivers is in the Mac KStars DMG

Read More...

Rob Lancaster replied to the topic 'INDI on MacOS X and Homebrew' in the forum. 3 weeks ago

It is in the latest kstars Mac dmg I believe

Read More...

Rob Lancaster replied to the topic 'Astrometry file downloads crashes KSTARS' in the forum. 4 weeks ago

I made the downloader last year because I thought it was a feature KStars really needed for Mac OS X. It was primarily intended for that audience because there really is no package installer for them like there is in Linux. Then it was suggested that I could make the feature work on Linux as well, but the issue is that on Linux the folder the astrometry files install to is write protected. KAuth is required to make them install in that location. I am not an expert on KAuth and as far as I know it should work correctly because I followed the instructions for using it as best I could. It often works but sometimes KAuth gives problems. So yes there are issues on Linux with that. I would like to resolve the Linux issues but I am not sure I can do anymore unless somebody who has experience with KAuth works on it.

The index file downloader should not have issues on OSX which is what I originally intended the download function for. PK, were the issues encountered on OS X or Linux? If on OS X do you have logs?

Read More...

Clive Davies thanked Rob Lancaster in topic Re:Loosing the plot 2 months ago
Jasem Mutlaq thanked Rob Lancaster in topic Re:Loosing the plot 2 months ago
Rob Lancaster replied to the topic 'Re:Loosing the plot' in the forum. 2 months ago

I do believe this issue has a solution, it is to create a udev rule that uses the port to determine the name. My script does not do that because I didn't think that we would have a device that had all of those things be the same, but I could modify it to include that option as a last resort.

I do not know if the Stellarmate web manager would solve this problem, you would have to ask Jasem about that. But certainly if his code encounters the same issue that mine did with your problem, he could modify it to have a similar solution to what I mention above.

The idea of Stellarmate is that it is a completely set up and configured system to help people who are less familiar with Linux, raspberry pis, or do not like to tinker as much. Jasem also provides lots of support if you run into issues like the one you mention here.

Yes, stellarmate does use mostly the same open source code from INDI and KStars. Jasem, myself, and a number of other folks have invested countless hours in developing free and open source software for astrophotography. Purchasing the product will support him in continuing this development and you could consider it a donation to his countless efforts to help us all. But since it is free and open source, you don't have to buy it. But the alternative is that you have to be willing to tinker and work at it until you can get it all working. Purchasing stellarmate would result in less frustration I think.

Read More...

Rob Lancaster replied to the topic 'Re:Loosing the plot' in the forum. 2 months ago

So the reason we use these UDEV rules is because the first device to connect gets called usb0 and the next will be usb1. The reason that this is a problem is because if both are already connected when you turn on your system you don’t know which one will get which name or if you plug them in in the wrong order the names could get switched. So just always plugging them into specific USB ports is not enough

I think you can also make a UDEV rule that uses the port you plug it into to define the name of the device just like my script does for the product, vendor, and serial ids. I haven’t tried this before of course since I just found out about it today when I googled your issue.

Read More...

Rob Lancaster replied to the topic 'Re:Loosing the plot' in the forum. 2 months ago

I just did a google search and found that in these cases, some people write the UDEV rule such that it uses the port that you plug the device into to determine its identity. If you did that of course then it would really matter which port you plug each device into, but at least this way they would get a unique identification

Read More...

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!