erik's profile

Hey, I figured it out. Was, in fact, just my own lack of experience.
So, there is this BaseClientQt for a reason when using Qt and QThread. Switched over to that one from BaseClient and now it works like a charm!

Cheers
Erik

Read More...

Hey,

so I'm having some weird thread behavior, or at least it seems weird to me. I don't have too much experience with threads yet.

I made my client inherite from QObject and BaseClient to have it emit signals etc. (I'm aware that I could have used QtBaseClient, but when I started writing my code, there was no need to use Qt and now its a little too complex to change with low effort and no real need)

class cl_SacherClient : public QObject, public INDI::BaseClient
{
    Q_OBJECT
    
  public:
[....]
};

My client is child of the GUI.

QApplication app (argc, argv);
sacher::cl_SacherGUI* gui = new sacher::cl_SacherGUI;
std::unique_ptr<sacher::cl_SacherClient> client_ptr(new sacher::cl_SacherClient(gui));

So my problem is that the construction of GUI and client is all in one thread, everything fine so far, but than the newDevice, newAnything functions seem to be called from another thread which troubles me as I am constructing new QActions in the GUI (so this QActions will be children of the GUI due to clean up etc...) depending on the arrival of new basedevices. But the children-parent assignment doesn't work since the GUI is still in the first thread and children and their parent must live in the same thread as Qt states. Which results in these errors:

QObject: Cannot create children for a parent that is in a different thread.
(Parent is sacher::cl_SacherGUI(0x5594e6af8ca0), parent's thread is QThread(0x5594e6b498a0), current thread is QThread(0x7f1f1c002060)
QObject: Cannot create children for a parent that is in a different thread.
(Parent is sacher::cl_SacherGUI(0x5594e6af8ca0), parent's thread is QThread(0x5594e6b498a0), current thread is QThread(0x7f1f1c002060)
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread

Plus, for every "newDevice" I receive I construct an object representing this object, much like a layer in between mostly for convenience. And these object are than also constructed in the second thread, which is not so severe as the first issue, but somewhat annoying.

So my question goes something like this: Is this normal behavior? If not, how could I solve this issue? If yes, what would be the workaround for the "children-parent-different thread" problem? Using QObject::moveToThread() for each QAction I add, which seems kinda quick and dirty to me?

It seems to me, like this could be normal since the client and GUI are created in my main.cpp, thus living in the main thread. But, of course, the newSomething functions are called from somewhere else (?). But than, how would that work? Is it thread-safe? (Again, I don't have too much experience with threads, please forgive me if I'm assuming weird things here)

Ubuntu 18.04.3 LTS
INDI Library: 1.8.2
Code 1.8.2-tgz. Protocol 1.7.
Qt: 5.9.5
KDE Frameworks: 5.44.0

Read More...

Hey,
it's pretty much the title. I can't figure out what devices I'm receiving. Of course I know, but my client only sees, driver interface is 0, so it's useless. Am I doing anything wrong?

void client::newDevice(INDI::BaseDevice* dp)
{
  log("CLI:\tnew device: %s", dp->getDeviceName());
  
  uint16_t driver_interface = dp->getDriverInterface();
  log("driver_interface: %d", driver_interface);
  if( driver_interface & INDI::BaseDevice::DRIVER_INTERFACE::TELESCOPE_INTERFACE )
  {
    if (int_telescope==NULL && ( !strcmp(dp->getDeviceName(), TELE) || !strcmp(dp->getDeviceName(), TELE_SIM) ))
    {
      log("CLI:\tReceived Telescope:\t%s...", dp->getDeviceName());
  //     telescope = dp;
      int_telescope = new cl_TelescopeInterface(dp, this);
    }
    else if(int_telescope==NULL && !strcmp(dp->getDeviceName(), TELE_STAN))
    {
      log("CLI:\tReceived Telescope:\t%s...", dp->getDeviceName());
  //     telescope = dp;
  //     int_telescope = new cl_TelescopeInterface(dp, this);
      int_telescope = new cl_TelescopeHondelage(dp, this);

    }
    
    connect(int_telescope, SIGNAL(reachedTarget()), this, SLOT(reachedTarget()));
//     connect(int_telescope, SIGNAL(reachedTarget()), this, SLOT(setNewTransit()));
    connect(int_telescope, SIGNAL(reachedTarget()), this, SLOT(writeImageInfo2File()));
    connect(int_telescope, SIGNAL(slewingError()), this, SLOT(slewingError()));
  }
  else if( driver_interface & INDI::BaseDevice::DRIVER_INTERFACE::CCD_INTERFACE)
  {
    addCamera(dp);
  }
  else if( driver_interface & INDI::BaseDevice::DRIVER_INTERFACE::AUX_INTERFACE)
  {
    if (int_joystick==NULL && (!strcmp(dp->getDeviceName(), JOYSTICK)))
    {
      log("CLI:\tReceived Joystick:\t%s...", dp->getDeviceName());
      int_joystick = new cl_JoystickWingman(dp, this);
    }
}
  }

that second log statement always returns zero. I tried so far a few simulator drivers and the lx200gps and they all returned zero when asked for their interface.

Thanks in advance!

Cheers
Erik

INDI Library: 1.8.2
Code 1.8.2-tgz. Protocol 1.7.

Read More...

Thanks. So summerize things up:
- INDI still misses the capability to differentially track satellite, we can make up for that by leapfrogging along the satellites pass, for once.
- KStars can show satellites on screen, you can select them and drive towards their current position, but there is no tracking, neither differentially nor leapfrogging. For leapfrogging you'd have to slew onto a future position which is not possible at the moment.
- No automated imaging of satellite when in FOV

So, to get things started, it might be interesting to implement the leapfrogging. I'm not too deap into KStars and Eko, so where would I want to add this feature? Make another Ekos tab?

During my work as scientific student here at the TU Braunschweig, I wrote a standalone program, using INDI, to "measure" satellites orbits via leapfrogging, given a telescope and a camera as equipment. But the complexity increases somewhat drastically with added functionality, and using KStars/Ekos, with its many already existing functions, such as taking Dark Images, etc, might be the logical next step.

I'd be happy to contribute something, although I'm just a mechanical engineering student , all I know about programming is what I taught myself.

Cheers
Erik

Read More...

I'm curious. What is the current state of INDI concerning satellite tracking? And with regards to KStars, since it relies on INDI, does somebody know what that is able to?

I'm asking here, because this thread already existed and I didn't want to start an entire discussion from scratch just for my curiosity.

Cheers
Erik

Read More...

han.k wrote:
The FITS standard 4.0 specifies this:
[±C]CCYY-MM-DD[Thh:mm:ss[.s...]]

So four digits, accuracy 0.1ms.

To me, the 4.0 standard doesn't read as if it was restricted to 3 or 4 decimal places. I'm aware of the fact that 6 decimal places might be far from reality, but for instance would a INumberProperty be sufficient to state the number of decimal places that are written to the FITS header?

Concerning the actual definition of the timestamp, whether it is the starting point or somewhere in the middle of the exposure, I guess you have to know what the program wrote when making the FITS. Am I right when assuming, that INDI generally states that to be the beginning?

And how accurate should you be on mid exposure of a long exposure?

Paul

Well, of course, generally the longer the exposure the less relevant is the accuracy of the timestamp, but I want to image satellites and measure their orbit. Thus using exposure times of approx. 0.1 seconds. Assuming an average speed of 7 km/sec, I'd like to have the uncertainty as low as possible.

As Han pointed out 0.1 ms would be already quite good, but is yet not implemented in INDI indiccd missing one decimal place. If this collides with other programs, would it be possible to use MJD-BEG, MJD-AVG or MJD-END? I'd be happy to do the implementation and make the PR.

Same goes for the altitude, might be not too interesting when imaging stars and planets, but for me, knowing I can later read all the information I need from the FITS header makes it somewhat simpler to lay out the over all schedule of measurering satellite orbits.

Cheers
Erik

Read More...

Hey,

would be awesome if the DATE-OBS seconds would be logged up to the 6th decimal place (minimum). I know, off-the-shelf cameras don't support this accuracy, once there is a camera that support this, that would be awesome. Precise timestamps could be possible using digital I/O. Have a look f. i. here Using Trigger and Digital I/Os .

Secondly, would be awesome if the altitude/height of the observer could be added to the keywords.

Thanks in advance.
Cheers
Erik

Read More...

Got it. I used

find_package(INDI REQUIRED v4l driver)

instead of

find_package(INDI REQUIRED)

.
Although I don't seem to get why this works since the latter should link to all indi libraries, not?

Read More...

I did. Still undefined references, though.

[ 50%] Linking CXX executable indi_v4ltis_ccd
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::V4LTISCCD()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:157: undefined reference to `V4L2_Driver::V4L2_Driver()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::~V4LTISCCD()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:162: undefined reference to `V4L2_Driver::~V4L2_Driver()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::initProperties()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:174: undefined reference to `V4L2_Driver::initProperties()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISGetProperties(char const*)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:182: undefined reference to `V4L2_Driver::ISGetProperties(char const*)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISNewSwitch(char const*, char const*, ISState*, char**, int)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:187: undefined reference to `V4L2_Driver::ISNewSwitch(char const*, char const*, ISState*, char**, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISNewText(char const*, char const*, char**, char**, int)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:192: undefined reference to `V4L2_Driver::ISNewText(char const*, char const*, char**, char**, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISNewNumber(char const*, char const*, double*, char**, int)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:197: undefined reference to `V4L2_Driver::ISNewNumber(char const*, char const*, double*, char**, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::updateProperties()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:202: undefined reference to `V4L2_Driver::updateProperties()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x98): undefined reference to `V4L2_Driver::saveConfigItems(_IO_FILE*)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0xf0): undefined reference to `V4L2_Driver::StartExposure(float)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x100): undefined reference to `V4L2_Driver::AbortExposure()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x118): undefined reference to `V4L2_Driver::UpdateCCDFrame(int, int, int, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x128): undefined reference to `V4L2_Driver::UpdateCCDBin(int, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x180): undefined reference to `V4L2_Driver::StartStreaming()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x188): undefined reference to `V4L2_Driver::StopStreaming()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x1a8): undefined reference to `V4L2_Driver::initCamBase()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x1b0): undefined reference to `V4L2_Driver::getBasicData()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTV9V4LTISCCD[_ZTV9V4LTISCCD]+0x1b8): undefined reference to `V4L2_Driver::updateV4L2Controls()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o:(.data.rel.ro._ZTI9V4LTISCCD[_ZTI9V4LTISCCD]+0x10): undefined reference to `typeinfo for V4L2_Driver'
collect2: error: ld returned 1 exit status
CMakeFiles/indi_v4ltis_ccd.dir/build.make:98: recipe for target 'indi_v4ltis_ccd' failed
make[2]: *** [indi_v4ltis_ccd] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/indi_v4ltis_ccd.dir/all' failed
make[1]: *** [CMakeFiles/indi_v4ltis_ccd.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

Oh, and the branch on the indi-3rdparty fork I'm working with is github.com/emktubs/indi-3rdparty/tree/v4l_tis_expansion

Read More...

I just pushed it all. Sorry.

It's not yet much what I did. I only took the generic ccd and used it as template to inherit from v4l2_driver.

Read More...

github.com/emktubs?tab=repositories

Thanks!
Erik

Read More...

Hey, thanks for the hint with the lx200 library.

I had a look at that and tried to do it similar, I changed the CMakeLists.txt accordingly and adapted the FindINDI.cmake in indi-3rdparty as well, but I seem to have been missing something, 'cause the newly written driver inheriting from V4L2_Driver does not link to the created library. Undefineed references to all member function..

CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::V4LTISCCD()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:157: undefined reference to `V4L2_Driver::V4L2_Driver()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::~V4LTISCCD()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:162: undefined reference to `V4L2_Driver::~V4L2_Driver()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::initProperties()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:174: undefined reference to `V4L2_Driver::initProperties()'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISGetProperties(char const*)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:182: undefined reference to `V4L2_Driver::ISGetProperties(char const*)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISNewSwitch(char const*, char const*, ISState*, char**, int)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:187: undefined reference to `V4L2_Driver::ISNewSwitch(char const*, char const*, ISState*, char**, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISNewText(char const*, char const*, char**, char**, int)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:192: undefined reference to `V4L2_Driver::ISNewText(char const*, char const*, char**, char**, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::ISNewNumber(char const*, char const*, double*, char**, int)':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:197: undefined reference to `V4L2_Driver::ISNewNumber(char const*, char const*, double*, char**, int)'
CMakeFiles/indi_v4ltis_ccd.dir/v4ltis_ccd.o: In function `V4LTISCCD::updateProperties()':
/home/erik/indi-3rdparty/indi-v4ltis/v4ltis_ccd.cpp:202: undefined reference to `V4L2_Driver::updateProperties()'

Anyway, here are the changes I made to build the v4l library:

########### INDI::CCD V4L Driver ###############
IF (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
    SET(v4l2driverccd_SRC
        ${CMAKE_CURRENT_SOURCE_DIR}/libs/lx/Lx.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/drivers/video/v4l2driver.cpp
        ${CMAKE_CURRENT_SOURCE_DIR}/drivers/video/indi_v4l2driver.cpp)

    IF (UNITY_BUILD)
        ENABLE_UNITY_BUILD(v4l2driverccd v4l2driverccd_SRC 10 cpp)
    ENDIF ()

    add_library(indiv4l SHARED ${v4l2driverccd_SRC} ${libwebcam_C_SRC} ${libwebcam_CXX_SRC})
    set_target_properties(indiv4l PROPERTIES VERSION ${CMAKE_INDI_VERSION_STRING} SOVERSION ${INDI_SOVERSION} OUTPUT_NAME indiv4l)
    add_executable(indi_v4l2_ccd ${v4l2driverccd_SRC} ${libwebcam_C_SRC} ${libwebcam_CXX_SRC})
    target_link_libraries(indi_v4l2_ccd ${JPEG_LIBRARY} indidriver)
    install(TARGETS indi_v4l2_ccd RUNTIME DESTINATION bin )

    install(TARGETS indiv4l LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR})
    install(FILES
        ${CMAKE_CURRENT_SOURCE_DIR}/drivers/video/v4l2driver.h
        ${CMAKE_CURRENT_SOURCE_DIR}/libs/lx/Lx.h
        DESTINATION ${INCLUDE_INSTALL_DIR}/libindi COMPONENT Devel)

    install(FILES
        ${CMAKE_CURRENT_SOURCE_DIR}/libs/webcam/v4l2_base.h
        DESTINATION ${INCLUDE_INSTALL_DIR}/libindi/webcam COMPONENT Devel)
    
    install(FILES
        ${CMAKE_CURRENT_SOURCE_DIR}/libs/webcam/v4l2_decode/v4l2_decode.h
        DESTINATION ${INCLUDE_INSTALL_DIR}/libindi/v4l2_decode COMPONENT Devel)

    # For DBK21 camera
    install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/drivers/video/80-dbk21-camera.rules DESTINATION ${UDEVRULES_INSTALL_DIR})


ENDIF ()

I did include that into the paragraph of the v4l driver.
As for the FindINDI.cmake I just added this line

INDI_declare_component(v4l  indiv4l)

To my understanding, shoudn't be the v4l library now be included into the INDI_LIBRARIES variable in cmake? I seem to be missing something obvious.

Cheers
Erik

PS.: Once it works, shall I do a pull request?

Read More...