Update and lingering issue - I was able to work on this issue intermittently over the last few days. I checked the dialout group and my user was indeed already included. What ended up fixing my serial connections was to follow the instructions from the website ask Ubuntu . Admittedly, I don't fully understand why this worked other than there seemed to be a product ID conflict and commenting this out did allow me to connect to my devices via /dev/ttyusb0,1,2,3...

Here is the solution :
1) Edit /usr/lib/udev/rules.d/85-brltty.rules
2) Search for this line and comment it out: ENV{PRODUCT}=="1a86/7523/*", ENV{BRLTTY_BRAILLE_DRIVER}="bm", GOTO="brltty_usb_run"
3) Reboot


LINGERING ISSUE - I still cannot get my QHY183c to be recognized by Ekos. When I start the service in Kstars Device manager I see the following:
2023-05-09T03:18:40: startup: /usr/bin/indiserver -v -p 7624 -m 1024 -r 0 -f /tmp/indififo88932c7a
2023-05-09T03:18:40: listening to port 7624 on fd 5
2023-05-09T03:18:40: Local server: listening on local domain at: @/tmp/indiserver
2023-05-09T03:18:40: FIFO: start indi_qhy_ccd
2023-05-09T03:18:40: FIFO: Starting driver indi_qhy_ccd
2023-05-09T03:18:40: Driver indi_qhy_ccd: pid=3013 rfd=9 wfd=9 efd=10
2023-05-09T03:18:40: Client 8: new arrival from 127.0.0.1:49540 - welcome!
2023-05-09T03:18:40: Driver indi_qhy_ccd: -- qhyccd.cpp param
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResource()|START
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResource|auto_detect_camera:false,call InitQHYCCDResourceInside
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResourceInside|START
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|libusb_version 1.0.25.11696
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|libusb_init(libqhyccd_context) called...
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResourceInside|numdev set to 0
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResourceInside|END
2023-05-09T03:18:40: Driver indi_qhy_ccd: ************************** config file path 23.3.26.4 svn: 1 ************************************
2023-05-09T03:18:40: Driver indi_qhy_ccd: QHYCCD|QHYCCD.CPP|InitQHYCCDResource|Load ini filePath = /home/orangepi fileName = qhyccd.ini

When I run lsusb in terminal it doesn't recognize the device as QHY, it's seeing it as Cypress WestBridge. I did read that there could be an issue with the fxload file. So I downloaded the latest SDK from QHY's Linux support page for arm64. I decompressed it and found the fxload and replace my /sbin/fxload, but that did not work.

Has anyone else had this issue?

Read More...

Thanks for the suggestions. I’m looking forward to seeing if 4 will help, I know I have not done that. I’ll look thru your stuff. Thanks for sharing.

Read More...

Hi Alex, (or anyone else trying to use Ubuntu on an Orange Pi5 for astrophotography)
Have you encountered any issues connecting your devices to Ekos while using Ubuntu on an Orange Pi5 for astrophotography? I am facing an issue where Ekos is unable to connect to my QHY183c, I get a pop-up asking if the device is connected and powered on. Yes, it is. In addition, the serial connections are displaying a port failure error of "No such file or directory." I am curious to know if you have faced similar issues.

A few months ago, I came across the Orange Pi 5 and thought of using it as a replacement for my RPi4 to take advantage of its stronger machine and faster speeds of the NVMe connection and SSD. With the help of a friend we designed a housing allowing us to combined a few other devices under the OPi5's roof, such as a 7-port powered USB hub, focuser PCB, EL panel PCB for flats and automated shutter control, and a 12v power supply for three barrel jacks. After some hard work, the device powers up, headless with a VNC desktop via X11. Unfortunately, I couldn't get tightvnc working, as there was an issue running kstars, and it kept showing an error with Qt.

