QHYCCD

Comments on the newest (V20190122_0.tgz) SDK

Comments on the newest (V20190122_0.tgz) SDK
« on: February 03, 2019, 05:27:24 AM »
I'm developing matlab wrappers for a QHY367 on ubuntu 16, I will probably report about and share in another post, when things are more cleaned up.

Here, however, to start with, are a couple of comments about what bothers me in the latest SDK, which I'm trying.
  • the SDK comes in the form of a .tgz which has to be extracted in /. This is BAD. I would prefer a clean way to install, track and uninstall it, e.g. a .deb package
  • libqhyccd.so "forgets" to declare its dependency from libusb-1.0, as can be seen from readelf -d /usr/local/lib/libqhyccd.so. Several symbols from libusb are needed and undefined, as clear from nm -D /usr/local/lib/libqhyccd.so | grep "U libusb". This leaves as only option (IIUC) to set LD_PRELOAD=/lib/x86_64-linux-gnu/libusb-1.0.so.0 before using executables (matlab I mean here) which call the library as external.

Re: Comments on the newest (V20190122_0) SDK
« Reply #1 on: February 03, 2019, 10:03:03 AM »
I'd report here some coding pearls as I find them. Considering that I found no full documentation of the SDK, that usage is to be understood from looking at code examples, and, as I read on the threads, hoping that they really work, I think it makes sense to mention them. #1: /usr/local/testapp/SingleFrameMode/SingleFrameMode.cpp, lines 119-139

Code: [Select]
    // get overscan area
    retVal = GetQHYCCDOverScanArea(pCamHandle, &overscanStartX, &overscanStartY, &overscanSizeX, &overscanSizeY);
...
    // get effective area
    retVal = GetQHYCCDOverScanArea(pCamHandle, &effectiveStartX, &effectiveStartY, &effectiveSizeX, &effectiveSizeY);
...

Re: Comments on the newest (V20190122_0.tgz) SDK
« Reply #2 on: February 04, 2019, 03:07:51 AM »
qhyccd.h defines three prototypes of OSX.... functions and one SetQHYCCDQuit() which are not found in libqhyccd.so.4.0.12. No harm but comes in the way when making automatic imports.

Re: Comments on the newest (V20190122_0.tgz) SDK
« Reply #3 on: February 04, 2019, 03:15:16 AM »
/usr/local/testapp/SingleFrameMode/SingleFrameMode.cpp, lines 243-245
Code: [Select]
        retVal = SetQHYCCDBitsMode(pCamHandle, 16);
        if (QHYCCD_SUCCESS == retVal) {
            printf("SetQHYCCDParam CONTROL_GAIN set to: %d, success.\n", CONTROL_TRANSFERBIT);
sloppy copy-paste. Again, no harm, but.

Re: Comments on the newest (V20190122_0.tgz) SDK
« Reply #4 on: February 04, 2019, 06:44:34 AM »
Code: [Select]
#include "config.h" in the four .h files, while the file is not in /usr/local/include/. Maybe I'm missing an obvious dependency, or an obvious prebuild command which should resolve it, but being that so, I can't build e.g. SingleFrameMode.cpp

Re: Comments on the newest (V20190122_0.tgz) SDK
« Reply #5 on: February 04, 2019, 10:07:14 AM »
/usr/local/testapp/SingleFrameMode/LiveFrameSample.cpp, line 5
Code: [Select]
#include <libqhy/qhyccd.h>might want to be
Code: [Select]
#include "../../include/qhyccd.h"or
Code: [Select]
#include <qhyccd.h>
Ditto in LINUX_LiveMaxFpsTest.cpp from https://www.qhyccd.com/html/test_version/QHYCCD_SDK/tools/LINUX_test_max_fps_demo.tgz
« Last Edit: February 13, 2019, 03:51:18 AM by Enrico Segre »

Re: Comments on the newest (V20190122_0.tgz) SDK
« Reply #6 on: February 06, 2019, 11:02:46 AM »
A positive note at least: the QHY367 which I'm testing worked at high speed, out of the box, when plugged to an USB3 port, at least on one ubuntu18 host. It didn't on an older host with and ubuntu16, but that may be a specific problem of the older motherboard/OS. That is, the fxload step described here seems to have been now correctly incorporated in the udev rules.

Re: Comments on the newest (V20190122_0.tgz) SDK
« Reply #7 on: February 12, 2019, 11:11:14 AM »
Well, here are a few more. Tests have been done via my Matlab wrappers, with the combination QHY367c/USB2/Matlab 2015b/Ubuntu16/SDK v19.1.22.0. Now I would even be happy of sharing my github project with the world, but alas, I'm not yet going to do that at this state of support.

  • SetQHYCCDBinMode(camhandle,xb,yb) returns error 0xFFFFFFFF only for a few incongrous modes with xb=yb (e.g., 3,3). It returns 0 for any other combination of xb and yb, e.g. SetQHYCCDBinMode(camhandle,1672,433)==0.
  • GetQHYCCDParam(camhandle,param) returns error 0xFFFFFFFF for all four binning modes, i.e. qhyccdControl.CAM_BIN1X1MODE, qhyccdControl.CAM_BIN2X2MODE, qhyccdControl.CAM_BIN3X3MODE, qhyccdControl.CAM_BIN4X4MODE
  • The dimensions reported by GetQHYCCDOverScanArea() are unclear. In fact the numbers returned are actually the same as those of GetQHYCCDEffectiveArea() (but once I saw something even less logical -- probably depending on some other mode-setting call).
  • The functional difference between SetQHYCCDParam(camhandle,qhyccdControl.CONTROL_TRANSFERBIT,bp) and SetQHYCCDBitsMode(camhandle,bp) is not explained. Moreover neither function returns errors if bp is any number different than 8 or 16. It is not clear which one of the two if not both have to be set consistently for a correct acquisition, and I suspect that ExpQHYCCDSingleFrame crashes if they are not.
  • If color mode is set (that is SetQHYCCDDebayerOnOff(camhandle,true)) and transfer mode is 16 bit, acquisition segfaults in _ZN7QHYBASE14QHYCCDDemosaicEPvjjjS0_h. Ok, it is stated in here and here, but seriously, it should be handled more gracefully
  • The organization of pixels in the image buffer, when in 8bit/color mode w/o binning, is different from images returned in single frame and in live mode. I'm not always able to make sense of it. In single frame in particular, the organization seems to be differently wrong (e.g. image split and reinterleaved, buffer only partially filled) when the mode is changed.
  • In bw mode, overscan ignored, the buffer still has black bands -- only, instead of a single vertical band on the left of the image, the black is half at the left and half at the right (in live mode but not in single exp mode). The upper four black lines are not removed though.
  • The return value of GetQHYCCDParamMinMaxStep(camhandle,parameter) may be 0 even for non supported parameters.
  • GetQHYCCDMemLength(camhandle) returns always 110023200 no matter binning, color mode, ROI, overscan, resolution set (SetQHYCCDResolution) no matter whether called before or after acquisition is started. Ok, said here. But alas, that is unreasonable, and doesn't help dimensioning correctly the image buffer. Setting always max can turn out wasteful.
  • There is no function like a GetQHYCCDResolution(). "Resolution" (in fact ROI) can only be set. But without a way to read it back, there is no basis for allocating correctly the image buffer for image transfers. Recipe for segfaults. The fact that GetQHYCCDSingleFrame() and GetQHYCCDLiveFrame() return the image size is irrelevant because the buffer has to be allocated before their call.
  • GetQHYCCDSingleFrame() often hangs, I suppose if called after a change in one parameter which affects the image buffer size
  • if Texp<Ttransfer, GetQHYCCDLiveFrame() returns all the time error 0xFFFFFFFF after the second frame. That looks as if, by bad design, GetQHYCCDLiveFrame() is supposed to return the same return code both for "image not yet fully transfered into framebuffer", and "framebuffer full". Ideally that should not happen, the framebuffer should be circular, and the last available frame should be returned even if intermediate frames are lost.
« Last Edit: February 12, 2019, 11:13:23 AM by Enrico Segre »

QiuHY

  • *****
  • 5000
    • View Profile
    • Email
Re: Comments on the newest (V20190122_0) SDK
« Reply #8 on: February 14, 2019, 09:00:26 AM »
I'd report here some coding pearls as I find them. Considering that I found no full documentation of the SDK, that usage is to be understood from looking at code examples, and, as I read on the threads, hoping that they really work, I think it makes sense to mention them. #1: /usr/local/testapp/SingleFrameMode/SingleFrameMode.cpp, lines 119-139

Code: [Select]
    // get overscan area
    retVal = GetQHYCCDOverScanArea(pCamHandle, &overscanStartX, &overscanStartY, &overscanSizeX, &overscanSizeY);
...
    // get effective area
    retVal = GetQHYCCDOverScanArea(pCamHandle, &effectiveStartX, &effectiveStartY, &effectiveSizeX, &effectiveSizeY);
...


Hello,

       That's you very much to point these point.These days we are do some improvement of the LINUX SDK and ready for the PRI3. So we will solve the issue you said at the same time.

       And to learn how to use the SDK. We have a demo software which should give you more idea. Espcially the function calling sequence. You can find it at https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=127&id=166


Best regards,
Qiu Hongyun
Qiu Hongyun