Matteo Piscitelli replied to the topic '64bit Astroberry' in the forum. 2 months ago

Actually in Astroberry repo I can see some arm64 packages. But if system is ready or not, I think only Radek can answer....

Read More...

Hi Willy,

SkySafari driver, AFAIK, is not meant to let an indi client interact with drivers, but to let SkySafari interact with drivers as it was an indi client itself. It's not clear how are you planning to use your mount: you want to drive an astrophotography session via Ekos? Or?

Read More...

Here too it is working. Seems to me that also "Auto update" can be left checked: if unit is "app", found that changing binning updates Low and High scales with the correct numbers.

Read More...

Hy, I'm very sorry I was working and haven't seen your msg until now. Reading on I discovered you found parameters to replicate it anyway :woohoo: Super!

Read More...

Not RaspberryPI-related only: here on a intel VM, 2GB ram configured, Ubuntu 20.04 and KStars 3.6.0 from ppa, same behaviour: all-simulators profile, three error assestment solves went perfect (4 sec exposure, less than 1 sec each), adjust plate solves (same refhresh 4 seconds, tried also with 6 seconds) all fail.



Read More...


Try lowering the step size.

Read More...


Maybe you already know, but while Ekos reports guiding error in arcseconds, PHD2 reports it primarily in pixels, and in arcseconds in parenthesis; so be sure to check arcseconds with arcseconds.

Maybe you only wrote it wrong, but to be clear: it's not "close to the horizon", it's "close to the celestial equator" (i.e. close to Dec = 0).

HTH
Matteo

Read More...

This Is open source anyways... anyone of us with enough skill can look at the code and fix It. Just to say...
Back on topic: I have just terminated 5 nights of captures changing broadband and narrowband filters during every night on two differenti rigs, and I didn't get a single filter tag missing sub. It's clear that the bug appears in very specifc circumnstances, otherwise we'd all experiment It: precise information and debug logs are essential for the developers to track down the issue and fix It.
I didn't experiment the bug, otherwise I woud have done It myself.

Read More...

Jasem you're right, at startup iOptron driver overrides MF setting in HC, it happens to me too. Fix is setting it in the driver and saving configuration, as you said.

Euripides, you have to let the mount track some time AFTER CROSSING MERIDIAN, otherwise MF is not going to happen. In iOptron at "Meridian Behaviour" setting "Flip" or "Stop" doesn't matter here, since MF will be triggered by Ekos; but the "Limit" you set does matter. Basic rule is:

0 < EKOS LIMIT < MOUNT LIMIT

Example: set Ekos to trigger MF 3° after crossing the meridian, and set mount limit to 6° after crossing meridian.
Ekos limit should be greater than 0, because Ekos and mount must exactly agree on which side on the meridian we are: allowing to track some degree after crossing it, relaxes the precision needed and accounts for small difference in models and approximations between Ekos and mount firmware. Mount limit should be greater then Ekos limit, because some time is usually needed to complete the running capture when filp time occurs (should be: MOUNT LIMIT - EKOS LIMIT > LONGEST EXPOSURE PLANNED).
And MOUNT LIMIT should be small enough to avoid the mount smashing your equipment on a tripod leg or something).

Hope this helps.

Read More...

I think that is correct: REL_FOCUS_POSITION property is used to move the focuser a relative amount in respect to where it is now; since the focuser moves, also abs position changes. To say: if focuse is at absolute position 100, and you set relative position to 20, it will move to 120. Then you set relative position to -40, and it will move to absolute position 80.

Read More...


I'd make two sequences: one for the lights, and one for the calibration frames, and two correnpondent scheduler jobs. The calibration one should have dusk/dawn check disabled and lower priority than the lights one. This way, when is imaging time, the lights job will run. When dawn arrive, lights job will be stopped by constraints, and calibration job will be free to run.

If you have all the robotics to do this without human intervention (which I have not), in theory you could go sleep and wake in the morning ready to start processing :woohoo:
For LRGB or narrow band, it totally depends on how you want to image: some prefer to use one whole night for single filter, to avoid small problems caused by filter wheel inherent positioning error and related flat mismatch. In this case there's nothing different from what we have already said.
If you plan to exchange filters during the night, and want to distribute them evenly across subject altitude variation, your only option is define a sequence containing all filters: for instance, keeping base 1 hour, you could do 12x120s L, 4x180s R, 4x180s G, 4x180s B, and let the sequence repeat until dawn; or any other combination.

Read More...


Hi,

provided a sequence generator is a good idea IMO, many of us tend to use the scheduler to do what you want: prepare in advance some "standard" sequences, to be repeated or stopped early by the scheduler. Example:

- Prepare some sequences, with different standard exposure/gain/offset (1 for 120s Gain 100 Offset 20, 2 for 180s Gain 100 Offset 20, 1 for.....), all lasting 1 hour (i.e. 30 shots for exposure 120s, 20 shots for 180s, etc.).
- When preparing your actual session, choose the right sequence for exposure, gain and offset and set it in a scheduler job, selecting one of the "Repeat <something>" options: your 1-hour sequence will be repeated n times, or until a datetime, or indefinitely (depending on which of the "Repeat ..." you chose), stopping at configured time or by "job constraints" (i.e. twilight, subject altitude, moon, weather...), whichever comes first.

Hope this helps.

Matteo

Read More...