I have plugged the USB hub into the OPi5's USB A 3.0 port. The focuser and the EL panel are plugged directly into the other USB A ports, while the mount, camera, and guide cam are all connected through the hub. However, only the ZWO guide cam seems to be connecting. I have used this same setup with RPi4 without any issues.

I ran "ls /dev/tty*" and get like 63 root available serial connections but no indication of what is connected. I also ran "lsusb" and this is what I got:
Bus 006 Device 003: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 006 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 002 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 002 Device 003: ID 03c3:120c ZWO ASI120MM Mini
Bus 002 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Any suggestions would be very much appreciated.

Read More...

Hi All,
I think I'm experiencing a bug, but I'm not sure if it's with the device firmware or the Indi driver. The issues is FlipFlap driver not recognizing a state change from Parked to Unparked and and vice-versa. I am not using a filter wheel, as I've seen in other threads, but am experiencing a failure when I'm running KStars 3.6.0 on RPi4 with with Arduino Nano flashed with El Flat Panel firmware . I can Unpark and Park the flap from within the indi Controll panel manually, but the status light stays red and the Unpack button tries to turn green but flashes back to grey and the Parked button turns green again, even though it is in fact unparked. This isn't a huge deal, but when I try to run the scheduler it sees the cap as "Parked" when it's really "Unparked" and aborts the job. I've run thru this with verbose logging turned on and there isn't much info that I can see. I've attached a log and the cap errors out towards the bottom of the log. Any help or direction would be greatly appreciated. Here is the section of the log the error presents itself:

