Search the Community

Astroberry (strictly speaking Astroberry Server) is a fantastic operating system for the Raspberry Pi that allows control of your astromony kit and even better it's free! However, while there is a lot of useful information on SGL and elsewhere on the web, I had some trouble understanding how to set everything up and I couldn't find a beginners step-by-step guide. I don't have much experience of the RPi or Linux or indeed any operating systems other than windows but after some trial and error I've got things working so I thought it might be useful to chronical the steps that hopefully will get you up and running. Astroberry uses INDI Library - an Open Source Architecture for Control & Automation of Astronomical Devices - you can think of this a bit like ASCOM. Astroberry is also really flexible and there are multiple ways to do most things so what follows is just ONE way to get you up and running. So let's get started. When I say 'computer' I mean your main computer and I use RPi when referring to the Raspberry Pi (that's a computer too, of course, but just to differentiate between the two). The Astroberry homepage is at https://github.com/rkaczorek/astroberry-server. You'll need a Raspberry Pi, of course, (apparently Astroberry works with any RPi; I was using an RPi 3), an SD card of at least 16GB, and a computer with a suitable SD card slot (the RPi 3 needs a microSD card; most microSD cards come with an adapter that allows you to use a standard SD slot in your computer), and access to the internet. Firstly download the Astroberry Server image file from https://www.astroberry.io/distro/ (the image file is the operating system that will run on your RPi). Unzip this file into a folder on your computer. Then download balenaEtcher from https://www.balena.io/etcher/ - you'll use this to write the image file of the Astroberry operating system to your SD card; this process is known as 'flashing'. Once you've installed balenaEtcher, run it and select the Astroberry Server image file (when I did this the file was called astroberry-server_2.0.0.img) from the folder where you unzipped it. Insert your SD card into the SD card slot on your computer, select this card from the 'Select target' button on balenaEtcher and then select 'Flash!'. The process takes a little while but will show progress as the file is copied and then verified. Make sure the flashing process has completely finished before removing the SD card from your computer. [Note, as the author of Astroberry @RadekK states in a comment below it's actually possible to set everything up without a monitor, mouse or keyboard. To do that, insert the newly flashed SD card into your RPi and power it on. After a few moments a wifi network 'astroberry' should be available. Connect your computer to that network and point your browser to http://astroberry.local or http://10.42.0.1 (which is the default IP address assigned by Astroberry). You should be able to everything via this remote connection. Astroberry is also able to use a remote desktop app called VNC (icon is in the top right) so you can play with that too once you're well acquainted with Astroberry.] Insert the newly flashed SD card into you RPi, connect a display, keyboard and mouse to your RPi and power it up. You should see the Astroberry operating system load up. Answer the questions and set your localisation options. Astroberry will create its own wifi network called 'astroberry' that you can use to connect to your RPi (very useful for use 'in the field') but this won't be connected to the internet. We're not going to use the astroberry network for now. Instead we are just going to have your RPi connect to your home network / internet. To do this, click on the icon in the top left corner of the screen, select 'Preferences' and then 'Advanced Network Configuration'. Use this to add your wired or wifi network. When you boot up your RPi, Astroberry should now connect it to your home network in preference to the Astroberry HotSpot. If for some reason that doesn't work and Astroberry is connecting to it's HotSpot instead then you can do the following: Click on the icon in the top left corner of the screen, select 'Preferences' and then 'Advanced Network Configuration', select your home wifi network from the list and then click on the cog icon in the bottom left of the Network Connections window. Click on the 'General' tab ensure that the 'Connect automatically with priority' has a tick next to it, and set the value to 1. Close the editing window.# Then select 'Astroberry HotSpot' from the list, click on the cog icon in the bottom left of the Network Connections window again this time to edit the settings for Astroberry HotSpot. Click on the 'General' tab ensure that the 'Connect automatically with priority' has a tick next to it, and set the value to 0. Close the editing window, and then close the 'Network Connections' window. These steps will mean that when your RPi is switched on it will connect to your home network if it can, and if it cannot it will start up its own wifi HotSpot called 'astroberry'. At this point, you should be able to connect to your RPi from your computer. Open a web browser, type or copy http://astroberry.local/desktop/ in the address line and press enter. You should see a screen asking you to connect to Astroberry Server (which is running on your RPi). Click on the connect button; the password is astroberry (in fact, if in doubt try astroberry as the password for everything - it usually is!) If this has all worked correctly, you should now be able to control you RPi remotely so you can disconnect the display, mouse and keyboard from your RPi. You'll see some other icons in the top left corner of the Astroberry desktop including one for PHD2 but don't go there yet! Before we do anything else we need to start the INDIserver service - this will load the drivers etc that you need to run your kit. On the left of the screen is a blue-grey tab that will expand to show some buttons. Click on the telescope icon which brings up the INDI Web Manager window. You can go through and select the drivers for your equipment. Click on the 'Start Server' button at the bottom of the INDI Web Manager window which starts INDIserver - this is like starting ASCOM. Once you've done that, type a name in the 'New Profile' box and save it. You can then select it from the 'Equipment Profile' box; delete the simulator profile if you like. There are check boxes under the 'Equipment Profile' box that allow you to automatically start INDIsever select a particular profile and connect to your devices - so long as the devices are connected and powered on. If you check these boxes you don't need to repeat the step of selecting your profile etc. This should have you more or less ready to go. If you experience connection problems with kit that gets its electrical power from USB (e.g. the QHY5L-II guide camera) then use a powered USB hub as the RPi USB ports don't provide enough electrical power to properly power some equipment. There are icons for some astronomy programmes in the top left of the Astroberry desktop. PHD2 is familiar to me and you can test that your kit is connecting in that. KStars (the telescope icon next to the left of the PHD2 icon) is planetarium software that also allows you to launch Ekos (Tools>Ekos or ctrl K) and this allows you to set up equipment profiles and run imaging sequences. Hopefully this guide will enable you to get things set up and your kit connected. I haven't yet explored Kstars or Ekos much, nor much of the rest of the desktop but hopefully it will be fairly intuitive. I've written most of this guide from memory so if a step doesn't work then please let me know and I'll try to correct it. Hope this helps and huge thanks to the Astroberry developer, @RadekK, for making this software available to the community - I'm sure it took a huge amount of work. Clear skies, Ian

From my other post, you all should realize 2 things about me. 1: I can't leave well-enough alone. and 2: I like to fiddle around with things. In my last thread, I got setup with my goto telescope and managed to control it remotepy with KStars or Stellarium and even got my CCD working so I can sit inside in comfort while stargazing.....ALMOST. I still have to run in and out to turn the focus knob. So.... There is a raspberry pi running the INDI server pointing the scope and managing th CCD. I have a nice little geared motor and a HAT board that I know how to connect and control with the pi to make the motor go fast or slow, or forward and backward. I can manage the machine work to create a connection to the focus mechanism for the motor. What I need to know is if there is already a DIY-ish or configurable driver for INDI. And yes, this probably is a post for INDI forum, but for some reason I can't get a login there. So, if anyone knows or has done this, thank you in advance for any information you are able to provide.

Hey, I have a question, did anyone here have luck installing ASCOM alpaca Remote Server on a Raspberry Pi 4? Or is it like I suspected as in the below image not possible, unless it's a windows machine?

I made a new video - which walks through the downloading, installing and setup of AstroBerry (astronomy software running on Raspberry Pi) - and then I connect to an HEQ5 and DSLR camera. Nothing to complicated - but its the basics covered. There are a lot of videos out there on using AstroBerry, but not too may walkthroughs on the actual setup. Although Rp and Ab should be simple theres a lot of questions out there just on the setup. Hopefully the video gives people confidence on the first steps and is enough to get them going. https://youtu.be/Bgn3KioAAJ0 Many Thanks - clear skies & if the video is helpful please subscribe.

Hi, first post so please bear with me, having issues with autoguiding, looked at numerous forum threads and cannot find the issue specific to my setup and the issue I am having. Equipment in question: ZWO 224 using as guide camera plugged into raspberry pi running Astroberry via USB3, Lynx Astro EQDIR cable plugged from USB on raspberry pi into hand controller port on AZ GTI. Configuration: Synscan android app successfully connected to AZ GTI via wifi and can control via mobile phone, AZ GTI setup to connect to raspberry pi (so it's on the raspberry pi network) AZ GTI connected successfully as it is recognised in PHD2 and EKOS, In PHD2 the mount is setup as INDI mount (AZ-GTI) and connects. Issue: PHD2 is unable to guide in either RA or declination (see screenshot error showing up), it is always one or the other. I have tried setting up multiple times, tried using the network cable which came with the camera directly from the camera into the hand controller port and setup in PHD2 as "on camera" (I suspect this setup is wrong anyway and was one of the first I tried). Polar alignment has been checked multiple times, the end result is always the same, the star field within PHD2 window will always drift in one direction so any star chosen will eventually disappear out the field of view as the mount isn't moving to follow it. Looking at the PHD2 graph I know it is trying to send pulses to the mount but either the movement is too much for the mount to move or something isn't happening as it should, in the example screenshot provided I tried this indoors on a fairly fast (compared to in the field) rotating star field looking at a screen so it will fail, though the mount didn't adjust at all, no matter how I've setup prior the AZ GTI refuses to adjust to follow a guide star. I have tried manually moving the mount in PHD2 and it doesn't seem to move in any direction, manually moving however does work in EKOS so the hardware seems to be plugged in correctly. EKOS even knows where the mount is pointing and can issue go-tos (although it is slightly off target at the moment). I am kind of at my wits end to why autoguiding isn't working, if anyone can help please assist. On another note if someone can advise how to configure PHD2 so the off yellow warning box colour can be changed so the error message can be read clearly - I know theres a line of code I can use in the terminal window which refers to a resource file to change to the default PHD2 colours and launches the software but the changes are never saved.

Hello! This is my first post on stargazer’s lounge, so forgive me if this is the wrong place to ask. I have a SkyWatcher AZ-GTi mount (with a firmware update + eq wedge so that it can run in eq mode). I also have a Raspberry Pi 4 with INDI, KStars, and Ekos tools. I don’t have a guidescope (and my budget is extremely limited), so I was wondering if there was a way to polar align my DSLR using just the software running on the Raspberry Pi. I’m also competent in Python, if that could be useful for anything.

Hi all, just getting straight to the point. Just got a Rasp Pi 400 (equivalent to Pi4-4GB), and looking to get into guiding through this as it's obviously a popular (and successful) technique. Plan is to have the RPi as mini computer at home, running it with RaspPiOS (supplied on µSD with the full kit), then use it with a SECOND micro SD card for astro - I figure having another SD to run Astroberry (as on SGL) may ignore any issues with the family using the pi for other stuff in the house, giving a stand-alone 'computer' as the OS and files would be available on different SD's. From this point, I'd setup as follows: Connect the RPi directly via USB to the mount (it's the newer SW-AZ-EQ6Pro with the USB-B port on the mount) Guidescope (240mm f/4) with T7C (equivalent to ZWO Mini) again USB-B direct to RPi Nikon DSLR (either on telescope or using camera lenses) connected to RPi via Nikon USB (using the 3 USB points on the RPi-400) to control capture and later using this for plate-solving (but that's not for just right now!) I don't spy any flaws in the plan, it's just going to be a matter of testing and setting things up hoping to follow the guide for Astroberry as linked to SGL below... Or is there an alternative OS? From brief reading, Astroberry includes KStars & PHD2 which is what I've got for use on the macbook (although not used in earnest as it doesn't appear to like the cold too much!) What about guiding software - I know KStars comes with it's own, and can run PHD2 from within, with PHD2 being the industry standard (and simplest?) to use? Control will then be sitting in the warm via OS-X, which seems to be again a common technique as I've had posts on my other questions about this! Thoughts???

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

Starting my 1st IOT project. Since i've been an astrophotographer with no permanent setup, it makes sense to reduce the physical footprint (and the weight) of as many equipment as possible, as well as to do better cable management. I am soon going to start using Astroberry Pi server, an Ubuntu based suite for Astrophotography. Just purchased a Raspberry Pi 3B along with a 3.5" display for that. Lets see how it goes.

I have an EQ5 telescope mount which i use for astrophotography. I have modified it with a motorised RA axis using a bipolar stepper motor - my thread for the build is here . I want to expand the mount's tracking ability by motorising the DEC axis and using a guide scope/camera. I generally use the mount in fairly remote locations so would like to use a raspberry Pi for portability. I understand that I'll need to use a Raspberry Pi Camera Module for the guide camera. The capability I want is: 1. guide the mount along RA and DEC axes using a guide star as feedback 2. track the mount using the RA axis only, and if possible continuously take 20-30 second exposures on the guide camera (this functionality is optional, but would assist in polar alignment of the mount) I don't want any GOTO capability. I am very new to RPi and need some help: - do I need to write code for this, or is there existing programming available for what I want to do? - is it possible to avoid the use of screens (in the field)? My preferred option would be to flick a switch to start and stop the guiding, with another switch for alignment mode (or something simple like this). - do I need to use any particular stepper motors/drivers for raspberry Pi? I'm using a bipolar stepper motor running quarter steps, with an A4988 stepper driver - is the RPi 3 Model B+ the unit I should buy? Thanks

Allsky camera and weather station is very important parts of the modern observatory. Here I wanna describe project that I build for my observatory. I started a new topic because I believe that this project is unique and I hope this description may be useful because project is open source/open hardware. This device contains two cameras, one is for beautiful daytime shots (over the horizon) and second for useful night shots. Also there is a lot of sensors: clouds, ir, light, temperature and humidity. Heart of the device is Raspberry PI 2 microcomputer. Everything is built in waterproof electrical box which can be found in hardware stores. Yep this exterior is not very nice looking due to silicone sealant. But nice looking is not most important part, especially when mounting device somewhere on a roof Acrylic dome is from CCTV camera. Inside the box I glued a thermal insulation and copper foil which acts like a EMI shield. This foil is connected to the building grounding circuits. All devices inside the box: - Raspberry PI 2 - internal temperature/humidity sensor - powering system (+3.3, +5, +12 volts) - ethernet lightning protection - tsl2561 ir/luminosity sensor - mlx90614 cloud sensor - cooling system - rtc with a back-up baterry External temperature/humidity sensor is mounted in separate aluminium can. Cameras module is mounted on the bronze pcb stands and will be described below. Raspberry PI runs all device software except database and long-time storage of the images. Camera can be accessed through simple web interface which running on nginx server. All data collecting and generation software is wrote on C, Python and Bash. All processes is starting by the CRON. Database is working on the remote server with reliable storage system and can be accessed through network. I'm using Mysql in this project. I found that this solution is more reliable and convenient rather than local storage on the SD card. All images are postprocessed by the software. Dark frames is extracted (only for night camera) and generated some text information on the bottom of the image.

Hi Everyone, With March about to pass without a single image being taken my mind has turned to wire reduction and being able to move the OTA and mount further away from the house tethered only by a network cable and mains supply. Because I have a Raspberry Pi3 Model B+ to hand I thought I would try Virtualhere - just to see how far I can get to realising my goal without too much extra spend. The Virtual Client installed fine on the NUC and I have been able to install the basic usb-server (vhusbdarm) code on the Pi3B+; you can install the specific usb-server code without a licence although when I tried I got an illegal instruction command from the Pi. Nevertheless I persevered with the basic usb-server, connected successfully to the NUC and could see the Atik428ex connected to the Pi. I was all the more encouraged to see that Artemis could also see and use the camera. The resulting image was not so encouraging and I wonder if anyone can tell me the likely cause of the banding on the image. This is a 0.2s exposure using an L filter. The pylon is not that black but the sky colur is pretty accurate! I did not go so far as to try the mount connection (NEQ6) or guide camera (ASI120MM-S). Thanks in anticipation of any help. Adrian

Got tired of the mess of cables and loose devices I had to always put together and dismantle after each astrophotography session so I figured I'd do something about it. This tray will sit nicely under the tripod and provide a hub for everything including Fused Power, Raspberry Pi, USB Hub, GPS, Dew Heaters, Long Range WiFi etc... First version will be really crude as I need to have this working in less than a week as I'm going on a holiday taking my astro gear with me.

I'm finally nearing the end of my project to move imaging over from a Olimex A20 running INDI to a raspberry pi (also running INDI) that will be mounted to the side of my LX90 fork arm to really reduce the amount of cables running down the mount. I'm now down to a single multicore cable from the ground to supply two separate power lines, one for the dew heater and then the second that is split between CCD, LX90 and the Raspberry PI. The PI itself controls my CCD, Guide cam and filter wheel via USB but in addition I've built a "Hat" (although I shouldn't really call it that as it violates a few parts of the official hat spec). That provides an RS232 connection for the LX90 autostar and a DRV8805 based controller to drive my newly arrived (Early Christmas present to myself arrived just a few days before Christmas) Moonlite focuser. Below is an image of the final board mounted onto the Raspberry PI and here's a photo of it hooked up to the Moonlite focuser. The project wasn't without its issues, quite a few of them to be honest. From design flaws with the PCB switch mode power supply (luckily fixable without needing a new PCB) to... well they're all covered on my blog which has several posts covering the project. On Christmas Eve, it all came together though. With a custom INDI driver for the board driving the focuser perfectly. Full source for the INDI driver, hardware schematics and PCB gerbers along with a few kicad components are all available at:- https://bitbucket.org/BWGaryP/mup-astro-cat https://bitbucket.org/BWGaryP/mup-kicad-library If you're wondering about the name (he says hoping someone read this far), it was originally the MUP Astro Hat, but since I didn't end up following the full PI hat spec, I decided to rename it. It was a toss up between CAT (after the SCT it's used with) or CAP, since a Cap is like a Hat but not quite a hat! For the odd person who did get this far, there's much more detail on my blog in a series of posts including a totally, amazing, action packed video of the focuser erm moving. http://www.mups.co.uk/post/2016/12/moonlite-focusing/ Bottom of that blog post is a link to all the earlier posts which cover the many mistakes made and bodges to fix them This is the first PCB I've ever made, so I'm incredibly chuffed with how well it turned out despite some rough edges and the many issues along the way. Can't wait to sort the last couple of bits now (few cables and counterweights to sort) so I can finally give this focuser a proper test under the (hopefully not quite as blurry) stars

Inspired, as usual by Gina's exploits with a Raspberry Pi and Indi I decided to have a go myself. I have ordered an RPi 3 and await arrival. In the meantime I decided to modify a cheap 28BYJ-48 stepper motor for bipolar operation following Gina's instructions. Then I tested the motor with a Pololu A4988 stepper driver I had left over from my 3D printer build using details I found here and it worked first time. I needed a 12V supply to drive the 5V motor as now the windings are being used in series. Once the Pi arrives I will be installing Raspbian, Indi and connecting up to my Nexstar 127 SLT and then building a new focuser using my existing sketch and the motor I modded today.

Hey guys, I recently found out about INDI and Ekos and was curious to see how well it worked (check it out here). I had a raspberry Pi collecting dust and after a couple minor setup steps, my equipment was recognized and connected. My mount, DSLR, shutter release serial cable, and guide camera all connect directly to the Raspberry Pi. I then connect to the Pi from my mac laptop using SSH and the Virtual Machine provided by http://www.indilib.org/. The nice thing about the PI is that it uses little power (about 0.5 amps at 5v), has 4 usb ports, and has built in wifi. I picked up a usb battery bank for the Pi and threw the two into a project box. I'm fairly sure the Pi would run 20 - 40 hours on this small battery alone. Anyways, I've seen a couple posts touching on this subject and thought I should share my efforts as I'm quite excited about it. It seems like it will perform better than my previous setup. My previous setup consisted of an intel compute stick, small usb hub, 12v battery with a 5v converter, and an additional windows laptop to control it all. I would connect all my gear to the stick through the usb hub. In order to get everything going, I'd remote desktop into the compute stick through my windows laptop. This worked ok, but the compute stick (running windows) was unreliable, there were a number of imaging sessions where it decided it would be best to install an update for half an hour. Other times, it refused to auto connect to the wifi hotspot without logging in, meaning I could not remote desktop into it and would need to connect a screen. Eventually, I tried using a LattePanda board as well but had similar experiences due to Windows 10. Regardless, I do recommend the LattePanda for windows applications, it is a slightly stronger board than the Pi and has an Arduino built in but unfortunately is not too great at running linux yet. (old setup below)

Part 1: What complicated electronicality goes into your average GoTo mount? Answer: Not as much as you’d think! In fact, that’s it. The above picture comprises the entire guts of an early generation (circa 2000) Celestron Nexstar GoTo Mount that accompanied a 90mm refractor scope. This particular example is a dead one, but it’s enough to show us what’s going on. So what have we got there? Let’s break it down… The Control Board Ooohhh… it’s got chips on it. Must be clever. No. Ultimately there are 3x components here that do the work. On the right are 2x XIC0014 oscillators with a 4mhz crystal each. We can summarise their job as: timing. These keep tabs on timing for signals going to and from each motor. On the left in the middle we have a 74HC240D. This is an octal line driver which takes 8 incoming teensy pulse signals and amplifies them into 8 larger pulse signals. In the lower left corner we have an L293DD. This is a part of interest. This is a 4channel H-Bridge motor driver. The pins on the right hand edge are for the hand controller. The pins on the left hand edge are for the Azimuth motor (left & right horizontal motion). The pins on the top edge are for the Altitude motor (up & down vertical motion). That’s a lot of pins for a motor tho… There’s also a MOSFET up top, which will be involved in regulating the incoming 12v DC down to 5v DC to run the electronics. The Handset board Nothing complicated here. It’s an RJ45 socket, mounted on a board along with the 12v power connector. Black & Red are 12v, which goes up to the handset, and across to the controller. The remaining 4 wires carry TTL signals from the handset to the control board. The Motors (x2) The mount contains 2x motors. These are DC controlled, and rely on 2 wires only. So what are the rest of the wires (6x) for? Feedback! Mounted to the rear of each motor is an optical encoder wheel. The black box at the top has an LED mounted in it, pointing at a light sensor. In between these, the wheel passes. Note the slots. The sensor detects the light being blocked and unblocked by the wheel, and converts these into pulses. So there are 2 wires providing Grnd and 3.3v to the LED. The encoder itself outputs one pulse for each slot. This is our speed signal (by counting pulses over a period of time), and by storing the count they can be used for position also. That’s one wire. It also outputs a direction signal. This is a high or low (on or off) signal. If the output is high, the motor is moving forwards. If the output is low, it’s moving backwards. That’s another wire. The encoder circuit needs power… 5v & grnd. That’s another 2 wires, giving our 6. Gearbox… Each motor mounts to a gearbox. I haven’t a clue of it’s ratio, but from the surface dimples we can see that it contains an input gear, which translates it’s motion through 4 other gears, then to the output gear on the other side… …which in typical fashion is smothered with the stickiest cheap & nasty grease known to man. This drives the transmission wheel, which uses a friction plate to move the relevant part of the actual mount. Again, this is liberally smeared in sticky cheap mank. Summary All the control board does is translate signals from the handset directly into drive commands for the motors. ALL the intelligence is in the handset. A bit of diagnosis tells me that the handset for this mount has been fried, along with the control board, but both motors and encoders are in perfect working order, so how can we resurrect this setup? Seeing as all the control board is is a multi channel H Bridge motor driver and feedback sensor board, we can replace the lot with a Raspberry Pi and a few bits. The Raspberry Pi’s GPIO pins can quite happily output 2 channels of PWM to control the motors themselves, and can easily receive 4 channels worth (2 per motor encoder) of feedback pulses. All we need to do is get power to everything. Conveniently, all the bits needed can be picked up for a grand total of sod all (or less) from most robotics hobby places. I already have a veritable mountain of Raspberry Pi boards so I don’t need to acquire one. These cost me £18 each. To hook up the motors, I’ll need a dual channel Pi motor driver board, so I’ve opted for a DRV8355-based kit which can take a 12v DC power supply to run the motors, and with the addition of a 5v step-down board it can also power the Raspberry Pi itself which in turn can power the encoder boards (which also run at 5v). The Pi also provides a 3.3v output which can power the LEDs on the encoder boards. These two components from the provided links total £12.36 inc shipping. Add the cost of the Pi, and that’s £30.36 for a replacement control board.

I am preparing for guiding and have the ST80 with ASI120MM camera. I want to connect this to Lin_guider running on a Raspberry Pi, and use StarsPi as a user interface/client. At the moment I have connected the camera to the RPi and I can see the connection on the client in my android device. But it says that the camera is off line. That's where I am stuck. Does anyone know how to continue from here, i.e. get the camera recognised by the app?? Any help appreciated.

I have two Raspberry Pi boards - A Pi 2 and a Pi 3 which I would like to use for astro stuff and/or 3D printer control. I gather these can have versions of Linux installed. I have used Python to program Linux machines in the past mainly running Ubuntu or Linux Mint though may be a bit rusty now. Am I thinking along the right lines? Could someone give me some hints on using the Pi, please?

I have an old dslr, which won't connect to a computer anymore (USB isn't responsive, not even as a mass storage device). So, for astrophotography I have to use an intervallometer. The problem with this is that I can't control or monitor my camera remotely (remote = garden -- living room). Another, more annoying problem is that intervallometers have these absurdly small batteries that run low by just being outside, it seems. Especially during the rare clear nights we've had this winter, the intervallometer can't be trusted once the temperature drops below zero. Having nothing better to do, I decided to solve these problems. As I use a raspberry pi as a guiding computer, and have installed INDI for mount control, it only seemed natural to write a script to control my camera. With a few cents (kronor actually) worth of hardware, and a python script, I now have a cheap remote control for my camera. This is the hardware: an optocoupler and a resistor. The input (left) is connected to two GPIO pins of the RPi, and the output (right) goes to the remote port of the camera. The script and a more detailed description of its workings can be found here: http://wimvberlo.blogspot.se/2017/02/raspberry-pi-dslr-trigger.html Hope this can be of use to someone. Cheers,

Hey there, Curious about which CCD's you have been or are using successfully with auto guiding on a rpi2 or even a rpi3? lin_guider seems to support a bunch of manufacturers but a list of what models are proven to work with the Raspberry pi's will surely help my quest! Cheers for the help!

Seeing as it was rainy the other day, I took to my spare parts box and pulled out an old WifI IP Camera that had been drowned previously, control boards fried. Fortunately, it’s 2x stepper motors still worked (24BYJ-48 - you can get them off eBay for next to nothing). I’d picked up some UL2003 driver boards a while ago with the intention of a play with a Raspberry Pi, so this seemed the perfect project. 30 minutes in Python, a swift bit of Node-Red-UI, 2 pieces of Meccano and 10 minutes soldering et voila! PiFocus Testing the motor control via breadboard... The Raspberry Pi in question currently sports an Energenie two-way RFM69-based radio transmitter for controlling household sockets etc, and 2x 1-wire temp probes - these are handled by Domoticz, a free open source home automation system for which I wrote a plugin a few months back to allow voice / mobile control via Apple HomeKit protocol & Siri. Breadboard tests all worked, so got it all soldered up, and fortunately with the quick addition of two pieces of meccano, got it all strapped to my 114EQ OTA via the existing finder scope mounts... et voila! It’s not the speediest of things at the moment. Still needs some improvement to the “transmission” but it takes 45000 steps of the stepper motor to get from full-in to full-out, so it should be sensitive enough... so here’s the final test - mounted up with the weight of an Opticstar PL131M to give it something to work with: Rather chuffed if I do say do myself!! Last step is to add virtual switches into Domoticz for Siri-controlled action...! Am quite happy to share all the code etc if anyone wants it (s’all standard stepper control code kicking about a few raspberry pi sites). Should work on any Raspberry Pi running Jessie with Node-Red, Node-Red-UI & Python 2.7.x installed.

Hi Folks, I'm just about to start on my AstroPi project inspired by this site, a great website by some very clever lads. My project will be to remote my mount control via a Raspberry Pi using SkySafari, Dslr control via Backyard Eos and guiding via PHD or Lin_Guider. I have though come across two small queries someone may be able help me with: 1. It's suggested that control of the mount using SkySafari is done using a skywatcher serial connection to a usb-serial connector onto the RaspPi but could this not just be done with the ethernet in the RaspPi to the similar port on the Synscan handset? 2. Also the more problematic on is that Lin_guider apprently works the best but only has support for the QHY5 mono and i have the QHY5v, has anyone every had success in over coming this problem of driver support? Thanks for looking and I'll keep this thread updated with progress.

I’m about to do the handset mod on the EQ5 controller - I’m intending to run the connection into the Pi’s GPIO port via optocouplers. Anyone got any idea where to start getting phd2 to talk to things? Is there an API? I can’t seem to find an awful lot, it seems to assume I’m going to use an EQMOD and USB to Serial, etc.