universalmaster wrote: I have a stupid question to understand this, sorry to butt in.... When you say 'the mount' issue the actual flipping etc., do you then mean the eqmod indi driver or the actual mount/electronics in the eq6 mount?
(The synscan controller is not usually used with eqmod, so I thought the remaining electronics where just dumb motor controllers without knowledge of the sky, but it would be great to know for sure where to look for mistakes like this )
Yes EQMod is a special case because the "brains" are in the EQMod driver instead of in the mount itself like in my Gemini mount. So you are quite correct in that presumption. But from Ekos's point of view it is still talking to the mount driver, and telling it to go to the object. The difference in how that command is handled would be at the driver level instead of in Ekos. Ekos wouldn't really know that the driver is handling the computations instead of the mount. That was not a stupid question at all.
Hopefully that helps!
Please understand that I was not trying to be dismissive in any way of your issue, and I apologize if you think that I was. Yes in fact there might be a bug, as I indicated in my post. I know there were some folks working on some things that were happening during a meridian flip. I think what they were investigating was related to guiding in particular, but it could be related. I did in fact see that you mentioned it started to do the meridian flip and then got interrupted by something. That is not good and that does lead me to think there might be a bug as you indicated.
I wasn't trying to dismiss this with my post, but because of the way the software has to do meridian flips, as I explained in my other post, it is possible that the mount was properly told to go to the object, but maybe it was just a little too close to the meridian, so the mount finally decided it didn't need to switch sides to go to that object. I have a mount that often when told to go to an object that is a short distance away from its current position, or even at the same position, it will slew past the target, and then come back to it. I was thinking that my mount might look like it is doing exactly what you were describing when told to go to an object.
I was just thinking, as I believe some other posters had mentioned, that maybe increasing the hour angle a little might help. This had already been mentioned to you as a possible solution, and from the discussion that was going back and forth I got the impression that there was some misunderstanding about why increasing the hour angle might help solve the problem. I am not guaranteeing that it will solve the problem and as I said there could still be another bug that caused the interruption. But there is a pretty good reason that it might help with your issue and I was just attempting to explain why that is. I meant no offense, I was just trying to relay some information because I know a lot about how the software works because I volunteer my free time to help work on it when I can.
So you are correct if you are connecting to an already running INDI server on the remote device. If you connect to that running INDI Server, KStars will get the information about the running drivers not whatever ones you select in the profile on the local machine.
But, if you connect using Ekos and tell it to use the INDI Web Manager, you can configure everything from within Ekos. You can set up your profile exactly the way you want to on your local machine, and then when you tell it to start, the Web Manager on the remote machine will update your profile on that remote machine to reflect the profile you selected. If the profile doesn't exist on the remote machine, it will be created. Then the selected and updated profile on the remote machine will be used to start the INDI server.
So it is very important actually. And it is a much simpler way to work with the web Manager.
Here is a screenshot of how it should work:
I have a thought. Perhaps you put the wrong folder path to restore into the script?
So I think you are misunderstanding something about the meridian flip. Mounts generally do not really have concept of a meridian flip, and they will not do it automatically, nor can they be told to do one using a simple command. Software like Ekos can use the mount's features to effectively perform a meridian flip, but you need to know how it works to use it effectively.
Two key points:
1. Most telescope mounts will go to an object and then when you tell them to track the object, they keep tracking and tracking and tracking until either the telescope limit is reached or it hits the tripod legs.
2. Most telescope mounts, when told to go to an object will make the telescope orient itself in on whichever side of the pier makes the most sense (Note: the most sense in the mount's mind, not always in your mind). You cannot tell most mounts which side of the pier to orient themselves on.
So to make pier flips happen, typically what will happen is the software will wait till an object crosses the meridian (or goes an angular distance past the meridian that you decide), and then it will issue a goto command to the object (even though it is already pointing at that object). If the mount thinks that it would make more sense to go to the object on the other side of the pier since it is past the meridian (which is what you are hoping), then the meridian flip will happen when the goto command is issued. If the object is really close to the line though, the mount may not actually do the meridian flip, because it decided the scope was able to point at this object on its current side of the pier.
Now there could still be a bug, since I think there are some people currently working on the code for alignment, guiding, and meridian flips. But from your discussion I don't think you understood how it was supposed to work.
Hopefully this helps,
Ok, there is probably room for improvement. This was Jasem's solution to the problem 2 years ago when I told him about the issue with remote drivers not showing up because they had no xml file on the local system. There may be better ways to fix it or it could probably be improved upon. I can let him know there is an issue with overwriting drivers.
Hmm, I will check it out. But I just tried it and it worked. . .but I will look at it again. Maybe I made a mistake, but I don't think I did.
I mean honestly, thats all it does is copy files. . . so yeah you can manually do it.
Ok I just went back to the old command but added a delete first. Please try it again, thanks.
Ok I just pushed a change to the repo. Can you see if this works better?
So the issue was that the code that I wrote worked great as long as the kstars and indi directories didn't exist, but if they did, it got put into sub directories.
indidrivers.xml is certainly not obsolete. It is a very important file. This file is how KStars can list drivers for remote INDI Servers in the INDI profile and connect to them, even though your current computer doesn't have those drivers installed. If KStars does not have that file, then the drivers listed under "remote" would only include the drivers which are actually installed on the computer you are currently using. For an example, let's say you have a raspberry Pi and it has an SBIG driver on it. You are accessing it from your laptop that doesn't have 3rd party drivers installed. So that means that it can't see the xml file for SBIG since it isn't on the computer. So when you select "Remote" in the INDI profile, you can't select an SBIG camera in the profile to start it up, since it isn't in the list.
There are some drivers that can't be installed on some systems and not on others because the don't compile or work on that system. This file makes it possible to use those drivers remotely.
The file should not prevent other XML files from being loaded, so if you have custom drivers or 3rd party drivers that aren't from the 3rd party Repo. But it should make it possible to load drivers that aren't on your system so you can run them remotely.
Birthdate19. 07. 1980
About meEven though I am relatively young, I have been an astrophotographer for about 20 years. Within the last 5 years or so, I have taken my hobby to new heights. I built my own 10 inch telescope including grinding the mirror, bought a wide field newtonian for wider fields, acquired a much better mount to put them on (separately), got an SBIG camera for cooled CCD photos, modified a Canon XSi for better DSLR photos, and got lots of accessories. I have been doing all of my astrophotography with a Mac computer. I have basically made my own portable observatory, everything is carefully organized into boxes that I can load into my car in about 20 minutes. I take these things to dark skies and do lots of imaging at star parties.
I found out about INDI in May 2016 when Pleiades Astrophoto sent me an email about including an INDI client in their software. When I investigated further, I found out about KStars and Ekos. I quickly realized that I could install everything on a Raspberry Pi, velcro that to my scope, and use VLC to configure it from my computer using wifi. I have implemented 2 modes. The first is using the Raspberry Pi as an INDI server and using my Laptop as a wireless client using either the EKOS VM (running KStars and Ekos) or PixInsight as the client software. The second is using KStars and Ekos on the Raspberry Pi and controlling everything through VNC. Both methods have allowed me to cut the cords, move to WIFI control, and make all USB connections shorter. The second method also allows me to put my computer to sleep after I have configured the PI to do all the work. All I have to do is check in once in awhile to make sure it is working properly. So far this experiment is going very well, but I did have to work out quite a few issues along the way. I have been keeping a couple of logs of everything I have done to make it work, however, which is very useful. There are still a few problems, but the system is fully functional. It is a good thing it is summer so I have time to work on this!
The remarkable part is that you can automate your astrophotography setup, make the connection wireless, simplify the software by just running one program (KStars/Ekos) that runs it all, and you can make the connection to the devices separate from that program using INDIServer. (The last item is important because if KStars/Ekos were to crash, the devices would still be running on INDIServer.) And all of this will cost you around $100 including the Pi, a case, a 32 MB microSD card, the software, and a powered USB hub. There was a bit more work involved in setting it up and figuring it all out, but it was worth it.
I am an:
Physics and Computer Science Teacher
Delaware Astronomical Society Member
Mt. Cuba Observatory Education Associate