Welcome to INDI Community

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

That's easy. . . the NVME drive is drawing ALOT more power than the SD card. I assume that you're powering your Rpi thru the USB-C port on the Rpi? The Rpi-5 is already drawing alot of power and if it dips down below a certain voltage for a millisecond, then "things" can happen. It may not be enough of a brown-out to cause a total reboot of the Rpi, but it may be enough to cause individual chips or sub-systems to reboot.
.
Everything can be working along just fine for hours and then something happens where all 4 cores of the Rpi fire up to 100%, and the Ethernet system is working at 100%, and . . . and. . . brownout.
.
I went thru the exact same issue when I was setting up my Rpi-5/NVME system. The solution I came up with is to power the Rpi directly thru the 5VDC GPIO pins with a power supply that has alot of ass behind it maintain voltage no matter how many chips fire up.
.
I am currently getting ready to test an Rpi Hat that I've integrated a 5VDC@6A power supply feeding directly into the GPIO pins that should be able to handle anything the system throws at it, but that won't be ready for public consumption for a couple more months.
.
In the meantime, order one of these: a.co/d/1iQcW01 and power your Rpi directly to the 5VDC GPIO pins. The Rpi is specced to handle up to 5.2VDC on the GPIO pins, so hopefully you'll get one that gives you 5.1VDC. I've used several of these during my testing and it was the solution to all the little glitches I was having. Solid as a rock.
.

Read More...

Before I reassemble the NVME hat on the pi, why would this power problem only occur with an SSD card and not the SD card?

Read More...

Update: I did some more testing and found more strange issues.

Clearing the model seems to help a lot. The attitude is showing properly and doesn't change abruptly. However, the pointing seems to be reversed. If I point to a target in the east, it goes west. If I point to a target in the west, it goes east.

Part of the problem seems to be that it is not reporting what side of the pier the mount is on properly. Can anyone help me understand how the mount normally figures this out, and if there is a way to tell it what side it is on?

I don't think I'm doing anything crazy here. I put the telescope in the home position, turn it on, clear the model, and plate solve. However from there it can't seem to figure out what side of the pier its on and doesn't move to the right target.

Any help would be appreciated, even just resources on how some of the systems work. I'm not even sure what to test at this point.

Read More...

AFAIK, there is no downgrade path other than saving your settings and any captures to external media and then doing a re-install.
If you have having hardware issues, I would encourage you to submit a ticket at the StellarMate site so that Jasem and company can check it out. I had a similar issue not to long ago on an upgrade and the Pegasus Falcon rotator. Jasem was able to remote in and find the issue and get the fix in the pipeline for release (not to mention fixing it on my unit itself).
It's one reason I've gotten really hesitant to run any updates once I have a stable system. Generally there are no issues, but invariably for me they show up when least wanted.

Read More...

Hi!

Here's a screen-shot of the filter config:

I use the V-filter for alignment and for focus. This problem has occurred when I do a series of Miras where for each, I take VRI-band images, in that order. So that first shot is same filter as alignment.

Best,
Magnus

Read More...

Just go to: kstars.kde.org/de/download/
then, right click with the mouse to copy the link. Paste the link in the location bar and edit the version number. This should allow you to fetch older versions.
Example:
www.indilib.org/jdownloads/kstars/kstars-3.7.0.dmg

Best, Peter

Read More...

If you apply a PR, don't edit the rolloff.ino.standard as shown. Add an additional example sketch with your changes. The rolloff.ino.standard needs to retain the original relay polarity and pin numbering to match the standard Uno relay shield. That helps those who do not want to be involved with any code editing get on-line without any software changes.

Limiting the number of relays was intentional to limit it to just the purpose of controlling the roof. There was some discussion at the time of the Observatory being extended. Rather then put other observatory like functions in the individual roof/dome drivers. In the meantime there were 3rdparty drivers able to read and set particular pins.

Read More...

This issue occurs when the mount is preposition to the object before starting Scheduler. When scheduler starts it reports parking is off, etc and then calls Align, Scheduler enters a wait for Align loop. Align takes an image, solves the image and identifies the object is within range. Scheduler does not recognize Align has finished and remains in an infinite wait state.

Get Connected!