Jose Corazon replied to the topic 'Celestron focus motor' in the forum. 2 days ago

Bart wrote: Indeed Jo,
I used one of those slim line.
Nema 14 could also be ok, but I had the 17 lying around and a bit of headroom in the torque is nice to have.
I prefer the Trinamic fdrivers, for they are just absolutely smooth, which just 'feels' good.

Yes Mohamed, the code to control the stepper motor driver (microstepping, speed, acceleration etc) is in the Arduino code.
I'm busy now, but will upload files later this week.

Cheers!


Bart, where can I find the Trinamic driver code? Can you post it?

Jo

Read More...

Jose Corazon replied to the topic 'Celestron focus motor' in the forum. 4 days ago

mhammady wrote:

El Corazon wrote: The DRV8825 stepper controller allows you to select microstepping down to 1/32, i.e. 32x200=6400 steps/rev. In fact, you can use any microstepping mode in 2x intervals.
I am using my NEMA17 at 1/32 microstepping and the resolution is far better than required for my telescope, so you can try out how much resolution you require.


Thanks Jo for explanation. Is this settings from the driver interface or the Nano code?


Thank you
Mohamed


There are three physical microswitches on the DRV8825 control board. The DRV8825 spec sheet will tell you how to set them to have 1, 1/2, 1/4, 1/6, 1/16 or 1/32 microstepping modes.

In this video I demonstrate how they work:

www.dropbox.com/s/7pwzxom3mpi0z1m/Arduin...serInAction.m4v?dl=0

Read More...

Jose Corazon replied to the topic 'Re:Celestron focus motor' in the forum. 4 days ago

mhammady wrote:

El Corazon wrote:

mhammady wrote:

Bart wrote: Hi mate,
I have 3D printed a focus motor attachment & coupler for my C8.
I've shared a photo of my setup before here, I guess you can find it there.
What I like is that it still has a (big!) handwheel.

Would you like to have the design?
It uses a direct drive very flat Nema 17 stepper motor and the SilentStepper drivers (TMC2130) on a breadboard still.

Works flawlessly and runs absolutely smooth. I have attached a temp sensor and configured it to play well with the Moonlite protocol.

Cheers!
Bart



Hi Bart, thank you and would appreciate if you can share your 3D designs. I’m in the process of building mine.

One more thing is that your motor is much lighter and smaller (as I can tell from pictures) from the one I got, can you please also share your hardware specs as well?


Thank you
Mohamed



I use the MyFocuserPro, not the MyFocuserPro2 IDE, but assume much of it is interchangeable. The cranking power of a regular NEMA17 is plenty to lift a truck attached to a camera (figuratively speaking). A NEMA14 should be plenty. You can drive both from a DRV8825 stepper controller.

The beauty of building your own focuser is that once you have done it once, adapting it to another telescope is easy.

Also, with a DRV8825 you will have a stepper resolution of 6400 steps/rev, i.e. ~ 0.05 degrees, which more than likely is far better than the mechanical tolerance of your focuser.

All I can say is, I built one based on the MyFocuserPro (not 2) instructions and the result could not possibly (repeat; possibly!!) be better.

Jo

PS: Looks like Bart is using a slim version of the NEMA17 ( smile.amazon.com/gp/product/B00PNEQ79Q/r..._title?ie=UTF8&psc=1 ). I have that as well, but have not implemented it yet. Should work fine, though, I assume.


Thank you Jo, what confuses me a little is that the specs of the motor you mentioned in Amazon is “This is Short Height Bipolar Nema 17 stepper motor with 1.8 deg. step angle (200 steps/revolution). “

Is this specs still capable of 0.05 degree/step?

I would prefer using a lighter motor as the one I got is much heavier...


Thank you
Mohamed



The DRV8825 stepper controller allows you to select microstepping down to 1/32, i.e. 32x200=6400 steps/rev. In fact, you can use any microstepping mode in 2x intervals.
I am using my NEMA17 at 1/32 microstepping and the resolution is far better than required for my telescope, so you can try out how much resolution you require.

Read More...

Jose Corazon replied to the topic 'Re:Celestron focus motor' in the forum. 4 days ago

mhammady wrote:

Bart wrote: Hi mate,
I have 3D printed a focus motor attachment & coupler for my C8.
I've shared a photo of my setup before here, I guess you can find it there.
What I like is that it still has a (big!) handwheel.

Would you like to have the design?
It uses a direct drive very flat Nema 17 stepper motor and the SilentStepper drivers (TMC2130) on a breadboard still.

Works flawlessly and runs absolutely smooth. I have attached a temp sensor and configured it to play well with the Moonlite protocol.

Cheers!
Bart



Hi Bart, thank you and would appreciate if you can share your 3D designs. I’m in the process of building mine.

One more thing is that your motor is much lighter and smaller (as I can tell from pictures) from the one I got, can you please also share your hardware specs as well?


Thank you
Mohamed



I use the MyFocuserPro, not the MyFocuserPro2 IDE, but assume much of it is interchangeable. The cranking power of a regular NEMA17 is plenty to lift a truck attached to a camera (figuratively speaking). A NEMA14 should be plenty. You can drive both from a DRV8825 stepper controller.

The beauty of building your own focuser is that once you have done it once, adapting it to another telescope is easy.

Also, with a DRV8825 you will have a stepper resolution of 6400 steps/rev, i.e. ~ 0.05 degrees, which more than likely is far better than the mechanical tolerance of your focuser.

All I can say is, I built one based on the MyFocuserPro (not 2) instructions and the result could not possibly (repeat; possibly!!) be better.

Jo

Read More...

Jose Corazon replied to the topic 'Parking after polar alignment' in the forum. 6 days ago

avarakin wrote: It looks like there is a new feature implemented in the Polar Alignment procedure, where after alignment is complete, the mount is automatically parked.
I think this feature makes the alignment more tedious - you have to wait till mount slews to parking position, then unpark etc.
This becomes even more problematic if parked position is not pointing to north pole.
Is there any way to disable this feature?


Yes, just unselect 'AutoPark':



Read More...

I had the same problem about a week ago. Fortunately I realized it after the first 10 frames and before I went under for the night.

I fixed it by compiling the drivers including 3rd party drivers from sources. It has not recurred since (but I also have not updated the drivers in the meantime).

Read More...

rlancaste wrote: Jo,

This is certainly a good idea for the future, but right now unfortunately it might be kind of hard to implement. As I mentioned, it is slightly hard to say exactly which index file will solve any particular image. You can say that certain index files tend to work pretty well with a certain setup for sure, but you never know with certainty which exact one will solve it. So then the question would be, how would we determine which indexes to load? Do we load just the ones closest toe the scale we think it is? How much bigger or smaller do we go? Should that be somehow user configurable?

Also I would want to make sure that whichever way we do this for the internal solver, it will also work for the local solver as well. Right now, both the internal and external solvers are configured to just load all the indexes the given folder list. It is certainly possible to load just specific files for both the internal and external methods, but that would require a significant change to the code. Right now the only options are "load all the indexes" or don't do it and load them sequentially. I have considered a third option to have it automatically determine which one to do. This would be like a fourth option?

Another problem is that I'm not 100% sure that the RAM calculation that I have in there is perfect yet. It is supposed to shut off the "load all indexes in memory" option if there is not enough RAM. Before we would play with loading only certain indexes, I would want to be certain that that calculation works.



Rob,

Making it user configurable would be one option. What I did was just move all the index files the astrometry page in the solver options told me were optional (i.e. those marked with an asterisk, presumably this is based on the calculated FOV of my telescope (?)), into a subfolder so they would not be loaded. That made a TREMENDOUS difference in speed.

I was hoping that would be easy to implement, to the tune of adding another check box "Do not load optional index files for parallel solving" or something to that effect.

Although my Pi4 has 8 Gb of RAM plus another 8 Gb of Swap Space on an SSD, and the total size of the index files I have downloaded is 5.6 Gb, the solver consistently determines that there is not enough RAM to load them all into memory. However, just moving the largest sets (those >1Gb) into a subfolder where the solver can't see them, makes the solver happy and I am rewarded with a 5 fold speed increase.

The advantage of having this option of initially loading only the non-optional index files would eliminate the need for moving the optional files into a subfolder, thus keeping them accessible to the solver if parallel solving fails. It could then fall back to sequential solving, now making use of the entire data set.

I thought that was the way the code was structured anyway, but I understand that if that is not the case significant changes might be necessary which do not appear justified at the moment.

But please keep this in mind nevertheless. The difference in speed is indeed enormous and many of us are using small SBCs with limited RAM to run their rigs. That means parallel solving might always necessitate manually removing optional index files - and moving them back in those special cases when the solver fails. That just feels a bit klutzy.

But, by all means, thanks again for building this fantastic solver!

Jo

Read More...

rlancaste wrote: Hi Alan,

So the message you are referring to was actually a function of KStars, not astrometry.net. Yes we could make it print that message again saying that you don't have the right indexes, but actually I didn't like that message because it was often incorrect. It would just say you don't have such and such index files even though you didn't need them for your image scale and I got tired of seeing that message. It is actually hard to say which index files you actually need to solve a particular field size. Yes, the index files are definitely meant for certain scales, and we could just do a table lookup based upon the scale size you/Kstars indicate the image should be and to just search for the index files with sky marks that size and the ones a little larger and a little smaller than your scale. But one issue you might encounter is that sometimes the index files that are significantly larger or smaller than your scale are the ones that actually solve the image. So it can be hard to say exactly which ones should be included. I did write an algorithm in the index file downloader a few years ago that attempts this. Maybe we could use similar code here. I mean I guess it is just a warning so you could ignore if it is wrong. We can look into it.

