pete_l

For reference, this is what a 6 second image from raspistill looks like. I've used the same values for digital and analog gain that meteotux produced (see above). Though this image is a single 6 second exposure, while the ones I took with meteotux were 60*2 second subs. The colour balance is different and there is a lot more noise. I find this camera produces a light band along the top with long exposures. Light leakage? Amp glow?

IMX219 (I've just added that to the text)

Good stuff! Here's a "first light" sample taken from my Pi4 with the 8MPix camera IMX219 sensor + 160° lens. Sky conditions are 100% clear, SQM=19.6 with the Moon rising imminently The view is straight up. North to the top of the image. The summer triangle is to the left, Deneb / Cygnus the higher point. Vega in the centre and the trapezium of Hercules off to the right. The red blob is my WiMax internet parabola. The light along the left side is from my sound-activated security light, which comes on when the wind blows and it *is* gusty tonight The parameters to meteotux_pi are: ./meteotux_pi -d 120 -e 2000 --verbose The --verbose option reports camera settings typically as: AWB Red =1.67 AWB Blue =1.71 Exposure =1999983 Analog gain =7.53 Digital gain =10.00

Personally, if I had had a problem with one example of a mount that is very popular and has a good reputation I'd just go for anther mount of the same type. There are no generic communications problems with HEQ5s so this would seem to be a single bad example. Not a reason to abandon the entire range. In my experience (sample size: 1 * HEQ5 Pro) my communications problem was caused by an inappropriate power supply. One that was intended as a charger for laptops rather than to power sensitive equipment. Once I swapped that for a better supply, all my problems disappeared.

In your do1mjobs routine you sum the contents of the meanArray irrespective of the number of entries in it. Then divide the total by a constant. That would explain why your mean value increments. I have no idea why it gets reset to zero - does the ESP32 get reset somehow? As far as OTA uploads go, I would advise you to look into this. It saves a great deal of time and is well worth the effort. It also loads the code in faster

OK, so what you know is that collimation looks good and the focus doesn't seem to be a problem. The one thing I would strongly recommend is to not go adjusting anything. You say there is another eyepiece(s) on order. I'd wait for that and to try them. It is quite possible that one of the optical elements in the E.P. has come unglued. Aside from shaking it and listening for a rattle (doesn't always work!), you could try to cast an image just through the EP onto a piece of paper. But to repeat: until you have a good diagnosis of what the problem is, making adjustments just complicates the matter and makes finding the solution many times harder.

Last night I was running a Pi with its 8MPix IMX219 camera. See the photo enclosed After bringing it indoors to tweak the focus, the very next images had these white splodges on them. I immediately thought that the lens had got some smudges on it. It never occurred to me that they were clouds P.S. With a 10s exposure at full resolution the camera sees down to Mag 5 - maybe 5½. When the Moon goes away I'll see if it goes any deeper. This is for a meteor detection system. P.P.S To fix your water ingress problem, have you tried a rubber sealing gasket rather than silicone sealant.?

and not a "cigarette lighter" connector in sight! Great work.

Can't have variable names beginning with a number?

Ah, an optimist! A 12inch F/5 newt is 5 feet long. And the balance point is quite a long way towards the rear. With my 30cm F/5 dob there is 90cm from the balance point to the top of the tube. And more distance if you have a dew shield after that, I'd say that 8 feet (2.4m) inside measurements is right at the lower limit of what you'd need.

I have the camera's control panel set to 10 FPS with a max. exposure time of 80mS (as high as it will permit). I am using opencv + python to grab 5 MPix images off the stream and save them as PNG format stills. After I have collected a batch, which usually takes about 12-13 seconds then I numerically add them. The result is gamma adjusted and sharpened a little to produce the final result. If someone has an alignment algo in python then I'd be interested to see it

I have used IP cameras (they send a video stream across an internet connection) with both IMX291 and IMX335 sensors. I find the IMX291 (1920x1024) unsuitable due to the wide+narrow format. It is a poor match for a lens that projects a circular image. However the IMX335 has a 4:3 format and a chip size that is a good match for many M16 lenses. Ordinary fisheye lenses have absolutely tiny apertures so there are very few stars bright enough to register. However, there are some lenses available that work at F/0.95 (yes! less that a unity focal ratio). These are pretty good at gathering starlight, although they don't provide coverage of the entire sky. At present I am using a 4mm FL lens of dubious quality and unknown focal ratio. That gives a 70°x50° view (plate solved example here) and when I stack 100 subs, there is a decent level of sensitivity. Although as you can see, there is considerable distortion on bright stars.

Word is coming out of a problem with the latest update to this app from Adobe. Briefly, it deletes all your stuff and you cannot get it back! See this article for all the details.

That makes the assumption that a star of 1.3 arc seconds dispersion is exactly resolved on a single sensor pixel of the same size. That is extremely unlikely to happen and any star's image will almost always be shared between several adjacent pixels. Hence the idealised SNR from the calculation will rarely be obtained. And then, only for a small proportion of stars since they are randomly positioned in the sky. When you add to that the random tracking errors of the mount, there will never be a case where the textbook calculations are met. Simply put: the difference between theory and practice in practice is greater than the difference between theory and practice in theory

Having a seeing of "X" does not mean that your CCD/CMOS arcsec/px has to be the same, Nor does it follow that matching the two will give the best results. Or that having a mismatch will be a disaster. While there may be some sort of theoretical optimal relationship, ISTM the link between the two is not strong. Especially since the chances of any particular star perfectly occupying an entire CCD pixel is extremely small. Most will sit across two or (many) more. And as for dispersed objects (DSOs) the argument weakens considerably as features will be much larger than a star's pinpoint image. So pretty much any pixel scale, within reason, will give very acceptable results.

The professional observatories keep the interior of the dome at night time temperatures all day long. I am thinking of a "scope fridge" product. To be released in late March / early April

The "rule" is that in most places atmospheric seeing (turbulence) sets a lower limit on the spot-size of a star of between 1 and 2 arc-sec. However, any connection to the "best" arc-sec per pixel image scale is, at best, rather loose. Personally, I'd be quite happy with 0.7 arc-sec per pixel.

Linux is not good at handling USB. I find that my system goes through bouts of reassigning a different ttyUSBx port number each time a device is plugged in - or even each time it is reset / opened. This is especially annoying when doing Arduino development. I would suggest running the terminal command: ls -lt /dev/ttyUSB* to discover what USB ports your system thinks it has got. Do this every time there is a problem. Or use the following script in a terminal window (resized to small and moved out of the way) to continually monitor the USB serial ports. #!/bin/bash # script to report which Serial USB ports are connected while [ 1 ] ; do clear ls -lt /dev/ttyU* | cut -c33-99 sleep 1 done

+1 for Nomachine. So easy to install and use. No futzing around with configurations, licensing, connections or any of the faff that comes with VNC variants. It just works and it's reliable.

It is much easier to lower a price if there is no interest in an item than it is to raise it if there is too much I have a feeling that the price actually got for a sale is as much about the buyer feeling "safe" that they are getting what they pay for. So an advertisement should be as informative as possible. It is also important to remember that from the buyer's point of view the cost is agreed price PLUS p&p. So sales that are easy to collect (and inspect) in person will get more attention than ones with high shipping costs from a remote location.

websockets

Tried and trusted every time. There are no points for style or perseverance, it is only the results and ease of getting them that count!

Are you missing a strftime() call?

When thinking about the benefits of higher priced gear, it is always worth stopping to consider what other goodies you could spend the cost difference on if you bought the cheaper option. Then weigh up the performance improvement (if any) against the fun, quality, ease or whatever else floats your boat that you would get from the lower-cost item and all the extra stuff

Yesterday I received an IMX335 board camera and a 25mm F/L F=1.2 lens from China. Here's the first try-out of what it can do. This is a single frame grabbed from the 15FPS stream. No processing