This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
friedtj at free.fr friedtj at free.frFollowing my recent inquiry about direct sampling using the newer RTL2832U+R820T(2) DVB-T receivers: 1/ I know from past experience that the E4k based dongles work fine in direct sampling. Since the E4k is zero-IF, I could just get rid of the I+/I- or Q+/Q- capacitors and feed the RTL2832U with the signal I want to sample. This works fine. 2/ The proposed patch I got last week aimed at canceling the IF frequency since R820T(2) receivers are not zero-IF. Here I was failing to get any result. Going back to basics, I realized that using my old E4k in direct sampling mode (rtl=0,direct_samp=1 in Gnuradio-companion osmosdr source) is also not working. This is an unexpected behavior since E4k based dongle configuration should not change whether direct sampling is used or not. Indeed using the same dongle *without* the direct_samp option did generate the right results. I tried yesterday hacking librtlsdr in an ugly way to get raw samples from the 820T(2) based receiver (solving my short term concern of getting data). I could indeed acquire relevant raw samples by getting librtlsdr to believe I was using a E4k dongle by replacing line 1580 of librtlsdr.c (right after the "found:" label) with dev->tuner_type=RTLSDR_TUNER_E4000; now this induces a change in all the init functions with the function pointers just defined afterwards (&tuners[dev->tuner_type];). I have not yet tracked the difference between the init functions, but I think it would be more or less safe to jump to the E4k code in case the direct_samp option is given. JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France