Andy_ZH

Hello Bill, sorry for the very late reply. The flu got me and the whole family. I have been out of business for quite some time, but now slowly recovering. Which drivers do you have? When I read about the 1/8 ... 1 / 16 micro steps, my first thought is: stop, don't do that! Use the new TMC drivers, they have a much better micro stepping resolution up to 256. Before anyone comments: Yes, I know that the 256 resolution does not result in the same gain of position resolution. But whenever you tried these (e.g. TMC2209), you will never go back to the Polulu or TI drivers. With the 2209, you will not be able to feel any stepping at low speeds, and you will hear no noise. They are just quiet. The new drivers cost about 10-20 USD per piece, but I strongly recommend to use these drivers. Even more, they can handle higher currents (if you need the torque). > Using steppers you have a top frequency y limited by resonance and a bottom one through diminishing returns in micro stepping. The stepper drivers maximum speed depends (nearly proportionally) to the driving voltage. This is similar to any other motor, and depending on the motor characteristic (and voltage), you could expect 600-2000 rpm (max speed). The code that I have (it is not yet very far progressed) is only meant for 2208 or 2209 drivers, since it communicates with the driver with UART, i.e. my PiZero Code tells the driver via the serial interface: How fast to move (there is an oscillator on the driver), the current settings, operating modes ("stealth chop" for low speeds). And in case of a nonsinusoidal motor design, you could even save a lookup table on the driver which corrects for nonlinearities. So, I am not trying to convince you to use my code (you can have it, though). Just in case you are trying to continue with steppers (and not servos), please use the luxury variant of the driver, and not these shaking and vibrating 4988 drivers. The TMC drivers are pin compatible and give the same functionality as the legacy drivers. Andreas

Hello Osprey, wow, nice pictures! This will not be a horseshoe mount. This will be a Dinosaur-Shoe mount! My misunderstanding before was that I thought the declination axis will be at the horseshoe level, but as I can see now it is not, and therefore the eye piece end (in your case "camera end") is more accessible. Just some additional thoughts on the threaded bar: Possibly it is a good idea not to leave all the weight on the threaded bar, but have 2 roller wheels to take the main weight, and the bar / screw is pressed by a spring or something similar to generate pressure/tension onto the horseshoe. And you could try to initialize the mechanics with a second threaded bars: To the first one, you could grind a bit of roughness into the surface with (fine!) sand paper in order to create the first thread, and later on you could replace this by the smooth one. As I can see, you are making quite some progress with your horseshoe. I should add a disclaimer to the offer of my raspberry pi stepper driver source code: My project is still at a quite early stage, and currently it contains just the code to drive the 2 motors and get an accurate step count via an interrupt kernel module. I did quit my job some days ago in order to take care of my kids for a while (the little one is now 1.5 years). Though I will have more free time to spend with my hobby, my progress with the software might not be as fast and predictable as your hardware is advancing. I guess that I still need some 2-3 months to get basic goto features to work. So, in case you plan to have everything ready earlier (and more reliable / tested), Onstep should be your preferable software. > The choice of whether to drive a stepper or a servo is purely about your ability to measure and manage the speed, in your case either will do fine, for geared or friction drives. There is no difference in 'drift' susceptability. When I mentioned the possible slip with the friction drive, I had in mind as "servo" the closed loop between the DC motor and the horseshoe itself. And then in this case, you would need encoders on the horse shoe. With the thread or any drive that involves teeth, the encoder on the horseshoe would actually not be necessary, but the encoder can be on the motor shaft, or you could use a stepper instead. Of course, in case you compare a servo motor with an integrated encoder, they are more or less equivalent. The scope that you are using and any discussion about is now a bit off-topic: I am still scared about your refractors strong chromatic aberration. Did you already try your scope in combination with a camera or visually at a star? My experience is that with an eyepiece, the human eye is quite forgiving and can adapt its focus, but when you use finally a camera, there could be some disappointment. And I think it would be a pity if you build a fine mount and your optics are quite limited at the end. However: In case a H-alpha filter (or any narrow-band filter) is used, the problem should be gone immediately. Therefore, I am asking myself why people are even using APO's for the sun and H-alpha? A very simple single element lens should be perfect for any solar scope. Of course, there will be other aberrations (spherical, koma, astigmatism), as far as I know the biggest problem of refractors is their chromatic aberration. best Andy

