You can use Stellarmate to run INDI, and connect with your current Mac with KStars via ethernet.
That's the way I do it.

Read More...

Ferran Casarramona replied to the topic 'Ekos Optical Trains' in the forum. 11 months ago

Forget my last message. I needed to delete userdb.sqlite.backup also, and now it works.

Read More...

Ferran Casarramona replied to the topic 'Ekos Optical Trains' in the forum. 11 months ago

Hi,

I installed version 3.6.4 for OSX and when I try to add an optical train ('+' button) Kstars closes without any message.

I tried to delete userdb.sqlite file, but this didn't change anything.

Any advice is welcome.

Ferran

Read More...

I notice the problem described in this link: ST8 Read Noise

The solution seems straight forward, and is described also in the link. Just disconnect cooling during readout phase, but I don't know if this must be done in the SBIG Linux driver or in the INDI driver.

Read More...

I don't know if this is related, by I'm having issues with some of my devices connected in a hub.

I work around these problems, unplugging and plugging again the USB cable of each device.
In previous versions of StellarMate OS there are not such issues.

Read More...

It works Ok in my iMac 21,5", Intel i5, 8 Gb, ending of 2013.

Read More...

I have a similar issue after uptating to Stellarmate OS 1.7.1

In my case, plate solving never ends, and if I press "Stop" it hang during 1 or 2 minutes. Eventually it recovers, but not always.

KStars 3.5.9 (or 3.5.8 the issue is the same).

Read More...

For an automatic observation (without a human intervention) I thing it's better to install Ekos int the remote site, since you eliminate one point of failure (internet connection). 
Also, this allows you to connect from different locations/computers without having to install/configure Ekos in many computers.

On the other hand, the indi webserver option provides more security if multiple users have access to the telescope, avoiding any uauthorized user mess up the remote computer.

Take a look to Indihub (indihub.space) , and may give a try to taste what indi webserver can deliver.

 

Read More...

I'm working in a new version. I will do a basic test in my observatory, but my mount doesn't report pier side, so I can test it this part. When my tests were done I will ask you to test ti on your observatory.

Read More...

I tried to repreduce the bug with the telescope simulator + dome simulator, but I can't.

Maybe is dependent on the procesing speed of the computer. Can you reproduce the same behavior with both simulators in the Respberry Pi?

Read More...

Hi, I checked the code and saw a bug. This is the relevant code:

LOGF_DEBUG("HA: %g  Lng: %g RA: %g", hourAngle, observer.lng, mountEquatorialCoords.ra);

  //  this will have state OK if the mount sent us information
    //  and it will be IDLE if not
    if(CanAbsMove() && OTASideSP.s == IPS_OK)
    {
        // process info from the mount 
       if(OTASideS[0].s == ISS_ON) OTASide = -1;
        else OTASide = 1;
   }
    else
    {
        //  figure out the pier side without help from the mount
        if(hourAngle > 0) OTASide = -1;
        else OTASide = 1;
        //  if we got here because we turned off the PIER_SIDE switches in a target goto
        //  lets try get it back on
        if (CanAbsMove())
            triggerSnoop(ActiveDeviceT[0].text, "TELESCOPE_PIER_SIDE");

    }

    OpticalCenter(MountCenter, OTASide * DomeMeasurementsN[DM_OTA_OFFSET].value, observer.lat, hourAngle, OptCenter);

    LOGF_DEBUG("OTA_SIDE: %d", OTASide);
    LOGF_DEBUG("OTA_OFFSET: %g  Lat: %g", DomeMeasurementsN[DM_OTA_OFFSET].value, observer.lat);
    LOGF_DEBUG("OC.x: %g - OC.y: %g OC.z: %g", OptCenter.x, OptCenter.y, OptCenter.z);

This part is wrong:
// process info from the mount 
       if(OTASideS[0].s == ISS_ON) OTASide = -1;
        else OTASide = 1;

OTASideS[0] is the switch for east side, and OTASide variable meaning is 1 for east and -1 for west.

So the correct code must be:
// process info from the mount 
       if(OTASideS[0].s == ISS_ON) OTASide = 1;
        else OTASide = -1;

I did not debug this, but seems related.
I have bad weather here, so I don't know when I could debug this.

Read More...

I will take a look this weekend. It's a long time since I wrote this code.

Read More...

Hi Phillipe,

Nice to see you join to our community.

The change in Dome position from 29 degrees to 335 degrees was due the change of the OTA_SIDE property from 1 to -1.

This property can be changed by the telescope driver or by the user pressing the OTA Side button (I discard the second case for obvious reasons).

So, the question is why the telescope driver changed this property?

A nice test to be done would be to check your dome driver (or dome simulator) with the telescope simulator.

On the other hand, OTA pier side is a confusing concept when the telescope point to circumpolar stars, and this can cause programing bugs.

In my particular observatory, because my mount do not report the pier side, I always set this property manually, so I never seen this problem, of course.

Regards,
Ferran

Read More...