Split image on ZWO ASI 120mm

snowy911

Hi there,

Would you happen to know why I get a cropped image with parts split into segments as per attachment 'ASI Crop Image' using by ZWO ASI120mm (USB 2.0 version). The issue occurs about 25% of the time, whilst the rest of the time the image appears fine, as per 'ASI Crop Image2'. I'm currently using the latest oAcapture software on a raspberry pi3 with the latest up to date Raspian OS, however I have also experienced this with the same camera on a windows 10 PC run Maxim DL 6.

For reference I am editing the image using Imagemagick to convert from a TIFF to a JPG and adding a timestamp, however the original image is of course unaltered and experiences the same issue.

Thank you

Julian

Sam@ZWO

usb2.0 120 camera may have such problem under PI

did you connect the camera directly to the PI

no hub no extender can make it better

snowy911

Yes, camera is connected directly to the Pi.

thank you

Julian

Sam@ZWO

snowy911 wrote:
Yes, camera is connected directly to the Pi.

thank you

Julian

did you upgrade the firmware?

snowy911

Yes running the latest version, used the FWTool.

thank you

Julian

caracol_uk

This split frame problem is exactly the same problem I reported in a separate thread (though I described it as a corrupt frame). My ASI120MC is connected directly to the Pi. I find it only occurs on short exposures of less than 0.5s. It has never occurred on an exposure longer than 1s.

I use my camera as an all sky camera and run it all night every night. This problem never happened once until I upgraded the SDK last year. Now I get a few split frames every evening. If I remember correctly, I never used to have the problem when I was using SDK version V1.12.0.1 2016.9.20 (or possibly V1.12.0.2). All version after that seem to have suffered this problem. It was also at this point that every so often the camera would underexpose images (a 10s image sometimes appears as though it has only exposed for less than 1s). I did try reverting back to SDK version V1.12.0.1 2016.9.20 and both problems went away. However, I'd prefer to keep my Pi up to date with the latest drivers so for now I'm living with the problem as it happens on less than 10% of the images.

Regards

Simon

snowy911

Thanks Simon, good to know that it's not just my setup.

Do you have any additional filter on the ASI120 to protect the chip during daylight?

It was highlighted to me that you could potentially damage the chip by the excessive daytime exposure that an all sky camera would experience.

Also set mine up as a all sky camera, and posted on SGL last week. Haven't mounted it outside yet, but so far so good, well with the exception of the odd frame as above:

https://stargazerslounge.com/topic/296873-another-raspberry-all-sky-camera/

caracol_uk

I'm not using a filter but I've built a shutter for my allsky camera. It closes during the day and opens at sunset. I'm only collecting images at night.

Simon

Sam@ZWO

snowy911 wrote:
Yes running the latest version, used the FWTool.

thank you

Julian

you should use the original firmware which is more powerful

but I am not sure newest PI kernel support the original firmware or not

Sam@ZWO

caracol_uk wrote:
This split frame problem is exactly the same problem I reported in a separate thread (though I described it as a corrupt frame). My ASI120MC is connected directly to the Pi. I find it only occurs on short exposures of less than 0.5s. It has never occurred on an exposure longer than 1s.

I use my camera as an all sky camera and run it all night every night. This problem never happened once until I upgraded the SDK last year. Now I get a few split frames every evening. If I remember correctly, I never used to have the problem when I was using SDK version V1.12.0.1 2016.9.20 (or possibly V1.12.0.2). All version after that seem to have suffered this problem. It was also at this point that every so often the camera would underexpose images (a 10s image sometimes appears as though it has only exposed for less than 1s). I did try reverting back to SDK version V1.12.0.1 2016.9.20 and both problems went away. However, I'd prefer to keep my Pi up to date with the latest drivers so for now I'm living with the problem as it happens on less than 10% of the images.

Regards

Simon

thanks Simon

we will check this issue with you

but we need more info

can you send one mail to our tech Yang.Zhou(at)zwoptical.com

caracol_uk

Thanks Sam, I've just emailed you.

Regarding your comment about the original firmware, do you mean we should use the version labelled "compatible"? That is the version I am using as the other version available does not work properly if used with the Pi due to the USB transfer size issue.

