Maybe you can try this

Read point 9.4
wiki.archlinux.org/title/TigerVNC

bbs.archlinux.org/viewtopic.php?id=101243

Read More...

1. Any software author can make rules for their requirements. So you end up with multiple applications/drivers trying to claim the same device.
2. The rules are processed in numeric order.
3. Higher numbers "win" by overwriting matching rules in lower numbers. There's also priority from where the rules are stored. See www.freedesktop.org/software/systemd/man/latest/udev.html
4. Mode=0666 is setting permissions. 6 means r/w, there are three of them for owner, group & all users. Ignore the leading 0 for most purposes.
5. Don't know
6. Don't know

If you were unable to reproduce the problem, it is probably because the configuration files are correct. Tried changing your gpsd file with the previous values, and you should end up with the mount problem again.

IdVendor is the name of the company that produces several products (idProduct). The products are found in different rule files with the (unique) company id in front.
Look at these links to better understand the rules files:

devicehunt.com/view/type/usb/vendor/067B/device/2303

unix.stackexchange.com/questions/44308/u...ermissions-in-libusb

forums.opensuse.org/t/udev-rules-priorit...with-operator/100210

Your cable contains a PL2303 chip and not FTDI. So nothing to change in 69-libftdi.rules and you must leave it in 25-gspd-usb.rules because the PL2303 chip is used in some GPS

Read More...

After mulling my last post over, several questions come to mind. I am referring to this:

Hi Akarsh,

This is what it looks like on the Mac (Macbook Pro M1 running Sonoma 14.4.1). It works perfectly on my Linux machine.

Cricut Account Login: Access Your Designing Software

It’s been four years since I started using the Cricut machine to create custom-made projects, and I...Cricut Account Login: Access Your Designing Software

It’s been four years since I started using the Cricut machine to create custom-made projects, and I still get excited whenever I decide to make new crafts. During that time, I realized that apart from having Cricut cutting machines
.
.
.
#cricutsetup #cricutmachine #cricutdesignspace #cricutlogin Show more

Cricut Account Login: Access Your Designing Software – cricut.com/setup

For easy Cricut account login, you must download Design Space on your device and create a Cricut ID. Read this blog and get to know…

The menu entry is called "Views" and not "Custom Views" although we've referred to the feature as "Custom Views". Please check if there is a menu item titled
"Views" in the "View" menu, screenshot from my Linux machine attached. I've tested the build on MacOS and at least on my custom builds, it showed up fine.

Clear Skies,
Akarsh

Read More...

Sorry, that was a nice feature. Can it be added?

Read More...

I spent a frustrating morning playing with my rig in three different setups.
1. No Dongle
2. Dongle connected after Pi booted
3. Dongle connected before Pi boot (the situation last night).
In no case could I reproduce the problem I saw last night. I made the mount go to various objects which were all invisible (due to my doing this in daylight hours) but in all cases the scope was pointed in the right general direction according to the map in KStars. If the problem had recurred, i would have seen error messages like these I saw last night

[2024-04-17T20:32:32.364 MST DEBG ][           org.kde.kstars.indi] - Celestron Advanced VX HC : "[DEBUG] CMD <e> "
[2024-04-17T20:32:32.364 MST INFO ][           org.kde.kstars.indi] - Celestron Advanced VX HC :  "[ERROR] Serial write error: Write Error: Input/output error "
[2024-04-17T20:32:32.365 MST INFO ][           org.kde.kstars.indi] - Celestron Advanced VX HC :  "[ERROR] Failed to read RA/DEC

It is a missing feature due to VNC server change: now with TigerVNC, as you can read here github.com/devDucks/astroarch/releases/tag/v1.8 the clipboard isn’s supported :(

Read More...

Hello,
Clouds, clouds, clouds, clouds and wind and rain... no astro since monday.
So, trying to understand how to set up video mode so as to get smooth frames with ASI183 on RPi 5.
The sensor is 5496x3672, which needs almost 2 seconds to transfer to the PCIe SSD. It has always been, and I think it will always be.
This means that fast exposure subjects are not a good idea : almost 120 seconds for 60 pictures at 0.1 second, 3600 frames of the moon that ought to last 6 minutes actually take around two hours.
Okay, there is a video mode in the capture tab, but at 0.1 second exposure, I get a framerate of ca. 4 images per second. A little bit better, but still not satisfying.
I then tried to figure out the way to lower the resolution, for instance decreasiing to 1280x720 at which, according to the manufacturer's data, the 183 is capable of 103 fps.
But nowhere in the menus of the SM APP on the tablet I could find how to achieve this.
I finally thought this could be done from the streaming tab of the Indi dashboard, but alas! even with so lower resolution of 1280x720, when i start capturing the framerate remains at 4 FPS
Long preamble to explain my problem, so now : how can I get a real video mode, that would allow to capture at least 20 fps ? What and where in the SM APP do I need to set ?
Rgrds,

Read More...

In Astriarch 1.7, the noVNC clipboard used to allow me to copy something from the host PC into the window, then copy it again and paste it into a window on the Pi where Astroarch is running. This would enable cut-from-host-paste-to-Pi. In Astroarch 1.8 this doesn't work. I can copy from the host-pc into the clipboard window, but when I paste in a Pi window, some other clipboard is the source of what gets pasted. It seems that there are two different clipboards in play. As I said, this was not the case in 1.7 or with Astroberry before that. Is this a bug, or is there some setting I need to set?

Read More...

My first attempt to climate telescope was with phone camera too. But I quickly realised, that is impossible to place phone at exact center of focuser tube. That wouldn't be issue if at least you could place phone at exact same spot near the center, but that's is just impossible. At least it was for me. What's the point in collimating telescope if your optical path constantly changes? Sure you can do collimation each time you take phone off and back on, but good luck with that. It will be OK for visual observation, but not for astrophotography.

That's why I'm using raspberry pi camera with special case designed and 3d printed, the way that it can be screwed on top of my focuser. This way optical path stays the same even if I take my camera off and put it back on.


Read More...

The problem comes from udev and its way of mounting dev points.
It is possible to create rules to obtain a static point according to the manufacturer's name
wiki.archlinux.org/title/Udev#Setting_static_device_names

A tutorial made by Indi to create the rules file
www.indilib.org/support/tutorials/157-pe...al-port-mapping.html

It would be interesting to know the identifier of your GPS and the USB/RJ cable of your mount. And check if they are in the rules /lib/udev/rules.d/25-gpsd-usb.rules and /lib/udev/rules.d/69-libftdi.rules
To find them, use the following command as noted in the tutorial

"To find out the serial ID, run the following command against the device node. For example, the find the serial id of the device connected to /dev/ttyUSB0:"

udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1

Read More...

After sleeping on the matter, I decided to say, to hell with the GPS. Since I have to enter the time and location every time I start the mount, I could just go with that, and use the "Mount updates KStars" for time and date setting. That would cover most of it. The only thing missing would be updating the system clock. I could live with that.

In any case that would fulfill your first test item. I will send you logs and screenshots. Then I would go back to trying the GPS, both after startup and before, and send those logs and screenshots and the other information you request.

But I am still wondering, what is going on on the system level here? Why doies tthe system decide that /dev/ttyUSB0 is no good, and set up /dev/ttyUSB1 instead? KStars and INDI logs provide no information on that, even at the most verbose level. Something is causing that to happen and I wonder if system logs would record some useful information about this.

Read More...