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.

sgl_imaging_challenge_banner_android_vs_ios_winners.thumb.jpg.803608cf7eedd5cfb31eedc3e3f357e9.jpg

han59

Members
  • Content Count

    205
  • Joined

  • Last visited

Community Reputation

136 Excellent

About han59

  • Rank
    Star Forming

Profile Information

  • Gender
    Not Telling
  • Location
    Netherlands
  1. From Pi 3 to Pi 4, the lost time between exposures is reduced with little more then a factor 2: https://www.indilib.org/forum/ccds-dslrs/5416-raspberry-pi-4-vs-pi-3-performance-test/41015.html
  2. Installing INDI is cumbersome on the Pi4. For those who are interested, I have prepared an Pi 4, Raspbian Buster image for a 32 gbyte memory card: https://drive.google.com/open?id=1c15nmRsHeIMaFBQ6NXHEfRpuXNhltnwU A 4.1 byte rar archive, Unrar it with Winrar, 7zip or unrar Use win32diskimager to write the *.img to your 32 gbyte memory card If you get error 5, first format the card with SD formatter. Installed software: INDI 1.8.1 CCDCiel + ASTAP solver PHD2 HNSKY planetarium program XRDP for remote desktop control from a window PC If you want to install it all yourself: Installation instructions:
  3. The down sampling factor 2 helps to combine the red, green, pixels (bayer matrix) of the OSC/DSLR raw format. That helps with star shape and therefore the star detection. Reducing the number of stars you better do with the solver parameters then higher sampling factors. If you get solving in 4-6 seconds there is not much to improve.
  4. Before buying a new one PC, consider that In some cases there are too many (solver) indexes installed. This by specifying a too small field during installation. This will slow down solving signficantly. Normally indexes up to 20 % or 30% of your field size have to be installed. Consider that also when installing on a faster PC. As said before an other primary solver PlateSolve2 or ASTAP could solve your images on the old PC as fast as ASPS (Astrometry.net) on a new PC. My old PC from 2009 solves images in a few seconds (not with ASPS)
  5. With respect to the solving problems: For setting astrometry options, there are only two screens (camera and astrometry) to configure in the menu edit, preferences. See screen shots. Loading the nightly produced FITS file in a viewer will tell you if the sensor pixel size and focal-length are set correctly by the reported FOV. Both PlateSolve2 or ASTAP will do that for you. CCDciel will write this data in the FITS header. Personally, I prefer to set these settings independently of the driver. Focal length is expressed in mm and pixel size in micrometer. If it all fails, you could try ASTAP as solver. For DSLR camera set downsampling to 2 en search area to something like 30 degrees rather then the default 5 degrees..
  6. NGC6914 is a small bluish reflection nebula of 3 to 5 arc-minutes size and not visible on this H-alpha image. Here an annotated image taken from Wikipedia. (North at 02:00 hours:
  7. The image below contains the small nebula NGC6114 in the middle and a very nice (unidentified) dark cloud. It was created from exposures taken during three clear nights in august 2019 and one night in 2018. The large annotation in the top is LBN80.79+3.15/ LBN292 classified as a bright nebula. Astrometric (plate) solving makes it possible to image the same area during several clear nights. No other software was used then indicated. Maybe the documented size of NGC6914 is wrong. Something to investigate. Han Telescope 100 mm APO astrograph APO100Q, F5,8 ASI1600MM-Cool Camera Filter H-alpha 7 nm 133x200 sec on 2019 & 2018 (four nights) CCDciel en ASTAP stacking & plate solve program link to full resolution image
  8. I don't use SGP except for some testing, but any other gain then unity gain =139 will reduce the ASI1600 dynamic range and give virtual no improvement in noise values. For proper stacking, you have to use the same gain for darks, flats and bias images so I always stick to unity gain. I can't help you with the offset setting. In my humble opinion these settings should be only adjustable in the ascom driver or not adjustable at all.
  9. You can run the Pi 4 remotely with 4k desktop using XRDP but I don't understand the word video in this context. Remote desktop works fine and probably better then VNC. It creates a new session so local screen is different then the remote session. VNC just copies the local screen.
  10. Transport & saving of images while the next exposure is running will solve all delays except the transport time from camera to Raspberry Pi. Patrick has already created the code for an experimental CCDCiel version which does multitasking. So starting the next exposure and saving the previous image goes in parallel. First test indicates the lost time between exposures will be half or less. Note the above test results where for local ram-disk option. Transport via INDI localhost where 10% or 15% slower.
  11. I did some experimenting. CCDCiel has a temporary and capture folder. Created a ram disk and set the path's to the ram disk. No performance improvement. Dropped the question to Patrick, here.
  12. The speed difference of the USB3.0 is significant. I assume you could also gain with a better memory card but the 2.5 seconds are fine for me. The RAMDISK could be interesting. This a technology used in the past. But CCDCiel has already the image in memory, if it could start a new thread and save the image in parallel while starting the new exposure this saving doesn't count anymore. Maybe it is already done. I could redo the test with only viewing the image and see how much time that takes. If it is shorter, that means time can be saved by starting a new separate thread. If so we could ask the CCDCiel author Patrick Chevally to implement a new thread for saving the image. But in any case these "lost times" are already pretty good. Han
  13. Maybe of interest, a practical performance test between the Raspberry Pi 3 and Pi 4 Both system where running Raspbian Buster. The camera an ASI1600-MM Cool was connected using an USB 3.0 cable. The imaging program was CCDCiel and ASTAP was installed as the solver as described here. PHD2 was installed for guiding but not used in this test. The results show that the Pi 4 is in average twice as fast as the Pi 3. A lot of time is lost by downloading and saving the image. A class 10 memory card was installed. The time lost is the time between the exposures for downloading the image via USB and saving it to the memory card. So in the Pi 4 if you operate the ASI1600 camera in bin 2x2 mode there is 2.5 seconds lost between the exposures. That's pretty good for deep sky imaging. The solving time is the time required for plate solving the image. Han
  14. Good you managed to install Ekos & Kstars . This means you store the images locally on the RPi4. Are the image download and disk storage speed as fast as expected? I had already planned to buy a passive heatsink with a plastic case.Your experience is worrying. I'm not familiar with Kstars, but I remember it was CPU hungry. I assume CCDCiel&PHD2&ASTAP will be less CPU intensive but time will tell. Han
  15. I have updated the instruction for installing the latest INDI drivers. Installing INDIstarter.deb using the file explorer popup menu installs INDI v1.7.5 over version 1.7.9 wrecking the INDI driver installation. See INDI forum
×
×
  • Create New...

Important Information

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