decide on wiring table format and mechanisms

[rerpha]

Wiring tables is a concept that still exists however the format is now different (.csv as opposed to the old wiring table format).

The options that we're considering are:

• change .csv to align with the old format
• write a service/script to convert to/from .csv
• keep the two formats separate, acknowledging that they will not be backwards or forwards compatible

acceptance criteria

• choose one
• create more tickets to actually implement anything needed

[Tom-Willemsen]

Do we enforce contiguous spectra once mapped by the wiring table?

e.g. not allowing "2 spectra" where the 2 spectra are 1 and 1001.

[Tom-Willemsen]

Linked with #41

The reason the wiring table format is currently different is that it is doing a different thing - instead of mapping channel: int -> int, it is mapping:

(source_ip: str, board_type: str, packet_type: str, pixel: int) -> int

[Tom-Willemsen]

There are currently a lot of fields in the DSG-proposed format that only really apply to one or two boards. I would very much like to work with them to come up with a scheme that means we can reduce the "wiring table" to just pixel-offsets, with all other parameters encoded in the UDP headers.

[Tom-Willemsen]

There are currently a lot of fields in the DSG-proposed format that only really apply to one or two boards. I would very much like to work with them to come up with a scheme that means we can reduce the "wiring table" to just pixel-offsets, with all other parameters encoded in the UDP headers.

This was done and agreed with DSG; boards were harmonised and the information to decode pixel IDs now comes as part of the UDP packets.

We then had a follow-up discussion because we might actually need another layer of mapping between hardware_detector_id and detector_id, to be able to be sufficiently flexible to cope with different instrument and electronic layouts. DSG to propose a scheme, which we hope can be implemented in the hardware side.