You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In isodriver.cpp, I noticed breaks in the spectrum-mode signal dt_samples1 every 12375 samples. From what I can tell, this is the number of samples written to the internal buffer of a given channel (in 375 khz mode) every call to frameActionGeneric. These breaks are a source of error in the computed power spectrum.
I think that the problem arises in the existing code because this block
is located ahead of the buffer write commands such asinternalBuffer375_CH1->writeBuffer_char(&isoTemp[ADC_SPF*i], VALID_DATA_PER_375);. This appears to cause the write commands to be executed only every kSpectrumCounterMax=4 calls to frameActionGeneric, which results in a break in the waveforms every 12375 samples. The issue can be resolved by moving the if spectrum { block below the buffer write commands. For reference, I attached a plot showing converted_dt_samples1 waveforms from before and after implementation of the fix.
Strangely, the breaks appear even when a 1khz signal is being measured despite the fact that the 12375 samples comprise exactly 33 periods of such a waveform at the 375 khz sampling frequency. In principal, in the existing code, 33 wave periods would be read in, the next 99 would be missed, and so on, but the waveform would be continuous. A possible explanation for the presence of breaks even at 1 khz in the current code is that the calculation of the spectrum causes some additional samples to be missed beyond those that are lost due to the position of the if spectrum { block. As far as I can tell, though, as long as the fix described above is implemented, the spectrum mode waveforms are continuous. So, the issue seems to be resolved, but, given how it can be fixed, I am confused as to how it appeared even when 1 khz signals were being measured.
The text was updated successfully, but these errors were encountered:
In isodriver.cpp, I noticed breaks in the spectrum-mode signal dt_samples1 every 12375 samples. From what I can tell, this is the number of samples written to the internal buffer of a given channel (in 375 khz mode) every call to frameActionGeneric. These breaks are a source of error in the computed power spectrum.
I think that the problem arises in the existing code because this block
is located ahead of the buffer write commands such as
internalBuffer375_CH1->writeBuffer_char(&isoTemp[ADC_SPF*i], VALID_DATA_PER_375);
. This appears to cause the write commands to be executed only every kSpectrumCounterMax=4 calls to frameActionGeneric, which results in a break in the waveforms every 12375 samples. The issue can be resolved by moving theif spectrum {
block below the buffer write commands. For reference, I attached a plot showing converted_dt_samples1 waveforms from before and after implementation of the fix.Strangely, the breaks appear even when a 1khz signal is being measured despite the fact that the 12375 samples comprise exactly 33 periods of such a waveform at the 375 khz sampling frequency. In principal, in the existing code, 33 wave periods would be read in, the next 99 would be missed, and so on, but the waveform would be continuous. A possible explanation for the presence of breaks even at 1 khz in the current code is that the calculation of the spectrum causes some additional samples to be missed beyond those that are lost due to the position of the
if spectrum {
block. As far as I can tell, though, as long as the fix described above is implemented, the spectrum mode waveforms are continuous. So, the issue seems to be resolved, but, given how it can be fixed, I am confused as to how it appeared even when 1 khz signals were being measured.The text was updated successfully, but these errors were encountered: