fix: assembly of quad modules / triplet modules with serial number determination

Fixing bug reported by @gemmec via email:

usually I assemble my modules using the Unicorn interface, but I know that it does not check the new module S/N, neither if parts are in my place, therefore I tried the LocalDb interface.

I am surprised as I got a S/N that is not expected.

According to the EDMS AT2-IP-EP-0026 the module name is just 20UPGM2 X 012345

X = The first classification digit is used for the FE chip version for both quads and triplets (2 for v1.1). The last 6 digits (for pre-production and production) of the serial number for quads will be the same as the PCB serial number.

Therefore when I assemble a module with flexPCB 20UPGPQ2210482 I should get 20UPGM2 2 210482 while the local PDB reports 20UPGM2 2 200482 i.e. a different 3rd classification digit than expected [ see below]

anybody has observed anything similar?

This bug was due to two separate problems.

• fix corrupted ITkPD information for the bare module / sensor tile so localDB doesn't think it's a triplet
• added a checkbox to indicate if triplet or not (to allow entering the triplet information)
• improve the flow handling for quads vs triplets to be more explicit about what the user is doing

The flow now looks like:

If one enables the triplet box like so:

There is more explicit information about using triplet instead of quad for serial number determination even though it's still labeled as an "OUTER_QUAD_MODULE" - quite simply, this is because one was trying to inject in triplet information, or treat it as a triplet for serial number handling which breaks things quite badly anyway. This at least fixes the issue for quad module assembly, but triplet needs to be figured out more properly.