Hello HyperCP team,
Last week we noticed that the Level 0 data which we collect with So-Rad has a different number of pixel wavelength bins for the Gen 1 (256) versus the Gen 2 TriOS radiometers (250). However, the calibration files for Gen 1 and Gen 2 are both defined for 256 pixels (or 255 if we neglect the first line header).
Our current L0-L1 So-Rad processing assumes that the Gen 2 Level 0 data maps to the first 250 lines of the respective calibration file. Riho confirmed that Tartu have also assumed this is the case (and confirmed that Gen 2 sensors record 250 pixels in their operation).
I think the easiest way to deal with this problem is to pad the Gen 2 L0 data so that it is the same length as the Gen 1 L0 data. There are no changes within HyperCP for the So-rad branch, since I already do this when creating the L1A HDF. However - I think this issue will likely need to be dealt with if a user runs a Gen 2 TriOS sensor through the processor
Thanks,
Tom
Hello HyperCP team,
Last week we noticed that the Level 0 data which we collect with So-Rad has a different number of pixel wavelength bins for the Gen 1 (256) versus the Gen 2 TriOS radiometers (250). However, the calibration files for Gen 1 and Gen 2 are both defined for 256 pixels (or 255 if we neglect the first line header).
Our current L0-L1 So-Rad processing assumes that the Gen 2 Level 0 data maps to the first 250 lines of the respective calibration file. Riho confirmed that Tartu have also assumed this is the case (and confirmed that Gen 2 sensors record 250 pixels in their operation).
I think the easiest way to deal with this problem is to pad the Gen 2 L0 data so that it is the same length as the Gen 1 L0 data. There are no changes within HyperCP for the So-rad branch, since I already do this when creating the L1A HDF. However - I think this issue will likely need to be dealt with if a user runs a Gen 2 TriOS sensor through the processor
Thanks,
Tom