LuckieEddie

I run KStars/Ekos/INDI on a Pi4 8GB built into my mount controller. Raspberry Pi OS 64-bit, software built by Nou's scripts. Also PHD2, FireCapture and occasionally Siril. All accessed via VNC. 32-bit KStars is indeed a dead end. The software now uses some stuff that is only available on 64-bit systems.

1st IANAL. I'm an however a lover of and contributor to open source software so I'm surprised by that statement. Can you provide any reference for it please? It's proven (and grudgingly admitted, eventually) that ASIAIR is built on INDI and their failure to meet the requirements of the GPL licence is skirting the limits of legality. They are keeping it closed to keep out other manufacturers. I suspect it's only their position as a prominent manufacturer of other astro kit that the open source community wants/needs to keep supporting that is preventing more action regarding this.

I've used a Fuji X-T2 with a Skywatcher N200/1000 newtonian on an EQ-5. I run it at ISO800 using kstars/Ekos/Indi. The only real issue I had was the unusual XTrans CFA requires proper handling. Shoot in raw. I use Siril for stacking. You can see some of my results on my telescopius page - equipment used is listed on each image. The other comments are spot on - I similarly found the 200/1000 was too much payload for the EQ-5 and have now upgraded to a larger mount.

Hi DT, Welcome to SGL. I can't comment on an AVX as I've never used one, so this should only be one input into your decision process, however... I have an old EQ-5 that I converted to an OnStep belt driven system - DIY not an Terrans kit. I rarely use it any more as I've moved onto a Losmandy G11 (also using OnStep). I used it with a SkyWatcher N200/1000 which is definitely too much payload for the EQ-5 but was just about practical - it would be fine for a lighter / shorter FL system such as yours. You can see what I managed imaging wise on my Telescopius account. Most of the images there were taken using the EQ-5 unguided - the equipment details are in the descriptions. I've found OnStep to be great. The system itself, the resources and support around it, and the people behind it. Drivers are mature and full featured. I never auto-guided the EQ-5 but do guide the G11 via Indi / PHD2 and it works fine. A couple of things to be aware of regarding OnStep: The system design and code is Open Source. There are businesses, such as Terrans (and others), that have taken this and made a commercial product around it. This is okay and in keeping with the licenses. However they are not renowned for the best technical support. There are often customers of these commercial kits seeking support on the OnStep forums and the community, quite rightly, is not especially happy to provide free technical support to these companies customers. There are other sources of kits active on the OnStep forums that do feed into the community and provide good support (in particular see https://graydigitalarts.com ). OnStep reached maturity (generally) in the 4.x release series. 4.24s is the current official release. However, for a couple of years it has received only bug fixes as development has switched to OnStepX. The older OnStep codebase reached the point where the author (Howard) felt that it deserved a ground up rewrite to make it more maintainable, extendable and all round better. (A bold step that many software projects could learn from.) OnStepX is still in Beta and not yet officially released, but it's stable enough for most users. It's just that the development of new features is still progressing and so updates are frequent.

I recently got a definitive answer regarding the MLX (which I'm planning to use myself). The standard 'A' package TO-39 varient is sealed to IP65 so it should be fine exposed to general weather. Just make sure you seal the body of the can to your housing and don't jet-wash it.

I tried these a while ago. I found that on my 8" Newtonian they did almost eliminate the diffraction spikes but in doing so spread that extra light evenly around. This meant that the stars went from tight points with sharp spikes to softer and larger without spikes. For me I considered that a failure.

As an alternative you could get a sleeve of brass with an internal bore of 2.6mm and an external diameter of 6mm and bond it onto the 2.5mm shaft with Loctite 638. Then you could just use an easy-to-buy 6mm - 6mm coupler. This would be a one way journey though, you wouldn't be able to remove the sleeve without a blowtorch. I could knock up the sleeve for you for cost+postage. Message me if you want to go that route.

2.5mm is a challenge to find - are you certain that's correct? I've found 2mm -> 6mm & 3mm -> 6mm on AliExpress but nothing for 2.5mm. You might have to go for a 2mm and bore it out.

Looks like a good candidate for an OnStep conversion to me. You can go full DIY for around £100 or there are ready made kits available for more cost but less effort - still well within your budget. This class of mount is well supported, there's lots of existing conversions. I OnStepped an E-Q5 - works well.

Hi all, I've written an INDI driver for OCS. This is an open source hardware and software observatory controller project from the author of OnStep. The driver is at the point where it's feature complete but has only been tested by myself on one set of hardware. If any other OCS users could test it out that would be great. The driver is available in my indi-3rdparty fork in the indi-ocs sub-directory. Full documentation is in there as well. Note: The driver requires OCS V3.04 (or higher) for full functionality as some new commands were recently added to support the development of this driver. Please post any bugs/issues/suggestions as replies here. Thanks Ed P.S This is cross-posted in the OCS groups & INDI forums as well.

Signed

Onstep could be your friend for this project. Its a full featured open source control system that runs on various Arduino systems. Drivers for Ascom and Indi are mature. I've converted two mounts to use it so far an E-Q5 and a G11.

Another alternative to 'rolling your own' completely from scratch is the Observatory Control System (OCS) which is open source SW & HW authored by Howard Dutton who also created the OnStep telescope control system. There are ASCOM drivers available. See https://onstep.groups.io/g/onstep-ocs/topics.

Nice. For any given amount of time on a target, I'd suggest taking significantly more exposures, even if they have to be shorter. 10's or even better 100's of subs will let the stacking average out the noise, including satellite trials. For the same reason 10's of darks are recommended.

Here's a post from last week that may help.

If you have access to a 3D printer here is a fully customisable model that I made. Just set the parameters on the left and then export as a .stl file

Hi all, Is anyone available in the Canmore/Banff area to buddy up for a couple of hours stargazing tonight (Wednesday)? I've got an unexpected opportunity, and would love to see/snap the milky way under a decent sky but don't fancy driving out of town in an area I don't know, in the dark, on my own. I would be happy to pay for your time and it would only be a short session as soon as it gets dark because I've got an early start in the morning.

Hi all. If anyone here uses KStars for imaging I would really appreciate it if you could hop over to this topic on the indi forum and give your opinions. I'm doing a bit of coding work on KStars and trying to gather a consensus on the best direction to go with the related GUI changes. Thanks Ed

Wow. Can you elaborate on the "Star repair" module workflow please?

Thanks for the responses. Tomatobro - I do like the idea of a "follow me" system controlling the dome from the mount. Genius. inFINNity Deck - That's a seriously impressive build. Way beyond what I'm hoping to achieve. Thanks for the tips and the links.

I need an observatory for all the usual reasons. Unfortunately our corner plot only has one suitable location - and it's triangular. I think I'm going to be making a variation on a dome to modify the shed that's already there. Right now I'm planning the structure but also thinking ahead to future automation. I have a question for anyone using an automated dome: I assume the dome rotation gets synchronised to the mounts Azimuth co-ordinate via the chosen software/drivers but what happens when the scope changes pier side after a meridian flip? The resulting Azimuth is (almost) unchanged but physically the optical axis is displaced by a significant amount (eg. maybe 0.5 - 0.8m). I'm assuming that the typical dome shutter aperture isn't wide enough to allow for this so is there some offset applied to the dome rotation depending on current pier side?

Hi, I use a Fuji X-T2 with Kstars/Ekos/indi. The driver has some limitations but it does work. Driver configuration points: Leave the camera in T mode and only use exposures from the preset list - Bulb mode does not work properly. Set the SDCard mode to Delete - on the Fuji this seems to control the RAM buffer usage as well. If you don't set this to Delete, the camera will take shots until it's RAM buffer is full and then hang. Note this also means that the images are only saved via indi (to your computer) not to the SDCard. I set the Transfer Format to Native (RAW) not fits because on a Raspberry Pi (I'm running a RP4 8GB) the 'bayer' decode of the funky Fuji X-Trans CFA takes too long (10's of seconds). This means you can't run the fits viewer during capture. Image display for other functions eg. focus, plate solving alignment, PA work fine as they use the image un-debayered. Also note that the Transfer Format setting does not seem to get saved in the Capture module or passed from the indi driver settings - you have to set it each session in the Capture module. I can't comment on ASIAIR though, sorry.

I've completed two Onstep conversations, one on an E-q5 and the other on a G11. I've found the system to be great in use, intuitive and rock steady. Most of the issues I've seen mentioned on forums are about the physical system design where someone wants to design a conversion from scratch rather than following the established routes. This shouldn't be a problem if your looking to buy a kit. If you're considering a kit from Instein just be aware that they have a bit of a reputation in the community. It's not that they're bad but that they've forked off their own version of Onstep, which is fine, it's open source, but they don't seem to provide much in the way of support or contribute anything back to the community. The Onstep community can't support their users as the code base is different and they don't want to provide free tech support for a commercial (ab)user of their work.

I think a Bahtinov mask was the first thing I 3D printed for astronomy. White PLA works great. I've made a fully configurable CAD model that's freely available here. No sign in required. Just set the configuration variables (top left) to fit your scope/lens. Right click on the Part "Bahtinov mask" (bottom left) and select export to download a .STL you can throw in your slicer. Hope it helps someone.