Increase more BW Options to Capture App #433
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 .
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 ,
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)
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 .
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 .