Hi Osprey, thanks for the pics. I have some more questions. Sorry if I seem to be pedantic, but I just cannot imagine some things: You are aiming for solar observing. The sun runs on the ecliptic. But the (e.g. at equinox), when you scope points to the ecliptic, the scope will be within the plane of your horseshoe. Do you have enough space there? Without mirror, you will not be able to access the eyepiece point. Even worse, in summer when the sun is above the sky equator, your observation point will be between the horseshoe and the floor. Or did I get something wrong? I would have guessed that for a refractor, a fork mount would be more appropriate. > Writing software to enable a mount to star-align & goto is orders of magnitude more complex than just tracking. Well, yes, there is some more coding involved, but this is also no rocket science, but some more advanced geometry calculations. The difficulty comes when you try to do too much within a microcontroller (Arduino) where C is the only option of programming language. I described my planned Raspberry Pi project here: if you like, I can share my code with you. It is not yet ready for open-sourcing, but I can drive two stepper motors quite precisely. There is no need for an Arduino, my software runs just directly from the pi and it simply needs two 2209 drivers. Your refractor seems to be quite fast. Will you use some H-alpha filter with it? If not, I wonder if it will have an enormous chromatic aberration. Friction drive (without teeth): This would be ok in case you just do visual observations. But since there are no teeth on a friction drive, your tracking / goto could drift (=slide) away over time. Therefore, you would also need some encoders in order to get feedback of your actual position. I believe with a pure friction drive, stepper motors don't make sense anymore since you are loosing the advantage of the stepper with its discrete steps. How about the following suggestion: Use a threaded bar to drive the horseshoe. With your wooden horseshoe, after applying some pressure and driving the horseshoe with the threaded bar for a while, it will grind its own thread into the wood. For instance, a M12 threaded bar has 1.75 mm per turn, which would give you your necessary gearing ratio. E.g. with a horseshoe circumference of 1.75 meters, you would have 1000 motor turns per day, which should be perfect. Best Andy

Hello Bill, as I wrote in the other thread, I am also tinkering with my mount, therefore I'd like to join the discussion. I think something is missing in the data that you gave. I think for sure, you cannot drive your mount directly from the shaft of your Nema17 stepper motor, and this is probably the reason why the step count in the calculations above is so little. Horseshoe mounts are sometimes driven on some kind of tension wheel, and if this is the case for your mount, you have to include the size ratio between the horseshoe circumference and the driving wheel. > Armed with this minimal amount of information, first: is there software that already exists for horseshoes so I do not have to go through all the math? Except of considering the mechanics, there should be no difference between the horseshoe mount and any other mount , es e.g. a fork mount. Therefore, you could use any software that you can find online, e.g. onestep. > Third: How different is solar tracking from "regular" tracking? As mentioned above, there is nearly no difference except a little higher speed of the sun. Please note: the moon also has its own speed. But I would not try to calculate the accurate number of steps in too much detail beforehand. Usually, you can fine-tune this later when your hardware is ready. A rough estimation would be sufficient. In my case with the Vixen new Atlux, the calculation is: 180 teeth, driven by a worm, with a 2:1 pulley / belt results in 1 degree per stepper motor rotation. With 200 steps and some micro steps, I am just a the (my) limit of accuracy. Another degree of freedom is that we could use a 0.8 degree / 400 step motor. But also as mentioned above, in case you don't have a worm that drives your mount, you probably need to have an additional gear to increase your stepper accuracy. For direct driven 3d printer extruders, you can get for very little money stepper motors with attached gear that would probably fit. I made good experience with Trinamic 2209 drivers, they are also excellent when driving from a Arduino. They have less on resistance which reduces the necessary cooling of the driver. Could you please add some kind of picture or drawing of your mount? From books and pictures, I remember that real horseshoe mounts are used by dobsonians, and I cannot imagine a refractor sitting in the horseshoe. Usually, the scope is not accessible at the horseshoe end, and that's why it was meant for dobs. Best Andy

Hi Tony, thanks for your in detail reply and your advice, i will for shure consider some of your points. I have to admit: My efforts looking at Reprap equipment is not really low cost driven, it is fun driven. I know about the microstepping / accuracy issue. Actually, I can see this discontinuous motion just by looking at the motor shaft operating at very low speed. However, with 0.25 rpm, 200 steps per revolution and microstepping, I don't think this will be an issue. Currently, I will not do any further action until I have my scope with the new setup outside. Even though the microsteps are not 100% accurate, they provide some kind of smooth motion which will (as a first guess) lead to an tracking error of some arc seconds. Later on, when this seems to manifest as a real issue, i can a) go for a 0.8 degree / step motor or b) fine-tune the stepper driver microstep table. This driver is able to store a specific current in a chip-intern table for every microstep. I guess that the biggest influence for the observed discontinuous motion is the motor design itself, which is not behaving as an ideal (n-pole) permanent magnet synchronous machine, but the sinusoidal current rotation is leading to a non-sinusoidal field rotation within the motor. I know a short article where someone measures the stepper (and driver) microstepping accuracy: https://hackaday.com/2016/08/29/how-accurate-is-microstepping-really/ and I could do a similar measurement, but being pragmatic and use the setup under the sky will be more efficient. > Open source astro engineering projects and getting their assistance would be wise I did find a Pi image called "Astroberry", this looks quite promising. My option is: I will continue with my project (and I have fun with it), and later on it could be a nice extension which could be included in Astroberry, for instance. > Another consideration is the emulation of common mounts. There is a huge installed base of Skywatcher/Orion amateur mounts globally, for example, but only one TCS project (EQDrive out of Ukraine) I’ve seen that exploits that ecosystem by adopting the SW mount controller command set (perhaps Yes, this is indeed true, I will keep this in mind. Also thanks to Brown Dwarf for your reply. I know that SD cards could make problems. I just got a bunch of them for 10€ each. At the moment, I am just doing a backup image of the card, with the expectation that it could die anytime. On the other hand: How many hours per Year do I use my mount / scope? I know some people who are outside under the sky at every opportunity, but even wenn the card will be used 10-20 nights per year, I expect them to live for some years. So, thanks again for your opinion. I will try to use this thread as an update history for my project. Andy.

