Closed theschles closed 3 years ago
Hi there, I assume you've tried it out during the day with a far away object in the pictures above? In any case, it seems from picture 2 that the Astrocam application is correctly installed/showing what the HQ camera sensor is seeing, as otherwise you would get a black/white screen all the time, but as you can see from picture 2, what appears to be dust on the telescope optics or on the sensor is visible, so the camera must be working properly.
Since you can't see anything else though, my guess would be that your focusing is off; DSLRs typically have a longer backfocus due to the mirror adding space between the sensor and the scope, so if you are keeping the same settings from when you tested it with your SL1, try to refocus the scope or move the HQ Camera itself a little further back too, so that it lies at the correct focusing plane. Also, make sure that you are pointing somewhere where objects to focus on are visible, i.e. not at the sky.
Hope that helps and feel free to write back once you have checked the focus and determined that it was or wasn't the issue!
Raw pic taken by the Canon EOS SL1 looking at a tree about 155 ft away (measurement from Google Maps): IMG_6593.CR2.zip
Note, you're looking through the screen covering my open garage door here.
Here's what that setup looked like:
Telescope hasn't moved; now connecting up the RPi:
Odd thing: it's working now; I was able to get it to show me that 155-feet-away tree's branches.
Maybe because it needed an object to be farther away than the hillside by my house?
New question: why is the image flashing? Is it due to some sort of latency on my 802.11ac WiFi? Video: https://imgur.com/a/l4ylE2X
Also FYI when I click the Quit button on the AstroCam window on my ssh -X
connection to the RPi, the app doesn't return me to the command prompt. Instead, it hangs...and when I hit Ctrl-C, i get this:
^CException ignored in: <module 'threading' from '/usr/lib/python3.7/threading.py'>
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 1281, in _shutdown
t.join()
File "/usr/lib/python3.7/threading.py", line 1032, in join
self._wait_for_tstate_lock()
File "/usr/lib/python3.7/threading.py", line 1048, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):
Looks like a focusing problem is what it was then! That can be quite inconsistent due to each telescope having a different optical design, thus also different focus distances and backfocus settings. In any case, since it seems to work now, just make sure that you always pick an object that's as far away as possible each time you set up the Pi's HQ camera, so that it is guaranteed to be at infinity in the focal plane.
Regarding the flicker and the SSH prompt, the first one happens apparently quite often but also at random for other users. It probably isn't your wifi, as it has also been reported by users with a screen directly attached to the Pi. With my Raspberry Pi 4 setup, it doesn't happen on my touchscreen if I switch the camera.capture's use_video_port=True at line 112 in the Astrocam Python script to False, but that also apparently causes performance issues for some people to the point of the preview not working at times, which is why it is set to True as a default. You can try turning it off if the flicker bothers you, although I can't promise it will work on your Raspberry Pi 3.
The reason why this happens probably has to do with the way the SOCs GPU handles the image stream from the camera sensor for the preview, which is also surely why it varies across Raspberry Pi models and software versions, but unfortunately, that's about as much as I've been able to figure out until now looking into it. Since it is still functional and the preview only serves to check what the sensor is seeing prior to capturing a picture/video, it's not too huge of an issue in my opinion, but if it bothers you and you find out something, do feel free to write back with your findings so I can look into it further/maybe even implement a fix for it into the code!
As for the SSH prompt, you are running the Pî completely from an SSH terminal then or on a remote desktop through SSH? Can you maybe send me a screenshot of it hanging after closing it? That does seem like a proper bug and if so, I would like to look into it to see if I can troubleshoot it in the code.
Thanks in advance!
As for the SSH prompt, you are running the Pî completely from an SSH terminal then or on a remote desktop through SSH? Can you maybe send me a screenshot of it hanging after closing it? That does seem like a proper bug and if so, I would like to look into it to see if I can troubleshoot it in the code.
Here's how I connect using iTerm2 on MacOS Catalina:
➜ ~ ssh -X <removed>
<removed>'s password:
Linux telescope-rpi3 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Dec 9 14:14:22 2020 from 192.168.10.45
<removed>:~ $ ./RPi_Cam_Web_Interface/stop.sh
<removed>:~ $ sudo service apache2 stop
<removed>:~ $ python3 AstroCameraApp/PythonScripts/AstroCam.py
Start
And when I click the Quit button in AstroCam, all 3 of the AstroCam dialogs disappear -- and nothing additionally shows up in the terminal...until I click Ctrl-C. That's when this now appends to the terminal:
^CException ignored in: <module 'threading' from '/usr/lib/python3.7/threading.py'>
Traceback (most recent call last):
File "/usr/lib/python3.7/threading.py", line 1281, in _shutdown
t.join()
File "/usr/lib/python3.7/threading.py", line 1032, in join
self._wait_for_tstate_lock()
File "/usr/lib/python3.7/threading.py", line 1048, in _wait_for_tstate_lock
elif lock.acquire(block, timeout):
KeyboardInterrupt
<removed>:~ $
I will also note that one time when I clicked the Capture button in AstroCam the resultant file was just a grey rectangle (as opposed to the view of leaves from the far-off tree that was flickering in and out) ... which leads me to believe that there might be an issue with how you're pulling the data off of camera feed. Is there a way to confirm that the image you've retrieved from the (for lack of a better term) "camera buffer instance" is indeed a valid image capture? Completely speculating here without reviewing your code -- and I am a complete n00b about Python (I write Java, PHP, and Ruby professionally) -- but perhaps you're sampling too frequently?
Thanks for your feedback! I'm also sorry for not writing back earlier, as I was busy with some university stuff and am currently away from my Hubble Pi at the moment, but I will attempt to reproduce the errors you described once I get a chance to. Specially the app hanging in remote desktop after clicking the Quit function button.
Also, regarding your last point about one image coming out grey, I've actually never had this happen myself, do you think you might perhaps have overexposed? Astrocam automatically sets the digital and analog gains (which is essentially the ISO) each time you take a picture, as those can't be controlled manually due to the design of the sensor but need to settle on a high value to capture stars and faint night sky objects correctly. It might have been that or perhaps you moved the scope sligthly during that one capture. I say this because from the software and code side of things, all my program really does is capture a stream of images for the preview until one hits the capture/ ŕecord button, then for the duration of the capture/recording it stops the stream and takes the pictures/video it was tasked to by means of the corresponding Picamera function.
So, other than any bugs with Picamera, I don't think my program should be causing any problems with the camera buffer, although this is also my first program and I am thus still kind of an amateur myself and might have missed something. Has this happened to you repeatedly/have you found a way to consistently reproduce the bug?
No worries about the delay.
I'll try and see if I can reproduce it with some repeatability.
I have similar behavior here. It's a freshly set up Pi4 with HQ Cam following the PDF instructions. raspistill shows image data just fine but when using AstroCam.py I only get black images.
Ok, since the black or grey issue seems resolved, I will close this issue, but do you guys think you could open up one with the issues you just described (if you are still having them) on A) The exception when closing via the Quit button, preferably with a screenshot of when the exception occurs B) The issues you just described above @hdznrrd, it seems something is really not working right with the script on your setup if you are seeing just black on the screen preview, captures and regardless of ISO/Shutter Speed. Maybe astrocam isn't getting any access to your HQ camera module, did you open more than one instance of it maybe or is something else using the camera? We can go more in depth in a separate issue in any case.
Sorry for taking so long to respond lately in any case, as I'm still busy with university stuff and still away from my Hubble Pi, so proper testing will only be possible once I get back home after the situation with the pandemic gets better. :/
Hi there,
sudo apt update && sudo apt full-upgrade -y
Here's how I run AstroCam:
All I see is black when ISO 100:
or grey when ISO 800:
I will note that the lens cap on the big end of the telescope is off -- and that I can look all the way through to the other side. In fact, just to check, I 3D printed a EF-mount to 1.25in adapter for my Canon EOS SL1 and that does indeed see (somewhat clearly) the plants on the hillside a distance away. Replace that EF-mount to 1.25in adapter and get black or grey in AstroCam.
Help?