...

Note that these GTX and Chip maps are the same as what we expect from DataMergeOutMux. In the standard DP cable pin mapping, (1,3) is data0, (4,6) is data1, (7,9) is data2,  and (10,12) is data3. That's why in our config file, we have: chip1 rx2, chip2 rx1, chip3 rx0, chip4 rx3. This means that as long as we are using this adapter with the same config files, we should expect 1 data lane per chip while scanning, with no data merging.

Additional information:

The following page has some information on how the connectivity should be done: https://atlaswiki.lbl.gov/pixels/rd53bQuad/index

Also note that broadcast mode is chipID 16 for ITkPix instead of 8 for RD53A

Setup for reading the ITkPixV1 quad module with YARR + type0 ring + pp0

Image Added

Use the special ITkPix → type0 ring flex from Steven (not the one for RD53A)

This flex is designed so that as long as the ring is concerned, the data from chips 1, 2, 3, 4 are coming on lanes 0, 1, 2, 3, and not from lanes 2, 1, 0, 3 as we would have if we were using the ITkPix data adapter.

Of course there is still a mismatch between lanes on the ring side and the pp0, which luckily we have already mapped out here

Actually, you also need to swap the polarity for the CMD to get things to work - the exact reason for this is still unclear to me (Alex)

So for example, to run Q6: you need to make the following modifications:

In controller: 

rxPolarity: 65535

txPolarity: 65535

In connectivity:

Chip1: rx0, Chip2: rx1, Chip3: rx3, Chip4: rx2

Then you can run with:

bin/scanConsole -r configs/controller/specCfg-rd53b-16x1_on_ring.json -c configs/20UPGR91101015/20UPGR91101015_L2_warm_on_ring.json -s configs/scans/rd53b/std_digitalscan.json -n 1

For Q6 : Chip1: rx0, Chip2: rx1, Chip3: rx3, Chip4: rx2(tested on Nov 7 2022), you can simultaneously run all 4 chips, though chip 1 will always have some failing pixels. Presumably this is a problem due to the ring (maybe one half of the data is disconnected on the flex?)

Tested positions so far

The fact that only 2 data channels show after just turning the module on seems to be normal for ITkPixV1. They correspond to the output lanes for chips 2 and 4 and might have to do with how these two chips are designated for data merging (more investigation needed). 

Additional information:

The following page has some information on how the connectivity should be done: https://atlaswiki.lbl.gov/pixels/rd53bQuad/index

Also note that broadcast mode is chipID 16 for ITkPix instead of 8 for RD53A

Log for tests, with some maybe helpful debugging information, and some details on why we only see 2 data lanes on power-upOngoing log for tests: https://docs.google.com/document/d/1bvw4enmglHp-_2nJu62QusTybvB80sYdE18g9OzqC8U/edit?usp=sharing