Thanks,

Rob



Rob,

The parallel solving speeds up the solver significantly (about 4-5 fold under my conditions). It now solves routinely in under 1 s on my Pi4/8Gb, but it takes up to 5 seconds otherwise. However, for this to work I need to restrict the astrometry files the Solver loads into RAM to a minimum. Since I am using a wide-field scope at 250 mm focal length, that is feasible on a Pi4. However, when I select all the astrometry files needed to solve on any of my scopes, including an 8" RC, then the file size exceeds the RAM available and solving slows down dramatically.
At the moment, I am managing this by manually moving the astrometry files that are not needed for my short focal length into a subfolder from which they are not loaded. I then can manually move them back when I am putting a larger scope on the mount.

What I am wondering is whether it would be possible for the Solver to just load those files it ANTICIPATES it needs for parallel solving BASED ON FOV into RAM and ignore the rest for first pass. Only when solving is unsuccessful, it would then include the remainder of the astrometry files for sequential solving.

That way, it would not be necessary for the observer to make that decision and then, if solving fails, having to move back larger astrometry files into the folder on which the Solver is looking for them.

I would think it should be possible to do that in an automated fashion?

Thoughts?

Jo

Read More...

starman99 wrote:

starman99 wrote: Is this latest release included in Ekos/Kstars nightly? Thanks for all the work on it - looks exciting!


I'm running Ubuntu Mate 20.04 LTS. Is there a stable version of Kstars/Ekos that includes the new solver?



The current nightly works flawlessly for me. I suggest installing that for the time being.

Read More...

Jose Corazon replied to the topic 'EKOS autoamted FLAT and ADU%' in the forum. 2 weeks ago

xsnrg wrote: There is a lot of information out there about capturing flats. It really depends on the camera. You want a good signal, but do not want to saturate pixels. My 1600s are not true 16 bit cameras, so do not have full 65535 well depth available. Even though they call them 16 bit, they are actually 14 bit with bit shifting, so this affects maximum ADU.

Here is one such thread about flats: www.cloudynights.com/topic/579728-flat-f...the-ideal-adu-value/



I have set my ADUs for flats for the ASI1600MM to 23,000 +/- 2000 ADUs.

The tolerance is really not that critical, as long as you are in the linear range and do not clip at either end.

As Jasem wrote, 20,000 - 25,000 is a good range also for the ASI1600.

Read More...

Cerro Torre wrote: @Jasem,

just a side note:
You have updated the dependecy list in the README.md

On KDE neon I get this error message:

Starting pkgProblemResolver with broken count: 1
Starting 2 pkgProblemResolver with broken count: 1
Investigating (0) libraw-dev:amd64 < none -> 0.19.5-1ubuntu1 @un puN Ib >
Broken libraw-dev:amd64 Hängt ab von on libraw19:amd64 < 0.19.6~202002010816~ubuntu20.04.1 @ii mK > (= 0.19.5-1ubuntu1)
Considering libraw19:amd64 10 as a solution to libraw-dev:amd64 9998
Done
.....
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
libraw-dev : Hängt ab von: libraw19 (= 0.19.5-1ubuntu1) aber 0.19.6~202002010816~ubuntu20.04.1 soll installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.



Have you tried:

sudo apt-get -o Dpkg::Options::="--force-overwrite" -f install

Then run the installation again

??

Read More...

Bart wrote: Hi,
I have a similar issue. I just didn't want to start a new topic for it, but now you brought it up it's good to contribute:

I've had two occasions in which I had my nice and shiny data the next morning and found out that the ASI1600mm recorded everything in 8 bit, while the day before it was data as expected at 16 bit depth. In the mean time I did not change this.
It's happened some days later again (and again totally unexpected) I happened to catch it after a quick check of one of the FITS. I hate to make it part of my work-flow to check if all settings keep being set as I set them before.

I've made a screen capture of it. Of course I had no logging on, because who expects a failure, right?



-Really- tiring that Stellarmate is so unpredictable/ unstable!



I experienced the same problem the other day, fortunately I saw it after 10 frames before I let the rig run by itself overnight. I tried switching back to 16 bit, but couldn't. Restarting Kstars did not help either.
I finally compiled the drivers fresh from the source. Then everything worked fine again. So far.
I did not open a topic, because it seemed like a fluke with not much to go on. But reading this, I now think there must be a more systematic problem.

Jo

Read More...

knro wrote: Fixed in master.


Confirmed.

Read More...