Re: Help to remove DC offset

[Marcus Müller]

Hi Arhum,

some limited amount of DC offset is sadly to be expected from any direct conversion 
architecture (that's a result of LO leakage as well as systematic DC offset).


Since DC is the lowest of all possible frequencies, a high-pass filter can be used to 
eliminate it. The design of that filter depends on what you want to do with the signal 
afterwards – for example, for some communication system signals, the DC offset literally 
doesn't matter.


Another option is, if your signal is sufficiently more narrowband than the Nyquist 
bandwidth dictated by your receiver's sampling rate, to "offset-tune"; i.e., to put your 
signal of interest to the positive (or negative) side of your LO frequency, and then 
digitally shift the signal of interest to actual baseband and filter.


The USRPs bring that functionality out of the box, integrated into the device's digital 
part, so you can just deal with the signal decimated to the bandwidth you need in your 
computer. I'm not sure, but I don't think the HackRF allows for that. You'd have to 
offset-tune within your full sampling rate, and in GNU Radio use something like the "freq. 
X-lating FIR filter" to get the part of the spectrum you want.


Best regards,
Marcus

On 10.02.24 12:02, Arhum Ahmad wrote:

Hey all,

I'm currently working on frequency sensing using the HackRF SDR. However, when I 
calculate the FFT, I encounter a DC offset that's higher than the actual signal strength 
itself. This offset is interfering with my ability to detect the intended output 
accurately. Could you please assist me in understanding how to remove this DC offset?


--
*Thanks and Regards**
*
*Arhum Ahmad*
Ph.D. Scholar, Electrical Engineering Department, IIT Ropar

+91- 7974897279 | arhum.19eez0...@iitrpr.ac.in 



Lab No. 323, Communication Research Lab, J.C.Bose Building


*
/CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are 
intended solely for the addressee(s) and may contain confidential and/or privileged 
information and may be legally protected from disclosure. If you are not the intended 
recipient of this message or their agent, or if this message has been addressed to you 
in error, please immediately alert the sender by reply email and then delete this 
message and any attachments. If you are not the intended recipient, you are hereby 
notified that any use, dissemination, copying, or storage of this message or its 
attachments is strictly prohibited./

* 

OOT module 'gr-sdrplay3' and SDRplay API update (supports new model RSP1B)

[Franco VENTURI]

A few weeks ago SDRplay announced a new model, the RSP1B 
(https://www.sdrplay.com/rsp1b/); at the same time they also upgraded their API 
to version 3.14 in order to support the new hardware.
 
I have been working on a new branch ('sdrplay-api-3.14') for the OOT module 
'gr-sdrplay3' to work with the new SDRplay API and to support the RSP1B: 
https://github.com/fventuri/gr-sdrplay3/tree/sdrplay-api-3.14
 
Our initial tests are successful, and we are are able to use it with both the 
existing RSP modules and with the new RSP1B; I would like to have a few more 
people give it a try, and in a week or so merge these changes into the 'main' 
branch (the code in the current 'main' branch will become the branch 
'sdrplay-api-3.07' for those who have to keep the old SDRplay API for some 
reason, and it won't have any more changes), unless someone finds major 
problems in the new version.
 
Also we started a discussion with SDRplay about changing the defaults for AGC, 
DC offset correction, and IQ imbalance correction (they are currently disabled; 
they would become enabled be default).
Regarding this last item I would like to receive some feedback before making 
the changes; especially regarding what kind of application you use the 
'gr-sdrplay3' OOT module for: if it is more for scientific research/measurement 
purposes as opposed to listening to radio stations, or other use case scenarios.
I just created an 'issue' in my repository where you can write a couple of 
lines (or more, of course) about your use case, feedback, and suggestions: 
https://github.com/fventuri/gr-sdrplay3/issues/30 - if you don't have an 
account on GitHub or prefer email, you can email me directly.
 
73,
Franco K4VZ