Opened 16 years ago

Closed 15 years ago

Last modified 15 years ago

#189 closed bug (wontfix)

Black flecks in ATM data

Reported by: benj Owned by: benj
Priority: alpha 4 medium Milestone:
Component: Processing: general Keywords:
Cc: mggr Other processors:

Description (last modified by benj)

Some (generally high-brightness) level 1 ATM data contains scattered black flecks (can be quite numerous). Most frequent in band 7, but do occur in other bands. Example screenshot (from EUCAARI day 136):

Looking at the raw data with qcdisplay, the flecks aren't present, but there are short horizontal white lines. These seem to be less numerous than the black flecks and may or may not be related. Example screenshot (same flight):

Probably not worth doing anything about, since ATM is dying and due for replacement. First noticed as part of #115

Attachments (2)

atm_blackflecks.png (540.5 KB) - added by benj 16 years ago.
atm_whitelines.png (99.1 KB) - added by benj 16 years ago.

Download all attachments as: .zip

Change History (6)

Changed 16 years ago by benj

Changed 16 years ago by benj

comment:1 Changed 16 years ago by benj

  • Description modified (diff)
  • Type changed from task to bug

comment:2 Changed 16 years ago by benj

  • Description modified (diff)

comment:3 Changed 15 years ago by benj

  • Resolution set to wontfix
  • Status changed from new to closed

ATM probably won't be flown again - no point in worrying about this ticket.

comment:4 Changed 15 years ago by benj

Email from Bill:


I've had a quick look at your Eucaari line and checked the occurance of zeros in the original raw ATM file; also I have tried the same with day 116 ATM for comparison.

It's clear from printing out zero value pixels and ones either side that they are due to overflow in the A2D due to a bright source, ie clouds. It looks like my original understnding from the a2d chip data sheet that overflowed pixels would be ffff and underflowed would be zero was incorrect - it looks like undeflow never occurs and overflows get set to zero.

Trying listing zero pixels on "normal" data ie over ground scenes gives no raw zero pixels.

So I would conclude that this ticket 189 problem is just bright scene overflow and not increasing problems with the ATM; these are to my knowledge still restricted to noise pick-up and sync stability.

Br Bill
Note: See TracTickets for help on using tickets.