Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.



  • Content Count

  • Joined

  • Last visited

Community Reputation

129 Excellent

About festoon

  • Rank
    Star Forming

Profile Information

  • Location
    Cambridge, UK
  1. No reason why this would not work. My only worry is they do not spec what the max current output at 12V is. Personally I use these https://www.firstlightoptics.com/batteries-powerpacks/tracer-12v-24ah-lifepo4-battery-pack.html They have never given me any issues after a few years of using and last forever between charges
  2. festoon


    Images taken with my portable EAA kit - C5 on a AZ GTi, with an intel compute stick PC
  3. Just spent ages this morning with a similar problem. Registax only wants to stack one image. Went to use Autostakker and this worked only if I used Image Stabilisation - Surface option. I then loaded the file into registax to do the final wavelet and de-noise processing
  4. Thank @vlaiv - your a top man!!!! And you've picked out the one bit of coding that I was unsure about As @Martin Meredith points out the term below comes from the reference from Raab. --> we receive about 4E10 photons per second per square meter from a star of 0mag [3]. A difference of 1mag corresponds to a factor of 2.5 in the brightness. photons_sec_m2 = 4 * (10 ** 10) / (2.5 ** mag_target) In the cases shown here I take the object to be a star --> but I also put into code (currently commented out) a line if the object is a extended object. For the sky brightness, am referencing the sharpcap tools page and I used the equation as he does to work out sky brightness to ensure agreement (from http://tools.sharpcap.co.uk/). Also thank you for your suggestions, I'll start to incorporate them
  5. Hello all, Inspired by what Robin has done with Sharpcap and the python coding that @Martin Meredith posted last week considering peak SNR for different mono cameras - I've been working on a python code that determines the exposure time for an allowed pre-determined increase in total noise, compared to the situation if only one long sub was taken. The program has camera constants such as QE, pixel size, dark current, and bandwifth of pixel (colour or mono). Telescope constants of aperture, central obstruction, and F ratio. Sky constant being sky brightness, the object you are trying to detect magnitude and FWHM. Also input is the total exposure time and allowed increase in noise for stack compared to a single long exposure. Fell free to take a look at the code and delve into tthe details. the results track well what Robin published in his recent presentation (albeit this does not take into account dark current or object noise) https://onedrive.live.com/view.aspx?resid=8C8FC1CCC662B920!15845&ithint=file%2cpptx&authkey=!AFJ0lTBqEagivdI For my setup, it shows quite nicely that for my ASI385MC CMOS with low read noise I can use low exposures (~6 seconds for a 5% increase in total noise), and for my Atik 414 this minumum time increases to 24 seconds for the same % increase in noise. However the Atik can detect fainter objects after the stack of stars at magnitude 20.69 compared to 20.36 for the CMOS. Criticism will be welcomed - I hope this is (or eventually becomes) a useful script optexposure.py
  6. If the read noise of stack scales as sqrt(n)*read noise, I get - which indeed agrees with the statement above As I say, I don't know if one is right (and which one is right). I am using the calculations for a different purpose - namely to optimise (determine the minimum) exposure for an acceptable increase in noise for a stack.
  7. Hi @Martin Meredith...just been looking at the code again. There is one discrepancy between the code, and what Robin has published when discussing optimum exposure times for imaging In the python code you have the read noise of the stack as noise_read = n_subs * read_noise If we look here (taken from https://forums.sharpcap.co.uk/viewtopic.php?t=456) The contribution of the read noise is noise_read= sqrt(n_subs) * read noise I'm not saying one is right and one is not. I'm not sure. What do you think?
  8. Hi @NickK - very sorry but I'm not following this...could be its just over my head technically Is it possible to please explain what you mean? I don't think I'm using the GPU on the compute stick as I am remote desktoping to it
  9. Just read the instructions to this and it looks a very exciting development I look forward to trying it in the future. Unfortunately for now all my cameras are OSC....so I won't have the ability to use it right now. But well done on producing innovation to this field of astronomy
  10. thanks @Martin Meredith that makes sense. I'm now getting numbers as you do. I understand its not exactly important, but just for my understanding....For the obstruction - you have input 0.02 - does that correspond to 20mm? Would the f/4 quattro not be 68mm (or 0.068m)?
  11. Hi @Martin Meredith Thank you so much for posting the python code. I wonder am I doing something wrong. Below are a couple of screen shots and I am trying to recreate your lodetar result for "what SNR will I reach when looking for a mag 20 target using my 8" f/4 scope in mag18 skies with FWHM = 3" seeing using 10 x 30s subs" I've probably inputted something incorrectly!!!! But I cannot see what it is From your data I'd expect to see an output of 3.6432
  12. The R2 was my first camera I bought for EAA and really got me hooked. I started to see so many deep sky objects that I only would have dreamed of seeing from my back garden. Its uses a very sensitive IMX811 sony CCD sensor. Can do colour or mono. Can be used with sharpcap live stacking if you use the USB video capture card. Only down size is FOV limited by 1/3 chip sensor size Here is a section of objects that I've imaged using this camera. They are not hubble..this is real time, no processing apart from stacking. It's worth noting these are taken with a C5 OTA from an urban backyard with sub 5 mins total stacking time. Crab Nebula M81 and M82 Dumbell Nebula M2 M92 Andromeda Bodes galaxy Cigar galaxy Needle Galaxy Pinwheel galaxy Orion nebula
  13. I have my atik 414ex working with Sharpcap using the ASCOM driver (downloaded as part of the core software https://www.atik-cameras.com/downloads/) Gives me control of exposure and temperature set point
  14. I think the M3 processor is a big improvement on the previous stick using the Atom processor. It honestly feels as quick as my i5 laptop
  15. Just wanted to report back, that I got my M3 compute stick a few weeks ago. The first thing I did was do the required windows updates - then I upgraded to Windows 10 Pro to allow me to use RDP. I have also inserted a 256GB microSD memory card as additional memory, and a neat USB3.0 hub to give me a few more USB ports. It happily runs synscan mobile via a serial com port from USB to the AZ GTi mount. Stellarium, Sharpcap, Stellarium Scope all installed fine. Astrotortilla installed fine also. Also I've moved my wifi router to be on the 5GHz band to avoid any interference with my USB 3.0 CMOS camera. Also followed the suggestion of @noah4x4 and disabled remoteFX compression. First and second light were very successful over the weekend. To power the device outside I used a USB type c cigarrete adaptor capable of supplying 5V, 3A - connected to a 12V lithium polymer tracer battery. I'm using the same battery to power my AZGti mount. I also bought a USB type C inline voltmeter/ammeter. Under no load this supplied 5V. When under stress (>2A) the lowest reported voltage was ~4.8V but the compute stick kept going. Comparatively, even with the as-supplied power supply plug (using the same voltmeter and >2A current) was reading 4.9V. The spec of the supplied power is 5.2V 2.2A DC. So a small difference using a 5V cigarette adaptor would be expected. The only time I saw an issue was attaching the USB hub to the compute stick caused the compute stick to freeze. However I saw no more issues after reboot. Just taking the USB of the camera in and out caused no problems, and this only occured when attaching the hub. So I guess there may be a lack of stability at the moment of connecting multiple USB devices at the same time but no problems if the setup remains unchanged. The compute stick ran for several hours, and my RDP connection indoor was fantastic (as long as I placed my router just outside my back door). Was happily running stellaium, and sharpcap acquiring raw16 bit frames. Platesolving (via sharpcap interface) only took a few seconds. Stacking in sharpcap was not an issue. In summary, very happy with the outcome. I might try a wifi usb high gain antenna with the compute stick to see if I can keep my wifi router indoors. I also may and try use a programmable buck converter to match the as supplied power supply - so convert my 12V DC to 5.2V. However I have understood from Intel forums that the compute stick is very sensitive to over voltage. So as long as I see no issues, I will continue with the cigarette adaptor setup I have now.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.