pete_l

#!/usr/bin/python3 from __future__ import print_function import sys import picamera from picamera import mmal, mmalobj, exc from picamera.mmalobj import to_rational import time from fractions import Fraction import datetime as dt MMAL_PARAMETER_ANALOG_GAIN = mmal.MMAL_PARAMETER_GROUP_CAMERA + 0x59 MMAL_PARAMETER_DIGITAL_GAIN = mmal.MMAL_PARAMETER_GROUP_CAMERA + 0x5A def set_gain(camera, gain, value): """Set the analog gain of a PiCamera. camera: the picamera.PiCamera() instance you are configuring gain: either MMAL_PARAMETER_ANALOG_GAIN or MMAL_PARAMETER_DIGITAL_GAIN value: a numeric value that can be converted to a rational number. """ if gain not in [MMAL_PARAMETER_ANALOG_GAIN, MMAL_PARAMETER_DIGITAL_GAIN]: raise ValueError("The gain parameter was not valid") ret = mmal.mmal_port_parameter_set_rational(cam._camera.control._port, gain, to_rational(value)) if ret == 4: raise exc.PiCameraMMALError(ret, "Are you running the latest version of the userland libraries? Gain setting was introduced in late 2017.") elif ret != 0: raise exc.PiCameraMMALError(ret) def set_analog_gain(camera, value): """Set the gain of a PiCamera object to a given value.""" set_gain(camera, MMAL_PARAMETER_ANALOG_GAIN, value) def set_digital_gain(camera, value): """Set the digital gain of a PiCamera object to a given value.""" set_gain(camera, MMAL_PARAMETER_DIGITAL_GAIN, value) ####################### settable values here ####################################### started = dt.datetime.now() # current date and time date_time = started.strftime("%d%b%Y_%H%M%S") print("Started at:",date_time) endtime = dt.time( 7,0,0 ) # end imaging at 7 a.m. lasttime = dt.datetime.now().time() # gains settings of (12,4) produce an ISO of 2500 in the exif data # analog gain, values over 12.0 get set to 12 a_gain = 12 # digital gain, use values of 4 or less, 2 is best for me d_gain = 2 exposure_us = 10100000 # just over 10 seconds (max) def fnames(): global lasttime frame_num = 0 while True: ts = dt.datetime.now() timestamp = "%04d_%s" % (frame_num,ts.strftime("%d%b%Y_%H%M%S")) # t = '%s_%04d' % (timestamp, count) thistime = dt.datetime.now().time() if lasttime < endtime and thistime >= endtime: print("Ending at {} after {} images".format(ts.strftime("%d-%b-%Y %H:%M:%S"), frame_num)) break lasttime = thistime yield "long2_%s.png" % timestamp frame_num += 1 ####### main code starts here ################## if __name__ == "__main__": # with picamera.PiCamera(sensor_mode=4, resolution=(1640,1232),framerate = Fraction(1,10)) as cam: with picamera.PiCamera(sensor_mode=3, resolution=(2592,1952),framerate = Fraction(1,11)) as cam: cam.color_effects = (128,128) # monochrome / greyscale cam.exposure_mode = 'night' cam.drc_strength = 'low' cam.shutter_speed = exposure_us set_analog_gain(cam, a_gain) set_digital_gain(cam, d_gain) # it is said that values > 4 saturate the image (?) # use stdout here to get output immediately sys.stdout.write("Waiting for gain to be set (Ctrl-C to stop) ") sys.stdout.flush() try: while cam.digital_gain < d_gain: sys.stdout.write(".") sys.stdout.flush() time.sleep(2) except KeyboardInterrupt: print("Stopping...") # fix the auto white balance gains at their current values g = cam.awb_gains cam.awb_mode = "off" cam.awb_gains = g print("\nAWB gain: ", g) # fix the analog and digital gains so they won't change during the shots cam.exposure_mode = 'off' print("Set a/d gains: {}, {}".format(cam.analog_gain, cam.digital_gain)) print("Starting sequence until ...".format(endtime)) s1 = time.time() # without burst = True, 30 frames takes 661 seconds, with it 318s cam.capture_sequence(fnames(), use_video_port=False, burst=True, format='png') # cam.capture_sequence(fnames(), use_video_port=False, burst=True) s2 = time.time() print("Finished in {:.3f}s".format(s2-s1)) exit long_shot.py Run from the terminal as ./long_shot.py This takes back-to-back 10s exposures with almost no gap in between. The exposures are lossless and about 5.2MB each. Cancel either with Ctrl-C or it ends automatically at 7:00 a.m. The first image takes up to a minute due to some silliness inside the Pi camera (I'm sure my phone doesn't wait a minute before taking a photo and the IMX219 is a phone camera ;( ) I have tried using the full resolution of the v2 camera (3280x2464) but the software falls over with an out of memory error. Although the raspistill software manages it with ease. This seems to me to be a crock in the picamera module. Almost none of this is my original work. I am no expert in Python so will not be able to answer any difficult questions.

If you're up for a little experimentation I can send you the python code I use to handle my v2 camera on a pi-zero. This is an example of the sort of image it produces. It doesn't look great here, but the uncompressed image gets down to about Mag 6. The bloom at the top left is due to the Moon (north is to the top). Though I am not too happy about all the other edges.

Yes. When I started in 1999 I was under the false impression that in the UK the night sky was mostly clear on most nights. Since people only write observing reports after good nights there was almost no information on the frequency of bad nights. This seems to be the opposite of equipment reports: where people generally only publish complaints, and only rarely (if ever) praise. So we have the situation where newcomers will think there are a lot of observing opportunities - but that most of the equipment is junk. Whereas in reality in both cases the opposite is true!

You could add a Barlow, however they are often said to reduce image quality. You could also try eyepiece projection with a suitable adapter. But since you already have the Mak, I'd say just give it a try. See whether the images please you and which targets are suitable.

If purchased wisely that would get you a mortgage on a not too bad house in the area near Pixelskies. Though that then becomes a long-term investment and requires some presence (if only to set up your robotic rig). Plus you have the issue of security. Would you be happy leaving 20k of kit unattended?

The electronics inside the mount will contain its own regulators to supply the 5 Volts or 3.3 Volts (or whatever low voltage the internals work at) that it needs. The only components that will "see" the input voltage will be the motors. As such any switching noise on the input should be pretty harmless - as long as you are using a supply that is designed to power equipment, rather than simply charge a battery. Having said that it is my personal belief that many, many "unexplained" faults with mounts are due to dodgy power supplies. Either ones that drop below their lower limit due to instantaneous high demands (such as when the motors first spin up) or power supplies that do strange things with their electrical Earth - common connections. And those problems that aren't electrical, are more than likely to be from mechanically unsound connectors.

Many people consider this part of Andalucia to be a desert, now. In general we get something over 200 clear days a year, 230-250 being the norm. (Although the last few days have been cloudy, it even rained today!) Though when you factor in the Moonlit nights, the number of observing opportunities drops considerably. (cue cries of sympathy .... ) When I lived in the S.E. UK I used to average about 17 observing sessions a year. Due to weather, work, family and social events. I expect that skiers in Abu Dhabi have it even worse than astronomers in the UK

When drawing how many Amps? If you just measure the voltage at the remote end without a load in place, the reading will not be any different than at the supply. You need to know what the maximum instantaneous current will be when all your kit is connected. Then ascertain what the supply voltage is at that instant. IME very many mysterious problems that people experience with their astronomy kit is due to dodgy power from supplies that drop to below the minimum required. Even if that drop is only for a few milliseconds, for example when the motors on the mount both start up and both take a switch-on surge current. That's the real test!

I would place just as much emphasis on the vendor as the brand, since most products are available from many sellers. I have a refractor made by Skywatcher, an SCT from Celestron, an ETX125 from Meade and a GSO rebadged dob from TS.

I do wonder what equipment all these youtubers (not just the astronomy ones) would own if they had paid for it with their own money. Ultimately those are the only reviews / promotions I consider valid..

One thing to remember is that the 300 dpi "rule" is from the days of glossy magazines. And really only applied to those sorts of people who listen to HiFi's in order to try and discern the hiss, crackles, pops and other faults. Consider the resolution of your monitor. Even a large one (70cm across, not diagonal) gives a perfectly acceptable resolution at 1920 pixels per line. That is 70 DPI. The reason is that the larger a screen is or the larger a print, the further away a person views it from. I get poster size photos printed at 100 DPI and they come out as good as I would ever wish for. It may well be that if a person scrutinised one from right up close, they might see a little pixelation, but nobody ever does

