I am reporting an apparent product defect in a provisional NISAR L0B RRSD granule, along with a demonstration of its impact on focused imagery. I understand the provisional designation and that calibration and validation are ongoing; I am passing this along because the signature is specific, reproducible, and visible in the corresponding official RSLC.
Affected products (both PROVISIONAL_V1, processing facility P05023):
- L0B RRSD, orbit 5821, path 13 descending, frame 71, acquired 2026-09-07, 40+5 MHz DHDH: NISAR_L0_PR_RRSD_030_013_D_238S_20260907T023628_20260907T024151_P05023_F_J_001.h5
- The corresponding L1 RSLC: NISAR_L1_PR_RSLC_030_013_D_071_4005_DHDH_A_20260907T024033_20260907T024111_P05023_N_F_J_001.h5
The defect. The transmit time tag array /science/LSAR/RRSD/swaths/frequencyA/txH/UTCtime (and its frequencyB twin) contains one spurious extra tag at index 104954, apparently inserted for a lost V-channel line: the inserted pair of intervals is 544.5 us plus 4.5 us where the PRISequence table calls for a single 549.0 us interval. rangeLineIndex remains continuous through that row, and radarTime carries the same insertion. The consequence is that every echo row from 104954 onward, which includes the entire Rosamond and Los Angeles basin portion of the frame, is labeled one pulse (about 585 us) early. JPL D-102267 defines UTCtime as the unique transmit time tag, so downstream processors reasonably take it at face value; ISCE3 reads UTCtime as shipped (we verified in 0.25.17, and the mission RSLC was generated with 0.25.16, the same reader lineage).
Evidence it is the tags, not the echoes. Three independent checks agree: (1) the positions of the inter-sub-swath transmit gaps in the echo data match the pulse times one row later to 0.01 us; (2) echo pulse-pair phase fits are roughly ten times better under the shifted intervals; (3) the per-line receive header clock (rxH RADAR_TIME) follows PRISequence exactly everywhere, with no insertion, so the header clock and UTCtime disagree by exactly one row from 104954 on.
Impact in the official RSLC of the same take. Point targets at the Rosamond corner reflector array show paired azimuth echoes at plus and minus 37 lines near -19 to -20 dB relative to the peak (the PRF-dither harmonics of the one-pulse mislabeling), and the main response sits about 0.8 azimuth line early. This also appears to explain most of the -0.69 azimuth sample mean peak offset reported in the product’s own QA point target analysis.
Demonstration. We patched a copy of the RRSD in which only the two UTCtime datasets are rewritten from the receive header clock (every other byte verified unchanged), and re-ran ISCE3 with the archived mission ancillaries on windowed segments covering the reflector array and three urban areas. In the corrected focus:
- The paired echoes are gone: the dither harmonics sit at the scene floor, -33 to -34 dB, versus -19 to -20 dB in the shipped focus.
- The main responses move 0.81 azimuth line later, as the one-pulse correction predicts.
- Interferometric coherence between the corrected and shipped focuses of the same data, after co-registration, is 0.917 to 0.945 over five 512 by 512 windows (reflector array, dry lakebed, and three urban areas); the timing defect therefore costs the shipped product roughly 5.5 to 8.3 percent of coherence against a correctly timed focus of its own data.
- The mean azimuth geolocation residual against the surveyed Rosamond reflectors improves from about -0.69 sample to about +0.12 sample.
A compact summary:
We would be glad to share the verification report (the byte extents of the patch), the patch methodology, and the per-window numbers if useful to the project; everything was done on local copies and nothing beyond the two time tag arrays was altered.
Specification question. Separately, we have been working from JPL D-102267 Rev E for the L0B RRSD format, and we see that Rev G of the product specification is now posted publicly. Before we move to it, could you confirm whether Rev G (or a newer revision) is the current one for data users, and whether it addresses the intended handling of inserted or lost-line time tags? That guidance is what we are really after.
Thank you, and thanks for the excellent provisional data access; the 2 to 10 hour L0B latency has been remarkable to work with.
Best regards,
B.G.
Azelon Labs