Did you check the USB cable ? (corrosion!) Do you have a USB HUB ?
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo ~/Projects/indi
then go to your build directory
make indi_celestron_gps #(just like you did)
when it's over a little shell script with something like :
cp -av indi_celestron_gps /your_bin_directory
cp -av libindidriver.so.* /your_lib_directory
ldconfig -v /your/lib_directory #(so the cache is updated)
should do it.
If/when this fork sees the light of day, I'm in to test
One thing would be great : the possibility to install this evolution in parallel and with no interaction with the "historical" Kstars, so we can swap between the two of them when necessary. It's easy to change the install path to /usr/local/bin, but there is still the problem of the config files in a per user hierarchy. Though we may install the new version under a specific user of course...
AstroNerd wrote: I really don’t see the difference between a set up profile or a set up imaging train... and maybe there are more important things to be moving forward with, rather that re inventing the wheel, at this point.... it seems that as soon as people get a good stable working system that they have learned to use, then it all changes... just my opinion
You are right from a user's point of view.
But Jasem speaks from a developper's point of view. At some point, some inconcistancies may emerge, due to years of evolution step after step, that make the soft difficult to maintain and make evolve. And some choices may lead to a dead end.
So the best thing to do is to give back some logic to the whole thing by regrouping inside the same structure things that are now in separate places.
If I get what Jasem has in mind, regrouping things that have to be together under a different unique profile should simplify maintaining the separate "tabs" so when you modify something in one tab, you don't have to lose your hair because of secondary effects on other tabs
Plus, if you want to deal with parallel processing of several "optical trains", you really need to regroup things under a common flag first, before you can launch several instances of this "optical train".
So it's not about "reinventing the wheel", it's about making some place to allow future developments of a more stable software.
At some point, this evolution is probably necessary, even is it asks the users to leave their comfort range for a while ...
ChrisRowland wrote: This looks like a good idea and should make things simpler both for development and the user. I've always thought that the Mount and the optics should be separated.
One thing is the guiding system. A separate guide scope is clearly a separate optical system but what about a combined guider and imaging systen? Either an OAG with a separate camera or a camera with a guide camera integrated.
An OAG with a separate camera should be treated like a different optical system. That would allow to introduce a small focal reducer before the guiding camera to augment the field of view of the guiding camera and the chances to find a guiding star, most notably with very long focal lenghs like C11 or C14.
This is a pretty good Idea. Actually we had this discussion one year ago, if you remember, Jasem .
The idea of one optical train/Ekos is excellent. But for what I understand, you'll need to start several instances of Ekos (One per optical train) in order to achieve that, am I right ?
So maybe this is all about completely separating Ekos from Kstars, which would give more flexibility and simplicity.
Here's an example : When I start one instance of Kstars (alone, no Ekos) it drains 7.6% of processor time and 3% memory. If I need to drive 4 rigs from a single computer, I waste 3x7.6% and 3x3% memory in useless Kstars, as one would be sufficient if it could monitor my 4 rigs.
Plus, the separation would let the possibility to use any planetarium software along with Ekos. That should increase the number of potential users of Ekos, every one having his own preference on that matter... From this point of view, Kstars and Ekos would act as 2 completely separate clients of the INDI server.
And for those who don't see the practical interest in all this:
- You're in the field imaging with one rig, while watching with the second one. (And you have plate solving/autoguiding for both)
- You're imaging with 2 cameras: one in color (RGB) The other one used for getting luminance (Ha, etc) Both at the same time.
- On a distant observatory suppose you need to double some gear for security purpose. (weather station or dome opening/closing for example)
And think about astronomy clubs, schools, observatories, etc...
Happy New Year !!!
Herrhausen wrote: I assume there is no point in it other than participating people having fun.
Like you, I haven't used my scope for a long time, since 10/31 to be exact.
I guess we'll both have to wait until the summer contest
So, what you really need is one *.fit file from a series ... So you can read the metadatas with the fits viewer. Everything you need is in there. Author, date, conditions and INDI signature
Except, a fit file can be really big. Will the server support 10ths of images 15Mpx heavy ?
One other thing. Here in Europe we are in the middle of winter. To be honest, I haven't seen much stars since the end of October
What's the point in asking for pictures taken during the month of January, as long as they are unguided 30 secs Ekos generated pictures ?
Megiddo wrote: I was asking for that myself... but it's there already.
See the little icon that looks like a funnel on your screen shot next to the FW: Filter Simulator? Click, that and you will see a list of all your filters and what to do when changing them.
I use an offset of -20, -10... etc. So when my filter changes, it moves my focuser to the new choice.
I found you have to run through the focus module for each lens to see what it should be. My focuser module does mess up and create donuts, so I have to be very close to focus to begin with.
If your setup is what I see on your thumbnail :
"The proper way to focus an SCT with the primary knob is to turn clockwise past focus, and then always reach focus turning counter clockwise.
This ensures that the focus screw is bearing the weight of the mirror (when the scope is pointed up)."
This well known tip will help preserve both your collimation and your focusing. I've found it to be useful.