From leif at sm5bsz.com Mon Oct 1 22:49:14 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Tue, 2 Oct 2012 00:49:14 +0200 Subject: Issues with rtl_tcp In-Reply-To: <20120927060321.12391.qmail@stuge.se> References: <5062D7AA.7050506@scottcutler.net> <20120926213343.10f7cc38.leif@sm5bsz.com> <20120927060321.12391.qmail@stuge.se> Message-ID: <20121002004914.85dd82c1.leif@sm5bsz.com> Hello Peter, > Your software (both source and binaries) undisputably constitutes a > derivative work of rtl-sdr, because it calls rtl-sdr. Well, my software will not call rtl-sdr if that package is not installed. I do not think "derivative" would be an appropriate description. What I want to achieve is that anyone who wants to use the dsp code that I wrote myself should be allowed to extract whatever he wants and use it in whatever way he wants. > A consequence is that your software is not really in the public > domain, as long as it calls rtl-sdr. > > Also keep in mind that the concept of public domain is problematic > across international copyright law. All nations do not allow an > author to abstain their copyright; I believe that's the case here > in Europe for example. I talked to a specialist. Sure I can abstain my copyright, but you are right - I am allowed to change my mind afterwords so anyone who uses it without a license faces a risk that I may change my mind. That is no good, seems I have to change my mind... > For maximum freedom I like to use the MIT license: > > http://opensource.org/licenses/MIT > > I understand the only requirement to be that copyright notices and > the license itself are also copied, when copying the source code. OK. Seems to solve all the problems, the cruicial thing is "substantial" here: "shall be included in all copies or substantial portions of the Software." It will be ok for anyone to take blocks from the dsp code and add into proprietary code without adding the license text. I do not think anyone would be interested in substantial portions of Linrad for other projects. My programming style is far from modern... > > The e4k tuner works very well, actually it is > > very competitive when compared to the FUNcube Pro dongle, > > but only with a modified library. > > http://www.sm5bsz.com/linuxdsp/hware/funcube/funcube.htm > > I urge you to work with the rtl-sdr maintainers to find how your > improvements can be reworked so that they are included in rtl-sdr. > > It is a waste of everyone's time that you keep some local changes. I sent some suggestions to Steve Markgraf. I hope he finds the mods I need to get good performance suitable for the rtl-sdr library. > Like authors of closed software you are circumventing the intent of > the rtl-sdr authors, but that is of course your prerogative. I actually find this hard to understand. What do you mean that their "intent" is? > To make your software unproblematic for others to use I urge you to > choose a permissive license that you like, in the list of popular > approved open source licenses. Here's the list: > http://opensource.org/licenses/category > > MIT is IMO the shortest and simplest of them. That's why I like it a > lot for maximum freedom software. Fine. It seems to do exactly what I want:-) Once I have given a license I can not change my mind. Or at least I will not easily be able to hurt someone who used it:-) Regards Leif / SM5BSZ From steve at steve-m.de Thu Oct 4 17:45:22 2012 From: steve at steve-m.de (Steve Markgraf) Date: Thu, 04 Oct 2012 19:45:22 +0200 Subject: Sweex USB dongle with rtl_sdr In-Reply-To: References: Message-ID: <506DCB32.1080204@steve-m.de> Hi, On 28.09.2012 21:02, Andrew Harrison wrote: > Can you add its id to the source code for others to use. Thanks, added. Regards, Steve From alain.prignet at univ-mlv.fr Wed Oct 17 14:13:32 2012 From: alain.prignet at univ-mlv.fr (Alain Prignet) Date: Wed, 17 Oct 2012 16:13:32 +0200 Subject: bug and parameters for rtl_fm Message-ID: <20121017141332.GA32005@smai4.emath.fr> Hello, I have found what I think is a bug in rtl_fm.c : on line 171 there is if (fm->prev_index < (fm->downsample)) { but fm->prev_index start at -1 so to get an undersampling of factor fm->downsample, one should have if (fm->prev_index < (fm->downsample-1)) { Without this correction, I get underruns, with this one, there is no underrun. Moreover, I have tried the idea of http://www.embedded.com/design/embedded/4212086/DSP-Tricks--Frequency-demodulation-algorithms- to avoid atan : +int polar_discriminant2(int ar, int aj, int br, int bj) +{ + int cr, cj; + double angle; + angle = (double)(ar * (aj - bj) - aj * (ar - br)) / (double)(ar*ar + aj*aj); + return (int)(angle*(1<<12)); +} Finally, to get good results, I use these parameters : DEFAULT_BUF_LENGTH (32 * 16384) capture_rate = 2304000 fm->downsample = 12 fm->post_downsample=8 sample_rate = 24000 Best regards, Alain Prignet From cd at maintech.de Wed Oct 17 16:55:42 2012 From: cd at maintech.de (Christian Daniel -- maintech GmbH) Date: Wed, 17 Oct 2012 18:55:42 +0200 Subject: News from the OsmoSDR frontier Message-ID: <507EE30E.6000102@maintech.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, since we found out that the Atmel SAM3U SSC interface is only capable of transporting 500ksps worth of I/Q data, we heard a lot of complaining because of the too narrow bandwith. Especially compared to the rtl-sdr with about 2msps, our 500ksps was bit contrained. The fact, that the OsmoSDR is much more sensitive to very small signals and brings a 14bit ADC instead of 8bits did not really compensate for the bandwidth loss. Also the mismatch between E4000 output resistance and ADC input brought some unwanted spectral effects. Instead of just releasing stuff, we decided to fix both issues: I now have a prototype with simple stack-on-board, that adds two op-amps to decouple the E4000 from the ADC and lower the impedance and also this board connecteds the available FPGA pins to the MCI (SD-Card) interface of the Atmel SAM3U. For this to get working, we had to rewrite major parts of the ARM firmware and the FPGA VHDL code. Today this work is completed and I can report success: The OsmoSDR now delivers up to 4msps at 14bits. Also the strange peaks around Niquist/zero frequency are gone. Find a screenshot of SDRangelove recording a DAB signal at 2msps (SDRangelove needs some more love until it can cope with 4msps in realtime - but we have verified that 4msps works without dropped samples using the builtin FPGA test mode). http://www.cdaniel.de/download/osmosdr-dab-2mhz.png We will now integrate the changes into the OsmoSDR mainboard and reroute the now free SSC pins to the pin headers instead of the MCI interface. Also we will add the opamps. For the already produced OsmoSDR boards, we will have more of the prototype stack-on-top-boards. We will keep you in the loop! Best regards, Christian PS: Regarding the DAB screenshot: - - The horizontal lines are correct - DAB uses a so called "pilot symbol", which only has energy on a few carriers. That's why it looks like a pause in the signal. - - The vertical line is also correct - DAB does not use the middle carrier to avoid I/Q offset problems on the transmitter side. - -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg | - --------------------------------------------------- | AG W?rzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd at maintech.de | - --------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQfuMIAAoJEHkgzUIsAWriHA0IAI2Agg0vnjLFa5dDpxu9AAkq 6crr1Q/XAgrlmN8TY86yoYTMjJc7IZmjsAAGpidczZtSbwbmLFuTdQEo12dOvaZZ GvkvNttoDE2zsnbU50MzWDK5BUcbfOJoQahX26P+8hbiaIsFKT8Gl8Ao9c2vz79u e04Cl2SodmDDKnV84VL9i39+KZdkGcsbCWnFizqGzTbWyDkoSVviZORp20a3lCEZ g8Af73jwDgVAU4lfrK9gO10G5jibHkQeULNIXFH8NbDiUPSF2557fGsu/9yC1UUC msT0g41x8twb5nesT4ZtWDfQ3tUBgvLHn/ebv9xBxCX1Wg1W2FAFlcajbXx4zRQ= =Taca -----END PGP SIGNATURE----- From 246tnt at gmail.com Wed Oct 17 17:18:40 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 17 Oct 2012 19:18:40 +0200 Subject: News from the OsmoSDR frontier In-Reply-To: <507EE30E.6000102@maintech.de> References: <507EE30E.6000102@maintech.de> Message-ID: Hi, First off: Just awesome ! :) > Also the strange peaks around Niquist/zero frequency are gone. I guess those were due to the impedance mismatch ? Did you also do a gain of 2 in there to boost the elonics output to use the ADC full range ? > http://www.cdaniel.de/download/osmosdr-dab-2mhz.png That's gorgeous :p Is there a manual DC offset corrected somewhere or is that the raw data from the DAC ? > For the already produced OsmoSDR boards, we will have more of the > prototype stack-on-top-boards. Do you already have the schematics ? Cheers, Sylvain From Shinji.Ikari_de at gmx.de Thu Oct 18 04:44:28 2012 From: Shinji.Ikari_de at gmx.de (Ronny Kunze) Date: Thu, 18 Oct 2012 06:44:28 +0200 Subject: News from the OsmoSDR frontier In-Reply-To: <507EE30E.6000102@maintech.de> References: <507EE30E.6000102@maintech.de> Message-ID: <507F892C.7080304@gmx.de> Hello , that are really good news. How can i get such a upgrade board ? Best regards, Ronny Kunze Am 17.10.2012 18:55, schrieb Christian Daniel -- maintech GmbH: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello everybody, > > since we found out that the Atmel SAM3U SSC interface is only capable > of transporting 500ksps worth of I/Q data, we heard a lot of > complaining because of the too narrow bandwith. Especially compared to > the rtl-sdr with about 2msps, our 500ksps was bit contrained. The > fact, that the OsmoSDR is much more sensitive to very small signals > and brings a 14bit ADC instead of 8bits did not really compensate for > the bandwidth loss. > > Also the mismatch between E4000 output resistance and ADC input > brought some unwanted spectral effects. > > Instead of just releasing stuff, we decided to fix both issues: I now > have a prototype with simple stack-on-board, that adds two op-amps to > decouple the E4000 from the ADC and lower the impedance and also this > board connecteds the available FPGA pins to the MCI (SD-Card) > interface of the Atmel SAM3U. > > For this to get working, we had to rewrite major parts of the ARM > firmware and the FPGA VHDL code. Today this work is completed and I > can report success: The OsmoSDR now delivers up to 4msps at 14bits. > Also the strange peaks around Niquist/zero frequency are gone. > > Find a screenshot of SDRangelove recording a DAB signal at 2msps > (SDRangelove needs some more love until it can cope with 4msps in > realtime - but we have verified that 4msps works without dropped > samples using the builtin FPGA test mode). > > http://www.cdaniel.de/download/osmosdr-dab-2mhz.png > > We will now integrate the changes into the OsmoSDR mainboard and > reroute the now free SSC pins to the pin headers instead of the MCI > interface. Also we will add the opamps. > > For the already produced OsmoSDR boards, we will have more of the > prototype stack-on-top-boards. > > We will keep you in the loop! > > Best regards, > Christian > > PS: Regarding the DAB screenshot: > - - The horizontal lines are correct - DAB uses a so called "pilot > symbol", which only has energy on a few carriers. That's why it looks > like a pause in the signal. > - - The vertical line is also correct - DAB does not use the middle > carrier to avoid I/Q offset problems on the transmitter side. > > - -- > - --------------------------------------------------- > | maintech # Dipl. Inf (FH) Christian Daniel | > | GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg | > - --------------------------------------------------- > | AG W?rzburg, HRB 8790 Tax-ID DE242279645 | > - --------------------------------------------------- > | http://www.maintech.de cd at maintech.de | > - --------------------------------------------------- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQfuMIAAoJEHkgzUIsAWriHA0IAI2Agg0vnjLFa5dDpxu9AAkq > 6crr1Q/XAgrlmN8TY86yoYTMjJc7IZmjsAAGpidczZtSbwbmLFuTdQEo12dOvaZZ > GvkvNttoDE2zsnbU50MzWDK5BUcbfOJoQahX26P+8hbiaIsFKT8Gl8Ao9c2vz79u > e04Cl2SodmDDKnV84VL9i39+KZdkGcsbCWnFizqGzTbWyDkoSVviZORp20a3lCEZ > g8Af73jwDgVAU4lfrK9gO10G5jibHkQeULNIXFH8NbDiUPSF2557fGsu/9yC1UUC > msT0g41x8twb5nesT4ZtWDfQ3tUBgvLHn/ebv9xBxCX1Wg1W2FAFlcajbXx4zRQ= > =Taca > -----END PGP SIGNATURE----- > From laforge at gnumonks.org Thu Oct 18 09:53:32 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 18 Oct 2012 11:53:32 +0200 Subject: News from the OsmoSDR frontier In-Reply-To: <507EE30E.6000102@maintech.de> References: <507EE30E.6000102@maintech.de> Message-ID: <20121018095332.GX18868@prithivi.gnumonks.org> Hi Christian, thanks for all your work and the major update. On Wed, Oct 17, 2012 at 06:55:42PM +0200, Christian Daniel -- maintech GmbH wrote: > For this to get working, we had to rewrite major parts of the ARM > firmware and the FPGA VHDL code. Today this work is completed and I > can report success: The OsmoSDR now delivers up to 4msps at 14bits. > Also the strange peaks around Niquist/zero frequency are gone. great! > We will now integrate the changes into the OsmoSDR mainboard and > reroute the now free SSC pins to the pin headers instead of the MCI > interface. Also we will add the opamps. Are you going to do more or less full re-route of the board? If yes, it might be worth designing the size such that it can fit into a standard-size (shielded metal) case. This doesn't mean that everyone would have to operate it in such a case, but at least it would be nice if an off-the-shelf case could be used. > For the already produced OsmoSDR boards, we will have more of the > prototype stack-on-top-boards. do those boards only address the opamp / matching, or actually the SD/MMC interface between FPGA and SAM3U? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From leif at sm5bsz.com Thu Oct 18 11:13:58 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Thu, 18 Oct 2012 13:13:58 +0200 Subject: Gain modes In-Reply-To: References: <502452AC.1040502@steve-m.de> Message-ID: <20121018131358.8c74c486.leif@sm5bsz.com> Hi All, The e4000 tuner is flexible in that it allows different gain distributions that optimize it for usage in different environments. With high gain near the antenna and low gain after the filters one can get a low noise figure and a good dynamic range for close range interference. The bad side is that the early stages can become saturated by signals at large frequency separations. If the user adds a bandpass filter for a narrow frequency range, this mode gives the best performance. With low gain near the antenna and high gain after the filters one can tolerate stronger signals at large frequency separation at the expense of a lower dynamic range for close spaced signals. This is useful when using the tuner without any filters. Besides the standard gain distribution which is a compromise I have added two more gain modes in Linrad. The function set_tuner_gain_mode() accepts values from 0 to 3 where 0 and 1 are identical to the original settings. The AGC mode does not work quite ok, it was better some months ago, but it does work with the batch below since it is no longer totally disabled. Always disabling the AGC in the rtl2832 chip may or may not be a good idea. The noise figures and points of saturation are similar at full gain in all modes. The table shows performance with the tuner set to 144.2 MHz with Linrad set to receive 144.5 MHz. The columns with a frequency show the signal level in dBm at each frequency that can be applied without A/D saturation or significant loss of S/N: Mode Gain NF 143.8 145.5 154.2 1 42 7.9 -53 -44 -43 2 25 8.3 -56 -44 -20 3 25 7.0 -59 -48 -20 Note what happens for 10 MHz separation. Better performance at wide range leads to worse performance at close range. In mode 2 there is a 3 dB dynamic range loss at close range. When the attenuator is set for a NF of about 17 dB (10 dB below optimum sensitivity for the desired signal, these data are obtained: Mode Gain NF 143.8 145.5 154.2 1 24 17 -41 -29 -30 2 10 20 -41 -30 -8 3 0 17 -34 -26 -16 The above was performed applying the pattc below to the library downloaded a couple of days ago. I do not think the changes will affect any other software that uses the library. The set_tuner_gain_mode() function now returns the gain mode or the highest allowed gain mode if the user tries to set a too high one. Before, the function always returned zero so there was no reason to check the return value. The patch is included below. If the basic principle is accepted for the osmocom library I guess defines should be moved to the header file and the global variable put into the dev structure. Regards Leif / SM5BSZ diff ../rtl-sdr-ref/src/librtlsdr.c src/librtlsdr.c 93a94,102 > // Sept 24 2012 SM5BSZ. Gain modes. > // Note that these things are used in tuner_e4k.c also. > // The routine using them should be moved to tuner_e4k.c > extern int e4k_gain_mode; > #define E4K_GAIN_MODE_OLD 1 > #define E4K_GAIN_MODE_LINEARITY 2 > #define E4K_GAIN_MODE_SENSITIVITY 3 > #define MAX_E4K_GAIN_MODES 3 > 127c136,140 < if(e4k_set_lna_gain(&devt->e4k_s, min(300, gain - mixgain * 10)) == -EINVAL) --- > // SM5BSZ Sept24 2012: Use only (the modified) set_lna_gain if the user > // asked for linearity or sensitivity. > if(e4k_gain_mode <= E4K_GAIN_MODE_OLD) > { > if(e4k_set_lna_gain(&devt->e4k_s, min(300, gain - mixgain * 10)) == -EINVAL) 129c142 < if(e4k_mixer_gain_set(&devt->e4k_s, mixgain) == -EINVAL) --- > if(e4k_mixer_gain_set(&devt->e4k_s, mixgain) == -EINVAL) 130a144 > // SM5BSZ: enhanced gain should affect how the AGC turns down the gain 132c146 < if(enhgain >= 0) --- > if(enhgain >= 0) 136c150,153 < return 0; --- > return 0; > } > e4k_set_lna_gain(&devt->e4k_s, gain); > return 0; 137a155 > 141a160 > 785a805,807 > // Sept 2012 SM5BSZ: Add standard gains > const int e4k_std_gains[] = { -250, -200, -150, -100, -50, 0, 50, > 100, 150, 200, 250}; 802c824,832 < ptr = (int *)e4k_gains; len = sizeof(e4k_gains); --- > // Sept 2012 SM5BSZ: Use standard gains (5 dB step) if gain is mode above 1. > if(e4k_gain_mode < 2) > { > ptr = (int *)e4k_gains; len = sizeof(e4k_gains); > } > else > { > ptr= (int *)e4k_std_gains; len = sizeof(e4k_std_gains); > } 879a910,922 > > // SM5BSZ Oct 17 2012 Reconfigure the rtl > if(mode) > { > /* enable SDR mode, disable DAGC (bit 5) */ > rtlsdr_demod_write_reg(dev, 0, 0x19, 0x05, 1); > } > else > { > /* enable AGC */ > rtlsdr_demod_write_reg(dev, 0, 0x19, 0x25, 1); > } > diff ../rtl-sdr-ref/src/tuner_e4k.c src/tuner_e4k.c 41a42,49 > // Sept 24 2012 SM5BSZ. Gain modes. > // Note that these things are used in librtlsdr.c also. > int e4k_gain_mode; > #define E4K_GAIN_MODE_OLD 1 > #define E4K_GAIN_MODE_LINEARITY 2 > #define E4K_GAIN_MODE_SENSITIVITY 3 > #define MAX_E4K_GAIN_MODES 3 > 659a668,671 > // SM5BSZ Sept 24 2012: Use all gain controls if gain mode > // is above 1 > if(e4k_gain_mode <= E4K_GAIN_MODE_OLD) > { 666a679,935 > } > if(e4k_gain_mode == E4K_GAIN_MODE_LINEARITY) > { > switch (gain) > { > case -250: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 0); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 9); > e4k_if_gain_set(e4k, 6, 6); > break; > > case -200: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 0); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 9); > break; > > case -150: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 0); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 9); > break; > > case -100: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 0); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 3); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 9); > break; > > case -50: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 0); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > > case 0: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 4); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > > case 50: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 6); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > > case 100: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 8); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > > > case 150: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 10); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > > case 200: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 12); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > > case 250: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 12); > e4k_if_gain_set(e4k, 6, 12); > break; > } > } > if(e4k_gain_mode == E4K_GAIN_MODE_SENSITIVITY) > { > switch (gain) > { > case -250: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 6); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case -200: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 8); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case -150: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 10); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case -100: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 12); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case -50: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 4); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case 0: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 2); > e4k_if_gain_set(e4k, 5, 3); > e4k_if_gain_set(e4k, 6, 3); > break; > > case 50: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, -3); > e4k_if_gain_set(e4k, 2, 3); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case 100: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, 6); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 6); > e4k_if_gain_set(e4k, 6, 3); > break; > > case 150: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, 6); > e4k_if_gain_set(e4k, 2, 0); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 2); > e4k_if_gain_set(e4k, 5, 9); > e4k_if_gain_set(e4k, 6, 3); > break; > break; > > case 200: > fprintf(stderr,"\nCASE 200"); > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, 6); > e4k_if_gain_set(e4k, 2, 3); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 1); > e4k_if_gain_set(e4k, 5, 9); > e4k_if_gain_set(e4k, 6, 6); > break; > > case 250: > e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 14); > e4k_mixer_gain_set(e4k, 12); > e4k_if_gain_set(e4k, 1, 6); > e4k_if_gain_set(e4k, 2, 6); > e4k_if_gain_set(e4k, 3, 0); > e4k_if_gain_set(e4k, 4, 0); > e4k_if_gain_set(e4k, 5, 9); > e4k_if_gain_set(e4k, 6, 9); > break; > } > } > return gain; 694a964,969 > // Sept 24 2012 SM5BSZ. Add a flag for more gain modes and return it > // so we know the library has this feature. > e4k_gain_mode=manual; > if(e4k_gain_mode > MAX_E4K_GAIN_MODES)e4k_gain_mode=MAX_E4K_GAIN_MODES; > return e4k_gain_mode; > 695a971 > e4k_gain_mode=0; 701a978 > From 246tnt at gmail.com Thu Oct 18 11:35:24 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 18 Oct 2012 13:35:24 +0200 Subject: Gain modes In-Reply-To: <20121018131358.8c74c486.leif@sm5bsz.com> References: <502452AC.1040502@steve-m.de> <20121018131358.8c74c486.leif@sm5bsz.com> Message-ID: Hi, Thanks for the tests and reporting. Some comments purely about the patch form and not the functionality itself (I'll leave that for the rtl-sdr maintainer to decide): >> // SM5BSZ Sept24 2012: Use only (the modified) set_lna_gain if the user >> // asked for linearity or sensitivity. Don't put comment logs in the code ... if you want to document what the code does it's fine, but the commit message is there for the date/name/change recording. Also, I think /* */ rather than // is the comment style in that project. >> switch (gain) >> { >> case -250: >> e4k_reg_set_mask(e4k, E4K_REG_GAIN1, 0xf, 0); >> e4k_mixer_gain_set(e4k, 4); >> e4k_if_gain_set(e4k, 1, -3); >> e4k_if_gain_set(e4k, 2, 0); >> e4k_if_gain_set(e4k, 3, 0); >> e4k_if_gain_set(e4k, 4, 0); >> e4k_if_gain_set(e4k, 5, 9); >> e4k_if_gain_set(e4k, 6, 6); >> break; That giant swith is just plain aweful. Either find a formula, or use tables. Cheers, Sylvain From cd at maintech.de Thu Oct 18 16:35:52 2012 From: cd at maintech.de (Christian Daniel -- maintech GmbH) Date: Thu, 18 Oct 2012 18:35:52 +0200 Subject: News from the OsmoSDR frontier In-Reply-To: References: <507EE30E.6000102@maintech.de> Message-ID: <50802FE8.8090408@maintech.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sylvain, thanks for the thumbs up :) On 17.10.2012 19:18, Sylvain Munaut wrote: > Hi, > > First off: Just awesome ! :) > > >> Also the strange peaks around Niquist/zero frequency are gone. > > I guess those were due to the impedance mismatch ? Yes, I think so, too. Every time the ADC opened the sample-and-hold circuit (low impedance), the high impedance of the E4000 caused a voltage drop. This means that the signal was overlaid with something exactly the frequency of the sample rate. Since this happened on I and Q equally, I assume this to be a pretty maths exercise for any communications engineering student. For the rest of us it is just a signal at the Niquist frequency, which appears either on the outer limits of the spectrum or at zero... At zero we would assume it to be a DC offset - but it isn't and that's why it wasn't easily compensated for or at least our algorithms didn't work very good. > Did you also do a gain of 2 in there to boost the elonics output > to use the ADC full range ? Yeppa, the impedance compensating op amps also have a gain of two. To be more precise, they have a I2C controlled potentiometer and the gain can be changed. This also makes it possible to do a hardware DC offset compensation and IQ imbalance compensation. However with the impedance mismatch gone, I think, this is not really needed anymore - the DC offset is quite simple to fix in software and the imbalance as well. Also adders/multipliers are in the FPGA datapath and we can do it there as well. The values are not so big that we absolutely need to do it on the analog side. > > >> http://www.cdaniel.de/download/osmosdr-dab-2mhz.png > > That's gorgeous :p > > Is there a manual DC offset corrected somewhere or is that the raw > data from the DAC ? You can see the DC offset compensation is switched off, but I forgot to also switch off the IQ imbalance compensation. To tell the truth there are some effects in the middle - much lower now, but still. Also routing the SDIO signal over wires or my stack-on-PCB is not a good idea. The noise is everywhere... >> For the already produced OsmoSDR boards, we will have more of >> the prototype stack-on-top-boards. > > Do you already have the schematics ? Yes of course. I will clean up my stuff and do a major check in tonight. > Cheers, Sylvain Cheers :) Christian - -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg | - --------------------------------------------------- | AG W?rzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd at maintech.de | - --------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQgC/iAAoJEHkgzUIsAWriP0MH/31PIlKXRWU97yNqvh2x//1p uZ6VXRKMGKuDCfK9kVCYM3RaBXJreJ2zLrs5PziEFWKC3P/y1mvWhuhCuWsH55Nm iSNvO2axUxT2tmOooffVsVMVYQkajEmjPGZuZV3IcPAMGQloElwCF4g+h7u+8gam QQCngMhx9rGIiGssaA8UQXzuWAa7mXFi1YpU2UnOrhC6n2ub/kMN3E/pTI5I4YdG cs5s+zY7WLaMVOn5bCbTRBFp7j+oly/0Ps6WTt9GisAuejBeMu88DrfrpMT4jc64 fIqB+a0YRkZUvLiq1fMO6x0XQtstCHJgNT3agB07bTXHETi+JGh/eEzyG7DosAw= =0LfS -----END PGP SIGNATURE----- From cd at maintech.de Thu Oct 18 16:37:27 2012 From: cd at maintech.de (Christian Daniel -- maintech GmbH) Date: Thu, 18 Oct 2012 18:37:27 +0200 Subject: News from the OsmoSDR frontier In-Reply-To: <507F892C.7080304@gmx.de> References: <507EE30E.6000102@maintech.de> <507F892C.7080304@gmx.de> Message-ID: <50803047.5090203@maintech.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, right now I have exactly one prototype. But we have more PCBs and we will populate them to fix the boards in the wild. When I have them ready, I will post it here. Best regards, Christian On 18.10.2012 06:44, Ronny Kunze wrote: > Hello , > > that are really good news. How can i get such a upgrade board ? > > Best regards, > > Ronny Kunze > > > Am 17.10.2012 18:55, schrieb Christian Daniel -- maintech GmbH: > Hello everybody, > > since we found out that the Atmel SAM3U SSC interface is only > capable of transporting 500ksps worth of I/Q data, we heard a lot > of complaining because of the too narrow bandwith. Especially > compared to the rtl-sdr with about 2msps, our 500ksps was bit > contrained. The fact, that the OsmoSDR is much more sensitive to > very small signals and brings a 14bit ADC instead of 8bits did not > really compensate for the bandwidth loss. > > Also the mismatch between E4000 output resistance and ADC input > brought some unwanted spectral effects. > > Instead of just releasing stuff, we decided to fix both issues: I > now have a prototype with simple stack-on-board, that adds two > op-amps to decouple the E4000 from the ADC and lower the impedance > and also this board connecteds the available FPGA pins to the MCI > (SD-Card) interface of the Atmel SAM3U. > > For this to get working, we had to rewrite major parts of the ARM > firmware and the FPGA VHDL code. Today this work is completed and > I can report success: The OsmoSDR now delivers up to 4msps at > 14bits. Also the strange peaks around Niquist/zero frequency are > gone. > > Find a screenshot of SDRangelove recording a DAB signal at 2msps > (SDRangelove needs some more love until it can cope with 4msps in > realtime - but we have verified that 4msps works without dropped > samples using the builtin FPGA test mode). > > http://www.cdaniel.de/download/osmosdr-dab-2mhz.png > > We will now integrate the changes into the OsmoSDR mainboard and > reroute the now free SSC pins to the pin headers instead of the > MCI interface. Also we will add the opamps. > > For the already produced OsmoSDR boards, we will have more of the > prototype stack-on-top-boards. > > We will keep you in the loop! > > Best regards, Christian > > PS: Regarding the DAB screenshot: - The horizontal lines are > correct - DAB uses a so called "pilot symbol", which only has > energy on a few carriers. That's why it looks like a pause in the > signal. - The vertical line is also correct - DAB does not use the > middle carrier to avoid I/Q offset problems on the transmitter > side. > > -- - --------------------------------------------------- | maintech > # Dipl. Inf (FH) Christian Daniel | | GmbH ### > Otto-Hahn-Str. 15 ? D-97204 H?chberg | > --------------------------------------------------- | AG W?rzburg, > HRB 8790 Tax-ID DE242279645 | > --------------------------------------------------- | > http://www.maintech.de cd at maintech.de | > --------------------------------------------------- >> > > - -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg | - --------------------------------------------------- | AG W?rzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd at maintech.de | - --------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQgDBCAAoJEHkgzUIsAWriFHUH/iThyWHVp0ZrE2s0HhPQ0CNp AwTSnwZRr4k4LMX9AhKyilhAW5faJesfDGXeUiRR9+nUIF1r3PmHZU+W0mAE22Bg MKc2DYDQyrY6QNpSYpfRxomAVjiMaoeTexeMzBJdYSYbG28T0DFHJeza2X6ASIjE FTBh5le07UyhFiUfmCNUeYKsk7Hsb3eOjv+hCTWqVvwbFvx230tBFJKqMOMny7nc DXEQcg+7MiC4fQQkFTjAs7W/g+428Wzope0cP0M4r2ejnpuiReOf2eCJN2FjTvIi DP64shlwKfy5eymYvfhGme21Dy5SQOAawDLOwI305NhBD0UVXfWpvuxRN52uXPQ= =6jxb -----END PGP SIGNATURE----- From cd at maintech.de Thu Oct 18 16:40:03 2012 From: cd at maintech.de (Christian Daniel -- maintech GmbH) Date: Thu, 18 Oct 2012 18:40:03 +0200 Subject: News from the OsmoSDR frontier In-Reply-To: <20121018095332.GX18868@prithivi.gnumonks.org> References: <507EE30E.6000102@maintech.de> <20121018095332.GX18868@prithivi.gnumonks.org> Message-ID: <508030E3.2050407@maintech.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Harald! On 18.10.2012 11:53, Harald Welte wrote: > Hi Christian, > > thanks for all your work and the major update. > > On Wed, Oct 17, 2012 at 06:55:42PM +0200, Christian Daniel -- > maintech GmbH wrote: >> For this to get working, we had to rewrite major parts of the >> ARM firmware and the FPGA VHDL code. Today this work is completed >> and I can report success: The OsmoSDR now delivers up to 4msps at >> 14bits. Also the strange peaks around Niquist/zero frequency are >> gone. > > great! > >> We will now integrate the changes into the OsmoSDR mainboard and >> reroute the now free SSC pins to the pin headers instead of the >> MCI interface. Also we will add the opamps. > > Are you going to do more or less full re-route of the board? If > yes, it might be worth designing the size such that it can fit into > a standard-size (shielded metal) case. This doesn't mean that > everyone would have to operate it in such a case, but at least it > would be nice if an off-the-shelf case could be used. A full re-routing will not be necessary, but the metal case is high on our priority list. Especially since I found a spectral line in the GPS range, which is kind of annoying when testing the GPS synchronisation stuff (it works when I put the OsmoSDR in a cookie box :). >> For the already produced OsmoSDR boards, we will have more of >> the prototype stack-on-top-boards. > > do those boards only address the opamp / matching, or actually the > SD/MMC interface between FPGA and SAM3U? Both, but you can test the SDIO interface alone if you put six wires on the connectors between SAM3U and the FPGA. Schematics will go to git tonight. > Regards, Harald Regards :) Christian - -- - --------------------------------------------------- | maintech # Dipl. Inf (FH) Christian Daniel | | GmbH ### Otto-Hahn-Str. 15 ? D-97204 H?chberg | - --------------------------------------------------- | AG W?rzburg, HRB 8790 Tax-ID DE242279645 | - --------------------------------------------------- | http://www.maintech.de cd at maintech.de | - --------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQgDDfAAoJEHkgzUIsAWri5KsH/3CAPPL2qbIEafp4aMxuF7BT f/H4L1gvyO9R6p9WEax+eyxyDtc81vgOiftxEHmnkgm+sAZhSHBXNqX0zsRUXiZc KzLyubE4Ua8DiYwKxTnFrHXzwAHVXPrf9YGuO0LKhvq2L4neR5Qrn/gEDyuyg7F6 4FzUeZ7KTUpMLpiKgxDDcpSSEHQ9/+wn1x2G++uFBnP+MkhyrRPq/UXPkNJNl6x/ 14AosL7Groy0hjpIYSlE4WLxIFrOWIdgd4uGWH56plGd2f11utE9AFnbMCzdTJYh mbDv0eCZP5N5yYdqV8ocvJkOZloJo5KcjgSBAkF1yXC72O4NiI5MIRED/+wA7rk= =iX6b -----END PGP SIGNATURE----- From mngc at citromail.hu Sun Oct 21 10:26:56 2012 From: mngc at citromail.hu (=?UTF-8?B?SMO2c3MgTGFqb3Mg?=) Date: Sun, 21 Oct 2012 12:26:56 +0200 Subject: =?UTF-8?B?UlRMLVNEUiB3aXRoIE1TSSBESUdJVk9YIE1pY3JvIEhEIHN1cHBvdA==?= Message-ID: <20121021122656.1249@citromail.hu> Hi, I have USB DVB-T stick. Possibly add suport for rtl-sdr? Name: MSI DIGIVOX Micro HD (Dexatek clone?, i see black diamond design, same as Dexatek, and i found 1d19 = Dexatek) USB ID (from linux and windows): 1d19:1104 Working (very old) driver for linux rtl2832u, my linux very old, i cannot complile the current rtl-sdr because libusb, etc. too old. I will ugrade to new linux, but requies long time. I not know how to identify the tuner, but from dmesg i think this device use rtl2832 chipset + FC2580 tuner I try with nightly build sdl-sharp, and the latest http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip on windows, no succes. mngc From steve at steve-m.de Sun Oct 21 15:24:54 2012 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 21 Oct 2012 17:24:54 +0200 Subject: RTL-SDR with MSI DIGIVOX Micro HD suppot In-Reply-To: <20121021122656.1249@citromail.hu> References: <20121021122656.1249@citromail.hu> Message-ID: <508413C6.7010906@steve-m.de> Hi, On 21.10.2012 12:26, H?ss Lajos wrote: > I have USB DVB-T stick. Possibly add suport for rtl-sdr? > USB ID (from linux and windows): 1d19:1104 Added the new ID. It can take some time until the windows build will be updated, though. Regards, Steve From pelletier.michel at gmail.com Sun Oct 21 17:25:18 2012 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 21 Oct 2012 10:25:18 -0700 Subject: Beginner question about rtlsdr Message-ID: Hello everyone, I hope this is an appropriate forum for a beginner question about using an E4000 dongle. I'm an amateur astronomer, and lately I've been wanting to get into amateur radio astronomy. The rtlsdr seems like a really cheap way to get involved. It can tune many interesting frequencies, in particular channel 37 around 608-614 Mhz. I am a Python programmer by trade so I am using roger-'s amazing pyrtlsdr library which is great, I can read samples from the device and they get returned as numpy arrays. The scipy.signal package allows me to correctly decimate the signal and I am working on a simple graphing program to graph signal levels in realtime, by hour, by day, and by week. I hope to basically reproduce the Jansky experiment that started the entire science of radio astronomy: http://en.wikipedia.org/wiki/Karl_Guthe_Jansky I have a question though about how to use the dongle that I can't quite figure out. roger-'s demo_waterfall program, for example, sets the default sample_rate to 1.4e6, but then on each scan only calls read_samples(2**16). The demo displays the entire megahertz of bandwidth, so I'm a bit confused as to how the 64K samples map onto the 1M samples of the device. It doesn't seem to make sense taht the device only returns the first 64K samples. Can anyone clue in a total beginner on the sample rate and reading samples from the device correlate? Thank you! -Michel From scott at scottcutler.net Sun Oct 21 20:12:26 2012 From: scott at scottcutler.net (Scott Cutler) Date: Sun, 21 Oct 2012 13:12:26 -0700 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: <5084572A.204@scottcutler.net> To get from the time domain (the raw samples) to the frequency domain (waterfall display, etc.), you need an FFT. The FFT operates on some given buffer size, and outputs a buffer of the same size filled with complex frequency levels (where the magnitude squared is the signal energy). The FFT width determines your frequency resolution, not the bandwidth. The bandwidth is determined by the sample rate--in your case, 1.4 MHz. So you choose your FFT based on your resolution and performance requirements. In your case, the FFT will return frequencies from -0.7 to 0.7 MHz around the center frequency--no matter what the FFT width. The FFT results store the positive frequencies from 1..(N/2-1) and the negative ones from (N/2+1)..(N-1). Sample 0 is 0 Hz and N/2 is 0.7 MHz (you can't really use this last one since it aliases). The other frequencies scale linearly between these points (sample N/4 is 0.35 MHz, etc.). For a waterfall display, this generally means you want to swap the left and right halves of a buffer. You can read as many samples as you want from the device. Conceptually, it's similar to an audio device--if you need more samples, you just wait longer. You could collect 64M samples if you wanted, and get some nice sub-Hz resolution, but it would take 45 s to record at your settings. There is of course a tradeoff between time and frequency resolution. I don't know much about radio astronomy, but you'll probably want to figure out what the shortest timescale events you'd like to track are, and choose the FFT width based on that. Incidentally, none of this is peculiar to rtl-sdr--even the fanciest and most expensive units operate the same way, though they have higher sample rates and such. In fact, the stuff I said is fundamental to all signal processing--if you're willing to get your hands dirty with math, you might want to read the wiki articles on Fourier Transforms and other signal processing subjects. -Scott On 10/21/2012 10:25 AM, Michel Pelletier wrote: > Hello everyone, I hope this is an appropriate forum for a beginner > question about using an E4000 dongle. > > I'm an amateur astronomer, and lately I've been wanting to get into > amateur radio astronomy. The rtlsdr seems like a really cheap way to > get involved. It can tune many interesting frequencies, in particular > channel 37 around 608-614 Mhz. > > I am a Python programmer by trade so I am using roger-'s amazing > pyrtlsdr library which is great, I can read samples from the device > and they get returned as numpy arrays. The scipy.signal package > allows me to correctly decimate the signal and I am working on a > simple graphing program to graph signal levels in realtime, by hour, > by day, and by week. I hope to basically reproduce the Jansky > experiment that started the entire science of radio astronomy: > > http://en.wikipedia.org/wiki/Karl_Guthe_Jansky > > I have a question though about how to use the dongle that I can't > quite figure out. roger-'s demo_waterfall program, for example, sets > the default sample_rate to 1.4e6, but then on each scan only calls > read_samples(2**16). The demo displays the entire megahertz of > bandwidth, so I'm a bit confused as to how the 64K samples map onto > the 1M samples of the device. It doesn't seem to make sense taht the > device only returns the first 64K samples. Can anyone clue in a total > beginner on the sample rate and reading samples from the device > correlate? > > Thank you! > > -Michel > From peter at stuge.se Sun Oct 21 20:22:36 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 21 Oct 2012 22:22:36 +0200 Subject: Beginner question about rtlsdr In-Reply-To: <5084572A.204@scottcutler.net> References: <5084572A.204@scottcutler.net> Message-ID: <20121021202236.26542.qmail@stuge.se> Scott Cutler wrote: > To get from the time domain (the raw samples) to the frequency domain > (waterfall display, etc.), you need an FFT. .. > In fact, the stuff I said is fundamental to all signal processing And as it happens, the GNU Radio package allows to snap many powerful signal processing blocks together using python. Don't reinvent a square wheel. Learn to use GNU Radio. //Peter From pelletier.michel at gmail.com Sun Oct 21 22:24:11 2012 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 21 Oct 2012 15:24:11 -0700 Subject: Beginner question about rtlsdr In-Reply-To: <5084572A.204@scottcutler.net> References: <5084572A.204@scottcutler.net> Message-ID: Scott, Thanks so much for your detailed reply. As an optical amateur I am really excited to be immersed in a new world of very interesting concepts related to radio astronomy. Thanks for patiently explaining to me how I was getting it wrong. I've read the wikipedia pages on FFT and some of the history and I think I get, at least abstractly, the distinction now. On Sun, Oct 21, 2012 at 1:12 PM, Scott Cutler wrote: > To get from the time domain (the raw samples) to the frequency domain > (waterfall display, etc.), you need an FFT. The FFT operates on some given > buffer size, and outputs a buffer of the same size filled with complex > frequency levels (where the magnitude squared is the signal energy). I don't think I want a waterfall "frequency domain" display however (I didn't know that, until I read the references you pointed me toward), I suspect that what I want is the time domain. From a very simple perspective, and initially to recreate the Jansky experiment, I just want the signal strength over a wide bandwidth plotted over time. Jansky used a simple pen plotter of signal strength (again, according to wikipedia) to chart the passage of a strong radio signal across his local zenith. After discovering the period was a sidereal day he consulted a sky chart and realized it was Sagittarius. > The FFT width determines your frequency resolution, not the bandwidth. The > bandwidth is determined by the sample rate--in your case, 1.4 MHz. > > So you choose your FFT based on your resolution and performance > requirements. In your case, the FFT will return frequencies from -0.7 to > 0.7 MHz around the center frequency--no matter what the FFT width. The FFT > results store the positive frequencies from 1..(N/2-1) and the negative ones > from (N/2+1)..(N-1). Sample 0 is 0 Hz and N/2 is 0.7 MHz (you can't really > use this last one since it aliases). The other frequencies scale linearly > between these points (sample N/4 is 0.35 MHz, etc.). For a waterfall > display, this generally means you want to swap the left and right halves of > a buffer. > > You can read as many samples as you want from the device. Conceptually, it's > similar to an audio device--if you need more samples, you just wait longer. > You could collect 64M samples if you wanted, and get some nice sub-Hz > resolution, but it would take 45 s to record at your settings. Ok, I think I'm getting the picture of this, and it's very enlightening. I think that I just want the signal strength of the entire bandwidth over time. Which I believe I can get by simply summing the magnitude squared of all my samples taken, and plot that over time. Does that sound right to you? I eventually plan to try and do some basic interferometry, where multiple observations are taken and combined to synthesize an aperture capable of resolving point sources. But I'm way far away from doing that or even really understanding it other than from a high level. There is an excellent python package called aipy that is developed by a group of radio astronomers that is used for a large scale 64 antenna array in southern Australia that I would eventually like to use to combine multiple sources. The whole sky images they have developed so far from cheap (compared to multi-meter dishes) crossed dipole arrays are very impressive. This may be utterly foolish thinking, but I really hope something like rtlsdr, or something like it terms of price, can bring large scale interferometry to the masses. > Incidentally, none of this is peculiar to rtl-sdr--even the fanciest and > most expensive units operate the same way, though they have higher sample > rates and such. In fact, the stuff I said is fundamental to all signal > processing--if you're willing to get your hands dirty with math, you might > want to read the wiki articles on Fourier Transforms and other signal > processing subjects. Thanks Scott, I'm digging deep and consuming as much information on the subject as I can. Can you recommend any standard works on signal processing I should dig into? -Michel From pelletier.michel at gmail.com Sun Oct 21 22:29:14 2012 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 21 Oct 2012 15:29:14 -0700 Subject: Beginner question about rtlsdr In-Reply-To: <20121021202236.26542.qmail@stuge.se> References: <5084572A.204@scottcutler.net> <20121021202236.26542.qmail@stuge.se> Message-ID: > > And as it happens, the GNU Radio package allows to snap many powerful > signal processing blocks together using python. Thanks Peter, I have installed gnu-radio and played around with it and rtlsdr, it was great for getting immediate results and picking around through the spectrum to see what's around. If it provides functionality for radio astronomy, of course i would love to use it, but my very initial investigation didn't reveal much for me. > Don't reinvent a square wheel. Learn to use GNU Radio. No square wheels here, pyrtlsdr, numpy, scipy, and matplotlib, are the precisely machined wheels I'm using so far to just dump and examine data. Any attempt on my part to implement any form of advanced signal processing would be totally foolish. -Michel From peter at stuge.se Sun Oct 21 22:45:14 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 22 Oct 2012 00:45:14 +0200 Subject: Beginner question about rtlsdr In-Reply-To: References: <5084572A.204@scottcutler.net> <20121021202236.26542.qmail@stuge.se> Message-ID: <20121021224514.4643.qmail@stuge.se> Michel Pelletier wrote: > > And as it happens, the GNU Radio package allows to snap many powerful > > signal processing blocks together using python. > > Thanks Peter, I have installed gnu-radio and played around with it and > rtlsdr, it was great for getting immediate results and picking around > through the spectrum to see what's around. If it provides > functionality for radio astronomy, of course i would love to use it, > but my very initial investigation didn't reveal much for me. I think it may provide the primitive blocks that you need, even if they weren't specifically created for radio astronomy. > No square wheels here, pyrtlsdr, numpy, scipy, and matplotlib, are > the precisely machined wheels I'm using so far to just dump and > examine data. One cool thing about GNU Radio is that while you use python to snap blocks together the data path is compiled code, so it will beat the performance of pure-python implementations. I don't know if numpy, scipy, and matplotlib are, but worth keeping in mind. Anyway, it's another option - if you need one specific simple signal process then GNU Radio may be overkill, and if it's simple enough with no bad performance tradeoff then reinventing that wheel can be fun and educational. //Peter From scott at scottcutler.net Sun Oct 21 23:04:43 2012 From: scott at scottcutler.net (Scott Cutler) Date: Sun, 21 Oct 2012 16:04:43 -0700 Subject: Beginner question about rtlsdr In-Reply-To: References: <5084572A.204@scottcutler.net> Message-ID: <50847F8B.5080509@scottcutler.net> Happy to help. I had to guess a bit on your level of background knowledge, but it sounds like I didn't go too over or under your head. If you just want the energy over the entire sampled bandwidth, you are correct that you can just average the samples squared. I believe this is equivalent to a "1 sample FFT", which as it happens is just the original value. So averaging the squares over time will give you a nice smoothed energy value. Note that by changing the sample rate, you can change the window size--the rtl-sdr chip supports from 250 kHz to 3.2 MHz. So that at least gives you coarse-grained control over your window. That said, you will almost certainly want to use a frequency view once you start really digging into this. So keep that in mind, even if in the short term you play with something simpler. Your goals with interferometry are ambitious, but not absurdly so! The rtl-sdr units have problems with frequency stability, and will be hard to synchronize--but these aren't necessarily insurmountable problems. It would be awesome to see progress here. Unfortunately, I don't have any good references for texts. I honestly use Wikipedia for most of my information. Maybe some others here have recommendations. -Scott On 10/21/2012 3:24 PM, Michel Pelletier wrote: > Scott, > > Thanks so much for your detailed reply. As an optical amateur I am > really excited to be immersed in a new world of very interesting > concepts related to radio astronomy. Thanks for patiently explaining > to me how I was getting it wrong. I've read the wikipedia pages on > FFT and some of the history and I think I get, at least abstractly, > the distinction now. > > On Sun, Oct 21, 2012 at 1:12 PM, Scott Cutler wrote: >> To get from the time domain (the raw samples) to the frequency domain >> (waterfall display, etc.), you need an FFT. The FFT operates on some given >> buffer size, and outputs a buffer of the same size filled with complex >> frequency levels (where the magnitude squared is the signal energy). > I don't think I want a waterfall "frequency domain" display however (I > didn't know that, until I read the references you pointed me toward), > I suspect that what I want is the time domain. From a very simple > perspective, and initially to recreate the Jansky experiment, I just > want the signal strength over a wide bandwidth plotted over time. > Jansky used a simple pen plotter of signal strength (again, according > to wikipedia) to chart the passage of a strong radio signal across his > local zenith. After discovering the period was a sidereal day he > consulted a sky chart and realized it was Sagittarius. > >> The FFT width determines your frequency resolution, not the bandwidth. The >> bandwidth is determined by the sample rate--in your case, 1.4 MHz. >> >> So you choose your FFT based on your resolution and performance >> requirements. In your case, the FFT will return frequencies from -0.7 to >> 0.7 MHz around the center frequency--no matter what the FFT width. The FFT >> results store the positive frequencies from 1..(N/2-1) and the negative ones >> from (N/2+1)..(N-1). Sample 0 is 0 Hz and N/2 is 0.7 MHz (you can't really >> use this last one since it aliases). The other frequencies scale linearly >> between these points (sample N/4 is 0.35 MHz, etc.). For a waterfall >> display, this generally means you want to swap the left and right halves of >> a buffer. >> >> You can read as many samples as you want from the device. Conceptually, it's >> similar to an audio device--if you need more samples, you just wait longer. >> You could collect 64M samples if you wanted, and get some nice sub-Hz >> resolution, but it would take 45 s to record at your settings. > Ok, I think I'm getting the picture of this, and it's very > enlightening. I think that I just want the signal strength of the > entire bandwidth over time. Which I believe I can get by simply > summing the magnitude squared of all my samples taken, and plot that > over time. Does that sound right to you? > > I eventually plan to try and do some basic interferometry, where > multiple observations are taken and combined to synthesize an aperture > capable of resolving point sources. But I'm way far away from doing > that or even really understanding it other than from a high level. > There is an excellent python package called aipy that is developed by > a group of radio astronomers that is used for a large scale 64 antenna > array in southern Australia that I would eventually like to use to > combine multiple sources. The whole sky images they have developed so > far from cheap (compared to multi-meter dishes) crossed dipole arrays > are very impressive. This may be utterly foolish thinking, but I > really hope something like rtlsdr, or something like it terms of > price, can bring large scale interferometry to the masses. > >> Incidentally, none of this is peculiar to rtl-sdr--even the fanciest and >> most expensive units operate the same way, though they have higher sample >> rates and such. In fact, the stuff I said is fundamental to all signal >> processing--if you're willing to get your hands dirty with math, you might >> want to read the wiki articles on Fourier Transforms and other signal >> processing subjects. > Thanks Scott, I'm digging deep and consuming as much information on > the subject as I can. Can you recommend any standard works on signal > processing I should dig into? > > -Michel From pelletier.michel at gmail.com Sun Oct 21 23:12:15 2012 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 21 Oct 2012 16:12:15 -0700 Subject: Beginner question about rtlsdr In-Reply-To: <20121021224514.4643.qmail@stuge.se> References: <5084572A.204@scottcutler.net> <20121021202236.26542.qmail@stuge.se> <20121021224514.4643.qmail@stuge.se> Message-ID: On Sun, Oct 21, 2012 at 3:45 PM, Peter Stuge wrote: > One cool thing about GNU Radio is that while you use python to snap > blocks together the data path is compiled code, so it will beat the > performance of pure-python implementations. I don't know if numpy, > scipy, and matplotlib are, but worth keeping in mind. Thanks a lot, in this case I'm passing pointer data from one C function to another, the python interpreter loop adds very little overhead, at least for the data collection step. For any kind of visual or interactive setup I'll no doubt be looking at GR. > Anyway, it's another option - if you need one specific simple signal > process then GNU Radio may be overkill, and if it's simple enough > with no bad performance tradeoff then reinventing that wheel can be > fun and educational. I love options! And I do confess to enjoy inventing a wheel or two. No one in their right mind would write another Forth compiler... oh wait. -Michel From jsalsburg at bellsouth.net Mon Oct 22 00:50:40 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 21 Oct 2012 19:50:40 -0500 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: Hello May I suggested a few things not related to the "Programming" issues but related to the Radio Astronomy subject? Just like retail, about "Location, Location, Location," Radio Astronomy's is about the "Antenna, Antenna, Antenna." One thing the TV Dongle offers for Radio Astronomers is the ease of placing the receiver (Dongle) on the Antenna. The USB must be extended from the Computer to the Antenna, instead of bringing the Signal from the Antenna to the Dongle. The advantage is lower noise and higher gain (without noise). There are many references on the Internet for extending USB, some for purchase, some DIY. Extending the USB is not limited to Radio Astronomy... -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Michel Pelletier Sent: Sunday, October 21, 2012 12:25 PM To: osmocom-sdr at lists.osmocom.org Subject: Beginner question about rtlsdr Hello everyone, I hope this is an appropriate forum for a beginner question about using an E4000 dongle. I'm an amateur astronomer, and lately I've been wanting to get into amateur radio astronomy. The rtlsdr seems like a really cheap way to get involved. It can tune many interesting frequencies, in particular channel 37 around 608-614 Mhz. I am a Python programmer by trade so I am using roger-'s amazing pyrtlsdr library which is great, I can read samples from the device and they get returned as numpy arrays. The scipy.signal package allows me to correctly decimate the signal and I am working on a simple graphing program to graph signal levels in realtime, by hour, by day, and by week. I hope to basically reproduce the Jansky experiment that started the entire science of radio astronomy: http://en.wikipedia.org/wiki/Karl_Guthe_Jansky I have a question though about how to use the dongle that I can't quite figure out. roger-'s demo_waterfall program, for example, sets the default sample_rate to 1.4e6, but then on each scan only calls read_samples(2**16). The demo displays the entire megahertz of bandwidth, so I'm a bit confused as to how the 64K samples map onto the 1M samples of the device. It doesn't seem to make sense taht the device only returns the first 64K samples. Can anyone clue in a total beginner on the sample rate and reading samples from the device correlate? Thank you! -Michel ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2741 / Virus Database: 2614/5846 - Release Date: 10/21/12 From pelletier.michel at gmail.com Mon Oct 22 01:22:21 2012 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 21 Oct 2012 18:22:21 -0700 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 5:50 PM, Jay Salsburg wrote: > Hello > > May I suggested a few things not related to the "Programming" issues but > related to the Radio Astronomy subject? Just like retail, about "Location, > Location, Location," Radio Astronomy's is about the "Antenna, Antenna, > Antenna." One thing the TV Dongle offers for Radio Astronomers is the ease > of placing the receiver (Dongle) on the Antenna. The USB must be extended > from the Computer to the Antenna, instead of bringing the Signal from the > Antenna to the Dongle. The advantage is lower noise and higher gain (without > noise). There are many references on the Internet for extending USB, some > for purchase, some DIY. Thanks Jay, I'm personally fascinated by the scientific aspects of the subject so I do appreciate your comment. I'm not sure if you're referring to the link I posted in this thread to a picture of my telescope, but I did as you suggested an embedded the dongle directly in the cantenna. My extension is a simple usb cable as my computer is just across the wall, although for my next antenna on the other side of my property, I intend to use a small dlink access point device flashed with openwrt and using usb over IP and power over ethernet to extend the other data source to my computer. This will give me a single interferometric baseline to begin using packages like aipy. I have the parts, I'm still piecing together the receiver. I live in Western Oregon so weatherproofing is key. :) FWIW the EOR array uses simple, omnidirectional crossed dipoles and Python: http://eor.berkeley.edu/ That's a pretty gorgeous picture of Centaurus A for some simple dipoles! Here is an excellent presentation on the python technology behind it: http://setiathome.berkeley.edu/~aparsons/papers/2008-08-10_LFSW_AIPY_Presentation.pdf there are some pretty pictures at the end. All of the software parts of the interferometry are basically done, what is needed is to vet the possibility that something like an rtlsdr dongle and a simple antenna, arrayed across an area, can produce data of sufficient quality to feed into a package like aipy. As roger-'s ecellent pyrtlsdr can already capture dongle complex data directly into numpy arrays, it seems like all the pieces are laying around, simply needing to be put together, and I intend to try it. As an update, thanks to Scott's great help I am currently dumping data at 1420 Mhz center frequency into numpy arrays and averaging their squares. Here's the simple "core" of my loop: while True: yield numpy.average(numpy.absolute(radio.read_samples(2**20))) I'm accumulating one average per secondish and dumping them into a data file that I am plotting on a simple graph. Cassiopeia reaches maximum at my local position around midnight, and the graph is currently trending upward. I'm really hoping that by morning I'll have a nice curve that peaks at midnight and hopefully not a bunch of random squiggles. :) -Michel From jsalsburg at bellsouth.net Mon Oct 22 02:00:37 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 21 Oct 2012 21:00:37 -0500 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: Hello Michel OK, I see you are way ahead of me. However, I have some experience using these TV Dongles, they have pitfalls. Number one is its frequency Accuracy, out-of-the-box; needs calibration. Another is that its frequency accuracy drifts over time and from the Ambient temperature necessitating periodic offset calibration. While it is possible to create a compensation cure for frequency drift vs. temperature, it may be far more prudent to place the Dongle in a temperature controlled enclosure (50C Heater) keeping it above the ambient to help prevent drift, in your case, the all too important Temperature related Phase Shift. I have thought of disconnecting the Dongle's Crystal and placing it in a Crystal Oven, but I have not tried that. The Entire Dongle is small enough to place it in a temperature controlled enclosure which also keeps it dry. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Michel Pelletier Sent: Sunday, October 21, 2012 8:22 PM To: Jay Salsburg Cc: osmocom-sdr at lists.osmocom.org Subject: Re: Beginner question about rtlsdr On Sun, Oct 21, 2012 at 5:50 PM, Jay Salsburg wrote: > Hello > > May I suggested a few things not related to the "Programming" issues > but related to the Radio Astronomy subject? Just like retail, about > "Location, Location, Location," Radio Astronomy's is about the > "Antenna, Antenna, Antenna." One thing the TV Dongle offers for Radio > Astronomers is the ease of placing the receiver (Dongle) on the > Antenna. The USB must be extended from the Computer to the Antenna, > instead of bringing the Signal from the Antenna to the Dongle. The > advantage is lower noise and higher gain (without noise). There are > many references on the Internet for extending USB, some for purchase, some DIY. Thanks Jay, I'm personally fascinated by the scientific aspects of the subject so I do appreciate your comment. I'm not sure if you're referring to the link I posted in this thread to a picture of my telescope, but I did as you suggested an embedded the dongle directly in the cantenna. My extension is a simple usb cable as my computer is just across the wall, although for my next antenna on the other side of my property, I intend to use a small dlink access point device flashed with openwrt and using usb over IP and power over ethernet to extend the other data source to my computer. This will give me a single interferometric baseline to begin using packages like aipy. I have the parts, I'm still piecing together the receiver. I live in Western Oregon so weatherproofing is key. :) FWIW the EOR array uses simple, omnidirectional crossed dipoles and Python: http://eor.berkeley.edu/ That's a pretty gorgeous picture of Centaurus A for some simple dipoles! Here is an excellent presentation on the python technology behind it: http://setiathome.berkeley.edu/~aparsons/papers/2008-08-10_LFSW_AIPY_Present ation.pdf there are some pretty pictures at the end. All of the software parts of the interferometry are basically done, what is needed is to vet the possibility that something like an rtlsdr dongle and a simple antenna, arrayed across an area, can produce data of sufficient quality to feed into a package like aipy. As roger-'s ecellent pyrtlsdr can already capture dongle complex data directly into numpy arrays, it seems like all the pieces are laying around, simply needing to be put together, and I intend to try it. As an update, thanks to Scott's great help I am currently dumping data at 1420 Mhz center frequency into numpy arrays and averaging their squares. Here's the simple "core" of my loop: while True: yield numpy.average(numpy.absolute(radio.read_samples(2**20))) I'm accumulating one average per secondish and dumping them into a data file that I am plotting on a simple graph. Cassiopeia reaches maximum at my local position around midnight, and the graph is currently trending upward. I'm really hoping that by morning I'll have a nice curve that peaks at midnight and hopefully not a bunch of random squiggles. :) -Michel ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2741 / Virus Database: 2614/5846 - Release Date: 10/21/12 From pelletier.michel at gmail.com Mon Oct 22 02:13:12 2012 From: pelletier.michel at gmail.com (Michel Pelletier) Date: Sun, 21 Oct 2012 19:13:12 -0700 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 7:00 PM, Jay Salsburg wrote: > Hello Michel > > OK, I see you are way ahead of me. However, I have some experience using > these TV Dongles, they have pitfalls. Number one is its frequency Accuracy, > out-of-the-box; needs calibration. Another is that its frequency accuracy > drifts over time and from the Ambient temperature necessitating periodic > offset calibration. While it is possible to create a compensation cure for > frequency drift vs. temperature, it may be far more prudent to place the > Dongle in a temperature controlled enclosure (50C Heater) keeping it above > the ambient to help prevent drift, in your case, the all too important > Temperature related Phase Shift. I have thought of disconnecting the > Dongle's Crystal and placing it in a Crystal Oven, but I have not tried > that. The Entire Dongle is small enough to place it in a temperature > controlled enclosure which also keeps it dry. Interesting! I was actually considering going the other way, and putting the radio in a Peltier cooled enclosure, but that was based only on my experience with cooling digital cameras for astrophotography purposes to lower noise. I just instinctively figured that lower temperatures would equate to lower noise in a radio receiver as well, but I have no experience with the kind of accuracy drift or phase shift you're talking about. Well, this is definitely something I will keep in mind when I try to capture my first baseline. :) -Michel From jsalsburg at bellsouth.net Mon Oct 22 03:53:47 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 21 Oct 2012 22:53:47 -0500 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: Hello Michel The fact about Cooling Electronics comes down to how much benefit is obtained by lowering the chip temperature. While lowering the temperature of CCDs contributes to lowering the Chip's Dark Current and single pixel artifacts, the benefits to reducing noise of Low Noise Radio Frequency Amplifiers is not very effective, at least from what a Peltier cooler would provide. Reducing noise in RF Amps will only be useful if you can reduce the "System Noise Temperature" (in Kelvin) by a factor of 4, resulting in doubling the effective communication range (number of Light Years). Examples of Cooling a GaAs PHEMT preamp with a noise temp of 50K at Room Ambient, with Dry Ice might at the most, reduce its noise by 35%; only a small improvement. However, the Antenna noise, plus Sky noise, plus Earth noise is the source of much of the unwanted noise, not the Amplifier hence the advantage of Space-based Receivers. So cooling an LNA with Dry Ice plus the unavoidable environmental noise provides only an 8% improvement. Cooling with a Peltier device or Dry Ice, while providing some benefit, is not worth the trouble. Cryogenic cooling provides a more desired effect. Placing a Cryogenic LNA (Liquid Helium) in front of the Tuner will definitely increase your Light Years, however, this technique is logistically complex and expensive, but possible. The obvious direction is toward an Array. This provides a solution to reduce noise through Signal Processing, with the down side of needing many more receivers and physical space for the Array. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Michel Pelletier Sent: Sunday, October 21, 2012 9:13 PM To: Jay Salsburg Cc: osmocom-sdr at lists.osmocom.org Subject: Re: Beginner question about rtlsdr On Sun, Oct 21, 2012 at 7:00 PM, Jay Salsburg wrote: > Hello Michel > > OK, I see you are way ahead of me. However, I have some experience > using these TV Dongles, they have pitfalls. Number one is its > frequency Accuracy, out-of-the-box; needs calibration. Another is that > its frequency accuracy drifts over time and from the Ambient > temperature necessitating periodic offset calibration. While it is > possible to create a compensation cure for frequency drift vs. > temperature, it may be far more prudent to place the Dongle in a > temperature controlled enclosure (50C Heater) keeping it above the > ambient to help prevent drift, in your case, the all too important > Temperature related Phase Shift. I have thought of disconnecting the > Dongle's Crystal and placing it in a Crystal Oven, but I have not > tried that. The Entire Dongle is small enough to place it in a temperature controlled enclosure which also keeps it dry. Interesting! I was actually considering going the other way, and putting the radio in a Peltier cooled enclosure, but that was based only on my experience with cooling digital cameras for astrophotography purposes to lower noise. I just instinctively figured that lower temperatures would equate to lower noise in a radio receiver as well, but I have no experience with the kind of accuracy drift or phase shift you're talking about. Well, this is definitely something I will keep in mind when I try to capture my first baseline. :) -Michel ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2741 / Virus Database: 2614/5846 - Release Date: 10/21/12 From jared.clements at gmail.com Tue Oct 23 21:57:03 2012 From: jared.clements at gmail.com (Jared Clements) Date: Tue, 23 Oct 2012 15:57:03 -0600 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: Hi list, hi Michel, I'm new here, but have been working on the same solution as you are, but for an Amsat all sky tracking receiver. First, let me point you to the signal processing textbook I've been working my way through: dspguide.com. It can be a bit verbose for a textbook, but that's been to my advantage several times. I've run into two clear obstacles trying to build an interferometric array. Both have to do with clock synchronization. First is clock drift. No matter how expensive the crystal, or precise the temperature control, two clocks are going to drift with respect to each other. I'm planning on solving this one by pulling the crystal off the dongles and replacing it with a clock input that I'll pipe from one single clock/crystal out to each dongle. I'm assuming that I'll have to use equal length cables to keep my timing correct. The second problem is synchronizing the separate data streams so I know which samples were taken at the exact same time. This one is a bit trickier, and I don't think there's a hardware solution for it. Most multichannel data acquisition systems have a trigger system to solve this, where all the channels get initialized but don't start to capture until the trigger is received. Unfortunately I don't think there's a trigger input pin anywhere in our dongles. There is another way, and that's find a known RF signal that we can use for synchronization. GPS would be ideal, because there's explicit solutions for time offsets/drift that's referenced to atomic clocks. We could record 5 minutes or so on the L1 band before an observation, then mid-capture tune to our frequency of interest...assuming we can shift the e4k chip without interupting the RTL2832 in it's capture sequence. Does anyone here know if this is possible? Shift the tuner without interupting the capture? This does require a wide band antenna, best options seem to be spiral and conical spiral. There's probably other options, like an active gps patch antenna that's duplexed in with a frequency specific duplexer, but I'm not much of an rf guy and I like the simplicity of the single wide band antenna. I've also been looking at options for building out an array, I've seen reports that a good LNA can get 20dB in SNR, but a wideband preamp runs $70 on minicircuits website. Plus the cost of a bias T and a clean power supply. And I'm not sure that I understand all the built-in options for amplification and filtering yet. That design trade is still pretty fuzzy. It might be more cost effective to just buy more dongles and get better SNR through summing their outputs. More research required! Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at peroulas.com Thu Oct 25 03:08:16 2012 From: james at peroulas.com (James Peroulas) Date: Wed, 24 Oct 2012 20:08:16 -0700 Subject: Beginner question about rtlsdr (Jared Clements) Message-ID: > There is another way, and that's find a known RF signal that we can use for > synchronization. GPS would be ideal, because there's explicit solutions for > time offsets/drift that's referenced to atomic clocks. We could record 5 > minutes or so on the L1 band before an observation, then mid-capture tune > to our frequency of interest...assuming we can shift the e4k chip without > interupting the RTL2832 in it's capture sequence. > I'm not very familiar with your application, but you may also have to do sub-sample time offset estimation and compensation. Even though all of the dongles are running at exactly the same sampling *rate*, their sampling * instants* will likely be different. This is despite the fact that you used the same length of cable to feed the clock to all the dongles. For example, if you want a 2.88MHz sampling rate, this will involve dividing the 28.8MHz input by a factor of 10. One dongle might use edge numbers 0, 10, 20, 30, ... of the source clock to produce the 2.88 MHz clock and another might used edge numbers 3, 13, 23, 33, .... Their sampling frequencies will be exactly the same, but the sampling instant will be different. > Does anyone here know if this is possible? Shift the tuner without > interupting the capture? > I can confirm that you can do this since this is what I did in my LTE cell scanner to improve search speed. I configured the A/D rate once, and then I just kept changing the LO frequency. The thing is that once you change the LO frequency, the phase rotation of the received signal will change randomly for all the dongles. So, during the calibration phase, you might find that dongle 1 needs a time correction of t1 and phase correction of p1 to get its signal to align with the signal from dongle 2. After you change the LO, dongle 1 will still need the same time correction (t1), but you wont know what phase to use. Perhaps phase alignment isn't necessary for your application? BR, James -- *Integrity is a binary state - **either you have it or you don?t.* - John Doerr -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared.clements at gmail.com Mon Oct 22 11:45:13 2012 From: jared.clements at gmail.com (Jared Clements) Date: Mon, 22 Oct 2012 05:45:13 -0600 Subject: Beginner question about rtlsdr In-Reply-To: References: Message-ID: Hi list, hi Michel, I'm new here, but have been working on the same solution as you are, but for an Amsat all sky tracking receiver. First, let me point you to the signal processing textbook I've been working my way through: dspguide.com. It can be a bit verbose for a textbook, but that's been to my advantage several times. I've run into two clear obstacles trying to build an interferometric array. Both have to do with clock synchronization. First is clock drift. No matter how expensive the crystal, or precise the temperature control, two clocks are going to drift with respect to each other. I'm planning on solving this one by pulling the crystal off the dongles and replacing it with a clock input that I'll pipe from one single clock/crystal out to each dongle. I'm assuming that I'll have to use equal length cables to keep my timing correct. The second problem is synchronizing the separate data streams so I know which samples were taken at the exact same time. This one is a bit trickier, and I don't think there's a hardware solution for it. Most multichannel data acquisition systems have a trigger system to solve this, where all the channels get initialized but don't start to capture until the trigger is received. Unfortunately I don't think there's a trigger input pin anywhere in our dongles. There is another way, and that's find a known RF signal that we can use for synchronization. GPS would be ideal, because there's explicit solutions for time offsets/drift that's referenced to atomic clocks. We could record 5 minutes or so on the L1 band before an observation, then mid-capture tune to our frequency of interest...assuming we can shift the e4k chip without interupting the RTL2832 in it's capture sequence. Does anyone here know if this is possible? Shift the tuner without interupting the capture? This does require a wide band antenna, best options seem to be spiral and conical spiral. There's probably other options, like an active gps patch antenna that's duplexed in with a frequency specific duplexer, but I'm not much of an rf guy and I like the simplicity of the single wide band antenna. I've also been looking at options for building out an array, I've seen reports that a good LNA can get 20dB in SNR, but a wideband preamp runs $70 on minicircuits website. Plus the cost of a bias T and a clean power supply. And I'm not sure that I understand all the built-in options for amplification and filtering yet. That design trade is still pretty fuzzy. It might be more cost effective to just buy more dongles and get better SNR through summing their outputs. More research required! -------------- next part -------------- An HTML attachment was scrubbed... URL: From friedtj at free.fr Sat Oct 27 17:51:03 2012 From: friedtj at free.fr (friedtj at free.fr) Date: Sat, 27 Oct 2012 19:51:03 +0200 (CEST) Subject: GNSS on rtlsdr ? In-Reply-To: Message-ID: <312171316.208686677.1351360263691.JavaMail.root@zimbra9-e2.priv.proxad.net> I have just seen that GNSS-SDR (http://www.gnss-sdr.org) is added to the list of applications at http://sdr.osmocom.org/trac/wiki/rtl-sdr. Did anyone manage to get it running ? I can get the whole compilation process completed, but when running, the dongle is detected and the application segfaults (of course, not much of a bug report as ios, but would like some feedback if anyone got the application running under GNU/Linux). JM From james at peroulas.com Sun Oct 28 16:53:23 2012 From: james at peroulas.com (James Peroulas) Date: Sun, 28 Oct 2012 11:53:23 -0500 Subject: Latest Ubuntu update Message-ID: I'm running Ubuntu 12.04 and after installing all the latest security and recommended updates, I'm having problems with the rtlsdr library relating to rtlsdr_cancel_async. For example: rtl_sdr -f 739000000 -n 1000000 cap.dat The above will successfully capture exactly 1M samples into cap.dat, but it will not exit after the capture is finished. I have to break out with ctrl-c. Anybody having similar problems? Hoping I don't have to re-install Ubuntu... :( James -- *Integrity is a binary state - **either you have it or you don?t.* - John Doerr -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at steve-m.de Sun Oct 28 21:48:35 2012 From: steve at steve-m.de (Steve Markgraf) Date: Sun, 28 Oct 2012 22:48:35 +0100 Subject: Latest Ubuntu update In-Reply-To: References: Message-ID: <508DA833.90306@steve-m.de> Hi, On 28.10.2012 17:53, James Peroulas wrote: > Anybody having similar problems? Hoping I don't have to re-install > Ubuntu... :( Strange. I just tried it with both Ubuntu 12.04 and 12.10 with all updates installed, and it works just fine... Regards, Steve From james at peroulas.com Mon Oct 29 03:46:24 2012 From: james at peroulas.com (James Peroulas) Date: Sun, 28 Oct 2012 22:46:24 -0500 Subject: Latest Ubuntu update In-Reply-To: <508DA833.90306@steve-m.de> References: <508DA833.90306@steve-m.de> Message-ID: On Sun, Oct 28, 2012 at 4:48 PM, Steve Markgraf wrote: > Strange. I just tried it with both Ubuntu 12.04 and 12.10 with all > updates installed, and it works just fine... > Hmm... So I just re-installed Ubuntu 12.04 from scratch and am still having the same problem... Are you using the 64 or 32 bit version of Ubuntu? I'm using 64 bits. BR, James -- *Integrity is a binary state - **either you have it or you don?t.* - John Doerr -------------- next part -------------- An HTML attachment was scrubbed... URL: