decide on wiring table format and mechanisms #27

Activity

1. rerpha

   added this to Data streaming for HRPD-X & SANDALS-IIon Jan 7, 2026
2. rerpha

   moved this to research/needs discussion in Data streaming for HRPD-X & SANDALS-IIon Jan 7, 2026
3. Tom-Willemsen commented on Jan 18, 2026

   

   Tom-Willemsen

   on Jan 18, 2026

   Last edited by Tom-Willemsen

   Member

   More actions

   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.
4. Tom-Willemsen

   added this to the September 2026 milestone on Mar 6, 2026
5. Tom-Willemsen commented on Apr 14, 2026

   

   Tom-Willemsen

   on Apr 14, 2026

   Member

   More actions

   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
   
6. rerpha

   moved this from research/needs discussion to Ready in Data streaming for HRPD-X & SANDALS-IIon Jul 21, 2026
7. rerpha

   assigned

   Tom-Willemsen

   on Jul 21, 2026
8. Tom-Willemsen

   moved this from Ready to In progress in Data streaming for HRPD-X & SANDALS-IIon Jul 28, 2026
9. Tom-Willemsen commented on Jul 29, 2026

   

   Tom-Willemsen

   on Jul 29, 2026

   Member

   More actions

   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.
10. Tom-Willemsen commented on Aug 20, 2026

    

    Tom-Willemsen

    on Aug 20, 2026

    Member

    More actions

    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.
11. Tom-Willemsen

    marked kafka_event_aggregator: do wiring table mapping #41 as a duplicate of this issue on Aug 20, 2026