Error in Ram memory usage of the OS, stretch module and calibration error Masterflat

Thanks for letting us know! So the exact same data did work fine on the Linux version.. that's indeed interesting. You did create the masterflat with bias loaded in as well I assume? As it seems to be an error which might indicate that is what's going on.

@vincent-mod

Hi Vincent, so the Masterflat is only created with Darkflat. Zwo recommends not to use bias frames for the ASI294, because of AMP glow. In APP 1.075 it worked without any error message.

I have uploaded the frames for testing.
The folder has the same name as the post.

That with Linux refers to the memory usage above left in the screenshot. I opened htop for comparison.

With kind regards

Thank you, yes I saw your data thanks for uploading! I've let Mabula know.

Thank you, Vincent.

Dear @minusman,

Thank you as always for reporting these issues. I will have a look at your data and will check the preview bug as well 😉 The linux memory reporting will be checked as well.

Mabula

Hello Mabula, I have uploaded new calibration frames again. Apparently the problem with the calibration error was caused by the dark frames.

Hi @minusman,

I have problems creating a masterflat. I have uploaded a record (folder has the same name as the post), I always get an error message in beta 1.076beta3.

I have first checked the data that you first uploaded. First of all, the message that you got is not an error message, it is warning 😉

That message only pops-up  if you have loaded lights, and are creating a masterflat when either:

1. the flats are not calibrated by bias or darkflats
2. the lights are not calibrated by bias or darks

Judging from your screenshot, I can only assume that you did not load bias or darks for your lights at the moment, or they were deselected. The message warns you that if you continue like this with calibration of your lights, things will not work properly.

Mabula

Hello Mabula, I have also done further tests, I think the warning message came not without reason.
Because apparently there is a problem with the darkframes. Could a driver update of the camera cause this problem? I had made an update recently.
Because now everything runs without warning. But the integration shows a strange ring-shaped pattern. Maybe caused by short exposure time?

I have created new calibration frames and uploaded them in a new subfolder. Maybe this brings more clarity.

Posted by: @minusman

 

When stretching the integration image, the preview hangs when you move the stretch slider and/or the contrast slider and jump from integration to rejection map. APP must then be restarted.

 

Hi @minusman,

I have located and solved this nasty bug 😉

Added to the release notes of 1.076:

• FIXED, PREVIEWFILTER & IMAGEVIEWER PANEL, a bug has been located and solved which caused the image viewer panel not to respond any more. If you would load a 16/32bits image and would set the zoom on on one of the B,W,ST, BA, CON sliders of the preview filter to 4 and then load an 8bits image, the previewfilter and imageviewer panel would stop working. This is now solved.

Kind regards,

Mabula

Posted by: @minusman

Hello Mabula, I have also done further tests, I think the warning message came not without reason.
Because apparently there is a problem with the darkframes. Could a driver update of the camera cause this problem? I had made an update recently.
Because now everything runs without warning. But the integration shows a strange ring-shaped pattern. Maybe caused by short exposure time?

Hi @minusman,

I did not see an obvious problem with the dark frames in terms of metadata or the creation of the fits files, which would have been a reason for mismatching with lights or read problems of the data.

But, if I look at the 15 second darks, they don't look good at all. Especially if you look at 2 different darks:

stretched images of 2 15 second darks:

The apparent banding, if it were part of the sensor's dark signal, should look the same in both darks. It clearly is totally different.... this indicates a problem with the camera I would, or maybe there is electronic interference somewhere ? A bad USB connection perhaps? Is it a new camera?

Mabula

Posted by: @minusman

I have created new calibration frames and uploaded them in a new subfolder. Maybe this brings more clarity.

Hi @minusman,

Those newly uploaded frames are not better, they have the same issue in terms of banding. I would suggest you check all electronics and probably also the supplier of the camera.

Mabula

Hello Manuela, the camera is the same. The difference is the last shots were taken with the new Mgen3 in conjunction with the mgenAPP. The app acts as a man in the middle which loops the camera signal through to control the dithering. I have already written the developer, but haven't heard back yet. If there could be such problems.
I will probably have to fall back on phd2.

