From 246tnt at gmail.com Thu Jun 21 18:10:18 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 21 Jun 2012 20:10:18 +0200 Subject: v2 Prototype issues and fixes Message-ID: Hi, The v2 prototype I still had a couple of issues so I'll describe them here and the corresponding fixes: - Bad TVS Diode: There is a diode that's supposed to protect against ESD near the antenna connector. Turns out that the component supplier swapped reels IIRC and so that's not a TVS diode that was mounted. My board had the rework to fix this already done. I don't know if any board shipped with the wrong part. It's the small ~ 0603 sized component near the antenna connector and it's supposed to be greenish. The result of this is a ~ 10-15 dB attenuation of the input signal. - Missing LNA bias inductor: The v2 has a LNA at the input but it's missing it's bias inductor which means it's powered off. So instead of boosting the signal by 18 dB, it actually attenuates it quite a lot. Solution is simple: Solder a 0603 bias inductor. Schematics call for a 470nH inductor and make sure to choose a good RF rated one and not random junk. - FPGA 1.2V LDO Oscillation: The output capacitor of the LP3965 regulator generating the 1.2V for the FPGA core has too low an ESR (a ceramic cap is mounted). This regulator needs a capacitor with an ESR greater than 0.5 ohm and lower than 5 ohm for it to be stable. Without this, the LDO is unstable and has high spectral content at 55 kHz and harmonics. This noise is present at the output but also leaks to the input voltage of the LDO which is the 3.3V rail that powers the LNA ... This is causing unwanted images of the signal at f +- 55kHz f+- 110 kHz ... The solution is simple: replace the cap by a tantalum one within the right ESR range. ( I used a TR3A106K016C1700 from Farnell ). This is before the fix: http://i.imgur.com/rRDDQ.png and this is after : http://i.imgur.com/VlOW7.png - Impedance mismatch between E4K output and ADC input: Ideally we'd like to imagine that the E4K IQ output have very low impedance and that the ADC input have very high impedance. Turns out that neither is true: The E4K has a ~ 500 ohm output impedance and the ADC is a track and hold type and the capacitance of the input changes when you start sampling, causing a small current flow. The combination of the 2 creates a noise at the sampling frequency on the IQ lines ... The effect of this is currently unknown and is being investigated ... it might be possible to lower the noise floor a bit and get less DC offset with this. But it certainly doesn't have as much impact as the 3 erratas above for sure. See for components location. http://i.imgur.com/M4Lvt.jpg Cheers, Sylvain From dfnsonfsduifb at gmx.de Fri Jun 22 12:54:04 2012 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Fri, 22 Jun 2012 14:54:04 +0200 Subject: Caputed RTL-SDR file for playing around? Message-ID: <4FE46AEC.1000209@gmx.de> Hi list, I've stumbled upon the rtl-sdr and am quite excited. Have already ordered a dongle, but it is going to take a while until it arrives. Since I'd like to play around with it already, is there a capture file available somewhere for download to test out the functionality (working with GnuRadio etc)? I.e. someone with a dongle doing ./rtl_sdr /tmp/capture.bin -s 1.8e6 -f 392e6 (or whatever frequency there is something audible on, preferrably something that can easily be identified like FM radio) and publishing the capture.bin file? This might also be of interest to people who consider to play around with SDR, but do not know if they should buy a dongle. Would be very cool if there was something available or somebody on the list could provide one. Best regards, Joe From steve at steve-m.de Fri Jun 22 13:01:38 2012 From: steve at steve-m.de (Steve Markgraf) Date: Fri, 22 Jun 2012 15:01:38 +0200 Subject: Caputed RTL-SDR file for playing around? In-Reply-To: <4FE46AEC.1000209@gmx.de> References: <4FE46AEC.1000209@gmx.de> Message-ID: <4FE46CB2.90001@steve-m.de> Hi, On 22.06.2012 14:54, Johannes Bauer wrote: > Would be very cool if there was something available or somebody on the > list could provide one. I have some random recordings here: http://steve-m.de/files/rtl2832/ Some are very old, and the quality might be not as good as it is with the latest code though. Regards, Steve From dfnsonfsduifb at gmx.de Fri Jun 22 13:09:12 2012 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Fri, 22 Jun 2012 15:09:12 +0200 Subject: Caputed RTL-SDR file for playing around? In-Reply-To: <4FE46CB2.90001@steve-m.de> References: <4FE46AEC.1000209@gmx.de> <4FE46CB2.90001@steve-m.de> Message-ID: <4FE46E78.9040503@gmx.de> On 22.06.2012 15:01, Steve Markgraf wrote: >> Would be very cool if there was something available or somebody on the >> list could provide one. > > I have some random recordings here: > http://steve-m.de/files/rtl2832/ > > Some are very old, and the quality might be not as good as it is with > the latest code though. Thank you very much, precisely what I was looking for! Best regards, Joe From leif at sm5bsz.com Fri Jun 22 19:55:51 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Fri, 22 Jun 2012 21:55:51 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. Message-ID: <20120622215551.2ed626e5.leif@sm5bsz.com> Hello, This mail is sent to all the E-mail addresses I have found in the source code of tuner_e4k.c and librtlsdr.c I have made a couple of modifications to the software and I now want to ask whether you can make changes to the standard package that you supply so Linrad users will not have to download modified files from my site to get proper operation of Linrad in the future. The most important modification is the gain setting. The tuner code requires knowledge of the gain table or searcing for legal gain values by use of the returned error code. I think that this is impractical and I changed it so the routine will now always set the nearest possible gain value and return it to the caller. The routine e4k_set_enh_gain(...) does not affect the gain of my hardware so I allow the gain setting function to use it with always the same value because I have no idea what this function is intended to do.... The default IF gain is too high. I reduced it by 6dB for a 6 dB better dynamic range. With the tuner_e4k.c currently incorporated in Linrad there is an AGC action that degrades the dynamic range by about 10 dB. I do not know anything about the e4000 internals but in case this remaining AGC can be disabled and the gain set 10 dB lower in the particular gain step controlled by the AGC, the dynamic range would improve from 66 dB to 76 dB with respect to the usual MDS (noise in 500 Hz bandwidth.) That means going from outside the scale in the QST "Key Measurements Summary" in their product testing to a mediocre result 6 dB above the limit of the range they have for SSB radios. The rtlsdr would be superior to hand held units like TH-D72A or VX-8GR in adjacent channel rejection (QST July 2011 and September 2011) if the AGC could be disabled. The details are here: http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The Extio_RTLSDR.dll file provides 6 dB worse dynamic range because of the high IF gain setting. It also has a poor noise figure. -------------------------------------------------------------- To be able to use the callback in Linrad I have had to include various structures in the Linrad c code. I need to have this code in Linrad: i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); Therefore I need the structure rtlsdr_dev which is not included in rtl-sdr.h. That structure requires other structures and it would be a good thing if those things as well as something like this: #define MAX_RTL2832_SAMP_RATE 3200000 #define MIN_RTL2832_SAMP_RATE 900001 were included in rtl-sdr.h I attach the Linrad interface routine to rtlsdr in case any of you are interested to see how I use the library. I realize the chip is far more clever and that I do not use it well. There is a substantial DC offset that seems to be possible to auto-remove. The AGC I want to get rid of might be something related to: /* disable auto mixer gain */ e4k_reg_set_mask(e4k, E4K_REG_AGC7, E4K_AGC7_MIX_GAIN_AUTO, 0); Hard to know without any documentation on the chip.... 73 Leif / SM5BSZ -------------- next part -------------- A non-text attachment was scrubbed... Name: rtl2832.c Type: text/x-csrc Size: 14294 bytes Desc: not available URL: From steve at steve-m.de Fri Jun 22 20:43:34 2012 From: steve at steve-m.de (Steve Markgraf) Date: Fri, 22 Jun 2012 22:43:34 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <20120622215551.2ed626e5.leif@sm5bsz.com> References: <20120622215551.2ed626e5.leif@sm5bsz.com> Message-ID: <4FE4D8F6.1060709@steve-m.de> Hi Leif, On 22.06.2012 21:55, Leif Asbrink wrote: > The most important modification is the gain setting. > The tuner code requires knowledge of the gain table > or searcing for legal gain values by use of the returned > error code. I think that this is impractical and I changed it > so the routine will now always set the nearest possible gain > value and return it to the caller. That's exactly what we have rtlsdr_get_tuner_gains() for. > The routine e4k_set_enh_gain(...) does not affect the gain > of my hardware so I allow the gain setting function to use it > with always the same value because I have no idea what this > function is intended to do.... Enhanced gain works only when both LNA and mixer gains are set to maximum, take a look at e4000_set_gain() in librtlsdr.c. Also be sure to enable the manual gain mode with the library function rtlsdr_set_tuner_gain_mode(). > The default IF gain is too high. I reduced it by 6dB for > a 6 dB better dynamic range. We still have to add functions to set the IF-gain from external applications, this is something on the todo-list. > With the tuner_e4k.c currently incorporated in Linrad > there is an AGC action that degrades the dynamic range by > about 10 dB. I do not know anything about the e4000 internals > but in case this remaining AGC can be disabled and the gain > set 10 dB lower in the particular gain step controlled by the > AGC, the dynamic range would improve from 66 dB to 76 dB > with respect to the usual MDS (noise in 500 Hz bandwidth.) The remaining AGC that's active is not in the E4K, but it's the Digital AGC (DAGC) of the RTL2832. Unfortunately we don't know how to disable it, since the way it's supposed to be disabled does not work. > To be able to use the callback in Linrad I have had to include > various structures in the Linrad c code. I need to have this > code in Linrad: > i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); > Therefore I need the structure rtlsdr_dev which is not included > in rtl-sdr.h. That structure requires other structures and it > would be a good thing if those things as well as something I don't really know why you're doing that... the way the asynchronous callback is meant to be used is spawning a thread and calling rtlsdr_read_async() from there. Just take a look at how gr-osmosdr or rtl_tcp handles it. Another example of correct usage is sdrsharp [1]. Regards, Steve [1] https://www.assembla.com/code/sdrsharp/subversion/nodes/trunk/RTLSDR/RtlDevice.cs From leif at sm5bsz.com Sat Jun 23 20:00:36 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Sat, 23 Jun 2012 22:00:36 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <4FE4D8F6.1060709@steve-m.de> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> Message-ID: <20120623220036.cf68c108.leif@sm5bsz.com> Hello Steve, > On 22.06.2012 21:55, Leif Asbrink wrote: > > The most important modification is the gain setting. > > The tuner code requires knowledge of the gain table > > or searcing for legal gain values by use of the returned > > error code. I think that this is impractical and I changed it > > so the routine will now always set the nearest possible gain > > value and return it to the caller. > > That's exactly what we have rtlsdr_get_tuner_gains() for. Good:-) I overlooked that and I will use it for the next Linrad version. > > The default IF gain is too high. I reduced it by 6dB for > > a 6 dB better dynamic range. > > We still have to add functions to set the IF-gain from external > applications, this is something on the todo-list. OK. Do you have an idea about the time scale? It would be a good thing from my perspective if this would be implemented before I release the next Linrad version. The lower IF gain is a significant improvement on 144 MHz. I do not know anything about the design so I do not know whether one should set IF gain differently on other frequencies. > > With the tuner_e4k.c currently incorporated in Linrad > > there is an AGC action that degrades the dynamic range by > > about 10 dB. I do not know anything about the e4000 internals > > but in case this remaining AGC can be disabled and the gain > > set 10 dB lower in the particular gain step controlled by the > > AGC, the dynamic range would improve from 66 dB to 76 dB > > with respect to the usual MDS (noise in 500 Hz bandwidth.) > > The remaining AGC that's active is not in the E4K, but it's the Digital > AGC (DAGC) of the RTL2832. Unfortunately we don't know how to disable > it, since the way it's supposed to be disabled does not work. That is bad news:-( Is there by any chance a way to reduce the sensitivity of the RTL2832? Something that would place the AGC onset at a point higher above the noise floor. > > To be able to use the callback in Linrad I have had to include > > various structures in the Linrad c code. I need to have this > > code in Linrad: > > i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); > > Therefore I need the structure rtlsdr_dev which is not included > > in rtl-sdr.h. That structure requires other structures and it > > would be a good thing if those things as well as something > > I don't really know why you're doing that... the way the asynchronous > callback is meant to be used is spawning a thread and calling > rtlsdr_read_async() from there. Just take a look at how gr-osmosdr or > rtl_tcp handles it. Another example of correct usage is sdrsharp [1]. I did it because that is the way I used to do.... I will check the timing of the conventional approach and switch to it if the difference is insignificant. I have tested the ExtIO_RTLSDR.dll which I assume is written by the book. It works fine on modern computers, even on less modern ones like a 2.4 GHz Pentium 4 but it fails on Pentium 3 with bad cpu overload (Win XP). The Linrad code runs fine at 2 MHz sampling speed on my old Pentium 3 at 650 MHz. (under Linux X11, 2.6.32 kernel) The cpu load is 80% and there are no glitches or other problems. The parameters are exactly the same that fail badly with the ExtIO dll on the same computer. The difference is most probably not due to Windows itself, it is the USB interface that is more demanding. Significantly more! Regards Leif / SM5BSZ From peter at stuge.se Sat Jun 23 21:41:56 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 23 Jun 2012 23:41:56 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <20120623220036.cf68c108.leif@sm5bsz.com> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> Message-ID: <20120623214156.17460.qmail@stuge.se> Hej Leif! Leif Asbrink wrote: > it is the USB interface that is more demanding. Significantly more! Depends on how the software in the device and on the host is written. USB per se is not demanding, rather the opposite, as the host controller does DMA. A device which makes poor use of USB primitives will of course have poor performance. A host software which makes poor use of USB primitives will also have poor performance. What freedom the host software has is largely determined by the device, but of course it's always possible to write bad software.. I didn't look at the ExtIO_RTLSDR source code, so I can't say if it is doing efficient USB communication or not. Where is the source? Kind regards //Peter From leif at sm5bsz.com Sun Jun 24 00:50:09 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Sun, 24 Jun 2012 02:50:09 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <4FE4D8F6.1060709@steve-m.de> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> Message-ID: <20120624025009.db49f33b.leif@sm5bsz.com> Hello Steve, > > The most important modification is the gain setting. > > The tuner code requires knowledge of the gain table > > or searcing for legal gain values by use of the returned > > error code. I think that this is impractical and I changed it > > so the routine will now always set the nearest possible gain > > value and return it to the caller. > > That's exactly what we have rtlsdr_get_tuner_gains() for. I have implemented the proper way of calling the original gain routine. Here is what I observe with rtlsdr as downloaded today: Set gain Signal level (dB) (dB) 49 49 47 49 45 49 43 49 42 49 34 42 29 42 24 37 21.5 35 19 32 16.5 28.5 14 27.5 11.5 24 9 22 6.5 19.5 4 17 1.5 13.5 -1 12 This does not look good. I have used a dongle bought here: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260995356948 I have two of them and they behave the same. In Linrad with modified code for the rtlsdr library it looks like this: Set gain Signal level (dB) (dB) 36 36 33 31 30 28.5 27 25.5 24 21.5 21 20 18 16 15 14.5 12 11 9 9 6 3 3 1 0 -4.5 At maximum gain the noise fig?re is 7.8 dB in both cases at 144 MHz. The dynamic range (1 dB compression) is 14 dB better with the modified code for Linrad. (lower IF gain.) It is a VERY significant improvement. Is there a way to get technical specifications for the chips used in the dongle? Regards Leif / SM5BSZ From a.nielsen at shikadi.net Sun Jun 24 10:47:03 2012 From: a.nielsen at shikadi.net (Adam Nielsen) Date: Sun, 24 Jun 2012 20:47:03 +1000 Subject: RTL direct sampling Message-ID: <4FE6F027.9060508@shikadi.net> Hi all, I've been watching with interest Steve's commits to the direct_sampling branch of the rtl-sdr repository. I haven't seen much mentioned about it though, so I'm just wondering whether anyone knows how it's progressing, and whether it's at the point yet where I should crack open one of these devices and try it out? Thanks, Adam. From jsalsburg at bellsouth.net Sat Jun 30 09:29:36 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sat, 30 Jun 2012 04:29:36 -0500 Subject: Super Efficient SMD Schottky Barrier from Comchip Technology Corporation Message-ID: http://beta.globalspec.com/featuredProducts/detail?id=372 &campid=736&exhibitId=209851&uid=%2D249525238&uh=e8a921&md=120628&mh=221961 -------------- next part -------------- An HTML attachment was scrubbed... URL: