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.

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 :-

Quote

Hi Gina, came across this just now. Looks like there might be a way to run multiple servers on a Pi using different port numbers. https://www.youtube.com/watch?v=RwKkLniEIIk

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.

On 31/10/2021 at 16:18, rwillett said:

Looks good, but I'd worry about flex when you get to something that sort of size.

I'm trying to work out (in what passes for my brain these days), where the max load will be and in which direction. That's my biggest worry in printing anything to do with AP.

I don't know enough about 3d modelling to work out how to do stress calculations or even if my free version of Fusion 360 can even do it.

It does remind me of the Astrotracker that somebody modelled a few months ago.

It looks like it's a hell of a size as well, whats the max dimensions?

Rob

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.

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.

Following on from the thread about my Turret Triple Imaging Rig, I'm designing a 3D printed "horseshoe" style mount for it that I can take to star parties.  Hopefully, lighter and more compact than the NEQ6 Pro mount that would be the alternative.

Should add...  I also have a laptop running Linux Mint 20.2 MATE that does the same as the tower machine (currently running LM 18.3 Cinnamon but due for upgrading as 18.3 is EOL.).

11 hours ago, vineyard said:

That looks amazing👏🏾.  Do you store the image files on each Pi (& so run independent [EKOS] instances on each Pi) or have you figured out a way to capture multiple cameras with the same EKOS instance?

Thanks very much.  I download the images to my tower machine indoors.  I run 3 Terminal windows to SSH into each RPi then 3 instances of KStars/Ekos on the tower to control each imaging system separately.  With the 3 imagers being on the same mount, one RPi controls the mount and all images are aligned (as closely as I could manage when I assembled the turret.  The 3D printed turret ends assured main alignment but rotation needed setting up by hand).

Here's a photo of my triple widefield, narrow band imaging rig with 200mm focal length lenses.  Mainly 3D printed to my own design.  Further details to follow.

Mounted on my EQ8 in the observatory.  Three cameras 2x ASI 1600MM-Cool and 1x ASI 294MM-Pro.  Mounted in the adapters directly on the cameras are Ha, OIII and SII Astrodon 3nm NB filters.  In the middle is an ASI 178MM with 55mm lens for guiding.  The main imaging lenses have remote focussing controlled by the Astroberry Focuser INDI driver in Raspberry Pi SingleBoardComputers.  The guider uses fixed focus as the focussing on a guider is not critical.

The ASI 294MM-Pro camera is run from an RPi 4B with Astroberry Server and controls the mount for slewing, plate solving and guiding as well as imaging in Ha. The other cameras run from RPi 3B boards.  The 3 RPi boards are contained in the yellow 3D printed box with blue top.  3 Ethernet patch cables connect the SBCs to a Network switch and a CAT6 Ethernet cable to the house.  The RPi boards are air cooled with a fan run at low speed to avoid vibration.

The turret rotation angle is controlled separately from an ESP32 SBC and MQTT network over WiFi (same network as I use for my weather station).  Controlling the turret rotation this way was much easier than producing a new INDI driver and matching control in Ekos.  MQTT network and Code-RED Dashboard make for an easily programmed control and data gathering system.

Ah didn't see the "All applications" option.  That's better.

Can't say I like the MATE GUI compared with Cinnamon.  Can't find the Screenshot and had to use Alt-PrtScn key which is far from ideal.  The menu is sparse to say the least!!!  I might put up with it for running KStars/Ekos.  But that's if I can get KStars installed and can't as yet. 

I've posted in the INDI Forum.

Success!!  Installed LM20.2 MATE on the laptop and I have multiple Terminals working!!  Hooray.

Quote

MATE runs faster, uses fewer resources and is more stable than Cinnamon.

The Xfce version is even lighter but I think I'll give MATE a try on the laptop.  If I like the GUI I may go for that on the tower.  I haven't yet found what Cinnamon does that MATE doesn't.

39 minutes ago, JamesF said:

Ahhhh!  Which version of 20.2 are you using?  Perhaps there's some different default behaviour between the versions.  I'm using MATE.

James

Aha!!   So you're running 20.2 MATE?  Maybe MATE is a better option for a laptop with limited resources.  I've used Ubuntu MATE on RPi boards before now.  I gather Cinnamon is a higher power GUI.  Think I'll download the MATE version and install that on the laptop.

Link to new thread

On my tower system I am currently running Mint 18 which is now at End Of Life and no longer supported so I want to upgrade to the latest version of mint.

I use multiple instances of Terminal to SSH into my three individual imaging systems.  These are running in Raspberry Pi boards.

I also want to be able to access my imaging system from a laptop  so have installed LM20.2 on my Asus laptop but as it stands, having opened one Terminal window, clicking on the icon just closes the window unlike Mint 18 in the tower which opens another Terminal window.

So my question is :- What do I need to do to enable multiple instances of the Terminal window?