External trigger needs timing resolution better than 1 frame

[joefowler]

For some reason, I solved #331 with the implied number of rows = 1, which means very coarse timing resolution (at the single-frame level). There is no practical reason to coarsen that much. The native timestamp information is recorded 4096x finer (4 ns vs 16.384 µs). Even if we recorded 1 ns clock ticks and counted until a signed int64 overflows, that takes almost 300 years.

The only remaining problem is that µMUX data has no natural "number of rows". We'll need to invent a number. I'm thinking 64. That would put timing info taken at the "row rate" down to ticks at 256 ns. And MASS will need to know that number, somehow.

[ggggggggg]

I don't think we should infect umux with the concept that rows affect timing.

From: Joe Fowler @.> Sent: Saturday, February 3, 2024 5:42 PM To: usnistgov/dastard @.> Cc: Subscribed @.***> Subject: [usnistgov/dastard] External trigger needs timing resolution better than 1 frame (Issue #335)

For some reason, I solved #331https://github.com/usnistgov/dastard/issues/331 with the implied number of rows = 1, which means very coarse timing resolution (at the single-frame level). There is no practical reason to coarsen that much. The native timestamp information is recorded 4096x finer (4 ns vs 16.384 µs). Even if we recorded 1 ns clock ticks and counted until a signed int64 overflows, that takes almost 300 years.

The only remaining problem is that µMUX data has no natural "number of rows". We'll need to invent a number. I'm thinking 64. That would put timing info taken at the "row rate" down to ticks at 256 ns. And MASS will need to know that number, somehow.

- Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/dastard/issues/335, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABHTXAIGHZ3E3XTJ57UC6L3YR3KOXAVCNFSM6AAAAABCYNF72KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGEYTMNZXGU2TSMI. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[joefowler]

Well, I don't think we should completely rewrite Dastard in the 24 hours before a beam time, so this is the compromise I came up with. The language of "row time" is littered throughout the lancero code. It's unfortunate, because it does NOT generalize (which is your point). But that's where we are.

I'll stress that the actual solution we're using only uses the language of rows and such. A superior solution would base external triggers around how they are handled in µMUX and avoid the word "row" entirely, and then wedge the Lancero's external trigger code into the new paradigm. But there's not time for that here in Japan.

Putting snark aside, maybe we should have an issue for broad ideas that would make Dastard more future-looking? This would be one. Another would maybe be to remove the Abaco ring buffers (which were a temporary expedient, no longer in use), and a third might be to completely replace the word "Abaco", so that code makes sense when we have RFSoC devices.

We could even think about taking all the source-specific code out of Dastard. We could make UDP-Mazsi packets be the only permissible data source. Then Roach or TDM would be required to convert their data into this kind of packet stream.