Hi All,

Just a quick question. I'm slightly confused with setting the mount's date and time via the standard property "TIME_UTC". Currently, I'm setting the "UTC type" to the current UTC time and then setting the "OFFSET type" to whatever the user's timezone offset is. For example, in the United Kingdom, I set this to zero., France it's set to +1 and for Perth it's set to +8.

My question is: Do I need to factor daylight saving into the OFFSET value? For example, in the United Kingdom, do I need to set OFFSET to +1 when in daylight saving or do I just leave the OFFSET at zero and set the "UTC type" to the current UTC time and not factor daylight saving into it at all?

Many thanks
Amanda

Read More...

There seems to be a problem building INDI 1.9.9 on Windows with MSYS2. My build environment is as follows:

  1. MSYS2 - Mingw64 and,
  2. MSYS2 - clang64.
  3. ucrt64 and clang64 environments

After running cmake and then mingw32-make the build fails with:
indi\libs\indidevice\indiutility.cpp:49:51: error: too many arguments to function 'int mkdir(const char*)'

This appears to be caused by mkdir() requiring one parameter when there are two parameters at line 49 of indiutility.cpp. I have "fixed" this problem by making the following change:
    // Remove mode_t from mkdir()
    if (errno != ENOENT || ((mdret = mkdir(dir.c_str())) && errno != EEXIST))
     {
           return mdret;
      }

Is this an acceptable fix?

Amanda

Read More...

Thanks Kevin. I appreciate your help.

Read More...

Hi Kevin and thanks for your response.

I've just had a look at IBLOB::format but this just contains ".fits" and not the pixel format information such as "RAW-8, RAW16 etc".

Any other ideas?

Amanda.

Read More...

Hi,

I'm attempting to add INDI support into my capture application. Currently, I have INDI mounts, filter wheels and focus devices working well but I am having various problems with implementing INDI cameras. The most significant problem is as follows:

Description of the Problem

My application needs to know various pieces of information before it can start to receive and process image data. The information needed are things like width, height, capture format and whether the camera is operating in 8 or 16-bit mode. This information is required so that I can size memory buffers and correctly save image data in various different image types (TIFF, PNG, FITS etc). I am able to reliable get the width and height values from CCD_FRAME, and the bit depth value from CCD_INFO / CCD_BITSPERPIXEL. My problems start when I attempt to discover the current capture format.

I have a block of code in newProperty(INDI::Property *property) which is supposed to hold a pointer to the CCD_CAPTURE_FORMAT property. Whilst this works for many INDI camera drivers, it does not work for all of them. The code looks something like this:

void indi_cam::newProperty(INDI::Property *property)
{
        string prop_name(property->getName());
 
       	INDI::BaseDevice *bd = property->getBaseDevice();
	if (bd->getDriverInterface() & INDI::BaseDevice::CCD_INTERFACE)
	{
                if ((prop_name == "CCD_CAPTURE_FORMAT"))
		{
                       m_svp_capture_format = property->getSwitch();
                }
        }
}

The problem that I am having is that some INDI drivers never offer the CCD_CAPTURE_FORMAT property and so m_svp_capture_format is often null. Just to be clear, this is not the case with all INDI Drivers. For example, CCD_CAPTURE_FORMAT works as expected for Atik and QHY drivers but not for Touptek or ZWO. I have, however, discovered a strange workaround that works in all cases. The workaround is detailed below.

Workaround

If I discover that CCD_CAPTURE_FORMAT is null, I programmatic create a new INDI instance and then connect that instance to the INDI server and then disconnect it and destroy the instance. Once I do this, newProperty(INDI::Property *property) runs again but this time CCD_CAPTURE_FORMAT is available which I can then use m_svp_capture_format in the normal way.

I discovered this accidentally by connecting another INDI application (phd2) to the same server whilst my application was attempting to check for the availability of CCD_CAPTURE_FORMAT. I noticed as I connected phd2 that CCD_CAPTURE_FORMAT suddenly became available.

Although this workaround serves the purpose, it's clearly not idea. Does anybody know how I can ensure that CCD_CAPTURE_FORMAT becomes available without having to use this workaround? Many of the cameras that I am using for the implementation have multiple capture formats (example, Mono, Raw-8, Raw-16, RGB24 etc). It's vital that I know the capture format reliably so that buffers can be sized and decisions about data processing can be made. An obvious example here would be to know if the image data needs to be passed through my debayering algorithms.

Just for a little more information. I attempted to discover the existence of CCD_CAPTURE_FORMAT by using the following code. The results were the same, that is CCD_CAPTURE_FORMAT property was null but becomes available if another instance is connected to the same INDI server.
if(m_base_device != nullptr)
{
    ISwitchVectorProperty *svp = m_base_device->getSwitch("CCD_CAPTURE_FORMAT");
    if(svp == nullptr)
    {
         throw std::runtime_error("CCD_CAPTURE_FORMAT is null");
    }
}

Thanks for reading and if you need further information then please ask. I may have other questions but this is the most important one for now.

Amanda,

Read More...

Hi,

I am currently implementing INDI functionality into my capture application. I have most of the functionality working but I am confused by the Right Ascension value that I am receiving from the Telescope Simulator. I am getting the RA and DEC values by using the following code:

INumber *raprop = IUFindNumber(m_prop_eq_coord, "RA");
INumber *decprop = IUFindNumber(m_prop_eq_coord, "DEC");
std::cout << "RA = raprop.value << " DEC = decprop.value << std::endl;

The code snippet above gives me the coordinates that the mount is currently pointing at in decimal. The Declination value is correct but the Right Ascension value appears to be way off. For example, I slew the Telescope Simulator to Messier 1 which has a RA value of +83.63308 but the value that comes from the code above is 5.50327 which is quite difference. I know the simulator is pointing at the correct part of the simulated sky because I have saved an image and plate solved it. I first noticed this problem when trying to convert the RA value to HH::MM:SS.

I'm clearly doing something wrong or misunderstanding something. Is there some special conversion that I need to do to the RA value coming from the code above?
Amanda

Read More...