Closed jonschumacher closed 12 months ago
Have you checked that its also happening with a calibration offset value? I noticed it happening with a "normal" offset on the fast DAC channel (offsetDAC!(...) set manually) plus a txSlow Channel from MPIMeasurements
A check like this would ideally also include the check that all periodic components (including AW) on a single RP output, do not sum to over 1V at any point in time. However this might be a little bit difficult to catch in the server, since you would have to look at the whole time signal. Is there maybe a way to handle that overflow in the blocks that sum the individual components on the FPGA? And just clip the output signal to 1V if an overflow happens? That would also not be ideal, but it should be safer than wrapping around to -1V.
No, I didn't check that, I just misunderstood you and wanted your issue to be documented ;)
We could have a larger register for the output values and check if they exceed a 14 bit integer at the last stage.
Yes, I think such a check should be done in the FPGA. I'll have to recheck what format the values are in, at some point we switch from Two's complement to just a binary value for the DAC.
We could even make this hard limit a configuration parameter, similar to the calibDACOffset
. Than with something like calibDAC(Positive)Limit
we could configure systems to not exceed 0.X V
With a configured offset value, a wrap-around of the fast DAC data might occur since it is not checked that the addition of the offset values does not exceed the limit of a 14 bit integer. @jusack