I updated to the latest indi-drivers available in the repository, Installed kstars-bleeding and still see the same behavior. I have done another observing session and attempted to start he scheduler. Again, same issue. I've stop/started the drivers, rebooted the system and I am running out of ideas. I have attached a screen shot of the scheduler and a verbose log info file of the session.

Any ideas or suggestions would be greatly appreciated.

Thanks,

Chris

Read More...

Hi All,

I have attached the log files and the esq files. Sorry, I didn't save the scheduler file (esl). There are two log included. The "save_log_22-41-35.txt is from the 05/26/2024 session. You will see some issues with setting up plate solving, but this was overcome by a changing the solver configuration. The other log, save_log_11-05-52.txt was done with the simulator today and it show the same issue that I am having with my equipment.

I did not notice anything strange in the logs other then some "qt qpa" warnings. The scheduler starts and then "nothing" until I stop the scheduler. I'll continue to see if I can get the simulator to work and maybe in the next few days, I'll have some clear skies to capture the logs and session eql/esl files. In the mean time, I noticed a newer apt package version out there and I may update but want to backup the system before I do.

Thanks again "maxthebuilder" and "Hy",

Chris

Read More...

Hi All,

I noticed there was a recent thread regard the Scheduler Failed to Start, but I don't believe this is related to time/computer time the local time is in sync with the computer and KStars..

I am having issues with Ekos and the starting of the scheduler. I do not see any messages indicating why the scheduler is failing to start the scheduler execution. The object was well above the horizon, there was no twilight limitations. I see that the scheduler was starting, but there was no actions occurring. The only message was that the "Scheduler is awake", then nothing. All the Indi drivers are connected to the devices and all work. Scope was polar aligned via the Ekos tools and slewing to objects works as it should.

I am at a loss why this is occurring. I know it's been a while since I've used KStars/Ekos and the scheduler so perhaps I over looked something. I am currently using:

Configuration:
System Raspberry Pi 4 running Ubuntu 22.04.4

KStars version 3.7.0 Stable (build 2024-04-12)

Indi Drivers:
indi-qhy/jammy,now 2.7+stable+202404120657~ubuntu22.04.1 arm64 [installed,automatic]
indi-asi/jammy,now 2.4+t202404120657~ubuntu22.04.1 arm64 [installed,automatic]
indi-eqmod/jammy,now 1.0+t202404022147~ubuntu22.04.1 arm64 [installed,automatic]
libindi1/jammy,now 2.0.7+202404100833~ubuntu22.04.1 arm64 [installed,automatic]

I noticed that there is a recent update for indi (20240601). I haven't tested this version nor am I running kstars-bleeding version. I did not notice any indications of issues in the logs. I have attached the screen shot of the Scheduler started and awake.

Any help is much appreciated. I am now waiting for clear skies again.

Best Regards,

Chris

Read More...

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...

Thank you!

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...