Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

dan_adi

Members
  • Posts

    328
  • Joined

  • Last visited

Posts posted by dan_adi

  1. On 16/04/2024 at 21:26, bosun21 said:

    I am looking at buying myself a new refractor shortly and I can't decide which way to go. The two contenders are the StellaMira 125 doublet with FCD100 and lanthanum glass and the Askar 140 triplet with one ED element (type not disclosed). I have been reading reports from owners of both and both are said to perform very well for visual. The 140 is bino friendly with a 3.5" R&P focuser as opposed to the 2.5" of the SM 125. It's the question of whether the better glass type of the doublet will be better than the supposed better correction of the triplet with one ED element. This being a considerable purchase for me I want to make the best choice possible. Any thoughts on the matter would be appreciated. Thank you.

    I would go for the triplet. Neither is top of the line, so might as well get better colour correction 

  2. Both are very good mounts. With the 10M mount you could go unguided if you pair it with a refractor. If the mount is in a permanent obsy, you will have to build a model once or twice a year provided that you don't change anything in your setup. Also because 10M  tracks in DEC you don't have to stress about polar alignment either, the model will take care of it. 

    So what scope will you use?

  3. Finally got to finish the master Luminance at 203 hours on the Abell 2218 galaxy cluster. Still undecided if to add colour data, but it would be cool to reach 270-ish hours like the first Hubble Deep Field. Data was gathered over the summer of 2021,2022,2023.

    The best images of the cluster I found on Abin was Mortens and Howards

    The image is on astrobin: Abell cluster

    Thanks for looking!

    • Like 5
  4. 18 hours ago, tomato said:

    This is definitely the last one, thanks for sticking with it.

    Image05cscx2DS.thumb.jpg.4af4373e8ccf93e09267913e5ade33a8.jpg

    Very nicely done 👍

    You can always add more data later, in between other projects.

     

    • Thanks 1
  5. On 16/01/2024 at 01:24, tomato said:

    I do indeed, it will be 10 years old this year. I dip into the Sitech forum regularly, blinky mode on the Sitech II is not unheard of, hence my concern.

    But my immediate hardware problem is with my 3 year old QHY268c camera which appears to have developed a temperature sensor fault…😒

    It's a great mount. Mine is 6 years old I think. Recently got a 10M 2000 HPS because I couldn't help myself :)) I did compare the mean eccentricity between the 10M and the Mesu and the difference is small in favour of 10M, kind of and unguided vs guided comparison. In fairly good seeing and good guiding  the Mesu goes head to head with the top brands for sure and at almost half the price. A good mount!

    • Like 1
  6. On 07/01/2024 at 16:58, tooth_dr said:

    I’ve attached some videos of my mount playing up.

    This is what is does when I unpark it and or start tracking:

    @AKB I swapped the RA and DEc power and encoder cables - the DEC axis continued to exhibit strange behaviour, the RA unaffected:

    I swapped them back again and the issues remain with the DEC axis.

    I tried manually moving the mount with the hand controller, and it’s behaving odd too.  Holding down any DEC button causes the mount to move back and forth.  RA not affected.

    Motors go into blinky mode as seen in the screen shot below.  I’ve loaded the original cfg again that i got from Lucas in 2021 when I bought the mount, but no bueno.

    IMG_8402.thumb.jpeg.9e8cff4ae5cc74efa6f3da61b2b6fa7a.jpeg

    Sometimes it also slews both ways on initiating tracking / unpacking.

    Next step will be to contact Lucas unless anyone thinks it’s the controller?

    Anything else to check?  

    Tony, what is the y shaped cable?  And do you mean the connectors soldered to the board?  I can definitely test all for continuity. 

    Had a similar problem way back. After unparking the mount started skewing on its own with no input from me or other software. The motors went to blinky.

    The problem was a loose wire in the sitech II controller. 

    Never liked the idea of the wires being exposed to the elements but what can you do ...

    Most likely it's a controller problem

    • Like 1
  7. 46 minutes ago, vlaiv said:

    n the end - integrated flux will be some number that will correspond to some magnitude - but that is simply because numerical values for flux are some arbitrary numbers and not true numbers for true star with some defined brightness.

    Quite wright,

    If I take the V band mag from Simbad v = 2.02 and scale the spectra at that amplitude, and then convolve the synthetic filter with the scaled spectra, I get the same mag as the input. 

    sp2 = Spextrum.from_arrays(waves=wave,flux=flux, flux_unit='FLAM').scale_to_magnitude(amplitude=2.02 * u.mag,filter_curve="./filters_ascii/johnson_V.dat")
    sp2.plot(flux_unit='FLAM')

    Plot

    Screenshot2024-01-04at00_06_00.png.3572037728a242f4dff6f9d25f5132d2.png

    Returned magnitude with V filter observation:

    v2= sp2.get_magnitude(filter_curve="./filters_ascii/johnson_V.dat", system_name="Vega")
    
    #output 2.02 mag

    So that means the color index only provides information about temperature, but not brightness. Makes sense distance is a factor in brightness, besides temperature. 

  8. 16 minutes ago, vlaiv said:

    What sort of intensity does this function return?

    Returns this when plotted:

    Screenshot2024-01-03at23_34_16.png.4be33ca90fd50008eae024f4207a230b.png

    But I do understand what you're saying. The b-v colour index I got from Simbad, I thought it encodes the intensity as well.

    Hmm, seems harder than I thought.

    I'm thinking of trying the other way around for fun, simulate the spectrum, then search the V band mag in Simbad, then scale the spectrum to that magnitude, then make a synthetic observation with the V filter and see if I get the same magnitude as Simbad. Scaling to the magnitude would basically underline your idea about brightness

  9. 54 minutes ago, vlaiv said:

    So you have a spectrum of the star and you want to calculate magnitude in particular band?

    You are probably short of a multiplicative constant. You need to calibrate your instrument to be able to get precise magnitudes - and in this case it is multiplicative calibration.

    Determining V band intensity from spectrum is fairly straight forward - you take spectrum and you multiply with V filter response and you integrate the result.

    V band filter response can be given in percent or rather 0-1 range - so it does not influence choice of units. Spectrum on the other hand needs to be scaled to appropriate values in units of interest and if it's not - you need to scale it, to find multiplicative constant for your system.

    To do that - calibrate on a known star. Take a spectrum of star whose magnitude you know - do the same integration to find numerical constant and then apply this constant back in the case of star you are interested in.

    It's really like regular photometry - you need to calibrate your instrument first.

    Hello Vlaiv,

    It is a theoretical exercise in synphot - python

    I make a source spectrum object that takes as argument Temperature [k] like this:

    sp = SourceSpectrum(BlackBodyNorm1D, temperature=bv.bv2T(0.60))

    bv2T is a method in the bv object that returns temperature having b-v colour index as argument.

    I retrieve the wavelength and spectral flux density as arrays (and make unit conversion for flux):

    wave = sp.waveset
    flux = sp(wave).to(u.erg / u.s / u.angstrom/u.cm**2,equivalencies=u.spectral_density(wave))

    then I make the same spectrum but with spextra library because it is easier to work with:

    sp = Spextrum.from_arrays(waves=wave,flux=flux)

    Next I make an observation using the V filter (it convolves the spectra and filter):

    integrated_flux= sp.get_flux(filter_curve="./filters_ascii/johnson_V.dat")
    
    # result is 4.737e-15 erg/s/cm2/A

    Also I get the magnitude easily:

    V = sp.get_magnitude(filter_curve="./filters_ascii/johnson_V.dat", system_name="Vega")
    
    # returns 14.69
    # the mag V in a Simbad search is around 2.2
    

    Given the difference I assumed I am actually computing instrumental mags, and I need a zero point for conversion to calibrated mags.

  10. Hi,

    I used the b-v colour index of Polaris to determine temperature. I fitted a back body spectrum for that temperature. All done using astropy, synphot, spextra libraries in python. Easy, but when I continue a make an observation with a V filter, I get an estimated V mag of 14.69, that is way off. 

    The b-v colour index is 0.6, the temperature is 5967.54 K. The flux through the simulated V filter is 4.737E-15 erg/s/cm2/AA

    It think it has something to do instrumental vs calibrated mags? 

    So basically what is the process to get the mags from an observed spectra? 

  11. This is a work in progress. Just ~40 hours of luminance data of ARP 319 region

    I applied background removal,  BXT, NXT, GHS. Don't know if its too many steps or to few but I like the result. Probably over did it with GHS but I wanted to see how much IFN there is

    ARP319Test.png

    • Like 1
  12. On 07/10/2023 at 17:49, Nigella Bryant said:

    Hi all, what's your take on this? Currently I have a 70mm telescope that I could use as a guide scope. Would there be any benefit to getting and using an off axis guider.  I'd be using an altair astro 26c on a C11 @ f6.3 or a 12inch f4 newtonian on the Eq8. 

    Thanks for looking. 

    OAG for everything.

    • Thanks 1
  13. On 08/10/2023 at 22:02, ollypenrice said:

    I'm terminally old school and would always prefer to ditch all hubs, mini PCs etc., and run a large number of direct USBs into a desktop PC with enough USB ports.

    Olly

    I went even deeper. I kept very short usb cables that connect to a USB->UTP converter. I also placed a small 12V Network Switch on the scope. This way everything is connected via ethernet connections. I don't keep a computer in the observatory or on the scope. One data cable and one power cable needed.

    Through ethernet I never have connection issues.

    For mobile use it's another story, but for an observatory there no need to place computers on telescopes

    • Like 1
  14. On 03/09/2023 at 16:06, Dan_Paris said:

    There's nothing wrong with  oversampling (within reason), as long the level of read noise from the sensor is well below the photon noise from the sky background.

    There is no benefit in binning with CMOS cameras except that it demands less computer resources (storage and CPU) but they are cheap these days. If you want to adapt to seeing conditions rescaling the final processed image gives always better results.

    Regarding the ideal sampling you should first evaluate your seeing conditions, or more accurately what the combination of your seeing conditions and tracking accuracy allows you.

    My current setup (200/750 newt with ASI183mm) gives me 0.67"/pix which is a perfect match for my seeing condtions. Indeed the average of the FWHM values that I got on my luminance stacks this year (24 imaging sessions) is 2", i.e. three times the sampling (ranging from 1.46" to 2.6"). On those nights with good seeing my best subs are around 1.3" so  I could sometimes benefit from a tighter sampling like 0.55".

    My previous camera was an ASI1600mm which gave me 1"/pix. It gave me clearly inferior results, resolution-wise.

    Instead of  an 8" EdgeHD, you could consider a 200/1000 Newtonian with a Paracorr (effective focal length 1150mm), which gives an ideal sampling for 2" seeing. In those conditions it would give a larger FOV than the EdgeHD, without sacrificing resolution.

    Well, oversampling will unnecessary increase the exposure time and will lower the systems entendue. Depending on how many clear nights you have this could be a problem or not. From the point of view of a telescopes entendue if I compare my 8 inch refractor operating at 0.93 "/pixel to a C11 SCT operating at 0.42 "/pixel, the refractor is 3.57x better. If the C11 would be operating at bin x2, 0.84"/pixel, then the SCT would be 1.1x better than the 8 inch frac. If I wanted to keep the resolution for the C11 at 0.42"/pixel and have a bigger entendue than the frac, then I would need an SCT with roughly 400 mm mirror ... 

    If you are aiming for resolution, those small pixels need to be coupled with a big mirror in order to compensate for the loss of flux at pixel level. 

    And to make matters worse, the lower the plate scale the better the mount you'll need, because at 0.42"/pixel any guiding error bigger than that will increase your FWHM, and defeat your original purpose of high resolution imaging.

    For my setup If I where to image at 0.42"/pixels I would need a mount capable at sustaining <= 0.2" guiding RMS, that means 10M, ASA, Planewave $$$ :)

  15. On 01/09/2023 at 22:08, OK Apricot said:

    I'm trying to wrap my head around this oversampling thing. I really want to get an ASI2600MCP for that lovely large FOV and pair it with my 61EDPH. I'm undersampled here but I kind of get that - my images are a bit soft. At the same time I'd love to get an 8" EdgeHD for galaxy season to really start to get in closer.

    I believe this is going to end up oversampled at 0.55"/px, but what's the deal here? Guiding on my EQ6-R is rarely  above that on the worst nights, so tracking errors shouldn't be an issue. Seeing? What about my sub frames - what will they look like? What's inherently bad about oversampling? 

    Oversampling means small pixels, and, depending on FL, small plate-scale.

    The only issue with oversampling is that light is spread over many pixels, and this will lower the signal/pixel. This translates into more imaging time for the same desired SNR compared to an optimal sampling. This is important because you are unnecessarily increasing exposure time.

    As an example for my setup, a chosen target with 23 surface mag (M33), a camera with 6 um pixels, plate scale 0.93, and a desired SNR of 40:

    • total exposure time: 22 hours for Luminance, 97 hours B, 86 hours V, 80 hours R

    Same setup but sensor with 3.76 um pixels and a plate scale of 0.58:

    • total exposure time: 36 hours for Luminance, 134 hours B, 133 hours V, 120 hours R

    So you see, simply changing the pixel size has a considerable impact of exposure time

    • Thanks 1
  16. On 01/01/2023 at 23:22, Lead_weight said:

    Hi All, I don't know how many across the pond consider AP mounts, but having recently purchased one to pair up with my 10Micron mount, I started getting asked what my thoughts were on the two.

    Suffice to say, they are both really good options, but if you were curious how they stack up from a service, hardware, and software standpoint, I put my thoughts down in a blog post.

    I tried to be fairly objective, so please let me know what you think.

    An honest impression ... and perhaps a little bad luck? The main thing is, many people praise this or that company but as in your case, everyone can screw things up a little. Nobody has 100% track record, neither 10M, or AP, or etc.

    I don't have any of these mounts, but I am curious about the absolute encoder tech on these mounts. Currently I use a Mesu 200, that is 5 years old, and although it took me some time to learn the controller software, I can always happily guide at 0.2-0.3" RMS, and never had a mechanical problem. As an opposite  example, there is a fellow mostly active on CN, that had a bad time with a Mesu, and always discourages others into buying the mount. I find it very awkward because most of Mesu users didn't have his problems, and we are happy with our mounts. 

    From what info I've gathered mostly in private messaging with owners of 10M mounts, most of them, especially above 1000 mm focal length or using an SCT, do guide these mounts. 

    To my surprise I even found fellow astronomers on the ASA forum that get better results with guiding.

    So I always wondered what is the point of paying for the encoders if, in the end, the best results are achieved by superimposing guiding corrections. Off course the guiding corrections are fewer, but still ... 

    If the main reason for purchase is quality craftsmanship then I fully understand, but most seem to be hypnotised by this unguided nirvana. This could be the reason why AP offers the mach 2 with encoders, the masses seek unguided imaging.

    From time to time, I am highly temped to replace my Mesu with a 10M 2000 HPS, but if I am getting the same 0.2-0.3"RMS unguided, it will have no impact on my images, worse still, if I have to guide for the same RMS, then I've paid 15K euros for the performance of my current 6K mount.

    Sorry for the long rambling ...

    • Like 1
  17. 22 hours ago, Stuart1971 said:

    You are not on your own, I think the Mk 2 Mesu, has a pretty poor system for polar alignment, compared to the original, and to other mounts of similar quality, it seems a real shame and IMHO a backwards step.

    Have you looked at the JTW Trident friction drive mounts, these are very well priced 75kg payload, and the same PA adjustments as the original mesu…seem to be getting quite popular with more models on the way…

    https://www.jtwastronomy.com/products/p75-trident-direct-friction-drive-telescope-mount

    also much more user info here

    https://groups.io/g/jtw-astronomy-users/topics

    They look like a cool Mesu :). Good to see more adoption of the friction drive. I also like they made a protective case for the motors, I'm always afraid I'll accidentally hit the motors on the mesu.

    Looking at the guiding graphs the performance is equal to the Mesu, that's great.

    Also I've noticed they recommend lower aggression and longer pause between guiding exposures, and this is what I also noticed with the mesu. Things settle down quite nice if I use 8 sec exposures and a couple of seconds delay

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.