Probably because the Pi4 requires a heatsink. That large chunk of metal can reduce the WiFi signal, depending on the type of heatsink used. For reasons of quietness and reliability I prefer passive heatsinks - no fans. However ones that completely cover the Pi4 board, like this one that cover both the top and the bottom make the onboard WiFi unusable. I have 3 Pi4's. One with a fan assisted stick-on heatsink in a plastic case and two with this sort of passive radiator. The plastic cased one makes too much noise. It was fine when new, but after a few weeks became noisy. The other two are great (apart from having no external points to fix the Pi4 to anything) but in effect have no WiFi. I would imagine the same applies to the onboard BlueTooth, although I have no use for that.

You will find that any of those mounts you listed will carry a 12.7kg payload such as an Edge-11, and they will all give you a similar experience for tracking, guiding, pointing accuracy. I understand you are concerned about reliability. Though personally I do not think that one bad experience should rule-out half the world's telescope mounts. On the internet, everyone publicises the problems they have and repeats third-hand stories no matter how old they are. But nobody ever posts to say that their equipment simply works as it should. So if you believed even a small amount of the stuff that is posted, you'd never buy anything. However, what I would say is that much of your bad experience would be due to the company you bought from, as much as the manufacturer. So as well as considering what mount to buy, an equally important point would be the reputation of the seller. Using that principle myself, there is one brand you have mentioned that gave me a terrible time. Simply because once the dealer had my money they simply weren't interested in providing assistance. But that was in England and it was long ago! The other aspects I would give consideration to would be how any of those mounts will integrate with your other equipment? Can you use the mount control software you prefer? Is there an active user community? Are you tied in to buying expensive accessories from just a single source with a limited range?

Since you already own the equipment you lose nothing by trying it out and relying on your own judgement as to whether it gives pleasing images. So at this time, I'd give it try.

Look at the images you have taken. Critically assess them and think about which aspects could be made better. Choose a new scope that fixes those shortcomings.

Yes. If you want to balance the mount then the centre of gravity should be along the axis of the mount. Traditionally the finder is offset in order to make it easier to look through. However if I was using the finder as a guide scope then I would put it directly above the mounting plate. You could always add another "shoe" if you will later require a guider or red-dot finder for visual use.

I use my ED80 with the 0.85 reducer corrector and an 1100D DSLR. So the reduced image size is 22x15mm. That gives a diagonal of 26.7mm. So the unreduced, image circle is at least 31.4mm HTH

I am aware of that. Just trying to get a handle on how much extra work and money is needed. Presumably a user also needs to obtain the correct adapter between mount and tripod/pier? Neither of these mounts appears to be "oven ready"

So to turn this into a usable piece of kit, the owner has to provide a tripod/pier, counterweights and a controller. Is that correct? What about a power supply. I see no mention of that on the product website. Does it come with the mount or is it an extra?

It appeared on CN a week ago with some test images. A couple of Italian sellers have it on pre-order, but with no price shown. They reckon available in October.

If you create a vacuum, would you have problems with heat dissipation? No air means no heat loss through convection.

And CO2 molecules are much larger that Helium ones, so the (inevitable) rate of leakage will be much lower. The gas in toy Helium balloons is a mixture of He and air. There will be no guarantee that it will be dry. I.e, no water vapour in it. Does that apply to those CO2 cannisters as well? Acetone is quite hygroscopic. A few drops of that somewhere strategic might get the water out of any gas you use.

Even then it doesn't replace the coatings that were destroyed by the fungus, so it's arguable whether the end result is any better.

Either completely remove and reinstall whatever drivers there are or remove and reinstall Sharpcap. Or both!

On the Arduino an int type takes 2 bytes of memory. There will be other variables adjacent to it with their own data values. When you try to store a 4-byte value in the space allocated for an int, the other 2 bytes will overwrite data in the 2 bytes either above or below that int. This is bad when done in global memory space. When done to local variables within a routine it can have even weirder effects. Especially if that ul data corrupts the routine's return address, which is also held on the same stack.