Simon

Sam@ZWO

caracol_uk wrote:
Thanks Sam, I've just emailed you.

Regarding your comment about the original firmware, do you mean we should use the version labelled "compatible"? That is the version I am using as the other version available does not work properly if used with the Pi due to the USB transfer size issue.

Simon

no, you should use the version without "compatible"

you can try to patch the kernel of PI if possible

have a look at here:

http://zwoug.org/viewtopic.php?f=17&t=7132

caracol_uk

That's a bit difficult for me to try at the moment as I'll need access to the camera to modify the firmware. It's installed in a remote location. I can modify software settings and update the SDK etc, but it might be a little while before I can change the firmware as I need to connect it to a Windows device to run the firmware tool. If there was a Linux version I could try it remotely though.

Simon

Sam@ZWO

caracol_uk wrote:
That's a bit difficult for me to try at the moment as I'll need access to the camera to modify the firmware. It's installed in a remote location. I can modify software settings and update the SDK etc, but it might be a little while before I can change the firmware as I need to connect it to a Windows device to run the firmware tool. If there was a Linux version I could try it remotely though.

Simon

we will try to find a firmware update tool under linux

yang

Please use this firmware update tool for linux(x86/x64/armv7):

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

if your architecture isn't included, just tell me.

caracol_uk

Thanks Sam, I'll give that a try as soon as I can and let you know the results.

Simon

caracol_uk

Just to keep this thread up to date, I'm currently working with Sam and Yang trying to determine the cause of both the split image problem and the underexposure problem (whereby exposures of >5s sometimes appear to only expose for <1s. I'll address each separately here:

Split image problem:

I was asked to check whether I have set the "USB Bandwidth" to the lowest value. This I had already set to 40 which I believe is the lowest value. I was also asked to check that I had set the "HighSpeed" mode to off. I had this set to on, so my first task was to update my code to turn this off. I then ran my code for several days to see what effect it had. Before turning the setting off I would get about 2 split frames each night (out of about 500 images a night). I have only had 1 split frame image in the past 3 nights (and on this image there was no horizontal shift, but the top half was brighter than the bottom half). This does seem like an improvement. I've also noticed that the number of times the camera would fail to complete an exposure has reduced. I would see this happen up to 15 times a night previously, and I have only seen this once over the last 3 nights. So, the "USB Bandwidth" setting change has certainly helped.

Under exposure problem:

While investigating the split image problem I was sent a test version of the SDK (dated 0731). I intend to run this for the next week or so to determine how it behaves properly. However, initial results after 1 night are that it may have helped with the under exposure problem. I need to check all the frames properly, but a quick glance this morning didn't reveal any dramatically underexposed frames from last night. I believe there are several that are underexposed (they look as though they exposed for 8s instead of 10s), but that would be a marked improvement. Once I've had a proper chance to analyse the images I will be able to confirm this, but it's likely to be next week before I have sufficient data to draw any conclusions. I've also sent Yang some of my code so he can try and reproduce the problem.

I'll wait until I've finished testing the new SDK version before I look at changing the firmware on the camera.

However, I'd like to thank both Sam and Yang for all their efforts so far.

Regards

Simon

caracol_uk

After 4 days of testing the new driver I have not had a single underexposed image. I've been testing the HighSpeed mode set to Off for a week and in that time I've had just one split frame. That's a brilliant result and thanks to Sam and Yan for all their help.

Regards

Simon

Sam@ZWO

caracol_uk wrote:
After 4 days of testing the new driver I have not had a single underexposed image. I've been testing the HighSpeed mode set to Off for a week and in that time I've had just one split frame. That's a brilliant result and thanks to Sam and Yan for all their help.

Regards

Simon

that's great news!

caracol_uk

Bad news, last night I had about 10 underexposed frames after 4 days of none at all. Interestingly these were all on 4s exposures. Usually my exposures are longer than 4s but last night it wasn't that dark because of the clouds. I think the new driver version has stopped the problem on longer exposures of 8-10s but has moved it to 4s. Looks like it isn't fixed yet after all.

Regards

Simon