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

Increase more BW Options to Capture App #433

Conversation

Brumi-2021
Copy link
Contributor

@Brumi-2021 Brumi-2021 commented Nov 21, 2021

PR to increase the BW Options in the Capture App , beyond the current max, 500khz. (from 600Khz to 2,75Mhz)

Thanks a lot to @sharebrained for your continuous teaching ! , I understood from him, that in order to avoid the usual SDR FFT DC spike , in that Capture App we are also using , as others SDR's , the fs/4 offset shift ,
And if I understood it well, later on , it will a postprocessing, with filtering and decimation , shifting to the center that badwith spectrum .
image

Additionally , we are applying a faster fs sampling , x 8 , and later on in the post-processing part , we are applying , filtering and decimation /8 .
Based on the discussions and lessons from Sharebrained ,

  • The decimation is about 8x
    I-)because of the reduced useful bandwidth,
    Ii-)because of the offset tuning,
    Iii-) and also because non-ideal filters don’t have cut-off frequencies right at 1/2 the output sampling rate.
    Iv-) Also, the closer to perfect a filter gets, the more math the processor has to do, and the processor is only a 200 MHz Cortex-M4.

We have here some of the available anti-aliasing filters on the MAX2837 : (the list is longer)

image

In previous Mayhem FW version 1.41, all the BW Options were using the COMMON FIXED selection 2,25 (or 2,5Mhz in some specs) .
That I confirmed , that is perfect for the 500khz BW selection, but we could still optimize slightly the background aliasing noise in the 250Khz options,

therefore , In this PR :

  • All Lower BW options <= 250Khz uses now , the MININMUM anti-aliasing BPF 1,75 Mhz, (minor slight optimization respect current FW)

  • and for 500Khz , BPF 2,5 Mhz (as it was before, this was already optimized )

  • For the rest of the new options , I tried many different bandwith settings , and testing them , till fixing the best options to keep reasonable compromise between several dB's lost in the right part of the screen (respect left , due to non flat and nor ideal BPF shapes) and the background aliasing noise. And even I shifted up a little 1Mhz option to 1,1Mhz to have similar background aliasing noise than the other options ,using the above discrete BPF values .

After testing that new feature , we can see,
1-) All options work quite well in the LCD screen ,
but > 1,5 Mhz , we start to see some flickering in the FFT waterfall (that is normal due to our CPU power limitatons)

2-) But only we can REC perfect .C16 size files (matching with the metadata file .TXT ,where is specified the recorded rate ) till <= 600Khz , (mean 600k* 2(I,Q) * 2 bytes (signed Int) = 2,4MB/sec, writing SD card.
Above this 600Khz BW Option , the saved .C16 format files, are automatically decimated by current SW ==> then at the moment those captures are not usefull for the Replay App- (but still good to see the recorded spectrum shape and details, with external sw tools like inspectrum in linux, or audacity , or others ...)
We may have several future options to solve it ,

a-) maybe hiding the "REC" icon button ,on those above BW >600Khz options.

b-) or increase slightly the current FW limitations to write > 2,4MB/s to the microSD , (maybe with good low latency SD Cards < 10-30 msegs (usual ones with 60-100 msegs random latency) with min Write speed rate > 3MB/s (usual ones min rate >4MB/s) , then we may reach easily good performance. Example with 3MB/S (able to record 750Khz BW in .C16 format) or , 3,5MB/s (875khz) or 4MB/s ( 1Mhz)...

c.) or trying to write another smaller file with 8 bit format , )as it was suggested by @heuristic1 , and also agreed by @sharebrained : "It may still be valid for some use cases to change the recording format to “.cs8” (complex) if people want to record at 2x the bandwidth while losing a small amount of dynamic range. The processing gain from filtering and decimation only increases the useful bit resolution to about 10 bits, not 16. But obviously, it’s difficult to pack and store 10-bit values efficiently on a byte-based computer"

d-) just , adding some message in the GUI , when user selects higher BW than the maximum recording SD Card rate limit.

I think that in the near future we should apply others PR's with the final recording solution for BW> 600Khz , (a) , (b) , (c) or (d) . (to avoid any potential user confusion when recording files above 600Khz , (that are in fact , decimated ones, and not usefull for Replay App) .

see current experimental recording test :

Personally , I think that we should explore and investigate (b) and once we fix new extended recording SD card rate limit (maybe blue lines with fast micro SD Card) , then apply (d) to the rest of higher BW options .

F57A6D65-57B7-442D-ABF9-DFD8C0BF1786

Then any help on this issue , will be always welcome and highly appreciated ! .

I hope that you will also enjoy that feature , and hopefully , no side effects .

image
image
image
image

PR to increase the BW Options in the Capture App , beyond the current max, 500khz.  (from 600Khz till 2,75Mhz)  all of them work well into  the screen, but only <=  600Khz BW are correctly saved  into SD Card with full captured data. (Onwards, >600Khz optiions, at the moment ,  the created SD card  file has  decimated data, due - to SD Card writting speed limitations),-  but I feel still quite interesting feature to keep them.
@ArjanOnwezen
Copy link
Contributor

It would be good to create a menu in the debug section too later on, to set several settings.

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.

None yet

3 participants