Get Connected!
Come and join our community. Expand your network and get to know new people!
Hi Wolfgang. I need some more time to come to a conclusion on re-using guiding calibration. I tried several short image runs on different targets approaching the meridian and yes guiding did not recalibrate however this didn't entirely fix the problem. The drift graphics on the guiding TAB indicate it takes a minute or two to get the drift back to pre flip low levels but there is no time delay and the next capture after flip shows drift in the image but subsequent images are OK.
To add complications I am trying to work out why focussing on filter change and post flip doesn't always happen. Same with alignment not happening after flip. I think it depends if or how I have aligned and auto focussed before starting the sequence queue. If auto focus and alignment happens after the flip then it seems guiding has had time to settle down before capturing the next image. Weird because guiding is suspended during these operations.
Will test further.
Read More...
How do I change the password used in the browser client to connect to the astroberry desktop? Do I change the VNC password on the astroberry server?
Thanks
Read More...
I will try the last version. May be next week, or next one.
I will comeback here to tell you if the problem is ok, or not.
Read More...
OK. I hope to test tonight with re-use calibration enabled to see if this circumvents this problem.
Is a state machine approach appropriate for EKOS jobs? Maybe this is how it is coded already? I am thinking it would be easier to understand with a state diagram what we expect to happen on a meridian flip and indeed at other times during an imaging run.
Read More...
I rebuild indi and redid setup and now camera does connect but after a few images it stops:
Aug 13 12:55:41 allsky [INFO] MainProcess allsky.run() #741: Total time since last exposure 15.0057 s
Aug 13 12:55:45 allsky [INFO] MainProcess indi.newMessage() #218: new Message 2022-08-13T18:55:45: [ERROR] Exposure failed after 3 attempts.
Aug 13 12:55:49 allsky [INFO] MainProcess allsky.run() #607: Camera last ready: 22.3s
Aug 13 12:55:49 allsky [INFO] MainProcess allsky.run() #608: Exposure state: ALERT
Aug 13 12:55:49 allsky [INFO] MainProcess allsky.detectNight() #853: Sun altitude: 68:37:59.4
Aug 13 12:55:49 allsky [INFO] MainProcess allsky.detectMoonMode() #870: Moon altitide: -54:51:10.5, phase 95.7%
Aug 13 12:55:49 allsky [INFO] MainProcess indi.getCcdTemperature() #422: Sensor temperature: 46.6
Aug 13 12:55:49 allsky [INFO] MainProcess allsky._queueManualTasks() #1441: Checking for manually submitted tasks
Aug 13 12:55:59 allsky [INFO] MainProcess allsky.run() #607: Camera last ready: 32.3s
Aug 13 12:55:59 allsky [INFO] MainProcess allsky.run() #608: Exposure state: ALERT
Aug 13 12:55:59 allsky [INFO] MainProcess allsky.detectNight() #853: Sun altitude: 68:38:17.1
Aug 13 12:55:59 allsky [INFO] MainProcess allsky.detectMoonMode() #870: Moon altitide: -54:52:39.1, phase 95.7%
Aug 13 12:55:59 allsky [INFO] MainProcess indi.getCcdTemperature() #422: Sensor temperature: 46.6
Aug 13 12:55:59 allsky [INFO] MainProcess allsky._queueManualTasks() #1441: Checking for manually submitted tasks
Aug 13 12:56:09 allsky [INFO] MainProcess allsky.run() #607: Camera last ready: 42.3s
Read More...
The other night with my CEM40 PHD2 surprised me by recalibrating after the scheduler slewed to the target, soon after calibrating near the equator (+22°, which is as close as I could get without running into a tree). This was with the stable build.
I was using my new mini-pc install for the first time, so I cannot be certain I did not miss some relevant setting, though I am pretty sure I had "reuse calibration" set correctly. The mount does report its position to PHD2, because I can see the coordinates recorded in the PHD2 log as each calibration starts. Can you look at your PHD2 log to see if yours actually knows where the mount is, also? There is nothing in the PHD2 log to explain why it recalibrated, but I won't be able to investigate further until the skies clear again - so maybe October...
Unfortunately, I do not have the corresponding KStars logs. One setting I overlooked while setting up the new computer is the checkbox for 'log to a file'.
Read More...
This appear to be a problem with Wayland and proprietary video drivers (at least in my case). If I set the system to use X11 instead of Wayland, the pointer is back, and everything works fine. It also feels faster. I am using proprietary nVidia drivers with a 3070.
Of note, kstars sky map changes the default cursor to an `X`. I do not remember this being the case in older versions of kstars, so it could be something in Wayland doesn't handle the custom hardware cursor?
Read More...
I updated in order to get the new focus model and now it seems to crash when trying to connect to my ASI290mm mini camera:
Aug 13 10:27:06 allsky [INFO] MainProcess allsky._initialize() #335: Found 1 CCDs
Aug 13 10:27:06 allsky [WARNING] MainProcess allsky._initialize() #338: Connecting to device ZWO CCD ASI290MM Mini
Aug 13 10:27:07 allsky [INFO] MainProcess indi.newMessage() #218: new Message 2022-08-13T16:27:06: [ERROR] Error connecting to the CCD (ASI_ERROR_CAMERA_REMOVED).
Aug 13 10:27:07 allsky [INFO] MainProcess miscDb.addCamera() #44: Camera DB ID: 1
Aug 13 10:27:07 allsky [INFO] MainProcess indi.configureDevice() #404: Setting switch DEBUG
Aug 13 10:27:07 allsky [INFO] MainProcess indi.newSwitch() #205: new Switch CONNECTION for device ZWO CCD ASI290MM Mini
Aug 13 10:27:07 allsky [INFO] MainProcess indi.newSwitch() #205: new Switch DEBUG for device ZWO CCD ASI290MM Mini
Aug 13 10:27:08 allsky [INFO] MainProcess indi.updateCcdBlobMode() #228: Set BLOB mode
Aug 13 10:27:09 allsky [INFO] MainProcess indi.configureDevice() #404: Setting switch CCD_FRAME_TYPE
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #36: An uncaught exception occurred:
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #37: Type: <class 'indi_allsky.exceptions.TimeOutException'>
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #38: Value: Timeout finding control CCD_FRAME_TYPE
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/allsky.py", line 128, in <module>\n action_func(*args_list, **kwargs_dict)\n'
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/indi_allsky/allsky.py", line 588, in run\n self._initialize()\n'
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/indi_allsky/allsky.py", line 363, in _initialize\n self.indiclient.setFrameType(self.ccdDevice, \'FRAME_LIGHT\') # default frame type is light\n'
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/indi_allsky/indi.py", line 266, in setFrameType\n self.configureDevice(ccd_device, frame_config)\n'
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/indi_allsky/indi.py", line 405, in configureDevice\n self.set_switch(device, k, on_switches=v[\'on\'], off_switches=v.get(\'off\', []))\n'
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/indi_allsky/indi.py", line 670, in set_switch\n c = self.get_control(device, name, \'switch\')\n'
Aug 13 10:28:14 allsky [ERROR] MainProcess allsky.unhandled_exception() #43: ' File "/home/thomas/indi-allsky/indi_allsky/indi.py", line 644, in get_control\n raise TimeOutException(\'Timeout finding control {0}\'.format(name))\n'
Read More...
I missed this post, but have the same problem. I am looking to see what to do to fix it. The pointer works in every other aspect, except in the main kstars window. The pointer appears when you grab and pan, and when you left-click, but as soon as you move to the main screen, it is gone.
Read More...
Fred,
That would certainly provide clearance for the RTC by mounting the fan sideways.
I guess the only question would be whether the displaced fan would give adequate cooling to the main chip.
This would be a minimally invasive way of getting what I would need, thank you for suggesting this.
I spent a couple hours searching online for a Pi case that was tall and included a fan and came up fairly empty, with only a couple plausible solutions.
It would seem that I would not be the only one looking for a little more clearance in a Pi case.
Another possible solution would be finding a RTC that didn't mount directly on top of the pins.
Read More...
Need to get this driver for iOptron mount with Fedora 32. Does anyone know where and when this driver will be publically available?
All the best,
John
Read More...
OK, I think I found the explanation. It seems like suspending guiding during calibration, focusing and the finish the suspension does not continue the calibration. Instead, guiding continues. If this is true, we should call it a bug.
Read More...
www.ibtoverseas.com/study-in-usa-without-ielts
Study in USA Without IELTS : Is It Possible?
In this article, you will find complete details about How to study in USA without IELTS exam. Follow our step-by-step guide to find out more…
Hi Paul,
I found the old top to the RPi case (the same one you purchased) with the fan still mounted - I've attached a photo. You'll see two of the standard fan mounting pegs above where the fan is mounted - obviously not being used in order to provide clearance for the RTC. If I recall correctly, I may have had to clip/grind the other two pegs down so I could move the fan. The four screws go into the vent slots and firmly hold the fan inside the case. The cover fits just fine with the fan inside the case, not mounted outside and not interfering with the case closing all the way.
Good luck on the project.
Read More...