Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Waveform generation clock settings #255

Closed
dbsamithey opened this issue Oct 31, 2023 · 2 comments
Closed

Waveform generation clock settings #255

dbsamithey opened this issue Oct 31, 2023 · 2 comments

Comments

@dbsamithey
Copy link

I think that line 219 of genericUsbDriver.cpp should be changed from
return CLOCK_FREQ / (division * channelData.samples.size() * channelData.freq);
to
return CLOCK_FREQ / (division * channelData.samples.size() * channelData.freq) - 0.5;

As I understand it, CPS = CLOCK_FREQ / (division * channelData.samples.size() * channelData.freq) is the appropriate number of clock cycles per waveform sample. Also, it looks like the PER setting of the waveform generating timer is set to the value returned on line 219, which is (int) CPS in the current code. But, the formula at the top of page 173 of the xmega-au manual indicates that the timer triggers every (PER + 1) clock cycles. This means that PER should be set to CPS-1 if CPS is an integer. If CPS is not an integer, adding 0.5 to the result before returning it produces a PER = (int) (CPS - 0.5) that is rounded instead of truncated to the nearest integer.

The attached plots show the power spectra of nominally 5 khz sin waveforms generated by the Labrador both before (PER = 75) and after (PER = 74) the change to line 219 is made. Before the change, the power spectrum peaks at 4,935 Hz, which corresponds to 76 clock cycles per waveform sample. After the change, it properly peaks at 5,000 Hz, which corresponds to 75 clock cycles per waveform sample.
Before change:
before_fix
After change:
after_fix

EspoTek added a commit that referenced this issue Nov 1, 2023
@EspoTek
Copy link
Owner

EspoTek commented Nov 1, 2023

Thanks so much for the write up. I've had a few messages about slightly off frequencies, but have always come to the conclusion that it was just quantisation error (which, I suppose some of it is, but still).

I've committed the fix and it should upstream soon.

@EspoTek EspoTek closed this as completed Nov 1, 2023
@dbsamithey
Copy link
Author

No problem at all. I'm glad I could make some small contribution to the device. I think this also explains why the spectrum mode waveform breaks (#241) showed up for a nominally 1 khz signal. Because the signal was actually 48e6 / (128 * 376) = 997.34 Hz, a phase difference ( [ 3 * 33 * (0.001 s) * (997.34 Hz)] mod 1 = 0.74 periods ) built up over the 3 missing frames.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants