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

frequency spectrum analyzer: double sample rate support #294

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

mmehari
Copy link
Contributor

@mmehari mmehari commented Feb 19, 2025

This PR fixes the issue described in #286.

By doubling the sample rate, the maximum frequency observed is also doubled (187.5KHz -> 375KHz).

Whereas if the Double Sample Rate option is not selected, the spectrum analyzer only shows half the frequencies (until 187.5KHz).

The following two pictures show the noise floor when Double Sample Rate is turned ON and OFF.

double_sample_rate_noise
Noise floor when Double Sample Rate is turned ON

single_sample_rate_noise
Noise floor when Double Sample Rate is turned OFF

@mmehari
Copy link
Contributor Author

mmehari commented Feb 19, 2025

@tdunning
Copy link

tdunning commented Feb 19, 2025

Sweet.

There is an anomalous shift in level due to the sample rate change. This should be fixed once the vertical axis is calibrated as described in #289

That should also decrease the noise floor substantially.

@mmehari
Copy link
Contributor Author

mmehari commented Feb 20, 2025

Indeed I have seen the level shift but this bug fix is all about enabling the double sample rate.

After this bug is fixed, we should tackle the calibration and unit issue and hopefully see a reduced noise floor.

@tdunning
Copy link

I understand that the level calibration isn't part of this bug. The higher than desired noise floor is also out of scope here.

My comment was simply stating that the level shift should be handled in a different issue. I think we agree on that.

@mmehari
Copy link
Contributor Author

mmehari commented Feb 20, 2025

Yes I do agree and are you able to put this PR on a test?

@tdunning
Copy link

I don't have the hardware handy any more, so no, I can't help with testing. I am happy to help (a little) with math and opinions, but can't help with testing.

@mi-hol
Copy link
Contributor

mi-hol commented Feb 25, 2025

@mmehari how do you want to proceed with this PR?

@mmehari
Copy link
Contributor Author

mmehari commented Feb 25, 2025

I was hoping either @tdunning or @Vincenzo-Petrolo would test this PR but they don't have the board. So their support is limited.

I could also rely from the maintainers pool but both @EspoTek and @turboencabulator are kind of busy now.

If their won't be anyone to test this PR, then I will merge it myself.

@mi-hol
Copy link
Contributor

mi-hol commented Feb 25, 2025

I did a quick search in closed issues and found #63
Maybe one of the posters there could be motivated to test?

@tdunning
Copy link

tdunning commented Feb 25, 2025 via email

@mi-hol
Copy link
Contributor

mi-hol commented Feb 25, 2025

What tests do you need?

Testing a real use case hands-on from a user perspective is required.
Looking at Screenshots has no benefit to find bugs in actual implementation!

@tdunning
Copy link

Oh well. I would have loved to have helped. I understand that some aspects are not possible to review from snaps, but I had hoped that I could add some value.

@turboencabulator
Copy link
Contributor

I don't really have the equipment necessary to fully test it, but I gave it a quick try with the signal generator.

One thing I noticed: Is it storing samples in a different buffer depending on the mode? Do we need to flush out old samples when changing the mode?

  1. Set the input to, say, 1kHz. Let it stabilize.
  2. Toggle the double sample rate setting (on or off, doesn't seem to matter).
  3. Change the frequency to, say, 2kHz. Let it stabilize.
  4. Toggle the double sample rate setting back. As soon as you toggle it, the spike at 1kHz shows up temporarily, then fades.

@tdunning
Copy link

tdunning commented Feb 26, 2025 via email

@turboencabulator
Copy link
Contributor

I don't think it's a reinterpretation because it works for any frequency pair (not just 2x like my example) and also when toggling the setting in either direction. But it's not a big deal since it clears quickly.

@mi-hol
Copy link
Contributor

mi-hol commented Feb 26, 2025

Oh well. I would have loved to have helped. I understand that some aspects are not possible to review from snaps, but I had hoped that I could add some value.

Appreciate the offer, there will be a next opportunity :)

@mmehari
Copy link
Contributor Author

mmehari commented Feb 27, 2025

One thing I noticed: Is it storing samples in a different buffer depending on the mode? Do we need to flush out old samples when changing the mode?

That is what it appears. When changing frequency values the buffers are holding both frequency samples (momentarily) and that is what is shown in the frequency spectrum.

Like you said, it clears out quickly and we can leave it as is or flush the buffer every time we change the frequency

@mi-hol
Copy link
Contributor

mi-hol commented Feb 27, 2025

flush the buffer every time we change the frequency

would be my preference due to the better user experience

@mmehari
Copy link
Contributor Author

mmehari commented Feb 28, 2025

Apparently there was a routine to clear oscilloscope buffers and I have extended it to clear the async_dft buffers as well. 36765ec

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

Successfully merging this pull request may close these issues.

4 participants