Many thanks for solving the preview problem.

Just a wild guess, but I had issues a few years ago because my equipment didn't have a common ground. This was leading to a signal on the USB lines and messing with my sensor signal. If you have equipment in between, it is a likely culprit.

Hello Vincent, can you describe the problems USB ground again exactly. What exactly was the reason for this, disconnections or similar?
I want to do some tests now, but I can already say that mgenAPP and even a short driver update of the recording camera have an influence. But the stripes and darks remain.
But they are also present in much older recordings.

I had a tiny computer (Pi) with its own power supply and other equipment with another power supply. They didn't have common ground. Apparently this caused a signal on the data-lines, causing background noise, which went away after making it into a common ground circuit (I did this by connecting the Pi to a USB3 hub with its own power and got rid of the power plug on the Pi which didn't have ground to begin with).

I use a long active USB cable, between my PC in the house and the mount with USB hub and own power supply in the garden. I want to buy a USB isolator to separate the connection from each other. Because the Usb-Hub is powered by a different circuit than the PC.
Maybe this helps to avoid problems.
Thanks for the tip.

Ah, that is interesting. An active USB cable that long might be of influence. Not saying it is, but worth checking out indeed. Good luck!

ps. also make sure that power outlet on the supply in the garden has a good earth as well. And safety wise obviously, take care of that as well. I had 220 in the garden, but put in several measures to keep it "safe". 🙂

@minusman & @vincent-mod,

Hmm, that construction with the Mgen3APP sounds that it might be the culprit, but on the other hand, if the variable banding was there already before using Mgen3, then I think therer might indeed be a problem with a cable or usb port. I know from 1 user that had an Altair CMOS camera that had similar banding, that the camera needed to be replaced under warranty, so if you can't locate the problem outside the camera, the problem could be a defective camera.

Oh and please check the 1.076 beta 4, I just released it 😉

Kind regards,

Mabula

Hello Mabula, hello Vincent. Well, I was able to save the pictures a little bit. I was able to calibrate and stack the pictures successfully with matching masterdarks and artificial masterflats. Because of the short total exposure time very noisy. 

Because of the camera, I did some research in the ZWO forum. It seems that this problem with the horizontal stripes affects most CMOS cameras, some less and some more pronounced. What is mostly recommended in the forum are suitable darks, dithering and
expose longer. So that the stripes are obscured by background noise. I will use this in the future, as an indicator for background limited images. I made a test exposure series on the weekend, because the calibration works fine again.

Apparently the driver update also had an influence on the images.

I'll check the USB connection anyway, maybe I can get some more information
improve things.
With kind regards

Hello Mabula, the new stable version works quite well for me so far. Turn the projection and the stretch module.
The only thing that still doesn't work properly is displaying the memory usage of the OS. The display does not reset itself. At least in Linux, in my case Ubuntu. In Windows it works. But that is not so tragic at the moment. Maybe in one of the next versions.

With kind regards.

Thanks for pointing that little issue out still, hope it'll work in a next release. @mabula-admin

Hello Vincent Hello Mabula, yesterday the weather god
once an hour to check my setup.
So USB problems are not present. My cables are okay so far. The current ZWO camera driver is not the best, my recording software crashed from time to time. An older version of the driver solved the problem.

The developer of MgenAPP contacted me. The MgenAPP does not influence the image data, it only controls the exposure of the camera. The developer has admitted that with activated dithering the image is in the waiting loop until the dithering is finished and then the camera downloads the image. It can happen (depending on the camera manufacturer) that the camera continues to expose in the background while dithering until the image is downloaded from the camera. Apparently the images can be calibrated badly because of this. When a new version of MgenAPP is available I will test it again. In this version the waiting loop should be abolished.

Here is the generated image from last night. Unfortunately there were only 6 useful exposures of 30s each, because of wind.

With kind regards

Ah yes, if the software continues to expose while dithering, your stars will be smeared out so those frames are lost then. Glad you're getting it running.