Gina

Orion's Sword in Narrow Band Captured on 20th January 2022 with my triple imaging rig and processed in PixInsight. HSO. Ha - 29x5m = 2h25m ASI 294MM camera with Ha 3nm Astrodon filter and 200mm Asahi Super Takumar lens OIII - 8x15m = 2h ASI 1600MM-C camera with OIII 3nm Astrodon filter and 200mm Asahi Super Takumar lens SII - 6x20m = 2h ASI 1600MM-C camera with SII 3nm Astrodon filter and 200mm Asahi Super Takumar lens Guider ASI 178MM camera and 55mm Asahi Super Takumar lens stopped down to f4 Capture systems Raspberry Pi 4B running Astroberry Server x 3. Connected via Ethernet to tower computer running KStars/Ekos.

Captured on 21 Nov 2021 with my triple imaging rig, 200mm f4 Asahi Pentax Super Takumar lenses. Astrodon 3nm filters, 83 x 120s Ha subs, 97 x120 OIII and 8 x 900s + 1 x 1200s SII. Captured with KStars/Ekos/INDI and RPi image capture. Cameras ASI 294MM Pro, 2 x ASI 1600MM-Cool. Processed in PixInsight.

Thinking of doing a bit more to this project as astro is grinding to a halt due to the weather. Thing is... Can I break my addiction to astro imaging????

The design needs modifying to include a path for cables via the rotation axes viz. turret, DEC and RA. This shows a new design of the horseshoe to provide a gap between that and the DEC arc where cables might pass. Now if the smaller hole in the horseshoe is changed to a larger one with a slimline ball bearing the cables have a possible path. The "axle" can be printed as part of the DEC arc.

The design so far has one serious deficiency! Communications and power cables. Even if I could arrange all the electronics on the turret and use WiFi there is still the need for power. So arrangements have to be made for cables to connect from the outside world to the turret. I've been investigating the possibility of running 3 instances of indiserver and the drivers on one RPi 4B and I think this may be possible. I had thought of Astroberry Server but can't see how ATM. Currently using a single instance for the ASI 294MM camera plus guider etc.

I no longer use ABS and mainly use PLA. Easier to print with and more environmentally friendly. I used enclosed cabinets with fume exhaustion when I was using ABS - nasty stuff. I used to think ABS was better but I am having good results with PLA. When I need a higher temperature product I use PETG.

Just ordered an RPi 4B with 8GB RAM for testing. I know I can run Raspbian OS Lite and install 3 instances of indiserver and drivers. That would be a lighter load than trying to install 3 instances of Astroberry Server. I don't need all the apps included in Astroberry Server. The big advantage of Astroberry Server is the ease of installation and setup. I'm happy enough with a piecemeal installation - done it lots of times.

Had this from a friend :- Wondering if this could be done with Astroberry Server. Though maybe the reduced software approach would be better. Seems to me that running 3 instances of Astroberry Server on one RPi 4B could be pushing it.

Probably one for @RadekK but any suggestions welcome. I have a triple imaging rig currently using 3 separate RPi boards. The imaging cameras are an ASI 294MMPro connected to an RPi 4B running Astroberry Server and two ASI 1600MM-Cool cameras on separate RPi 3B boards and the earlier indiserver. The RPi 4B also runs the mount and a guide camera. This system is accessed using 3 instances of Terminal with SSH and 3 instances of KStars/Ekos running on my tower system with Linux Mint indoors. I would like to reduce the remote electronics and wondered if I could run 3 instances of Ekos in Astroberry Server. IOW use one RPi 4 only and get rid of the RPi 3Bs. The original reason for using separate RPi boards was that Ekos was unable to distinguish between the two ASI 1600MM cameras - they come up with the same ID. I now wonder if separate instances of Ekos could access different USB ports and avoid the ID contention. Any information and suggestions gratefully received.

Looks like being around 400mm - 500mm in all 3 dimensions, but I haven't finished yet, there's still the PA adjustments to add. That might add a bit to the height.

Same size as earlier versions but with differences. The outside measurements of the "box" are 740mm x 660mm x 1m high. I was using ABS when I first designed it so the box consists of an extruded aluminium frame with clear acrylic panels for use as a fume cabinet. Now I use only PLA and fume control is no longer an issue. The bed is a 500mm x 500mm x 5mm aluminium plate with a mains powered 1200W heater pad stuck to the underside. I expect printing volume to be 290mm x 290mm x 700mm high. I'm planning to have the bed moving up and down for the Z axis. In one of my earlier versions I had a moving XY carriage and fixed bed but that proved impractical. The Z drive will consist of three trapezoidal threaded rods with 1mm pitch driven in unison by one stepper motor, 3 timing pulleys and timing belt. Adjusters will be provided on the nuts for rough bed levelling and fine bed levelling will be automatic using the software in the Duet 2 WiFi control electronics.

The "spokes" that connect the horseshoe to the bottom bearing have to be designed so that they miss the worm wheel and don't collide with the DEC arc or anything else. After a lot of messing about and trial and error, I came up with this. The turret and several other parts have been hidden for clarity.

I should point out that, unlike some of my earlier project threads, I am skipping many "blind alleys". This is still a Work-in-Progress ATM though. Next is the RA system for which I'm using a "horseshoe" for compactness. Like other horseshoe mount designs, this will have a rear gearing and front rollers. OK so this is how the horseshoe progressed. Starting with the basic shape.

The rollers can be attached to a ring and that attached to the back bearing with an arc providing the DEC system. The following CAD assembly screenshots show how the DEC system is built up, complete with worm gear to drive it. The large white spur gear turns the turret. The DEC worm wheel is shown in yellow.

This is the turret imaging rig with 200mm lenses mounted on my EQ8. The mounting method here would be totally unsuitable for a lightweight and compact DIY mount. I'm thinking of a "horseshoe" type mount. Though this shows the 200mm lenses, I have sets of shorter focal length lenses giving a wider FoV. Shorter FL lenses would probably be more suitable for use with a 3D printed mount. This is a CAD model of the rig with 28mm lenses showing the current mounting for use with standard GEM EQ mounts. Removing the mounting parts gives this. Ignoring the turret rotation drive and after much thought and playing around in CAD, I came to this arrangement as the simplest implementation for holding the turret. Applying mathematics or physics to the situation, any object in space has 6 parameters or co-ordinates. 3 spacial axes and 3 rotational co-ordinates. The central bearing takes care of the X, Y, Z co-ordinates. The rollers cover 2 of the 3 rotational values and the final one is the turret rotation about its axis which will be controlled by gearing and stepper motor.