Hi All,
I just did the standard upgrade:
(repository ppa:mutlaqja/ppa):
sudo apt-get update
sudo apt-get install indi-full kstars-bleeding
The software is updated to 3.5.3 (kstars-bleeding), but after starting kstars, the Ekos option is not found in the Tools tab. Scratching my head, I removed and re-installed but still no EKOS. Was the option missed during the build process? I am running Linux Mint 20 and was upgrading from kstars 3.5.2 to latest. After the installation the help/info shows: KStars
Version 3.5.3 Stable
Build: 2021-04025T15:57:41Z
Cheers,
Chris
Read More...
Hi,
I've see this exact issue using my asi120mm-s and asi178 or asi533. I use the asi120mm-s as the guide camera. Trying the Raspberry pi 4 going to a usb3 hub and then to the cameras. (side note, I've tried otther USB configurations, but still had issues.) This configuration never has worked for me. I could never use both cameras simultaneously without timeouts.
What I ended up using a second raspberry pi 4 for the guide camera and another for the main camera, mount, and filter wheel. Doing this split has always work for me. I have always suspected that there was a driver issue with ASI or a USB driver issue with the Raspberry pi's. At one time, the Pi's had horrible implementation of USB drivers (I am sure that this has been addressed in later drivers). Going to the bleeding-edge kstars or the latest SDK never resolved this issue. I was hoping with my new camera, asi533, things would improve, but bench testing showed that I still timeout/exposure failures and many times it would loop when using a single Raspberry Pi.
If you are interested, I can give you details on how I setup the two Pi's to work with Kstars/Ekos (based upon the article "INDI on multiple devices " by Jasem . Perhaps other's have had better luck, and with those cases I would be interested in their specific configurations.
Cheers,
Chris
Read More...
I have a similar configuration but not identical. The checks should run fine on Raspbian.
My Configuration (remote server)
QHY5L-II-M
Raspberry Pi 3
Powered Hub
Ubuntu 18.04.2 LTS
indi-qhy/bionic 2.4~201906051400~ubuntu18.04.1 armhf [upgradable from: 2.4~201906030127~ubuntu18.04.1]
indi-qhy-dbg/bionic 2.4~201906051400~ubuntu18.04.1 armhf
On the desktop side, I am running
kstars-bleeding/xenial,now 6:3.2.3+201905220414~ubuntu16.04.1 amd64 [installed]
After camera is plugged in, verify that the LED in back of the camera is lite. If this fails to light, it indicates issues with the camera. Then in a terminal session, type the following command:
lsusb
You should see:
Bus 001 Device 007: ID 1618:0921
The ID is the important part. Now remove the the camera's usb connection and re-run the command "lsusb", the device should now be gone from the list of the devices. If the device fails to show up , verify the usb cabling.
If the device is present, you can dig a little further by using the command:
sudo lsusb -v | grep -A78 1618:0921
You should see the verbose output now. Here is what my output looks like for comparison:
sudo lsusb -v | grep -A78 1618:0921
Bus 001 Device 011: ID 1618:0921
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1618
idProduct 0x0921
bcdDevice 0.00
iManufacturer 1 QHY-CCD
iProduct 2 QHY5-II
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled
Review the output from the following command:
dmesg
You should something like:
[ 2028.646670] usb 1-1.5.3: New USB device found, idVendor=1618, idProduct=0921
[ 2028.646682] usb 1-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2028.646692] usb 1-1.5.3: Product: QHY5-II
[ 2028.646702] usb 1-1.5.3: Manufacturer: QHY-CCD
If you get nothing, test with minimal USB cable length to the camera, replace the USB cable, and check the Pi's Power Supply. You should have at least a 2.5 amp good quality power supply. Also, if you are using a powered hub, I would test with a different power hub. You can test without a powered USB hub, but based on knowing the Raspberry Pi's, I would not recommend directly connecting to the Pi for normal use.
I hope this helps. As stated earlier in this thread, the older QHY5 camera have issues. And the above only pertains to QHY5L-II-M.
Cheers,
Chris
Read More...
I love this setup.. "Observatory in a Box". I have the same idea and you executed it beautifully!
Cheers!
Chris
Read More...
Thanks Jasem! I pulled the kstar GIT source, compiled and tested using my mount and guide simulator.
Looks Good!
2018-12-04T20:48:25 Please wait until mount completes rotating to RA (22h 35m 28s) DE ( 89° 57' 15")
2018-12-04T20:48:30 Mount first rotation is complete.
2018-12-04T20:48:30 Settling...
2018-12-04T20:48:40 Capturing image...
2018-12-04T20:48:51 Image received.
2018-12-04T20:48:51 Starting solver...
2018-12-04T20:48:54 Solver completed in 3 seconds.
.
.
I'll give it a full test in the field when the clouds part. Being in the US Midwest it may be a while as Nov/Dec are the cloudiest months here.
Again, thanks and best regards,
Chris
Read More...
Hi All,
I am trying to test the settling time with Polar Alignment. I am testing using the Guide Simulator and my iOptron mount inside (since clouds are spoiling my fun).
I think the settling time is not in the correct order of the alignment routine. What I am see is that the after the image is captured and solved, settle time, mount rotates, and then image is captured. I think the correct order would be to mount move first, then settling time, and finally the image capture and solve?
I can only do limited testing, but with the order of mount movement, settle time, and capture, appears to be incorrect.
Jasem, can you check?
Thanks in advance,
Chris
Here is the log (settle time was set to 5000):
2018-12-03T20:45:26 Capturing image...
2018-12-03T20:45:37 Image received.
2018-12-03T20:45:37 Starting solver...
2018-12-03T20:45:39 Solver completed in 2 seconds.
2018-12-03T20:45:39 Solution coordinates: RA (14h 35m 11s) DEC ( 89° 58' 15") Telescope Coordinates: RA (14h 32m 43s) DEC ( 89° 58' 21")
2018-12-03T20:45:39 Please wait while WCS data is processed...
2018-12-03T20:45:40 WCS data processing is complete.
2018-12-03T20:45:40 Settling...
2018-12-03T20:45:44 Please wait until mount completes rotating to RA (16h 32m 42s) DE ( 89° 58' 21")
2018-12-03T20:45:45 Mount first rotation is complete.
2018-12-03T20:45:45 Capturing image...
2018-12-03T20:45:55 Image received.
2018-12-03T20:45:55 Starting solver...
2018-12-03T20:45:58 Solver completed in 2 seconds.
2018-12-03T20:45:58 Solution coordinates: RA (14h 34m 28s) DEC ( 89° 58' 15") Telescope Coordinates: RA (16h 32m 43s) DEC ( 89° 58' 21")
2018-12-03T20:45:58 Settling...
2018-12-03T20:45:58 Mount second rotation is complete.
2018-12-03T20:45:58 Capturing image...
2018-12-03T20:46:03 Please wait until mount completes rotating to RA (18h 32m 42s) DE ( 89° 58' 21")
2018-12-03T20:46:09 Image received.
2018-12-03T20:46:09 Starting solver...
2018-12-03T20:46:11 Solver completed in 2 seconds.
2018-12-03T20:46:11 Solution coordinates: RA (16h 43m 35s) DEC ( 89° 58' 21") Telescope Coordinates: RA (18h 32m 43s) DEC ( 89° 58' 21")
2018-12-03T20:46:11 Please wait while WCS data is processed...
2018-12-03T20:46:12 WCS data processing is complete.
2018-12-03T20:46:12 Mount axis is to the Top Left of the celestial pole
2018-12-03T20:52:41 Solver aborted after 393 seconds
Read More...
