ds: UDP header format updates - #232
Conversation
|
|
||
| If all bits are high, this packet is a neutron data packet. | ||
| - **Bits 0..7**: Length of header, in 32-bit words (max 255 *too many?*) | ||
| - **Bits 8..23**: Header Type (max 65535 *too many?*) |
There was a problem hiding this comment.
We'll need some docs somewhere of what the different "header types" are...
There was a problem hiding this comment.
I guess the intention is that these correspond to the information that's currently in wiring .csv such as PacketType = DIM_OUT, SW_Pos and CH, so that the "wiring table" is just left with an IP -> detector ID offset mapping?
There was a problem hiding this comment.
Jack's off on leave at the moment but when he's back we'll get the Header Types doc created.
There was a problem hiding this comment.
I guess if it is intended to encode permutations of PacketType, SW_POS, CH, etc, then 65535 is probably sensible - it's plausible we could end up with a good few permutations.
There was a problem hiding this comment.
What you have suggested last is what I envisaged for the packet type. Then have a look up table on the PC that works out what to do with the rest of the header and how the data all splits up.
I did consider trying to include that information in the header but I can see situations where we will end up with 128 bits of data. with 8 different types of data being sent out and I'm not sure we can encode that sort of flexibility directly into the header.
(could either be lots of diagnostics data or the pulse heigh of the surrounding 6 fibres in a Wavelength Shifting Fibre Detecor for position reconstruction)
Clarified PCB Board Number encoding in UDP packet format documentation.
| - **Bit 4**: ISIS slow *-awaiting clarity what this is* | ||
| - **Bit 5**: period overflow veto *-awaiting clarity what this is* | ||
| - **Bit 6**: run sig veto *-not sure if this will be needed when not using DAE3* | ||
| - **Bit 7**: pause veto |
There was a problem hiding this comment.
We would like a runcontrol veto somewhere in addition to "pause veto" I think
There was a problem hiding this comment.
what would you like the "runcontrol veto" to show?
Currently it is configured to be active when the streaming board is configured to run but DAE2/3 isn't
There was a problem hiding this comment.
Both the "runcontrol veto" and the "paused veto" would be toggled by software, just under different circumstances. From the hardware/firmware side, what we need is to be able to write to "runcontrol" or "paused" registers (or a mask) in the SCB, and for events to:
- Not get emitted if we configured it as a hard veto
- Get emitted with the corresponding veto bit set if we configured it as a soft veto
…ts.md Co-authored-by: Jack Harper <harps912@gmail.com>
Have tweaked the order of the vetoes and added a Dwell veto
3 participants
Header format updates from @DaveTempleman