Linux SDK and ASI120MC bug?

caracol_uk

Hi all,

I've written my own image capture application using the Linux SDK to control an ASI120MC. In general everything is working fine, but I have noticed an issue which seems to occur if I take a long exposure (1s or longer) without first commanding the camera to take a short exposure (I'm using 100us). I've tried with Linux SDK versions v0.4.0929 and v0.6.0328 and the problem occurs with both. Here is a summary of what my code does to generate the problem:

ASIOpenCamera(CamNum);

ASIInitCamera(CamNum);

ASISetROIFormat(CamNum, width, height, bin, (ASI_IMG_TYPE)Image_type);

ASISetControlValue(CamNum, ASI_GAMMA, gammavar, ASI_FALSE);

ASISetControlValue(CamNum, ASI_GAIN, gain, ASI_FALSE);

ASISetControlValue(CamNum, ASI_BANDWIDTHOVERLOAD, 40, ASI_FALSE);

ASISetControlValue(CamNum, ASI_WB_R, wbr, ASI_FALSE);

ASISetControlValue(CamNum, ASI_WB_B, wbb, ASI_FALSE);

ASISetControlValue(CamNum, ASI_EXPOSURE, 2000000, ASI_FALSE);

ASIStartExposure(CamNum, ASI_FALSE);

usleep(10000);

while((status == ASI_EXP_WORKING)

{

ASIGetExpStatus(CamNum, &status);

}

if(status == ASI_EXP_SUCCESS)

{

ASIGetDataAfterExp(CamNum, (unsigned char*)pRgb->imageData, pRgb->imageSize);

}

This will work fine for a while, but usually after a few minutes it will fails with the status set to ASI_EXP_FAILURE. Now if I do the following instead it will actually work fine:

ASIOpenCamera(CamNum);

ASIInitCamera(CamNum);

ASISetROIFormat(CamNum, width, height, bin, (ASI_IMG_TYPE)Image_type);

ASISetControlValue(CamNum, ASI_GAMMA, gammavar, ASI_FALSE);

ASISetControlValue(CamNum, ASI_GAIN, gain, ASI_FALSE);

ASISetControlValue(CamNum, ASI_BANDWIDTHOVERLOAD, 40, ASI_FALSE);

ASISetControlValue(CamNum, ASI_WB_R, wbr, ASI_FALSE);

ASISetControlValue(CamNum, ASI_WB_B, wbb, ASI_FALSE);

ASISetControlValue(CamNum, ASI_EXPOSURE, 100, ASI_FALSE);

ASIStartExposure(CamNum, ASI_FALSE);

usleep(10000);

while((status == ASI_EXP_WORKING)

{

ASIGetExpStatus(CamNum, &status);

}

ASISetControlValue(CamNum, ASI_EXPOSURE, 2000000, ASI_FALSE);

ASIStartExposure(CamNum, ASI_FALSE);

usleep(10000);

while((status == ASI_EXP_WORKING)

{

ASIGetExpStatus(CamNum, &status);

}

if(status == ASI_EXP_SUCCESS)

{

ASIGetDataAfterExp(CamNum, (unsigned char*)pRgb->imageData, pRgb->imageSize);

}

The code above is summarised to show the general order of what I'm doing. Has anybody else seen this behaviour? Any ideas would be appreciated.

Regards

Simon

yang

I've fixed a bug in the SDK, please try this new version, thank you.

https://astronomy-imaging-camera.com/software/ASI_linux_mac_SDK_V0.6.0414.tar.bz2

caracol_uk

Thanks Yang. I shall test the new version and report back with the results.

Simon

caracol_uk

Hi Yang,

I've updated the SDK version on my Raspberry Pi and after carrying out initial testing the new code does seem a lot better. The first exposure still fails, but subsequent exposures then work fine. Further testing has revealed that if I cause the code to wait for 100ms straight after setting the exposure value on the camera, I don't get the failures at all. So by inserting the usleep command as follows, the problem seems to go away:

ASISetControlValue(CamNum, ASI_EXPOSURE, 5000000, ASI_FALSE);

usleep(100000);//100ms

ASIStartExposure(CamNum, ASI_FALSE);

I'm not quite sure why, but with the new version of the SDK an exposure of the same value as before seems not quite as bright as with version 0.4.0929. That's not a problem, just an observation.

Will this new version be added to the website?

Thanks

Simon

caracol_uk

I'm keeping a close eye on how the updated SDK is behaving and I've noticed two issues:

1: There seems to be a higher number of corrupt images than with v0.4.0929. These corrupt images appear fine in the top half of the image, but the bottom half appears with a grid pattern (perhaps not debayered) and is a duplicate of the top half. I've had 2 of these in the past hour and I'm taking 1 image every 60s. Before I would get one or two a week.

2: Every time an image is captured I see the following message in the messages log:

usb 1-1.5: reset high-speed USB device number 5 using dwc_otg

That suggests the camera is being reset every time an exposure is taken. That would be quite time consuming so is likely to cause additional delay between exposures. It also clutters the messages file and adds to wear and tear on the raspberry Pi SDcard. Besides, it just doesn't seem like that's a good thing to be happening.

Simon

yang

I'll release it on our website soon.

I'll test the problem of more corrupt images with this version.

Yes, our code resets the device during erery exposure.

caracol_uk

I've discovered another issue that affects all recent sdk versions. If a long exposure is collected, let's say 20s followed by a short exposure (lets say 10ms), the short exposure will be brighter than it should be. To test the rightness I convert the image to monochrome and determine the average intensity. To workaround the problem it's necessary to make the camera expose 3 or so short exposures, at which point the intensity has returned to what it should be.

Regards

Simon

caracol_uk

Sorry to add to the list of bugs but it seems that the average brightness issue isn't the only problem switching from long exposures to short exposures. I carried out a 20s exposure on the ASI120MC and then set the camera to collect several 100us exposures. The first 100us exposure sometimes succeeds, but subsequent 100us exposures then fail. When this happens it seems necessary to reboot before the camera can take exposures again. Even attempts to read out the camera sensor temperature fail as the value appears as 0.

If instead of using 100us exposures I set the exposure value to 100ms the problem does not occur.

Hopefully this should be an easy problem to reproduce.

Simon

caracol_uk

In an attempt to workaround the issues I've described above I've discovered that an alternative solution may be to call ASIInitCamera before switching from a long to short exposure. This is a technique I employed successfully in SDK 0.4.0929. In the latest version this results in a memory leak. It would seem that a separate thread is created when ASIInitCamera is called. I suspect it has been called using the default attributes by pthread_create which would render the thread joinable. Since the memory leak exists it's likely that no pthread_join is later called to reclaim the memory.

While the described use of ASIInitCamera is a workaround, it would be great if this issue could be resolved by adding a call to pthread_join to free up the resources. Alternatively, setting the detached attribute on the pthread_create call would also work.

Simon

caracol_uk

This is just a quick update on the issues above:

Corrupt frames problem: this is still a problem, but seems to occur only on short exposures of a few ms. It's more likely to occur after the camera has already collected long exposures, say 10 or 20s long.

Asiinitialise memory leak: if I call closecamera and opencamera before asiinitialise this resolves the issue as the memory is freed. This can probably be ignored.

Exposure brightness difference on short exposures collected after long exposures. This is still a problem and my current workaround is to collect 3 short exposures before collecting the final short exposure that I save. While it works, it really slows things down. It would be really good to have this issue resolved and I note it has been reported by someone else on the forum.

Simon

caracol_uk

I've carried out further testing since my last update, particularly with regard to the image brightness problem.To reiterate, if I carry out an exposure of 1ms straight after the camera has been initialised it will have a brightness value of x. I then capture a 10s exposure before collecting another 1ms exposure. The brightness of this second 1ms is much greater than the first.

This problem can be worked around by closing and reopening the camera beforee every exposure.

Another problem with image brightness seems to happen when an exposure of 5s (probably any exposure length above a certain value) is requested straight after the camera has been opened. An exposure captured like this will be much darker than a 500ms collected after a run of short (say 1ms or 10ms) exposures. By timing the exposures I've discovered that the camera does not actually expose for 5s even though that was requested. The exposure seems to run for 2 or 3s which explains why it is much darker.

It's possible to work around this problem by collecting shorter exposures beforehand.

My main problem now is the corrupt images that seem to happen much more often in the latest version of the firmware. I believe Yang is already investigating this problem, and aside from discovering that it affects short exposures of 20ms or so, I don't have much more to add here that might help.

Regards

Simon

caracol_uk

Just checking whether there is any update on the corrupt frame problem. Of the issues I listed earlier in the thread. It only seems to occur on short exposures (less than 1s). Also, every so often exposures appear very underexposed. This only seems to happen on long exposures (more than 5s), and the actual exposure does take the correct amount of time to complete. However, when the image is viewed it is very underexposed and would appear to only represent 0.5s or so of actual exposure.

Regards

Simon