Skip to content

Smart BUSY handling #44

@coderdj

Description

@coderdj

In saturation conditions the busy could become an issue. Imagine this: we run with 32 digitizers in a high rate. A digitizer fills up and emits a busy stopping input. We clear the digitizer and very quickly another digitizer fills, emitting another busy. In between busies there was just a tiny amount of time and some events have to be discarded since the busy cuts into them.

What we would rather do is give the maximum amount of time possible between BUSY signals, which means always clearing full boards last. This means that at the time the BUSY is cleared every board is guaranteed to have an empty buffer and acquisition can run for the maximum time possible before the next BUSY is emitted.

I don't know if this will work in practice. But there is a read-only register for the BUSY where the board's BUSY status can be queried. We could read this register before reading out each board. If it happens to be positive we set a boolean flag in the board object (bSeenAsBusy or something) to true and continue cycling through the boards. If we come across a full board where bSeenAsBusy is already true we set it to false and read the board out.

This is medium priority but it should be done before production (flagged for 1.2 release).

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions