rsarwar

you can use any camera that works on linux/rpi and can be opened using opencv in python. all that needs doing is changing the "video_idx" here  so that opencv can open it.

the reason for choosing the camera i chose is because having the ability to change focus is critical to ensure smooth calibration without needing to touch the camera and move it.

On 21/08/2023 at 15:00, kamayok3 said:

Is it possible to change video resolution inside your apps?

Should be fairly straight forward as it is using opencv. Here is how

https://www.google.com/amp/s/www.tutorialkart.com/opencv/python/opencv-python-resize-image.amp/

1.Multiply with scaler to resize resolution

https://github.com/rsarwar87/pyReflectorCollimator/blob/master/pyCameraController.py#L63-L69

2. Resize frame by the same scalar after this line

https://github.com/rsarwar87/pyReflectorCollimator/blob/master/pyCameraWindow.py#L53

        ret, frame = self.cc.vid.read()

Hi it was written to work from linux, but will work on rpi4. May also work on wsl.

3x drizzle integratio with almost 9 hours of data from brottle 6. really nice quality this scope i find !

https://www.astrobin.com/jjohdk/

Got the EL panels. Very flat. The lines appear only with shutter speed less than 1/250. The examples is with 1/4000.

Will need to be dimmed, I am adding a opal acrylic which should reduce brightness. Will see what happens with lower voltage 

Edit-- lowered voltage from 12 v to 5v, and the brightness scales accordingly. Power draw drops from 1.5 w to 0.2 w. 

Hi. I am in the process of making one as well. 

For led strip I am using these 13cm Diameter Backlight Panel 
https://a.aliexpress.com/_mMybhPc

It means there is an inverter I have to include along with a rpi pico to control it, but the light from it is well balanced I think.... Have to confirm, item still on its way. 

Still going to use a defuse to mitigate hots tops or lines

i think it is brilliant. you have control over how much noise you want to remove and if you have a GPU, it takes about 15 sec vs 1 hr on Ez Denoise. Certainly better results compared to EzDenoise. 

have not used topaz denoise as it does not run on linux..

4 x 1 mossaic. first time i did such a big one. almost 40 hours of data using Ha 3.5 from Baader and O/S 6n from astronomik + qhy256M. could not normalize the background evenly unfortunately.

https://www.astrobin.com/cz268t/?utm_source=astrobin&utm_medium=email&utm_campaign=notification&from_user=27646

yes, looking forward your review of the CC using your APS-C. although i believe the size of the image circle is also dependent on the size of the secondary mirror, which is small for 130 pds.

75 mm is ideal for me given my odd setup (need 68 mm). Why are we stuck with this 55mm non-sense any way!

On 25/03/2022 at 22:33, Chris said:

Thanks glad you liked it Well the coma corrector shouldn't vignette much at all with a full frame sensor as it has 44mm clear aperture, however as to how well it corrects star shapes to the edge with a full frame camera I do not know. Most of the reviews out there are for fast Dob owners using it as a cheap alternative to a paracorr.

I will be testing the coma corrector with an APS-C  Fuji sensor and adding to the information regarding the imaging side of things. The few imaging reviews I've seen do indicate it would be decent at f/5 with your 130pds, although they don't mention the sensor size! 

One thing to note is that the GSO/StellaLyra photo-visual coma corrector requires a slightly unusual back focus of 75mm as apposed to the typical 55mm so a 20mm extension tube will be required as well as your T-ring. 

 

 

 

 

excellent review chris!

do we know what the image circle is of the CC with this scope - maybe a flat image with an APSC or full frame camera. the product page on FLO only states 44 mm clear apparture.

also curious if it will work with a 130 pds - 5.5F seems slow in modern days, but that is not too bad. but will make my 130pds usable again as i need 68 mm of backfocus when using my OAG

May no t be exactly relavent, but i thought i would share some my of recent findings

I recently developed a fault on my QHY268M which meant it did not get detected by my PC/RPI4. i had the camera partially disassembled before sending it in for a replacement (Modern astronomy has been really helpful is mitigating the problem). However based on what i could see, the camera USB3 port is actually not isolated and shares the ground plane with the main power source. the power brick it comes with is fairly good, and seems to have proper grounding. however, in most cases, PI4/mount/usb hub power bricks are not, so there can be AC ground loop between the two device through the USB cable. since we are running the devices in outdoor settings, AC loop issues will be common if poor quality power bricks are used. this means, large current draw through the USB cable (on a bad day, as much as a few amps) which can potentially damage the camera and, more commonly make the camera USB link unstable.

In my opinion, the only way to solve it properly is to use a single good quality power adaptor with proper isolation to power both camera and all the other device. we are talking about something like a pegasus power box. ASI air is inadequite for qhy268m power requirements. 

alternatively use a single battery to power everything.

if you have to use multiple power bricks, one has to make sure all the device have the same grounding and use good quality power supply with proper isolation and grounding.

I think i managed to work out a "proper" way of collimating a RC. The idea is to 

1. make the secondary and the primary coaxial without the focuser attached.

