wimvb

Now you know what I'm going to say to that! 🤣 How did the photons entering your objective know the focal length of the system that followed? What matters is aperture and pixel size. F ratio is hot air. You proved this with your Liverpool Telescope images! Olly Well, actually... The photon capturing ability of an imaging system is proportional to the square of (pixel size / f-number). That’s why the f-rule works in day time photography; you can swap lenses and keep the exposure time if you don’t change the f-number. But this relationship can also be stated as: the capturing ability of an imaging system is proportional to the square of (aperture x imaging scale (”/pixel)). A lower f-number will either mean that you have a larger aperture, or you put more sky on each pixel. Both will get you more photons on each pixel. In Görans case, if he had used a 400mm telescope with a 56 mm f/7 aperture, he would probably still be collecting photons. The reason why the Liverpool telescope is so good at collecting photons, is its 30 um pixels at f/10, giving it an imaging scale of 0.3”/pixel at 2 m aperture.

I can only quote little orphan Annie: ”Tomorrow, tomorrow ...”

To let the clouds in, you mean? 😉

And me. I knew about the dust. It took me a lot more effort to reveal even a fraction of it. https://www.astrobin.com/294874/?image_list_page=3&nc=&nce= Great image, Göran

The voltage regulator you link to is a step down regulator. It needs an input voltage that is higher than what the mount wants. Because the mount will work well with a voltage higher than 12V, I think you’re better off with the battery alone.

My experience with the AZ-EQ6: you need to remove backlash, which in itself doesn’t improve tracking, but it will improve guiding. you need to tighten the ra belt. If not, you will get a 10 s periodic wiggle. This can not be guided out easily. you will then have a 120s periodic error which corresponds to one rotation of the ra timing pulley. This is smooth and can be guided out. you need perfect polar alignment if you don’t guide. If not, your images will exhibit so called walking noise. the mount has permanent periodic error correction, which you need to program, unless you guide. Best practice with this mount: you need to guide it. edit: to make analysis easier, rotate the camera such that the sensor’s long edge is aligned to RA.

Been there, done that. Never bothered with the t-shirt. Just last night I noticed that the belt wheel of the RA motor in my AZEQ6 had started come loose (I had replaced it last week, and had probably not tightened it enough). To tighten it, I need to take the motor out, and that's definitely not a night time job. So, I just packed it in and will go out in a moment to fix it. I can just say that when you gain experience, the things that can (and will) go wrong tend to become trickier. Except for: Forgetting to remove the Bahtinov mask after focusing (I never use a B-mask anymore, to avoid this. Now I have upgraded to an autofocuser that can mess up in stead.) "Where do those diffraction spikes come from?" -> "why can't I reach focus all of a sudden? It worked fine just last week." Forgetting to plug in the dew heater. "Have clouds moved in over my obsy? It looks clear outside." Forgetting to turn on the powered usb hub (mine has a push button on/off switch that is off in its default state) " why won't my camera connect? It worked fine just last week." Forgetting to turn on the mount after maintenance. "my mount stopped slewing. It worked fine just last week." Usb cables. "Where did I put the spare? Or is that the old cable , that I forgot to throw away? Last week." Bumping into protruding parts of the mount/telescope while fixing any of the above, and throwing off balance or polar alignment. "Ouch! Not again." Patience is not a virtue, it's a necessity.

If you want to use binning with a osc camera, you need to do it in software, so called super pixel debayering. The debayering process takes a group of 4 pixels and creates one pixel with the colour information of the original pixels. The R pixel provides red, the B pixel blue, and the average of the G pixels provides green. PixInsight has this as a deBayer option. Don’t know if DSS can do the same.

Sorry, I don’t know NodeRed. Atm I’m playing with influxdb and grafana. If I can get the esp to post its data directly into influxdb, I may be able to skip Mqtt altogether. Wireless udp as opposed to tcp may be the way forward. Udp doesn’t use connections, and there’s a risk that messages are lost. But the traffic is very low anyway, and an occasional lost message is no big deal.

If so, you can send the time stamp from the esp to your mqtt server.

Do you generate a time stamp in the esp devices? I use the Rtc time module and take the time from the router.

We could just say it’s superman’s cape. The simbad database and Wikipedia. http://simbad.u-strasbg.fr/simbad/sim-fid

If the guide deviations are equal in ra and dec, and truly random, your stars will look fat and blurry. You really need guide rms less than half image pixel scale if you want to keep details in your images. At the same time, you can’t expect guiding to be better than 0.1 - 0.2 pixels. That’s why the guiding pixel scale shouldn’t be too large compared to the imaging pixel scale.

Yes, I couldn’t see that in your screen shot. If you can increase that, the guiding variation may decrease.

Yes Sorry, my bad. Imaging scale ir pixel scale = 4.3*206/600 = 1.6”/pixel. Guide rms should then be < 0.8”. If it’s 1.5”, it’s more than 1 pixel, and since RA rms is larger than DEC rms, you won’t have round stars.

http://adgsoftware.com/phd2utils/ for the guide log viewer

The guide error, RMS value you are refering to, should be the one in arcseconds, which for you is 1.53” if I read correctly. This value should be at most half your imaging scale, ie less than 1.1”, otherwise tracking errors will affect the stars in your images. To avoid guiding on seeing flicker, keep your exposure time several seconds. If you go below 1 second, the guide star will move due to seeing. The guide assistant will give you recommended settings. Use these as a baseline. It will also show your polar alignment error and DEC backlash. If the latter is large, keep a small polar misalignment, and guide in only one DEC direction (opposing the drift). On the phd website, there is a link to a guiding analysis program. Download and install to analyse your guide logs.

Be very careful with optimising or scaling darks, even if a master bias is used. This may work well with standard ccd cameras, but there is no guarantee that it will work with cmos, dedicated astrocam or dslr.

Many of the faint fuzzies in the background have similar redshift values, and are 200 - 250 Mly away from us.

But, doesn't the light sub also contain this bias signal? If so, Bias(light) - bias(bias) =0 Or, bias(light) - bias(dark) = 0, and bias is canceled in calibration. And isn't that the whole point of calibration?

I guess that is what I meant with

Osc of course. 😋 @Rustang, & others: Regarding dithering. If you plan to dither 15 pixels, and you have a guide rate of 0.5 sidereal, then dithering should take twice your imaging scale ("/pixel) in seconds. Ie, if you image at 1"/p and your guide rate = 0.5, a 2 seconds dither will move your mount 15 pixels. The 12 pixel dither recommendation comes from a talk by Tony Hallas on astrophotography with a dslr. Dithering will never by itself lower the noise in an image. Only more data will do that. And then only when the exposure time is such that the read noise is burried in light pollution (photon) noise or thermal noise. For a non-cooled dslr at high ISO, you may run into dynamic range problems. Keeping the ISO down can be a good thing. But dithering will spread any fixed pattern noise, and break up so called walking noise.

It’s even more fun using simbad to find more about them. Some may be several hundred million light years away.

No, that wouldn’t have helped. This is purely a calibration issue.

Btw, if this example shows the worst star, then just blur as I suggested.