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.

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!

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]

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.

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.

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

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

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

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.