In one and only one of the 3 sub-swaths, i.e. sub-swath 1, the image S1B_IW_SLC__1SDV_20191017T205036_20191017T205104_018520_022E57_724A (used as either master or slave) leads to a slave product that contains empty stripes.
I tested back geocoding it in combination with
S1A_IW_SLC__1SDV_20191011T205131_20191011T205159_029416_035879_2222
Does this happen every time you run Back Geocoding on this sub-swath?
You could slightly change some of the parameters.
Do all sub-swaths look alright before this step?
Back geocoding works perfectly well in SNAP when using these 2 inputs:
S1A_IW_SLC__1SDV_20190929T205131_20190929T205159_029241_035277_6F56
and
S1A_IW_SLC__1SDV_20191011T205131_20191011T205159_029416_035879_2222
which have a longer temporal baseline
Sorry I was confused earlier. Both 6- and 12-day pairs can be from the same track. Have you opened the bands of the problematic product to see if they are filled with data normally?
In 2 of the 3 sub-swaths, i.e. sub-swath 2 and 3, the image taken on date 20191012 (used as either master or slave) leads to a slave product that contains empty stripes.
Actually, as you can see in the image below, I first assemble subswath 2 of the two images taken on date 20191012 (the e are needed to cover the area of the image taken 6 days before) and then do back geocoding with the image on 20191006. The same for subswath 3. And now I am wondering if I might do something wrong in the step that assemble the 2 subswaths.
I work for WASDI and we have a client who is looking for a product map based on these images. Is there any support that ESA can give us, perhaps in reproducing our steps?
This looks like the wrong bursts are possibly being paired together for some part of the swath. The mapping of corresponding bursts between reference scene and secondary scene seems to be changing by 1 - and you are essentially seeing burst overlap regions.