I added a picture of my mount. The raspberry pi zero is in the red plastic box, with some GPIO wires going into one TMC2209 stepper driver. The Pi zero is small enough to be placed inside the mount. I will replace the original metal mount cover with plastic. Otherwise, the Pi's Wifi signal will probably be screened too much. A mobile phone external battery pack is sufficient as power source. This could be integrated into the mount, too, or it can be attached with a USB-C.

Hello all, this is my first post at SGL, and it will be quite long. I am not native a English speaker, so please excuse any mistake. I have quite some plan with my telescope mount and its goto control, and I am looking for some feedback and comments. If somebody else did a similar project, please let me know. And please feel free and encouraged to make suggestions, ideas, critics, etc. The story in a few buzzwords: Raspberry Pi Zero → direct control of TMC2209 stepper drivers via the Pi's Uart serial interface to drive my telescope mount. I am writing a software (optionally: open source?) to control the mount. The language will NOT be C, as typically used for Microcontrollers (I know for instance OneStep) I am using Kotlin, which is a more advanced JVM language. I think this should be enough information to filter the readers who are interested in reading the rest of my post. Now the long and detailed story: My professional background: I am a physicist, and did a PhD in EE (Power Electronics). Later, I became software engineer. Besides being fascinated by Astronomy, I am a tinkerer (Reprap 3D printer, electronics, …). I did grind my first mirror (a 6'' Schiefspiegler) when I was 15 years old, and I built the cookbook CCD cameras in the 90's. After many years without a telescope (study time, relationship, ... ), I settled down with my family, and I started to get back to Astronomy. Recently, I did by a quite a massive second hand mount: the “Vixen New Atlux” from another other stargazer in Switzerland. My opinion is that the New Atlux' mechanical design is superb. It has (had...) internal wiring, the counterweight bar can be hidden in the mount for transport, good polar alignment screws, it has an excellent polar finder with a dimmable LED. But on the other hand the electronics: two weak servo motors in combination with the incredible Starbook 5.... Seigh... the starbook...(!) it is, well... the mount is just superb, and no more comments about the starbook game boy, which shall rest in peace at the garbage dump. I removed the servos and all electronics, and I put 2 stepper motors into the mount, which are coupled to the gear with a timed belt. My original plan was to put an Arduino into the mount in order to control the steppers. I have an old goto Celestron cg-5 with Starsense, and it would have been quite easy to mimic - with the Arduino as interface – the servos of the old cg-5 and translate the Starsense control signals to my New Atlux. I can write C, and there is even an open source project called OneStep, which uses a Microcontroller in a similar way as I do. But I don't like to write C code anymore. In the 3D printer community, people need to use real time electronics to control the printer steppers. Due to the real time requirement, C with a real time microcontroler (Arduino & similar) are the only option for 3D printers. Do we need real time for our telescope? No. We don't need to control a lot of Motor accelerations and high speed control. For the telescope, we need to set the Motors speed precisely, and we need to drive to any position in an accurate and controllable and slow way. Then, there are new stepper motor drivers available with as much as 256 microsteps. The TMC2209 stepper driver , which is very well know in the 3D printer community, is not vibrating at all. It runs just smoothly, also at very low speeds. I do drive my motor with 0.25 rpm (sideral speed). In case of a slew, I can accelerate to 1500x sideral speed, which also would allow me easily to track the ISS. Wonderful. The current status of my project is: The mount is equipped with the two new motors The TMC2209 drivers are connected to the Raspberry pi GPIO Interface, and I can control them via Software. Theoretically, I could attach up to 4 motors with a single Uart interface (1 wire protocol). For instance, a focuser or a filter wheel could be attached. I selected Kotlin as language. Java also would have been possible, but I think for a new project, Kotlin will lead to a much more readable code. The TMC drivers can be driven via a chip-internal clock signal. Different to what the 3D printer community is doing (they use the step / dir pins, and create every single microstep with the microcontoller), I can send a “speed” signal from the Raspi via UART to the 2209 chip, and it will execute this speed for me without any further action. The only time critical issue was that I need to precisely count the steps that the 2209 stepper drivers executed. This is done via a GPIO pin, receiving its index signal (a pulse for every 2209 fullstep). Here comes the pain with Linux (non real-time) and the Pi: For user programs, it is impossible to guarantee that every pulse from the stepper drivers will be registered. But I cannot afford to have a step count drift over time. The solution was that I wrote a Linux kernel module in C. I wrote that I don't want to write any C code. Well, a few lines for the kernel module were indeed necessary. I can live with that, having in mind that the rest will be written in Kotlin. The only task of the Kernel module is to count every registered step at the Pi's GPIO input pins. This kernel module output is then mapped to a character device file in /dev/ for every stepper. In Kernel space, it is possible to register and count interrupts without missing even any one of them. From a hardware point of view, this is indeed everything we I need. The project cost so far: 2x10€ for the stepper drivers, 2x10€ for the motors, 2x20€ for the tooth belts and pulley, 10€ Pi Zero plus some peripheral expenses: Micro SD card, USB charger, and 1200 € for the used Vixen new Atlux mount. And a lot of time. I have so many ideas on how to extend the ecosystem of my software, but these ideas are for the longer term (maybe years from now on): Multi-star alignment. The alignment should be able to be updated continuously during an observation night. With a set of stars, it should be possible to calculate the quality of the aligment points, and e.g. drop them if they are errorneous. PEC correction (should be easy on the Pi) End-Stop support The polar alignment routines of today's goto scopes are quite good. But what I would like to have is some audio-feedback when I move the alignment screws into the right direction. Possibility to pre-plan an observation night (e.g. the mount could tell you that the Jupiter moon shadow will be on Jupiter in a few minutes). Record the telescope movements during the night in order to be able to tag any picture. The TMC drivers have much more capability than what I am using currently. For instance, they could be current controlled for slews in order to set the stepper current exactly to the value that it needs without stalling. This saves a lot of energy. The TMC drivers have a feature called “Stall Guard”. This could be used instead of endstop switches (for 3D-printers, this is done frequently). Advanced options for tracking: siderial, solar, moon speed, ISS speed. Tracking in both axis (e.g. to compensate polar misalignments of atmospheric refraction) or just in right ascension. Commercial mounts do not allow much customization here. With slow slew speeds, 5V input via a USB-C cable is sufficient for the Pi + Motors. Usb-C and newer usb battery packs allow to output a higher voltage via USB. With an “USB-trigger”, the input voltage can be selected to my needs. Higher voltage allows higher slew speeds, but consumes more power. Autoguider support, or even better: simply connect a webcam via the Pi's USB connector and do the guiding on the Pi The Raspberry Pi touch screen could be used for telescope controlls Advanced German mount limits and meridian flip control (e.g. a warning about a necessary flip when driving to a specific goto target). An Android App, connected via WiFi to the Pi could be used as display alternative Language control (have a look at Mycroft, an open-source artificial intelligence). "Hey mount, please slew to the whirlpool galaxy!" Control the mount via SkySafari and Stellarium The Pi has a built in camera interface. How about an open source auto align? The Pi could look at the stars to align itself, which makes a lot of sense. I did already order a long focal length lens and monochrome camera from Arducam in order to do some experiments (the standard Pi camera has 3.5 mm focal length and is not really usable, although star imagining is possible). My first observation site is my balcony. And there, the real Starsense does not work at all. It always spin-loops on 2 alignment positions where the sky is covered by the roof – how silly is that?. This can be done better. Further, Starsense is doing only a initial alignment. It should update its position and accuracy over the time! I think I could do this better. Besides all my ideas, the first and most important focus of the software will be: Readability (therefore my choice of Kotlin), extensibility and open source. I like to have the Maths of the internal mount model clearly visible and understandable in the software. The calculations that are done within all our goto mounts are no rocket science. I admit, I am the nerd guy who wants to go the hard way and implement this from scratch. I am looking for a good project name, do you have any suggestions? How about QuickStep? this is possibly too close to OneStep and would offend the creators of OneStep? Does anyone of you have interest in joining my plan? Doing such a project in a small group would be more encouraging then just doing it for myself. And of course later on, I would appreciate if other stargazers would update their old mounts with my software. Any comments on my project plan are welcome! Clear Skies! Andy