2. add M90 tilt plate and the focuser and then by only adjust the collimation on the tilt plate to bring the focuser and the secondary coaxial. 

first the first one, i had to 3d print a M90 to M48 thread.

The adator was made such that it uses the pressure lock ring to centre the adaptor. and the on the M48 thread, screw in the electric collimator. then reiterate the collimation on the secondary and primary mirrors to get it as close as possible.

then take it off, put the tilt ring and the focuser and then the electric collimator and then adjust the tilt plate to recollimate. 

I dont see a point of perfectly dialing in the screws, but as close to perfect is good enough, as this will need to be readjusted using a artifitial star. I dont have one so i did it under the stars, but forgot to take images to document it. however, the above process resulted in near perfect collimation and needed on mirror adjustment.

this is a crop of main image - no drizzle applied, just a crop and a resample to a higher resolution.

really happy with the level of details. 12.5 hour integration

still a work in process. but quite happy with the SM90 + TSFLAT2. will do the horse and orion mosaic with the 0.8x flattener after this and see how that goes

[URL=https://astrob.in/jl4k1w/0/]https://astrob.in/jl4k1w/0/rawthumb/regular/get.jpg?insecure[/URL]

2 hours ago, malc-c said:

Not a an ASCOM vs INDI debate at all.  Just the way I see it you install a windows application on a windows machine that runs a standard platform (ASCOM)  so you would expect that windows application to support the platform designed for that operating system.  Not have to purchase another computer such as a pi to run linux to run the platform and then remote into it from the windows PC .

EQMOD as originally written is an ASCOM telescope driver.  So is selectable from other applications that need to control the mount, which is why the driver is listed in any other ASCOM compliant application.  Being an open source project others have ported it to other OS's and platforms.  Granted it's been a long time since I installed a flavour of linux so maybe things are more user friendly.  Back then adding a USB device required command line code which for someone totally new to the OS isn't ideal.  Windows, whilst in your opinion may not be the ideal OS on which to run software  for astronomical needs, and I respect that opinion, is more user friendly and plug and play.

I may play about later and see if installing a VM ware machine running linux will work - probably run into networking issues , but hey ho ... could be fun trying

good luck with the linux. i would recommend getting a rpi3/4 for testing or install ubuntu as dual boot. i am not sure if all USB devices will work properly over VM. maybe it will. linux  distros has come a long way in the last 5 years, let alone compared to 15 years ago or more.

to me it makes little sense to dedicate a laptop/pc in the observator when it can be done with rpi remotely. and if you are set up in the backyard without a fixed observatory. it even less sense to me. wifi and ethernet is everywhere in our home, why not take advantage of IoT compliant devices . they have more power and stable compared to a what they were even 3 years ago.

On 02/01/2022 at 11:28, Rafael said:

Finally, after almost two months, I was able to test my StellaMira. In the last 2 nights I could collect almost 7.5h data.
64x300sec with the Antlia ALP-T dualband filter and 40x180sec RGB data with UV/IR cut filter.
Camera QHY294C Pro on CEM40

 

lucy you, we still have clouds.


I was testing Stellamira with StarField 0.8x flattener: https://www.firstlightoptics.com/starfield-telescopes/starfield-08x-adjustable-reducer-flattener-for-90102mm-refractors.html
Stars are flat for the entire APS-C snesor and the back focus comes to about 59 mm. I could use my OAG, so the image circle is big enough for full frame but may been flats. TS sells the same device and lists it as having 42 mm image circle.

i feel it is a very good flattener for it's proce and can be used with a multitude of scopes. very well priced vs TS@250+ euro pre vat

also, if i am not mistaken, all ascom devices come with some form of driver from the manufacturer that sits between the planeterium and the device it self. so it really is inconsequential if one labels a device as ASCOM, as it requires a middleware to work.

essentially, indiserver provides the same functionality as this middle ware, but can also do a lot more than just allow kstar to comminicate with device located in a remote part of your observatory and you dont need to have usb cables running all over the place. just something like a pi zero W to run indiserver over wifi and have it comepletely detached.

2 hours ago, malc-c said:

Thanks for the advice, but this really clarifies the point I was making.  You have to have a computer of some sorts running linux to run the INDI Servre for the work around to function.  The fact you can download a version of Kstars written for windows and install it on a windows computer, but can't use its full potential to control a mount using ASCOM is so frustrating, especially for those not familiar with linux.  I'm sure if it was reversed, and the application was windows only, but got ported to Linux but without INDI support there would be the same concerns.  This for me suggests that making an application ASCOM compliant is far more complicated that we think ?

Indiserver is written for distributed control systems. So that is by design. 

Why do you think indi cannot handle ascom compplient devices? it can talk to ascom devices. i have written by own mount controller and i refused to uses ASCI so i had to re write part of indi-devcies to make it work with mine, because all it did was talk to ascom devices. also it is not true that ascom can give more control.
Ascom is just a uart/serial device with a control charactor followed by some hex digits written an ascii. personally i dont like working with softwares that requres me to parse string. but hey, its what proposed and  made in 1990s using 1980s teck due to limitation on hardware and computational power. but things are a bit different now in 2022

I feel like this os becoming a Linux vs Windows debate. But Everone  has their thing, but Windows is not the most stable platform to run a control platform with psudo real-time requirements.  it works better on Linux 

8 hours ago, malc-c said:

I would assume porting an INDI driver to the ASCOM platform is quite complicated.  I raised this in a previous discussion regarding K Stars, which I think is one of the best planetarium application out there, siting between the glossy Stellarium app, and the now somewhat dated looking GUI of CdC.  But when it was ported to run on Windows there is no ASCOM support natively built in for telescope control.  I can only presume that the reasoning was it was too complicated to do so.  There may be workarounds to get windows K stars talking to EQMOD etc but often it seems like a lot of faffing around and I've never managed to get it to work reliably.   I don't know enough about Linux to make the jump in order to run the same work flow and applications I'm used to, so I have no choice but to continue with CdC.

Where hardware is concerned  it would be nice if manufactures released drivers for all three platforms, windows, linux and mac OS... but  I guess they feel the latter two are in a minority so don't see the point in investing the time and effort to write / port drivers to these platforms.

 

they way i do is have kstar runing on ubuntu/windows (i use ubuntu but i tested it on on windows as well, no difference and dont need the indiserver on windows which is what is not ported on windows yet) and run indiserver and phd2 on a rpi4. then get the kstar to connect to the indiserver /phd2remotely. indiserver has its own version of eqmod which works reliably for me. 

RE: porting indi to ascom using python, it is possible. just wrap the indi calls with corresponding ASCOM and let the server run on rpi4. the open a virtual com port using serial to wifi driver and it should work fine. you ccannot do it for complex drivers, like for example eqmod, but for a focuser, it should be fairly straightforward

https://indilib.org/develop/indi-python-bindings.html

20 hours ago, BCN_Sean said:

Looking at the hardware side of it, it may be quicker and easier to modify the firmware for the focuser itself to recognise as and accept commands as if it was a MoonLite clone than looking around to try and translate the drivers from one platform to another.

I don't think that is true. Either way one needs to be able to map out the as om protocol. Question is where would you rather do it, in python which is easy to do for most with zero chance of breaking the firmware or in low level c code with possibility of breaking the device.. 

7 hours ago, dazzystar said:

Hi All,

I was watching a video about cameras for telescopes and the subject of back focus was brought up and how it needed to be 55mm from the CMOS chip on the camera. Not 54mm and not 56mm, exactly 55mm to achieve focus. I was then left pondering why on Earth you can't just use the focusing knob on the scope? What have I missed and can someone try and explain it please?

Cheers

Daz

assuming you are asking why 55 mm was chosen as a standard and not some other random number, it comes from the fact that the common DSLRs bodies have their sensor places somewhere in the range of 44-45 mm. add another 10 mm for the adaptor. so with 55mm it gives a very straightforward, almost standardized distance between the reducer and the dslr sensor, allowing someone new to enter into astrophotography without having to fiddle with spacers. hence it is 55 mm. just an ease of use, because if we were to use 45 mm as the standarized backfocus, most reducers wounld not work with DSLRs

it is possible. you need to have a python server running that will accept ASCOM commands and execute the corresponding indi commands through indi server.

indilib already supports python. so all you have to do is open a virtual serial com and listen to serial commands from ASCOM.

i did something similar for indiEqmod. feel free to use it as a reference. i was written in cpp and talks to the low level drivers of my DIY mount, but the concept is the same

https://github.com/rsarwar87/CmodA7-SkyTracker/blob/device-qmtech-a7-35t/koheron-server/libclient/ascom_server.cpp

Not really an experience of the cam itself, but I considered buying altair but decided to go with qhy because I found they are unable to provide basic info about their camera when asked. 

For example, they were confused why I would need drivers that work on raspberry pi. 

Also asked altair some question about their 115EDT, their answers were patchy and inconsistent. Almost like they don't know basic info of the products they are selling. 

It's quite easy to make it. It cost me 50 quid to make it, but it can be done much cheaper if you think you can find a cheaper camera. 

Just follow the same steps to collamate your RC. I software I have written if free to use, and can be modified easily to add support for more camera.

One can try to use a guide cam, as suggested, using a wide angle lense, but the problem with that is you can't change focus using the software. So you have do either do it without it and use a defocused image to guide yourself, or take the cam out and refocus manually everytime you need to check/go back and forth. 

First light with 90mm F6 + TSFLAT2. needed 120 mm of backfocus. i think i need to try 110. 

QHY268M, Baader Ha 3.5 nm. stack of 3 images with darks and bias only. not processed other than auto stretch.

Was able to get OAG working without issue. prism places along the shorter edge (furtherest from the centre) just to check if there is enough light there. The bottom 10 % have reduced exposure so for full frame, one would need to use flats. i have a fullframe nikon, but no nikon adaptor so cannot check more scientifically.