Veej

A QHY5III200M. It will be the guide camera for my Edge 9.25 and maybe occasionally get pointed at a planet. I think its the final "must have" on my setup ive been building over the last 12 months ( ignoring the ever growing "wish list" of course )

I must admit, a screw makes me happier ( as it were! ) The nosepiece / clamp combo seems solid - I've had a Qhy268m with QHY 7 slot filter wheel hanging from it with no issues and it gives me nice round stars across the field on long exposures.

usually the cooling starts for me pretty much as soon as i turn it on via the equipment/camera section ( QHY268m and ZWO 533mc Pro ). there can be a difference between brands in terms of the power increase curve. Silly thought - is the camera connected via something like a pegasus astro connection box - maybe that needs to be active in NINA before the cam can communicate? ( mine cams are and it does need to be on first )

the Stellamira ones dont use a screw connector like the official Starfield one, they have a 2" nose piece that is clamped in place by the scope. the M48 / M42 connector is on the camera side of the adaptor. On the plus side, it makes it very easy to rotate the camera as required and i havnt had any issues with loosening or movement.

Ive been using both the Starfield adjustable 0.8x reducer and the Stellamira flattener with my 102ED - both are great and have never caused me problems. I do keep eyeing up the 0.6x reducer from Stellamira - i think i might have a go on one of these this week.

just as an example - on the left are my correct details i manually enter ( they work fine for me ) - on the right are the coordinates stellarium generates when i use the "get location from gps or system service" option.

my experience of this happening with my EQ6R-Pro is that it is usually down to incorrect values in the system. I have seen incorrect values resulting from gps data when using a mobile - its probably worth double checking what other sites says these values should be and comparing them.

I did 1. is 2 a possibility with WBPP ? ( I'll give it a try tomorrow and find out ) i did find the clear cache button tonight, so i gave that a press just in case.

ive taken a few subs tonight with the L and R filters. It looks like they are behaving as expected - Images taken with L are brighter than with R given the same exposure time. If the weather gods allow, I will redo the R and L subs + calibration frames tonight and try a fresh set of processing. I think this is starting to look like the problem is in software land - maybe a bad cache or incorrectly labelled images.

you are not the first person today to suggest that maybe the L and R are swapped - im about to give that a test. ( i have confirmed the filters are in the right order in the FW and NINA labelled them so its not human error ) the integration times and amount of subs are the same across all channels, with each having their own set of calibration frames. it seems that for some reason it took 2 hours to platesolve - im assuming because of the over saturation. ( no idea why though )

ooooh, its my first post.... Hello! ( long time lurker, regular reader, hoarder of good things from FLO ) So I have dived into monochrome imaging - I'm shooting on a Qhy268 m with Antlia V-Pro LRGB filters and in this case im using a Starfield 102. I have stacked and processed the L,R,G and B channels separately in Pixinsight using the Weighted Batch Preprocessing script. I'm getting no rejected frames and each channel has its own set of calibration frames. L,G and B each take around 15 mins to process, but R takes closer to 2 hours. The following image shows the result of these stacks with a single STF applied to make them visible. As you can see, the R channel ( top right ) is really oversaturated which obviously doesn't work well when I combine the LRGB. I've tried rerunning WBPP but the result is always the same. Any thought or suggestions? Am I missing something obvious in Pixi or could it be something more fundamental like a back to front filer ? ( they are 36mm unmounted )