-
Posts
45,326 -
Joined
-
Last visited
-
Days Won
120
Content Type
Profiles
Forums
Gallery
Events
Blogs
Posts posted by Gina
-
-
1 hour ago, The Admiral said:
Yes of course they do Gina! My mistake. Doh! . Sorry for raising a red herring.
Ian
No worries. I need people to check my designs and theories.
-
9 hours ago, vineyard said:
If that's the K type 28mm f3.5 that's a lovely lens!
No, they are the M42 thread type. I have a K mount one I ordered by mistake which I plan to make an adapter for. It's actually f2.8.
-
The cameras do indeed turn in the right directions. Don't they???!!!
- 1
-
For the Milky Way mosaic I have Asahi SMC Takumar 28mm f3.5 lenses. From Cygnus to Orion - The Milky Way as an Ultra Widefield Mosaic - WIP
I also have 55mm f1.8 Super Takumar and 105mm f2.8 Takumar and 200mm f4 SMC Takumar lenses.
- 2
-
-
I'm calling this Dual and Triple Rigs because I plan to make a triple imaging rig with three ASI 1600MM-Cool cameras and Astrodon 3nm filters with three vintage film SLR lenses of very high quality. However, I only have two cameras at present so I shall start with a dual imaging rig but with provision for easy upgrade later.
As I mentioned in the DSO Imaging forum, I'm planning a mosaic project covering the Milky Way in NB. This requires that the cameras can be rotated in unison to line up the mosaic panels. My plan is to rotate the cameras using gears and stepper motor controlled by the electronics (using a special INDI driver).
The first 3 screenshots show a CAD model of the triple imaging rig. Two of the main assembly and one of the frame or bracket.
There are a few problems with 3D printing this frame so I have split it into two with each half individually bolted to the Losmandy type dovetail bar.
The next screenshots show a partial assembly on the dovetail bar and one side in the S3D slicer.
- 8
-
I do get slight vignetting but it is corrected using flats.
- 1
-
5 minutes ago, happy-kat said:
Perhaps when you join panel 1 and 2 it will give a feel for what overlap and angle change works.
Yes indeed.
-
The sky was such that I was able to image the Orion area a few nights ago and here are some results. The FoV doesn't match that for the mosaic as I didn't have remote camera rotation nor had decided how the mosaic would be built up at that time. I'm not totally satisfied with the results - I think the OIII was overexposed.
Here are some image stacks resulting from processing a couple of hours of Ha and OIII together with a simple colour combination. Processed in PixInsight.
- 1
-
Mosaic panel 5. Orion. Looks like the panels don't quite join so I may have to reduce the overlap on other panels. I wasn't expecting to cover it in 5 panels.
-
Panel 4. Two possible alternatives. On the whole, I think I prefer the second.
-
Next panel, +50° camera angle. Ignore the moon - capture will have to be when the moon is out of the way.
-
One of the problems of making mosaics is that the camera needs rotating from one panel to the next if the panels are going to follow on neatly. This first panel is with the cameras at -45°. The next panel above it needs turning to 0°. This FoV is shown in the next screenshot. To provide this I shall be making a dual imaging rig with remote camera rotation. This will be the subject of another thread.
-
This screenshot from KStars shows the area (FoV) of the first panel. This seems to cover the main DSOs with little in Vulpecula or Lyra.
-
Using 28mm f3.5 lenses on ASI 1600MM0Cool cameras and Astrodon 3nm filters I am starting a project to cover the Milky Way in a mosaic of something like 6 panels. Each panel will have a FoV of 36x27 degrees. I shall be taking Ha and OIII wavelengths to start with and may go on to add SII later.
This is Cygnus & Cepheus in Ha and OIII and a couple of bicolour versions.
- 20
-
I'll try that tomorrow.
-
char chDT[16]; void showLocalTime() { struct tm timeinfo; if(!getLocalTime(&timeinfo)){ myDT = "Failed to obtain time"; return;} else { year = timeinfo.tm_year + 1900; month = timeinfo.tm_mon + 1; day = timeinfo.tm_mday; hour = timeinfo.tm_hour; minute = timeinfo.tm_min; myDT = ""; myDT += year; myDT += "-"; if (month < 10) {myDT += "0";} myDT += month; myDT += "-"; if (day < 10) {myDT += "0";} myDT += day; myDT += " "; if (hour < 10) {myDT += "0";} myDT += hour; myDT += ":"; if (minute < 10) {myDT += "0";} myDT += minute; } myDT.toCharArray(chDT, 16); }
Then something like
client.publish("local/datetime", chDT);
-
All I want to do in this instance is display the date and time in the Dashboard.
-
I think I'll add the date/time code and message to the living room client rather that the ROR Automation then I can simply add a switch to change GMT/BST. Doesn't look like NTP does it.
-
MQTT needs strings converted to an array of char - so toCharArray()
-
I'm thinking of getting the time from ntpServer
const char* ntpServer = "pool.ntp.org"; const long gmtOffset_sec = 0; const int daylightOffset_sec = 3600;
void showLocalTime() { struct tm timeinfo; if(!getLocalTime(&timeinfo)){ myDT = "Failed to obtain time"; return;} else { year = timeinfo.tm_year + 1900; month = timeinfo.tm_mon + 1; day = timeinfo.tm_mday; hour = timeinfo.tm_hour; minute = timeinfo.tm_min; myDT = ""; myDT += year; myDT += "-"; if (month < 10) {myDT += "0";} myDT += month; myDT += "-"; if (day < 10) {myDT += "0";} myDT += day; myDT += " "; if (hour < 10) {myDT += "0";} myDT += hour; myDT += ":"; if (minute < 10) {myDT += "0";} myDT += minute; } }
-
I'm working on the ROR Automation ATM and I think I'll just format the date/time and send it in a message.
-
Got the wrong Text display. Seems I need some formatting!
Result
- 1
-
Thought I might have found it but not working ATM. I have something wrong, but what?
Dual and Triple Widefield NB Imaging Rigs with Remote Rotatable Cameras.
in DIY Astronomer
Posted
I'm not sure how to do it ATM, Olly. I have done it a bit in the past but not with PixInsight which I'm using now. Should be fun 🤣