-
Notifications
You must be signed in to change notification settings - Fork 122
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
base: master
Are you sure you want to change the base?
Conversation
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. |
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. |
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. |
Yes I do agree and are you able to put this PR on a test? |
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. |
@mmehari how do you want to proceed with this PR? |
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. |
I did a quick search in closed issues and found #63 |
What tests do you need?
I have the board (somewhere). I could also review screen shots if you like,
especially if you can feed a reference signal to the board.
…On Tue, Feb 25, 2025 at 11:14 AM Michael Mehari ***@***.***> wrote:
I was hoping either @tdunning <https://github.com/tdunning> or
@Vincenzo-Petrolo <https://github.com/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
<https://github.com/EspoTek> and @turboencabulator
<https://github.com/turboencabulator> are kind of busy now.
If their won't be anyone to test this PR, then I will merge it myself.
—
Reply to this email directly, view it on GitHub
<#294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5E6VJOI2HLSMRRF4EQ6D2RS6IZAVCNFSM6AAAAABXPEPNQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTGAZDKNBTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: mmehari]*mmehari* left a comment (espotek-org/Labrador#294)
<#294 (comment)>
I was hoping either @tdunning <https://github.com/tdunning> or
@Vincenzo-Petrolo <https://github.com/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
<https://github.com/EspoTek> and @turboencabulator
<https://github.com/turboencabulator> are kind of busy now.
If their won't be anyone to test this PR, then I will merge it myself.
—
Reply to this email directly, view it on GitHub
<#294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5E6VJOI2HLSMRRF4EQ6D2RS6IZAVCNFSM6AAAAABXPEPNQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTGAZDKNBTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Testing a real use case hands-on from a user perspective is required. |
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. |
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?
|
That sounds like the buffer holding the 2kHz samples is reinterpreted as
having been sampled at the slower sampling rate.
As you say, it self-corrects quickly.
…On Tue, Feb 25, 2025 at 7:33 PM Kyle Guinn ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub
<#294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5E6UEYO67K2FNIDDJHJ32RUYX7AVCNFSM6AAAAABXPEPNQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTHAYDQMRWHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
[image: turboencabulator]*turboencabulator* left a comment
(espotek-org/Labrador#294)
<#294 (comment)>
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.
—
Reply to this email directly, view it on GitHub
<#294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB5E6UEYO67K2FNIDDJHJ32RUYX7AVCNFSM6AAAAABXPEPNQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBTHAYDQMRWHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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. |
Appreciate the offer, there will be a next opportunity :) |
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 |
would be my preference due to the better user experience |
Apparently there was a routine to clear oscilloscope buffers and I have extended it to clear the async_dft buffers as well. 36765ec |
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.
Noise floor when Double Sample Rate is turned ON
Noise floor when Double Sample Rate is turned OFF