ASI120MM - picture issues

[jkoenig72]

Hi,

build two of those nice little cams. Fantastic work, Thomas!

One with the ASI120MC - all good, one with the ASI120MM - not good.

Some images - not all - get somehow faulty "mosaic-ed". Please see those examples.

Not all - only 50%.

I tried flashing to the "ASI120MM-compatible.iic" firmware and tried the format (RGB / RAW) settings.

Any idea what goes wrong?

Regards Joerg

[jkoenig72]

See? The last one is correct - but the others are not. Any hint?

[BrambleTheBoar]

I'm also having a similar issue with my 120MC. How long is your USB cable? What SD card are you using? Your sensor temp seems warm, what's your CPU temps?

[Fulhair]

I too am encountering the same issue where the image is halved or quartered. Testing out the build indoors before I mount the camera outside. Using a fresh install of NOOBS with ASI120MC, with the updated firmware and new 128GB adata sd. I have a 5m USB3 cable but still get the issue when I use a 30cm cable. CPU stats attached.

Any idea? Love the project/software otherwise.

[ZebrasHaveBigEars]

Try a short USB2 cable of high quality with the Pi 3B. It might be the problem?

[Fulhair]

Try a short USB2 cable of high quality with the Pi 3B. It might be the problem?

Tried again testing with various shorter USB2 cables but still had the image 'mosaicing' in the same way about 20% of the time.

[ZebrasHaveBigEars]

Check to see if the pics in the images folder are similarly distorted. If they are not distorted, the problem may be in the resizing command in saveImageDay and saveImageNight?

[Fulhair]

Checked and they are distorted in the image folder - here's one I copied straight from the Pi's image folder

[thomasjacquin]

What size are these images on disk? My theory is that for large images, the RPi is still transferring the last image to the images directory while it's already starting to write the new one to disk (overrwriting image.jpg)

It doesn't happen with my ASI224MC but it might be because my images are always somewhere under 200kB. I could be totally wrong about this but let's gather some data about what's common between all these images.

[Fulhair]

The image size is above 292 KB (300,014 bytes). I got a pi 4 for my all sky camera, rebuilding the OS in on a full Buster Iso image (the cut down one won't install as missing Open CV?)
Using the same camera, cable and SD card and this fixed the problem - no image mosaic. Then switched back to the Pi3b+ using all the same component/software and the mosaicing reappeared. I looked at the range of image sizes ranged from 191KB and there were some 300KB that mosaiced and some of the same size that didn't. On the pi4 the images went up to 400kb without issue. Anyway the problem is solved for me with the pi4, but hope the above might help with solving the issue for others.

[BrambleTheBoar]

All my images are between 300-400kb. There doesn't seem to be any relationship between image size and if they are "mosaic" or not. A lot of the larger file sizes are normal looking images.
I'm glad the extra power of the pi4 powered though the image processing and resolved the issue. I'll add one to my wish list. ;)

[freiform]

I have the same issue using a ASI120MM with a Raspberry B+ (1st Gen.). The interesting thing is that test runs at my desk worked fine. Putting the setup on the balcony yesterday evening showed the same stiched up images as shown above. I guess I have to use a faster Pi or see where else I can save some CPU-Time.

[freiform]

Apparently, flashing the current non-compatible firmware solved the issue. I don't see the fragmentation any more and I can even use dark-subtraction.

[mireianievas]

It is a well known issue without fix, apparently. I was also using one of these cameras (precisely trying the Datyson clone) and suffers from the same bug, so I am giving up on it.

[ckuethe]

I'm seeing something similar - I'm able to grab frames for a while and they come out ok:

And then all of a sudden, the right side of my image basically turns into a keogram:

After a while it seems to recover on its own if my nightly movies are anything to go by. Don't worry about the dew - I built a dew heater to be installed tomorrow.

Previously I complained about reset high-speed USB device number 6 using dwc_otg - I get exactly one of those when the camera connection is first opened by running capture. I've replaced the stock ZWO cable with a shorter, heavier cable which doesn't make much difference, so I think that kernel message was red herring.

It's also not disk load because I'm capturing to tmpfs, I'm using 6.5s integration time, and my images are only about 300kB.

Thinking about an ugly hack to reinitialize the camera connection every N frames...

Hardware: rPi 3B+, ZWO ASI120MM-S, 5.2V/3A PSU, no undervoltage events reported

[villiam13]

Hi @thomasjacquin

I know you closed this issue after accepting @liangchen-harold's pull request but you then had to revert that pull request. Either way, I found even using liangchen-harold's modified capture.cpp I was still experiencing what the original poster reported.

Not sure, how wide-spread a problem this is but I came up with something that so far is working for me that might make sense to fold into your main repository. I have kept some of what liangchen-harold had done, but removed his code that would not write an image if the auto exposure changed since the last time, I did keep his code for checking for corrupt images.

I added a new detection for looking for horizontal lines in the camera image. The details can be seen at the following README https://github.com/villiam13/allsky/blob/master/doc/bugs/asi120_mosaic/README.md

So far over the last 4 hours I have not seen the behaviour. I'll have to see what happens over night rather than day time.

Live Camera using updated code: http://oavatos.org/allsky/

NOTE this code currently assumes there is no horizontal line in the field of view of the camera. My camera is far enough from my house that I do not have that issue, others may not be so lucky.