The nightly macOS build looks like it hasn't been successful for 20 days now. If someone could fix that in the near future, I can give this feature a try.

Thanks,
Bill

Read More...

Hy,

Thanks for implementing that. I will have to wait until this is available in a release build. I'm not currently set up to build from source. How often do you do a release build?

Bill

Read More...

Peter,

No, that doesn't quite work for me. I wasn't totally clear in my explanation. With photometry, you need to make sure the ADU is within the linearity range of the chip. This is generally something around 48,000. Besides just saturation, I need to make sure it is in the linear range.

If the threshold for showing red was adjustable so I could set it to 48,000, then that would work pretty well. However, it would still be nice to see the Max in the region of interest popup.

Bill

Read More...

I primarily do variable star photometry. When planning my images, I need to adjust the exposure duration so the star in question (and the comparison stars) has a large enough SNR but also make sure they are not saturated.

The FITS viewer has a "Statistics of region of interest" feature, but it seems to only show the "average mean, average standard deviation and average median of the selected region". It would be really great it it could also show the Max value within the region. That would allow me to easily check for saturation. Currently I have to save the file and open it in a different app to check for saturation.

Perhaps there is already another way to check for saturation. If so, could someone explain it to me?

Read More...

INDI code is filled with code like:

INDI::PropertyNumber ccdTemperature = camera->getProperty("CCD_TEMPERATURE");

where literal string are used. This seems very error prone to me. If you mistype a property name, you will often have subtle, hard to find, errors in the code.

I was working with INDIGO before coming to INDI. They have #defines for all common property names.
//----------------------------------------------------------------------
/** CONNECTION property name.
 */
#define CONNECTION_PROPERTY_NAME							"CONNECTION"

/** CONNECTION.CONNECTED property item name.
 */
#define CONNECTION_CONNECTED_ITEM_NAME				"CONNECTED"

/** CONNECTION.DISCONNECTED property item name.
 */
#define CONNECTION_DISCONNECTED_ITEM_NAME			"DISCONNECTED"

//----------------------------------------------------------------------
/** INFO property name.
 */
#define INFO_PROPERTY_NAME										"INFO"

/** INFO.DEVICE_NAME property item name.
 */
#define INFO_DEVICE_NAME_ITEM_NAME						"DEVICE_NAME"

/** INFO.DEVICE_DRIVER property item name.
 */
#define INFO_DEVICE_DRIVER_ITEM_NAME					"DEVICE_DRIVER"

This seems to me to be a good practice and would recommend INDI adopt something like it in the future.

Read More...

OK, I *think* I have figured this out. It looks like the driver information for a device, in particular device.getDriverInterface(), is not valid until you have received a newProperty() notification for the property "DRIVER_INFO".

If in the body of that notification you ask for getDriverInterface(), you get back valid information and can determine what class of device this is.

It seems to me that the documentation should note that the various queries about the driver are invalid until this newProperty notification has happened.

Read More...

Very sneaky. Thanks for the explanation.

Read More...

I'm still looking for answers to my previous question (Getting all the Telescopes and Cameras), but perhaps this is related to things not working.

This may be related to my relative unfamiliarity to C++, but I am finding that instances of BaseDevice seems function as both an object and as a pointer to an object.

I am using Xcode on macOS for development and find that both these pieces of code compile just fine:

void IndiClient::newDevice(INDI::BaseDevice baseDevice)
{         
   IDLog("New Device: %s\n", baseDevice.getDeviceName());
   auto interface = baseDevice.getDriverInterface();
   if (interface & BaseDevice::TELESCOPE_INTERFACE)
   {
       IDLog("New Telescope: %s\n", baseDevice.getDeviceName());
   }
}

and
void IndiClient::newDevice(INDI::BaseDevice baseDevice)
{         
   IDLog("New Device: %s\n", baseDevice->getDeviceName());
   auto interface = baseDevice->getDriverInterface();
   if (interface & BaseDevice::TELESCOPE_INTERFACE)
   {
       IDLog("New Telescope: %s\n", baseDevice->getDeviceName());
   }
}

In the first case I'm referencing baseDevice as if it were an object and in the second case I'm using pointer dereferencing. They both compile without errors and both work. What's going on here??

Is this somehow related to the d-pointer pattern that INDI is using? Or is it some glitch in Xcode and maybe I need to have some setting different so this compiles poperlt?

Thanks for you looking at this.
Bill

Read More...

Still hoping to get a reply to this question. This seems really basic to writing an INDI client. The BaseDevices returned in newDevice() or getDevices()don't seem to be fully populated until some unspecified time later.

Is this supposed to work? Am I just using this wrong? Is there a bug in the INDI client library?

Thanks,
Bill

Read More...

I edited my text to fix a typo, and when I submitted it again it lost the <code></code> formatting. Seems like a bug in the message board system.

Read More...

This seems like a really basic question, but it has me stumped.

In my BaseClient subclass, I'm trying to get a list of all the Telescope and Cameras registered with the server. If I have this code:

void IndiClient::newDevice(INDI::BaseDevice baseDevice)
{
    auto interface = baseDevice->getDriverInterface();
    if (interface == INDI::BaseDevice::TELESCOPE_INTERFACE)
    {
        IDLog("New Device: %s\n", baseDevice->getDeviceName());
    }
}

The interface always comes back as 0 (GENERAL_INTERFACE). I never get anything specific.

I've also tried using getDevices() after receiving the serverConnected() notification:
void IndiClient::serverConnected()
{
    IDLog("Server Connected\n\n");    
    
    IDLog("Listing mounts:\n");
    std::vector<INDI::BaseDevice> mounts;
    getDevices(mounts, INDI::BaseDevice::TELESCOPE_INTERFACE);
    for (INDI::BaseDevice *device : mounts)
        printf("Mount Name: %s\n", device->getDeviceName());
    
    IDLog("Listing cameras:\n");
    std::vector<INDI::BaseDevice> cameras;
    getDevices(cameras, INDI::BaseDevice::CCD_INTERFACE);
    for (INDI::BaseDevice *device : cameras)
        printf("Camera Name: %s\n", device->getDeviceName());
}

This doesn't return any mounts or cameras. However, if I wait a second of so after connecting and make the getDevices() calls, then it works. But it is unclear how long I need to wait for the info be be valid.

How am I supposed to accomplish what I need?

Read More...

In addition to my original question of why starting the Web Manager fails the first time, could someone please explain why the Web Manager is needed? If I change my profile to not use the web server, Ekos always fails to connect to the INDI server on my remote Rpi4.

The docs say this:

INDI Web Manager is a simple Web Application to manage INDI server. It supports multiple driver profiles along with optional custom remote drivers. It can be used to start INDI server locally, and also to connect or chain to remote INDI servers. It is especially useful to install on remote Raspberry PIs installations where you can easily startup INDI server without needing to SSH into the device. Furthermore, the Web Manager provides a RESTful API where you can issue simple calls to start and stop INDI services over the network.

This implies the Web Manger needs to be used to start the INDI server on the remote device. Isn't there some way to have the INDI server automatically startup when the RPi boots? That would eliminate the need for it in most cases.

Read More...

And if I do enable that option, connecting to the Web Manager still fails the first time.

Read More...