Lines across my sub frames.... HELP! (Please)

[fwm891]

Of 40 sub frames shot tonight 12 had various line patterns across them similar to those attached. This happened on a previous night but the patterns weren't as strong or as numerous.

The patterns shown are from two different cameras. There was nothing seen as a problem on the monitor as frames downloaded.

The cameras are: ASI2600MC Duo and an ASI2600MC Pro both fairly new. Capture software is NINA, cameras fed into a Beelink PC at the mount via USB 3 leads (ZWO Red leads), Subs transferred from the Beeline to my iMac via USB stick.

Subs are captured as fit files. The problem is found when the files are viewed in PI's Blink to go through the frames to weed out any bad ones....

I'd like to think it's the USB stick but I really don't know?

Anyone come across anything like this before?

Edited September 10 by fwm891

[saac]

Crikey. If from two separate cameras it would suggest some corruption or interference is being picked up from elsewhere in the setup as you say perhaps in the usb or maybe the connections.  It will be interesting to discover what you track this down to as the cause. 

Jim 

[symmetal]

What's the USB speed limit set to in the camera's Ascom driver? If you're swapping cameras, you're likely using the same driver for both cameras unless the Duo has a different one. You have to click the Advanced button to see it. If set too high you can get image corruption or no image at all. I have mine set to 75% on my 2600 and anything higher can give errors. The default is a modest 40% which won't be an issue . Using a small ROI for planetary imaging then 100% USB speed seems fine, so it may have been set in the past and forgotten about. Just a thought.

Alan

Edited September 11 by symmetal

[Oddsocks]

Are the original files still on the Beelink PC?

If so, go back and review the images directly on the Beelink that are displaying as corrupted on the Mac

It’s possible that the original files on the Beelink PC are corrupted too but you didn’t notice at the time of capture because of the different stretch factors that N.I.N.A. employs during capture and the auto STF stretch that PixInsight applies during Blink.

By manually stretching the images on the Beelink PC using a different image display application to N.I.N.A and applying a manually adjusted stretch will help you eliminate the file export-import-via memory-stick as being a possible cause. 
I have had issues myself with a bad sector on a USB stick causing file corruption but in that instance random files could not be opened on the Mac rather than data corruption inside a file that could be opened.

I can recommend the free FITS viewer AVIS as an independent viewer for your Beelink PC as it is a small application that takes little disk space >click here< or the older ESA/ESO/NASA FITS Liberator, although I’ve not used FITS liberator on an OS later than Win7 and with the large files from full frame cameras it might struggle >click here<.

If you do find that the file corruption is visible on stored images in the Beelink PC using a different FITS file display application to N.I.N.A. then as @symmetal mentioned above reduce the USB bandwidth setting in the ZWO ASI driver to slow the transfer speed from camera to the Beelink, you might also need to add a pause-between-exposures of a few seconds in N.I.N.A if the Beelink PC is unable to write the incoming data stream to its internal hard drive as fast as the camera is producing images.

If the images are clean on the Beelink PC but corrupted after import to the Mac from the memory stick then try a different memory stick.

My own preference is to avoid using memory sticks to transfer data at all and instead write the images on the observatory Windows PC directly into a local shared folder on the PC and access that shared folder over the LAN from my Mac.
(Currently in Mac OS Sonoma a shared network folder is disconnected automatically whenever the Mac sleeps but it’s just a few mouse clicks to reconnect to the shared folder from the Mac finder menu).

Other sources of noise include a damaged, worn or wrong-sized DC power connection to the camera, which can manifest as noise during capture depending on how much current is being drawn by the TEC cooler, which means some images are clean while the cooler is idling and other images are noisy when the cooler power ramps up.

You can test for that by starting an acquisition sequence with the cooler switched off and the sensor at ambient, acquire a few dozen images then switch the cooler on and immediately begin capturing images before the camera has reached set point temperature and with the TEC running at maximum power.

When you review the images after capture if you find that the initial images were (apart from noisy) clear of horizontal breakup but began to show the defect once the cooler was switched on then that may point to a power supply or cabling problem to the camera.

William.

[fwm891]

Thanks @symmetal and @Oddsocks I've been out and check the original files on the Beelink with AsiStudio's Fit Viewer and there are no lines running across any of the original frames so thats a relief. I've reformatted the USB stick, defragmented it before transferring the files again. AsiStudio shows them to have transferred OK this time.

I've checked the USB transfer rate in NINA. It was set at 80% I've dropped it to 60% just to be on the safe side.

If I get some more clear stuff I'll give it another go.

Thanks again.

Francis

[symmetal]

9 hours ago, Oddsocks said:

or the older ESA/ESO/NASA FITS Liberator, although I’ve not used FITS liberator on an OS later than Win7 and with the large files from full frame cameras it might struggle

There's a newer Fits Liberator 4 which is 64 bit, and works with all file sizes. 🙂

It looks like the USB stick is the culprit as you surmised. USB3 sticks can get quite hot when writing for long periods, which likely doesn't help.

Alan

[symmetal]

3 hours ago, fwm891 said:

I've checked the USB transfer rate in NINA. It was set at 80% I've dropped it to 60% just to be on the safe side.

I assume you're using the native Zwo driver in NINA rather than Ascom. I believe the USB speed setting can't be set outside the Ascom driver as it's not a parameter externally available through Ascom.

Alan

[michael8554]

I'd try USB 2 cables.

And I believe ZWO cables have been proved to be sub-standard.

Michael