"2022-11-02T21:07:06.724 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - "Checking Startup State (6)..."
[2022-11-02T21:07:06.725 CDT INFO ][ org.kde.kstars.ekos.scheduler] - "Unparking cap..."
[2022-11-02T21:07:07.724 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - "Checking Startup State (7)..."
[2022-11-02T21:07:07.725 CDT INFO ][ org.kde.kstars.ekos.scheduler] - "Cap unparking error."
[2022-11-02T21:07:08.724 CDT INFO ][ org.kde.kstars.ekos.scheduler] - Scheduler is stopping...
[2022-11-02T21:07:08.724 CDT DEBG ][ org.kde.kstars.ekos.scheduler] - Job ' "Soul Nebula" ' is stopping current action... 0
[2022-11-02T21:07:08.726 CDT INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'Soul Nebula' has not been processed upon scheduler stop, marking aborted."

I use a 3d printed shutter, connected to this servoservo . It's purched on a 3d printed platform at the end of my dew shield. I use the servo blaster driver to control its opening and closing. I attached an EL panelEL panel to the inside plane of the shutter and while flats are not 100% automated, the servo blaster driver is picked up by Kstars and allows for automated darks and biases. And a remote triggering of flat capturing sequence.

The only problem I'm still trying to tackle from a DIY perspective is 100% automated flats. Which would then let me capture flats while using the Scheduler module. For now I have to manually engage the EL panel when I need to capture a fresh batch of flats and current configuration is not dimmable, but that will be changing soon.

To do this, I use the astroberry relay driver to flick on an RPi relay hat . Since I'm using a dedicated astro camera I can take advantage of the ADU auto flat capture feature within Ekos. So at least part of the flat capture process is automated.

Hope this helps.

Read More...

Peter, Tim,
Thank you for the insights!Given the nature of my question regarding code, I obviously see no dumb questions, ever, which is a blessing and a curse. I’m just grateful you’ve shared your thoughts. Yes, I am controlling the EL Panel with the relay board mentioned in my original post. As of right now, I am not too concerned about controlling the brightness of the EL panel. I’m shooting with one light pollution filter on a one shot color camera so I don’t need to adjust brightness for multiple filters at this point, that will be a bridge across later I suppose. For now, I want Ekos’s capture module two turn on the EL panel when servoblaster has my automated dust cap closed via the calibration settings for flats. The EL Panel is mounted to the inside of my dust cap. Automated flat capture is my final step in complete rig automation.  I’d like this to be a pi based solution if possible without adding another component to the mix. As far as the question about Ekos adjusting the brightness for a static exposure, I don’t know. I’ve never seen that behavior offered from the system before. But I do like that idea, it could check a lot of boxes, not that my opinion carries much weight.  Any suggestions on how I can modify a driver to fit my needs or a good place to start to learn how to accomplish that?

Read More...

Hi All,

If this is in the wrong place or there is already thread containing this info it please let me know. I just didn't see one.

First, I have very very limited coding experience, but am looking for some help in controlling an EL Panel via the Calibration settings within the capture module of Ekos.  I have an RPi 4 running astroberry with a Raspberry Pi Expansion Board, Power Relay .  I'm using a 3d printed shutter on a servo driven by servoblastercap.  The cap closes properly/automatically when it comes time to taking darks so that's not an issue.  I had planed to control el panel via the relays on the hat.  I found Astroberry DIY including the Astroberry Relay, and while I can manually flick the relays on within the INDI Control Panel, I can't seem to get it to respond to the calibration settings.  I also found a driver written dokeeffe on GitHub call qik_flat, which at first glance looks exactly like what I'm trying to do, but again I'm code dumb and don't know.  So I'm humbly asking the community for help.  Any direction would be fantastically appreciated.

Thanks all,
YKMFPTD

Read More...

Follow up:

Since my previous post I have upgraded to Kstars 3.5.4 on the remote machine and updated/upgraded the Astroberry.  I have not seen the crash and all seems to functioning properly.  Can’t say for sure the crash has been resolved as I’ve only had one night of imaging since the updates/upgrade. 

I can’t say thank you enough to all of you that manage and maintain the software. 

Read More...

I’m not completely sure I’m posting this in the proper location, but I can’t seem to find any other info about what is happening.  If this should be posted elsewhere please let me know.

Problem:
Kstars crashes while guiding is active.

Background:
I’m running the latest version of Kstars on MacOS. I have a RPi4 running Astroberry and connect to it remote from the Mac to control my imaging sessions. I’ve had great success with this set up until the most recent update/upgrade. I updated Astroberry and Kstars. At that point Kstars began crashing after the first two or three frames were captured. The crash only seems to take place while I have guiding active. I’m using the internal guider, but have not tried PHD2 at this point.  Has anyone else been experiencing this issue/crash. I’m grateful for any help you can offer. 

I believe I’ve captured debug logs and can supply those if needed. (I’m on my phone at the moment and away from the imaging comp.)

Read More...

Hi There, I am new to this site and am hoping you don't mind me piggy backing on this convo. If this should have been posted else where, I'm sorry and please let me know.

I just completed building the indi_servoblaster_cap driver as described in one of your previous posts knro . And I should say thank you for that post and all the documentation. I'm running Astroberry on RPi 4, and using Indi Web Manager in concert with KStars and Ekos on another comp. I have two question:

a. How can I get Indi Web Manager to see ServoBlaster as an optional driver from within the local driver drop list? It does not appear within the Auxiliary section, however it does appear when using KStars on the RPi 4, which leads me to my next question.

b. While in KStars, on the RPi 4, I can set ServoBlaster Cap as an auxiliary driver within one of my Ekos profiles and start it, no problem. However, in the subsequent Indi Control Panel, I can not get the servo to move when I click park/unpark. The servo is plugged into the GPIO pins as follows (and from what I can tell, matches your table in the previously mentioned link). Power to pin 2, Ground to pin 9, and signal to pin 11. On the Calibrate tab I choose servo ID 1, as per the table it correlates to pin 11. You should also know when I built the servo driver, I did skip the USBRelay2 Roof and Wiring PiGPIO as they were stated as being optional. Is Wiring PiGPIO required for manual operation of the dust cap or is it more for the automation within a capture sequence as describe earlier in this thread? What I'm I missing?

Read More...