From leif at sm5bsz.com Wed Jul 4 21:45:44 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Wed, 4 Jul 2012 23:45:44 +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: <20120704234544.e3b1a5b1.leif@sm5bsz.com> Hello Steve, > > 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. Since there was no response on this I have released a new version of Linrad with new versions of rtlsdr.c and tuner_e4k.c to go with it. Performance is now quite good. The noise figure is 7 dB with a dynamic range of about 74 dB (saturation vd MDS in 500 Hz.) When gain is reduced for a noise figure of 10 dB the dynamic range is 80 dB, 6 dB below the theoretical limit. http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The gain setting is clumsy, I just added some things that seem similar to the existing routines. It seems to me that a new approach would be desireable. If one wants to set the gain of the E4000 chip by use of a single parameter one has to use some of theIF gain controls as well as the mixer gain and the lna gain. I have not been able to see any effect of the enhanced gain. I tried various bits blindly and found a setting that eliminates the AGC in the RTL2832 chip. That is a significant part of the performance improvement. Today the rtlsdr with Linrad under Linux is not a toy. It is a surprisingly good SDR receiver (in relation to cost.) Performance is about 20 dB below what we find in standard transceivers like IC706MKIIG and others. I do not know how to proceed. I see two options: 1) librtlsdr is rewritten with a gain setting routine that operates on lna, IF and mixer gains in a way that optimizes performance. 2) I will provide a Linrad specific library that supports only the RTL2832/E4000 combination. I expect the simple change required to disable AGC in RTL2832 to be implemented pretty soon. Hopefully ExtIO_RTLSDR.dll and SDRSharp will soon be updated to remove the AGC. A gain setting function would surely make these softwares far more useful. I think the best way of setting the e4k gain would be to place a matrix in tuner_e4k.c with as many rows as the number of stages that we want to use for gain setting and as many columns at the number of different nominal gains ?e want to supply. That would be a lot of code to remove and not much to add - but I do not wish to take desicions for osmocom. Linrad-04.40 still uses its own callback and I may have to supply source code for todays version of tlsdr to go with it. In case the standard library from osmocom implements AGC off and a sensible routine for manual gain control I will adapt Linrad to the standard library. Regards Leif / SM5BSZ From la at tfc-server.de Thu Jul 5 00:06:31 2012 From: la at tfc-server.de (la at tfc-server.de) Date: Thu, 05 Jul 2012 02:06:31 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <20120704234544.e3b1a5b1.leif@sm5bsz.com> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> Message-ID: <4FF4DA87.8080800@tfc-server.de> > The gain setting is clumsy If it only was your gain setting function, but no, even your gain values for the lna are just plain wrong. I just have to ask: Why? What made you "improve" them? From leif at sm5bsz.com Thu Jul 5 11:27:00 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Thu, 5 Jul 2012 13:27:00 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <4FF4DA87.8080800@tfc-server.de> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> <4FF4DA87.8080800@tfc-server.de> Message-ID: <20120705132700.6e9d4641.leif@sm5bsz.com> I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have. I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended. I see two alternatives, there could be lna gain as well as IF gain as separate controls. The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.) Regards Leif / SM5BSZ On Thu, 05 Jul 2012 02:06:31 +0200 la at tfc-server.de wrote: > > The gain setting is clumsy > If it only was your gain setting function, but no, even your gain values > for the lna are just plain wrong. > I just have to ask: Why? What made you "improve" them? > From jsalsburg at bellsouth.net Thu Jul 5 13:06:11 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Thu, 5 Jul 2012 08:06:11 -0500 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <20120705132700.6e9d4641.leif@sm5bsz.com> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> <4FF4DA87.8080800@tfc-server.de> <20120705132700.6e9d4641.leif@sm5bsz.com> Message-ID: I assume everyone involved in constructing the Control Code for the Tuner Dongles started out by recording the I2C stream on the Dongle coming from the Original Dongle Software that comes with the Dongle for watching TV and FM Radio. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink Sent: Thursday, July 05, 2012 6:27 AM To: osmocom-sdr at lists.osmocom.org Subject: Re: Linrad with rtlsdr with and the e4000 tuner. I changed the numbers to get a reasonable agreement with the gain values I observed on the dongles I have. I did not care to match the gain setting to the real gain better than within 3 dB (the gain step size in Linrad.) The reason is that I assume that the routines from osmocom will be changed and that other softwares that support rtl dongles will allow gain setting in a reasonable way and that the performance will become similar to the current Linrad performance. When that happens I will rewrite Linrad to use the library as intended. I see two alternatives, there could be lna gain as well as IF gain as separate controls. The other alternative would be a single gain control, but in that case both lna and if gain have to be controlled. The first few gain reduction steps have to be on the IF because the most common problem is close range interference and the improved dynamic range is useful. (In case the lna gets blocked one should install a filter.) Regards Leif / SM5BSZ On Thu, 05 Jul 2012 02:06:31 +0200 la at tfc-server.de wrote: > > The gain setting is clumsy > If it only was your gain setting function, but no, even your gain > values for the lna are just plain wrong. > I just have to ask: Why? What made you "improve" them? > From st at metafly.info Thu Jul 5 14:42:40 2012 From: st at metafly.info (Stefan Sydow) Date: Thu, 05 Jul 2012 16:42:40 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <20120705132700.6e9d4641.leif@sm5bsz.com> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> <4FF4DA87.8080800@tfc-server.de> <20120705132700.6e9d4641.leif@sm5bsz.com> Message-ID: <4FF5A7E0.2010907@metafly.info> Hello, I've played around with your code and also had a look into the linux kernel driver which contains some elonics code [1]. There the LNA gains have an offset of 3dB compared with rtl-sdr. In the rtl-sdr header is also a constant defined but not used, to switch to 5dB gain steps. I'm wondering how this fit's with your observations. I've read your blog entry and would like to evaluate the gain values of my device, but it is not clear to me what equipment is needed - I assume at least a 144 MHz oscillator with defined level. Regarding your changes to the gain setting function, fear they contain lots of bugs, but I agree it would be nice to have a function which make IF-gain setting easier. The elonics code also contains a more stuff to configure the auto gain. Maybe this is interesting for rtl-sdr too. Regards Stefan [1] https://github.com/tmair/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/tree/ Am 05.07.2012 13:27, schrieb Leif Asbrink: > I changed the numbers to get a reasonable agreement with > the gain values I observed on the dongles I have. > > I did not care to match the gain setting to the real gain > better than within 3 dB (the gain step size in Linrad.) > The reason is that I assume that the routines from osmocom > will be changed and that other softwares that support > rtl dongles will allow gain setting in a reasonable way and > that the performance will become similar to the current > Linrad performance. When that happens I will rewrite Linrad > to use the library as intended. > > I see two alternatives, there could be lna gain as well as IF > gain as separate controls. > > The other alternative would be a single gain control, but > in that case both lna and if gain have to be controlled. > The first few gain reduction steps have to be on the IF because > the most common problem is close range interference and the > improved dynamic range is useful. (In case the lna gets blocked > one should install a filter.) > > Regards > > Leif / SM5BSZ > > On Thu, 05 Jul 2012 02:06:31 +0200 > la at tfc-server.de wrote: > >>> The gain setting is clumsy >> If it only was your gain setting function, but no, even your gain values >> for the lna are just plain wrong. >> I just have to ask: Why? What made you "improve" them? >> > > From leif at sm5bsz.com Thu Jul 5 19:05:28 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Thu, 5 Jul 2012 21:05:28 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> <4FF4DA87.8080800@tfc-server.de> <20120705132700.6e9d4641.leif@sm5bsz.com> Message-ID: <20120705210528.f394f38a.leif@sm5bsz.com> Hello Jay, The e4k chip has many registers. For example the function e4k_manual_dc_offset() changes the way the if gain settings work. There could also be something that affects the lna gain. The purpose of the changed code that I made available is to allow rtlsdr users to have the full performance of the RTL2832/E4000 dongles NOW. Today. I do not have access to any data for the chips. Performance is reasonably close to the theoretical limit and all AGC functions are disabled so it is now a good radio with Linrad. The function e4k_manual_dc_offset() is named in a way that suggests one can change the DC offset on the output from I and Q. Pointless, at least with the dongle I have because the E4000 is AC-coupled to the RTL2832. (I checked with an oscilloscope.) Regards Leif / SM5BSZ On Thu, 5 Jul 2012 08:06:11 -0500 "Jay Salsburg" wrote: > I assume everyone involved in constructing the Control Code for the Tuner > Dongles started out by recording the I2C stream on the Dongle coming from > the Original Dongle Software that comes with the Dongle for watching TV and > FM Radio. > > -----Original Message----- > From: osmocom-sdr-bounces at lists.osmocom.org > [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink > Sent: Thursday, July 05, 2012 6:27 AM > To: osmocom-sdr at lists.osmocom.org > Subject: Re: Linrad with rtlsdr with and the e4000 tuner. > > I changed the numbers to get a reasonable agreement with the gain values I > observed on the dongles I have. > > I did not care to match the gain setting to the real gain better than within > 3 dB (the gain step size in Linrad.) The reason is that I assume that the > routines from osmocom will be changed and that other softwares that support > rtl dongles will allow gain setting in a reasonable way and that the > performance will become similar to the current Linrad performance. When that > happens I will rewrite Linrad to use the library as intended. > > I see two alternatives, there could be lna gain as well as IF gain as > separate controls. > > The other alternative would be a single gain control, but in that case both > lna and if gain have to be controlled. > The first few gain reduction steps have to be on the IF because the most > common problem is close range interference and the improved dynamic range is > useful. (In case the lna gets blocked one should install a filter.) > > Regards > > Leif / SM5BSZ > > On Thu, 05 Jul 2012 02:06:31 +0200 > la at tfc-server.de wrote: > > > > The gain setting is clumsy > > If it only was your gain setting function, but no, even your gain > > values for the lna are just plain wrong. > > I just have to ask: Why? What made you "improve" them? > > > > From leif at sm5bsz.com Thu Jul 5 19:29:45 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Thu, 5 Jul 2012 21:29:45 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: <4FF5A7E0.2010907@metafly.info> References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> <4FF4DA87.8080800@tfc-server.de> <20120705132700.6e9d4641.leif@sm5bsz.com> <4FF5A7E0.2010907@metafly.info> Message-ID: <20120705212945.dc99743e.leif@sm5bsz.com> Hello Stefan, > I've played around with your code and also had a look into the linux > kernel driver which contains some elonics code [1]. > > There the LNA gains have an offset of 3dB compared with rtl-sdr. The absolute gain is insignificant. The dongle will convert an RF voltage to A/D converter bits and the number of mV per bit will change if there is an offset on gain values. I can not see that one is better than the other. Those who know the internals of the chip might want to set the scale offsets correctly because the different stages may actually have gain or cause attenuation. Such a strategy is not unambigous however. When the impedance level is changed we have to know whether dB refers to a power ratio or a voltage ratio. > In the rtl-sdr header is also a constant defined but not used, to switch > to 5dB gain steps. I'm wondering how this fit's with your observations. I have no idea. > I've read your blog entry and would like to evaluate the gain values of > my device, but it is not clear to me what equipment is needed - I assume > at least a 144 MHz oscillator with defined level. You just need a signal that is stable in amplitude. Could be your local FM station or any signal generator in the range 55 to 1000 MHz. Probably higher, but I do not have generators above 1 GHz easy at hand so I have not verified that. > Regarding your changes to the gain setting function, fear they contain > lots of bugs, but I agree it would be nice to have a function which make > IF-gain setting easier. Not bugs, but clumsy code. I tried to not change more than necessary... > The elonics code also contains a more stuff to configure the auto gain. > Maybe this is interesting for rtl-sdr too. In general purpose SDR we do not want any kind of auto gain. Those who want to use the builtin decoders have a different situation. Regards Leif / SM5BSZ > > Regards > > Stefan > > [1] > https://github.com/tmair/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/tree/ > > Am 05.07.2012 13:27, schrieb Leif Asbrink: > > I changed the numbers to get a reasonable agreement with > > the gain values I observed on the dongles I have. > > > > I did not care to match the gain setting to the real gain > > better than within 3 dB (the gain step size in Linrad.) > > The reason is that I assume that the routines from osmocom > > will be changed and that other softwares that support > > rtl dongles will allow gain setting in a reasonable way and > > that the performance will become similar to the current > > Linrad performance. When that happens I will rewrite Linrad > > to use the library as intended. > > > > I see two alternatives, there could be lna gain as well as IF > > gain as separate controls. > > > > The other alternative would be a single gain control, but > > in that case both lna and if gain have to be controlled. > > The first few gain reduction steps have to be on the IF because > > the most common problem is close range interference and the > > improved dynamic range is useful. (In case the lna gets blocked > > one should install a filter.) > > > > Regards > > > > Leif / SM5BSZ > > > > On Thu, 05 Jul 2012 02:06:31 +0200 > > la at tfc-server.de wrote: > > > >>> The gain setting is clumsy > >> If it only was your gain setting function, but no, even your gain values > >> for the lna are just plain wrong. > >> I just have to ask: Why? What made you "improve" them? > >> > > > > > > From la at tfc-server.de Thu Jul 5 19:41:04 2012 From: la at tfc-server.de (la at tfc-server.de) Date: Thu, 05 Jul 2012 21:41:04 +0200 Subject: Linrad with rtlsdr with and the e4000 tuner. In-Reply-To: References: <20120622215551.2ed626e5.leif@sm5bsz.com> <4FE4D8F6.1060709@steve-m.de> <20120623220036.cf68c108.leif@sm5bsz.com> <20120704234544.e3b1a5b1.leif@sm5bsz.com> <4FF4DA87.8080800@tfc-server.de> <20120705132700.6e9d4641.leif@sm5bsz.com> Message-ID: <4FF5EDD0.6090507@tfc-server.de> > I assume everyone involved in constructing the Control Code for the Tuner > Dongles started out by recording the I2C stream on the Dongle coming from > the Original Dongle Software that comes with the Dongle for watching TV and > FM Radio. As far as the e4k is concerned: We're currently using the OsmoSDR driver which was written by people who have access to the e4k datasheet, this driver predates rtlsdr by quite a bit, and I'd dare to say that it is unwise to modify constants used by it unless your datasheet disagrees with ours. Unfortunately there is very little known about the other tuners, so their code is mostly just modified v4l code. From f.gugliuzza at hacklabproject.org Wed Jul 4 23:45:28 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Thu, 5 Jul 2012 01:45:28 +0200 Subject: Disabling RTL2832 AGC Message-ID: A couple of days ago I posted on Reddit a small modification to librtlsdr.c to disable the RTL2832 AGC and internal amplifiers (link to post: http://www.reddit.com/r/RTLSDR/comments/vunuy/experiments_with_agc/c57sbpx the correct part is after the EDIT). Add the following lines of code: /* disable RF and IF AGC */ uint16_t tmp; tmp = rtlsdr_demod_read_reg(dev, 1, 0x04, 1); tmp &= ~0xc0; rtlsdr_demod_write_reg(dev, 1, 0x04, tmp, 1); /* disable AGC PGA */ rtlsdr_demod_write_reg(dev, 1, 0xd7, 0x00, 1); /* disable GI PGA */ rtlsdr_demod_write_reg(dev, 1, 0xe5, 0x00, 1); just after: /* disable AGC (en_dagc, bit 0) */ rtlsdr_demod_write_reg(dev, 1, 0x11, 0x00, 1); Since I don't have adequate tools to test the results, could you please test it, and if it does work, add the patch to your repository? Thank you! -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From friedtj at free.fr Fri Jul 6 07:52:40 2012 From: friedtj at free.fr (friedtj) Date: Fri, 6 Jul 2012 09:52:40 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? Message-ID: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> I am trying to implement equivalent time sampling using an EZCAP dongle configured using gnuradio-companion. Since I am not completely clear about the tasks of the E4000 wrt RTL2832, it could be that I am missing a significant information, so here is my experimental setup aimed at developing a monostatic pulse mode RADAR : * I am using a radiofrequency acoustic delay line to generate 4 echos delayed 1 to 2 microseconds after an incoming excitation pulse is generated by a frequency synthesizer. The excitation pulse is 125 ns long, and repetition rate is 4 microseconds. The carrier frequency at 860 MHz is chopped by a fast duplexer, one side being connected to the frequency synthesizer and the other sizer to the EZCAP dongle * the EZCAP is configured with an LO at 860 MHz, 2 MS/s output, and I plot |I+jQ| after keeping only 1 every 8 sample (2 MS/s=500 ns delay between samples, and 1 every 8 samples means a spacing of 4 us, close to the emitted pulse repetition rate) * equivalent time sampling is obtained by slightly tuning the emitted pule repetition rate off the 4 us: I have checked that I can indeed obtain time stretching by tuning the pulse repetition rate +/- 50 ns away from the 4 us dela, with time stretching factors of up to 10^5 (ie the 4 us pulses are recorded as 400 ms traces (thus including 10^5 points or an equivalent sampling rate of 25 GS/s). Now of course a stretching factor of 10^5 is overkill and the RF front end definitely does not have such a huge bandwidth, this is just to demonstrate the concept. With a more reasonable stretching factor of 10 (ie sampling every 4.4 us with a 4 us emission pulse repetition rate), I can expect to convert a 2 MS/s sampling rate to an equivalent time sampling of 20 MS/s, which would already improve my monostatic RADAR resolution by a factor 10, and more or less fit my targetted resolution. So now the questions: * the 125 ns pulse I generate would span 8 MHz. From my reading of the E4k description, this is within the IF bandwidth available. However, although I can observe the emitted pulse (0 dBm), I cannot see the echos (-35 to -40 dBm), whatever LNA gain I use (from 0 to 40 dB). Is the default configuration of the E4k an IF of 8 MHz, or lower. What parameter should I give the rtlsdr gnuradio source block to make sure I have the right bandwidth ? * since I am not clear about task distribution between the E4k and the RTL2832, is there another limitation that will prevent a 8 MHz wide (bandwidth) signal to be recorded through the 2 MS/s I/Q output recorded ? Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France From st at metafly.info Fri Jul 6 08:19:04 2012 From: st at metafly.info (Stefan Sydow) Date: Fri, 06 Jul 2012 10:19:04 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: <4FF69F78.70401@metafly.info> The rtl-sdr (and all other software) has only a bandwidth of 3.2MHz maximum available. Only the hardware demodulator inside the realtek chip can process full 8MHz. If you consider the filter setting of the rtl-sdr you effective bandwidth is about 2 MHz. It is hard coded in the tuner code but reasonable for most settings, as it avoids aliasing. Am 06.07.2012 09:52, schrieb friedtj: > I am trying to implement equivalent time sampling using an EZCAP dongle configured using > gnuradio-companion. Since I am not completely clear about the tasks of the E4000 wrt RTL2832, > it could be that I am missing a significant information, so here is my experimental setup aimed > at developing a monostatic pulse mode RADAR : > * I am using a radiofrequency acoustic delay line to generate 4 echos delayed 1 to 2 microseconds > after an incoming excitation pulse is generated by a frequency synthesizer. The excitation pulse > is 125 ns long, and repetition rate is 4 microseconds. The carrier frequency at 860 MHz is chopped > by a fast duplexer, one side being connected to the frequency synthesizer and the other sizer to the > EZCAP dongle > * the EZCAP is configured with an LO at 860 MHz, 2 MS/s output, and I plot |I+jQ| after keeping > only 1 every 8 sample (2 MS/s=500 ns delay between samples, and 1 every 8 samples means a spacing > of 4 us, close to the emitted pulse repetition rate) > * equivalent time sampling is obtained by slightly tuning the emitted pule repetition rate off the > 4 us: I have checked that I can indeed obtain time stretching by tuning the pulse repetition rate > +/- 50 ns away from the 4 us dela, with time stretching factors of up to 10^5 (ie the 4 us pulses > are recorded as 400 ms traces (thus including 10^5 points or an equivalent sampling rate of 25 GS/s). > > Now of course a stretching factor of 10^5 is overkill and the RF front end definitely does not have such > a huge bandwidth, this is just to demonstrate the concept. With a more reasonable stretching factor of 10 (ie > sampling every 4.4 us with a 4 us emission pulse repetition rate), I can expect to convert a 2 MS/s sampling rate > to an equivalent time sampling of 20 MS/s, which would already improve my monostatic RADAR resolution by a factor 10, > and more or less fit my targetted resolution. > > So now the questions: > * the 125 ns pulse I generate would span 8 MHz. From my reading of the E4k description, this is within the > IF bandwidth available. However, although I can observe the emitted pulse (0 dBm), I cannot see the echos > (-35 to -40 dBm), whatever LNA gain I use (from 0 to 40 dB). Is the default configuration of the E4k an IF of > 8 MHz, or lower. What parameter should I give the rtlsdr gnuradio source block to make sure I have the right bandwidth ? > * since I am not clear about task distribution between the E4k and the RTL2832, is there another limitation that > will prevent a 8 MHz wide (bandwidth) signal to be recorded through the 2 MS/s I/Q output recorded ? The e4k does the filtering but has an analog output. The RTL2832 is in effect an USB ADC. From leif at sm5bsz.com Fri Jul 6 10:02:22 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Fri, 6 Jul 2012 12:02:22 +0200 Subject: Disabling RTL2832 AGC In-Reply-To: References: Message-ID: <20120706120222.daa38333.leif@sm5bsz.com> Hello Francesco, I have tested it and it does not work. Your posting did however inspire me to do some wild experiments just setting bits on some other registers, the purpose of which was unclear to me. To disable the AGC: // Changing from 0x25 to 0xd5 here switches the AGC off SM5BSZ July2 2012 // rtlsdr_demod_write_reg(dev, 0, 0x19, 0x25, 1); rtlsdr_demod_write_reg(dev, 0, 0x19, 0xd5, 1); Just a couple of lines above the place of your modification. Performance becomes very good:-) http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The dynamic range is 80 dB if gain is set for a noise figure of 10 dB or more. With more gain one can get 3 dB lower NF at the cost of 6 dB lower dynamic range. Regards Leif / SM5BSZ > A couple of days ago I posted on Reddit a small modification to > librtlsdr.c to disable the RTL2832 AGC and internal amplifiers (link > to post: http://www.reddit.com/r/RTLSDR/comments/vunuy/experiments_with_agc/c57sbpx > the correct part is after the EDIT). > > Add the following lines of code: > > /* disable RF and IF AGC */ > uint16_t tmp; > tmp = rtlsdr_demod_read_reg(dev, 1, 0x04, 1); > tmp &= ~0xc0; > rtlsdr_demod_write_reg(dev, 1, 0x04, tmp, 1); > > /* disable AGC PGA */ > rtlsdr_demod_write_reg(dev, 1, 0xd7, 0x00, 1); > > /* disable GI PGA */ > rtlsdr_demod_write_reg(dev, 1, 0xe5, 0x00, 1); > > just after: > > /* disable AGC (en_dagc, bit 0) */ > rtlsdr_demod_write_reg(dev, 1, 0x11, 0x00, 1); > > Since I don't have adequate tools to test the results, could you > please test it, and if it does work, add the patch to your repository? > > Thank you! > > -- > Francesco Gugliuzza > HackLabProject.org Administrator > Linux user #374630 > Tel (VoIP geographic number): +39 0921440446 > Tel (Libera il VoIP number): 5125320 > E-mail: f.gugliuzza at hacklabproject.org > From jsalsburg at bellsouth.net Sat Jul 7 02:08:46 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Fri, 6 Jul 2012 21:08:46 -0500 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: Can I say I am impressed with what you are doing friedtj. One thing I have wanted to do with these new Dongles with the e4000 tuners is bypass the RTL2832 chip and piggyback a better ADC on the e4000 tuners output. Since there is so much activity in the "Group" of squeezing the maximum performance from the Dongle Tuners, it may be time to add better hardware. Just to test to see if this is a good route to take, it should be possible to connect a decent PC audio card to the output of the e4000 tuner to see if it suffers any degradation, the AGC debacle can also be checked with this method. If no problems arise then addition of a dual input, 14 bit, 100 Mega-sample, ADC would be the next step to take full advantage of the bandwidth and dynamic range of the tuner that the RTL2832 chip is obviously and purposefully limiting; forget the RTL2832 chip. Will someone publish the e4000 tuner's datasheet and stop all the IP BS. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of friedtj Sent: Friday, July 06, 2012 2:53 AM To: osmocom-sdr at lists.osmocom.org Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? I am trying to implement equivalent time sampling using an EZCAP dongle configured using gnuradio-companion. Since I am not completely clear about the tasks of the E4000 wrt RTL2832, it could be that I am missing a significant information, so here is my experimental setup aimed at developing a monostatic pulse mode RADAR : * I am using a radiofrequency acoustic delay line to generate 4 echos delayed 1 to 2 microseconds after an incoming excitation pulse is generated by a frequency synthesizer. The excitation pulse is 125 ns long, and repetition rate is 4 microseconds. The carrier frequency at 860 MHz is chopped by a fast duplexer, one side being connected to the frequency synthesizer and the other sizer to the EZCAP dongle * the EZCAP is configured with an LO at 860 MHz, 2 MS/s output, and I plot |I+jQ| after keeping only 1 every 8 sample (2 MS/s=500 ns delay between samples, and 1 every 8 samples means a spacing of 4 us, close to the emitted pulse repetition rate) * equivalent time sampling is obtained by slightly tuning the emitted pule repetition rate off the 4 us: I have checked that I can indeed obtain time stretching by tuning the pulse repetition rate +/- 50 ns away from the 4 us dela, with time stretching factors of up to +10^5 (ie the 4 us pulses are recorded as 400 ms traces (thus including 10^5 points or an equivalent sampling rate of 25 GS/s). Now of course a stretching factor of 10^5 is overkill and the RF front end definitely does not have such a huge bandwidth, this is just to demonstrate the concept. With a more reasonable stretching factor of 10 (ie sampling every 4.4 us with a 4 us emission pulse repetition rate), I can expect to convert a 2 MS/s sampling rate to an equivalent time sampling of 20 MS/s, which would already improve my monostatic RADAR resolution by a factor 10, and more or less fit my targetted resolution. So now the questions: * the 125 ns pulse I generate would span 8 MHz. From my reading of the E4k description, this is within the IF bandwidth available. However, although I can observe the emitted pulse (0 dBm), I cannot see the echos (-35 to -40 dBm), whatever LNA gain I use (from 0 to 40 dB). Is the default configuration of the E4k an IF of 8 MHz, or lower. What parameter should I give the rtlsdr gnuradio source block to make sure I have the right bandwidth ? * since I am not clear about task distribution between the E4k and the RTL2832, is there another limitation that will prevent a 8 MHz wide (bandwidth) signal to be recorded through the 2 MS/s I/Q output recorded ? Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France From 246tnt at gmail.com Sat Jul 7 08:34:00 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 7 Jul 2012 10:34:00 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: > If no problems arise then addition of a dual input, 14 bit, 100 > Mega-sample, ADC would be the next step to take full advantage of the > bandwidth and dynamic range of the tuner that the RTL2832 chip is obviously > and purposefully limiting; 1) AFAIK, The E4000 has a limited output bandwidth, in the range of 8 MHz max usable IIRC. It's designed for DVB/TV applications and they don't need more so the IF filters available don't go above that. 2) You still need to pipe all those samples to the PC somehow, this will raises the price of all of this way above the original 20 USD and make it a much bulkier setup. Cheers, Sylvain From friedtj at free.fr Sat Jul 7 10:21:01 2012 From: friedtj at free.fr (friedtj) Date: Sat, 7 Jul 2012 12:21:01 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: <4FF69F78.70401@metafly.info> References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> <4FF69F78.70401@metafly.info> Message-ID: <20120707122101.6584fa5b@dhcp-221.lpmo.priv> > The e4k does the filtering but has an analog output. The RTL2832 is in > effect an USB ADC. apologies if this is obvious to everyone and has already been posted (I have not checked the whole history of this ml), but indeed by connecting a couple of wires to the I or Q differential inputs of the RTL2832 you do get a fine 2 MS/s oscilloscope. This unfortunate AGC means that DC signals cannot be monitored (even after soldering the wires after the common mode cutoff capacitors), but neverless this does provide a 40 fold sampling rate improvement with respect to the use of sound cards as A/D converters (http://sequanux.org/jmfriedt/199999720input_middle.png and http://sequanux.org/jmfriedt/199999720input_top.png for the I and Q measurements when an input signal of 199.999720 kHz is generated by a synthesizer in order to synchronize with the sampled data, ie the sampling clock is off by 1.4 ppm, not too bad !). JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France From f.gugliuzza at hacklabproject.org Sat Jul 7 11:18:20 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Sat, 7 Jul 2012 13:18:20 +0200 Subject: rtl-sdr web git interface not updating Message-ID: The git web interface at http://cgit.osmocom.org/cgit/rtl-sdr/ is not reporting new changes after commit e5afd9894d730dd012ad6b73e6e56cf99e6266a2 (2012-06-08), and it's reporting wrong commit ages. Could it be fixed? Thanks. -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From f.gugliuzza at hacklabproject.org Sat Jul 7 11:42:35 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Sat, 7 Jul 2012 13:42:35 +0200 Subject: Disabling RTL2832 AGC In-Reply-To: References: Message-ID: Hi Leif! Nice work, and I'm glad to hear my post inspired you, even if my code didn't work at all! I'm now setting 0x05 (0000 0101) instead of the original 0x25 (0010 0101) or your 0xd5 (1101 0101), to avoid setting unknown bits, and it seems to have the same effect (I see an about 10 dB noise floor drop when on minimum gain with no signal). Could you test the new value and check if you get the expected results? Thank you! -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From st at metafly.info Sat Jul 7 11:48:21 2012 From: st at metafly.info (Stefan Sydow) Date: Sat, 07 Jul 2012 13:48:21 +0200 Subject: rtl-sdr web git interface not updating In-Reply-To: References: Message-ID: <4FF82205.5060700@metafly.info> I can see the current commits on the webpage: The summary page says: Branch Commit message Author Age master tuner_fc0012: add manual gain support Steve Markgraf 3 days steve-m/direct_sampling [experimental] enable direct sampling for frequencies < 30 MHz Steve Markgraf 3 days Age Commit message Author Files Lines 3 days tuner_fc0012: add manual gain supportHEADmaster Steve Markgraf 2 -3/+30 3 days tuner_e4k: relicense driver under GPLv2+ Steve Markgraf 1 -2/+7 4 days automake: define pkg-config variables Dimitri Stolnikov 1 -0/+4 4 days add another PID for Noxon v1 stick Steve Markgraf 2 -0/+2 6 days rtl_tcp: ignore SIGPIPE Steve Markgraf 1 -1/+3 8 days correctly clear DDC shift and if_freq registers Steve Markgraf 1 -2/+3 10 days introduce getters for tuner parameters (gain, type) Dimitri Stolnikov 3 -29/+115 10 days print the frequency for which the PLL couldn't lock Dimitri Stolnikov 1 -8/+8 12 days add PID for Zaapa ZT-MINDVBZP Steve Markgraf 2 -0/+4 13 days link applications to shared library Steve Markgraf 1 -3/+3 It looks like my git history. Have I missed a detail? Am 07.07.2012 13:18, schrieb Francesco Gugliuzza: > The git web interface at http://cgit.osmocom.org/cgit/rtl-sdr/ is not > reporting new changes after commit > e5afd9894d730dd012ad6b73e6e56cf99e6266a2 (2012-06-08), and it's > reporting wrong commit ages. Could it be fixed? > > Thanks. > From f.gugliuzza at hacklabproject.org Sat Jul 7 11:53:00 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Sat, 7 Jul 2012 13:53:00 +0200 Subject: rtl-sdr web git interface not updating In-Reply-To: <4FF82205.5060700@metafly.info> References: <4FF82205.5060700@metafly.info> Message-ID: 2012/7/7 Stefan Sydow : > I can see the current commits on the webpage: > > The summary page says: > > Branch Commit message Author Age > master tuner_fc0012: add manual gain support Steve Markgraf 3 days > steve-m/direct_sampling [experimental] enable direct sampling for frequencies < 30 MHz Steve Markgraf 3 days > > Age Commit message Author Files Lines > 3 days tuner_fc0012: add manual gain supportHEADmaster Steve Markgraf 2 -3/+30 > 3 days tuner_e4k: relicense driver under GPLv2+ Steve Markgraf 1 -2/+7 > 4 days automake: define pkg-config variables Dimitri Stolnikov 1 -0/+4 > 4 days add another PID for Noxon v1 stick Steve Markgraf 2 -0/+2 > 6 days rtl_tcp: ignore SIGPIPE Steve Markgraf 1 -1/+3 > 8 days correctly clear DDC shift and if_freq registers Steve Markgraf 1 -2/+3 > 10 days introduce getters for tuner parameters (gain, type) Dimitri Stolnikov 3 -29/+115 > 10 days print the frequency for which the PLL couldn't lock Dimitri Stolnikov 1 -8/+8 > 12 days add PID for Zaapa ZT-MINDVBZP Steve Markgraf 2 -0/+4 > 13 days link applications to shared library Steve Markgraf 1 -3/+3 > > It looks like my git history. Have I missed a detail? It seems so... here's a git log from my tree (I've done git pull half an hour ago): francesco at Spartan:~/Programmi/gnuradio/rtl-sdr$ git log commit 6ea029d92c73be2ffde6429430c7ea971a4c390d Author: Dimitri Stolnikov Date: Thu Jul 5 00:28:52 2012 +0200 add api function to control the IF gain for E4000 tuners commit 304c7c863d77b34ba0c0c4911394a3cfc1cfa017 Author: Steve Markgraf Date: Thu Jun 28 14:44:25 2012 +0200 rtl_test: tuner PLL benchmark only works with E4000 Signed-off-by: Steve Markgraf commit fc736ae67faa07a0d665a4aea8b44c24bda1bda5 Author: Steve Markgraf Date: Fri Jun 22 15:52:35 2012 +0200 init: disable 4 MHz clock output The pin where this clock is outputted is quite close to the ADC inputs, so better disable it. Signed-off-by: Steve Markgraf commit b09628b3e890bc24ddaf987788070d69acfabbc3 Author: Dimitri Stolnikov Date: Wed Jun 13 01:29:37 2012 +0200 fix symbol visibility for automake builds commit e5afd9894d730dd012ad6b73e6e56cf99e6266a2 Author: Steve Markgraf Date: Sat Jun 9 00:17:09 2012 +0200 tuner_fc0012: add manual gain support Signed-off-by: Steve Markgraf [CUT] -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From Steve.Markgraf at student.hs-rm.de Sat Jul 7 11:57:33 2012 From: Steve.Markgraf at student.hs-rm.de (Steve Markgraf) Date: Sat, 07 Jul 2012 13:57:33 +0200 Subject: Disabling RTL2832 AGC In-Reply-To: References: Message-ID: <3fbcee79de3af263214cec3d533b980f@mail.student.hs-rm.de> Hi, On 07.07.2012 13:42, Francesco Gugliuzza wrote: > Hi Leif! Nice work, and I'm glad to hear my post inspired you, even > if > my code didn't work at all! Your code was changing settings of the RF- and IF-AGC, which do nothing more than modulating the AGC_RF and AGC_IF outputs of the RTL2832, which are connected to the GAIN0/GAIN1 inputs of the E4000. But since we're using the serial interface gain control mode, enabling the RF/IF-AGC won't have any effect, because the GAIN0/1 inputs are ignored. > I'm now setting 0x05 (0000 0101) instead of the original 0x25 (0010 > 0101) or your 0xd5 (1101 0101), to avoid setting unknown bits, and it > seems to have the same effect (I see an about 10 dB noise floor drop > when on minimum gain with no signal). That's also what I observed, clearing bit 5 is enough to disable the AGC. I also noticed that both DAGC gain registers (page 1, 0x12 and page 0, 0x17) have no effect once bit 5 in the settings register is cleared. The control logic still seems to operate though, which can be observed by reading register 0x05 in page 3. Regards, Steve From st at metafly.info Sat Jul 7 12:10:31 2012 From: st at metafly.info (Stefan Sydow) Date: Sat, 07 Jul 2012 14:10:31 +0200 Subject: cleanup patch Message-ID: <4FF82737.7040606@metafly.info> Here are two patches. First one just removes old code and adds some comments. It also adds a FLO check from gr-baz [1] The second patch adds return value checks to i2c read/write operations. I haven't done it yet for the whole e4k driver, but will fix that if you think, this is a good idea. By now many i2c reads/writes aren't checked - I don't like that so I started catching it with assert. Thats not optimal but a least you notice when it fails. A device reset would be the best solution, but I'm not sure if we can do that form userspace. [1] https://github.com/balint256/gr-baz/blob/master/lib/rtl2832-tuner_e4k.cc (l. 1036) -------------- next part -------------- A non-text attachment was scrubbed... Name: 1_cleanup.diff Type: text/x-patch Size: 4027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2_i2c-check.diff Type: text/x-patch Size: 3963 bytes Desc: not available URL: From leif at sm5bsz.com Sat Jul 7 18:27:59 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Sat, 7 Jul 2012 20:27:59 +0200 Subject: Disabling RTL2832 AGC In-Reply-To: References: Message-ID: <20120707202759.90d59d32.leif@sm5bsz.com> Hello Francesco, As far as I can see there is no difference when I set 0x05 or 0xd5. The bits are no longer unknown - the posting from Steve Markgraf tells us that they mean nothing for a e4000 in "serial interface gain control mode" so the appropriate value should be 0x05. When I first implemented code for rtlsdr in Linrad I did not know how to disable the AGC. As a resuilt the system performance was at the "toy" level. (Not too bad for USD 20) Steve Markgraf wrote 2012-06-22: > 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 somehow in contrast to Steves latest posting.... Anyway, today the performance is well above the "toy level" now that we know how to disable the AGC. Regards Leif > Hi Leif! Nice work, and I'm glad to hear my post inspired you, even if > my code didn't work at all! > I'm now setting 0x05 (0000 0101) instead of the original 0x25 (0010 > 0101) or your 0xd5 (1101 0101), to avoid setting unknown bits, and it > seems to have the same effect (I see an about 10 dB noise floor drop > when on minimum gain with no signal). > > Could you test the new value and check if you get the expected results? > > Thank you! > > -- > Francesco Gugliuzza > HackLabProject.org Administrator > Linux user #374630 > Tel (VoIP geographic number): +39 0921440446 > Tel (Libera il VoIP number): 5125320 > E-mail: f.gugliuzza at hacklabproject.org > From Steve.Markgraf at student.hs-rm.de Sun Jul 8 10:01:03 2012 From: Steve.Markgraf at student.hs-rm.de (Steve Markgraf) Date: Sun, 08 Jul 2012 12:01:03 +0200 Subject: Disabling RTL2832 AGC In-Reply-To: <20120707202759.90d59d32.leif@sm5bsz.com> References: <20120707202759.90d59d32.leif@sm5bsz.com> Message-ID: <339884dfbf5e312fa643e036632b518b@mail.student.hs-rm.de> Hi, On 07.07.2012 20:27, Leif Asbrink wrote: > As far as I can see there is no difference when I set 0x05 or > 0xd5. The bits are no longer unknown - the posting from > Steve Markgraf tells us that they mean nothing for a e4000 > in "serial interface gain control mode" so the appropriate value > should be 0x05. No, I was not referring to the bits in register 0x19, but to the piece of code that Francesco posted earlier (which writes to registers in page 1). > Steve Markgraf wrote 2012-06-22: >> 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 somehow in contrast to Steves latest posting.... It is? Notice the date of the post. We did not know how to disable it until you figured out, I played around with register 0x19 earlier though, but managed to overlook the effect of bit 5. The "way it's supposed to work" I was referring to is clearing bit 0 of register 0x11 in page 1, which has no effect at all (en_dagc). I've now pushed a change to librtlsdr that disables the AGC by default, and added the function rtlsdr_set_agc_mode() that can be used to re-enable it again. Regards, Steve From jsalsburg at bellsouth.net Sun Jul 8 14:52:53 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 8 Jul 2012 09:52:53 -0500 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: If all you want to do is watch and listen to HAM and Police Trunk Radio, the $20 Dongle is adequate, but if you want to hack the E4000 Tuner, a better ADC is needed. 1) Yes, if all you need is to be able to detect a signal on an analog stream its Nyquist Frequency will do, (2 times the frequency being measured) a 20 megasample ADC would be adequate for the E4000 tuner's I/Q output, but there is more information in the Stream than just the presence of Radio Frequency Energy. If all you need to do is detect the presence of energy or listen to it (Audio Modulation) a 2 times Sample frequency is adequate, but if you need to decode octal phase modulated sideband signals, you need to go to at least 10 times Analog to Digital. This is the case with many signals on Satellite and Cable Streams and it is the case with many phase modulated signals over the air. Instead of just the minimum Conversion being done, you need 10 times the Conversion to reconstruct the modulation, and this may even miss subtle information. It is information we are seeking, information as intelligence modulating Electromagnetic Energy. Cable Modems, for example, Digitize the entire spectrum from 100,000 KHz to 800 MHz. This is because the TV Signals are encrypted with Octal Phase Modulation. You have to be able to digitize with wideband (multi-Hundred Megahertz Converters) to be able to Analyze, Decode, or even just to detect these modulation schemes. So even though the E4000 Tuner has only 8 MHz Bandwidth. You need at least 10 times that bandwidth to accurately reconstruct Phase Modulated Signals. In the vernacular of ADCs, anti-aliasing filters are required to remove unwanted high frequency content. Thus content is discarded, and noise is introduced. To adequately sample a broadband signal without discarding anything, radical oversampling is required. Oversampling allows Signal Processing to take place like Noise Reduction, with is very important for DXing. ADCs are cheaper than ever, driven by Scientific Instrumentation, Satellite, and Cable Industry needs. 2) Remember back a in the 1990s when USB first came to be. It was expensive and a luxury on high end computers. Now we have things like the Tuner Dongle with USB and virtually every computer with USB as a Standard; now there is USB 3; even faster. Apple came up with FireWire to solve the problem that USB had. FireWire is capable of real-time wideband serial communication. Better yet, even though it is still expensive, ThunderBolt will become the new "USB." At Multi-Gigabit Streaming rates (800 Mega Bytes per second). You will see in the near future, ADCs with USB 3 and ThunberBold built-in. There is just too much money to make. Current High Definition Cameras use SDI to stream their signals. There are already available Video equipment servicing the High Definition Television Industry with both SDI and ThunberBolt Side-by-Side. You may pooh-pooh this as too expensive, but so was USB when it first rolled onto the scene. -----Original Message----- From: Sylvain Munaut [mailto:246tnt at gmail.com] Sent: Saturday, July 07, 2012 3:34 AM To: Jay Salsburg Cc: osmocom-sdr at lists.osmocom.org Subject: Re: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? > If no problems arise then addition of a dual input, 14 bit, 100 > Mega-sample, ADC would be the next step to take full advantage of the > bandwidth and dynamic range of the tuner that the RTL2832 chip is > obviously and purposefully limiting; 1) AFAIK, The E4000 has a limited output bandwidth, in the range of 8 MHz max usable IIRC. It's designed for DVB/TV applications and they don't need more so the IF filters available don't go above that. 2) You still need to pipe all those samples to the PC somehow, this will raises the price of all of this way above the original 20 USD and make it a much bulkier setup. Cheers, Sylvain From 246tnt at gmail.com Sun Jul 8 15:29:02 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 8 Jul 2012 17:29:02 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: > 1) Yes, if all you need is to be able to detect a signal on an analog stream its Nyquist Frequency will do, (2 times the frequency being measured) a 20 megasample ADC would be adequate for the E4000 tuner's I/Q output. This is IQ signal you don't need twice the bandwidth, you only need once. So a 8 Msps IQ would be adequate to represent a 8 MHz bandwidth. > [snip ....] >You need at least 10 times that bandwidth to accurately reconstruct Phase Modulated Signals. No you don't. You want a concrete example: Most GSM phone are demodulating a phase modulated signal by sampling at exactly one sample per symbol (so they're even sampling _lower_ than the actual signal bandwidth) And although oversampling is useful in certain case to analyze signal, it's essentially useless if the signal has _already_ been filtered like it is in the E4000 case. If the IQ output has only 8 MHz of useful content at the output, you can oversample all you want, it won't bring back what the E4000 discarded ... Those antialiasing filter you mention, they're in the E4000 ! 2) I didn't say bigger / better SDR would be useless ... I'm just saying if you're spending hundreds / thousands on better ADC and better PC interface you might as well ditch the E4000 and use a better RF front end as well. The spectral output of the E4000 is far from being "clean", there is distortions / LO leakage / random spurs / 28.8M clock leakage / ... etc ... Oh and Elonics declared bankrupcy so the E4000 supply is fading ... Cheers, Sylvain From jsalsburg at bellsouth.net Sun Jul 8 17:30:05 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Sun, 8 Jul 2012 12:30:05 -0500 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: The E4000 Tuner offers a stepping stone into the world of SDRs. It does the heavy lifting, significantly reducing the size, cost, and complexity of a SDR. It does not do any programmable signal processing, which is where SDRs are strongest. Quantization has been left out of the discussion because the RTL2832 is so bad at it (to conserve size and cost). The RTL2832 hamstrings the usefulness of the E4000 significantly narrowing the application of DSP. If you want high fidelity reception, you must apply a high fidelity ADC. The Tuner Dongle offers a low cost opportunity for an enterprising hacker to jump ahead and produce a product worth pursuing. As is it is very limited. Also, GSM is very narrowband voice. Data is wideband and complex, Data is where the Gold is, mining it takes better tools which the RTL2832 prevents application to the reception. Typical low price ADC ...The ADC12DS105 is a dual 12-Bit, 105 Msps A/D Converter http://www.ti.com/product/adc12ds105 Price $31 http://www.ti.com/tool/adc12ds105lfeb Design Kit $495, Accessories include a USB Interface http://www.ti.com/solution/software-defined-radio-sdr-diagram http://www.ti.com/lit/an/slaa407/slaa407.pdf How to Select the (Best Minimum) Sampling Rate The selection of sampling rate is also important for ADCs. Fast encode clocks offer the advantage of making analog filtering significantly easier. Given a fixed signal bandwidth, a higher encode rate increases the allowable transition band. This allows lower order filters to be used to reduce cost, or, if higher order filters are still used, greater stop band rejection can potentially be realized. Another advantage with increasing clock speeds is processing gain. Processing gain is achieved when the signal of interest is oversampled and then digitally filtered. Processing gain occurs when noise outside the band of interest is digitally removed, which results in improved in-band SNR. Processing gain can be easily determined using Equation 1. This equation determines the increase in SNR over and above the SNR of the converter alone. Processing Gain = 10log10 (Half of the sample rate/ filter BW) Also, when selecting the sampling rate, the user must consider the second and third harmonics (HD2 and HD3). These harmonics must lie outside the band of interest. These can be filtered using the digital filter inside the DDC/DSP. That means, frequency planning also becomes important when designing a SDR system. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Sylvain Munaut Sent: Sunday, July 08, 2012 10:29 AM Cc: osmocom-sdr at lists.osmocom.org Subject: Re: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? > 1) Yes, if all you need is to be able to detect a signal on an analog stream its Nyquist Frequency will do, (2 times the frequency being measured) a 20 megasample ADC would be adequate for the E4000 tuner's I/Q output. This is IQ signal you don't need twice the bandwidth, you only need once. So a 8 Msps IQ would be adequate to represent a 8 MHz bandwidth. > [snip ....] >You need at least 10 times that bandwidth to accurately reconstruct Phase Modulated Signals. No you don't. You want a concrete example: Most GSM phone are demodulating a phase modulated signal by sampling at exactly one sample per symbol (so they're even sampling _lower_ than the actual signal bandwidth) And although oversampling is useful in certain case to analyze signal, it's essentially useless if the signal has _already_ been filtered like it is in the E4000 case. If the IQ output has only 8 MHz of useful content at the output, you can oversample all you want, it won't bring back what the E4000 discarded ... Those antialiasing filter you mention, they're in the E4000 ! 2) I didn't say bigger / better SDR would be useless ... I'm just saying if you're spending hundreds / thousands on better ADC and better PC interface you might as well ditch the E4000 and use a better RF front end as well. The spectral output of the E4000 is far from being "clean", there is distortions / LO leakage / random spurs / 28.8M clock leakage / ... etc ... Oh and Elonics declared bankrupcy so the E4000 supply is fading ... Cheers, Sylvain From leif at sm5bsz.com Sun Jul 8 19:29:10 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Sun, 8 Jul 2012 21:29:10 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> Message-ID: <20120708212910.a948b0a4.leif@sm5bsz.com> On Sun, 8 Jul 2012 12:30:05 -0500 "Jay Salsburg" wrote: > The E4000 Tuner offers a stepping stone into the world of SDRs. > It does the heavy lifting, significantly reducing the size, > cost, and complexity of a SDR. It does not do any programmable > signal processing, which is where SDRs are strongest. > Quantization has been left out of the discussion because the > RTL2832 is so bad at it (to conserve size and cost). The RTL2832 > hamstrings the usefulness of the E4000 significantly narrowing > the application of DSP. If you want high fidelity reception, > you must apply a high fidelity ADC. I do not understand how you think to arrive at this conclusion. The RTL2832/E4000 dongels allow superior quality demodulation of FM signals. The suppression of neighbouring channels is limited due to aliasing, but it is not bad and interference can be avoided by changing the LO frequency. There is also a mirror image but if you use Linrad you can apply the calibration procedure that eliminates image spurs. Now that AGC is eliminated these dongles allow a pretty good general purpose SDR at small cost. http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The high fidelity reception is in no way limited by the ADC in these dongles as long as the desired signal is not much weaker than surrounding signals. (Much means 50 dB or so.) Regards Leif / SM5BSZ From st at metafly.info Sun Jul 8 21:19:46 2012 From: st at metafly.info (Stefan Sydow) Date: Sun, 08 Jul 2012 23:19:46 +0200 Subject: Fix for rtlsdr_set_tuner_if_gain() In-Reply-To: <339884dfbf5e312fa643e036632b518b@mail.student.hs-rm.de> References: <20120707202759.90d59d32.leif@sm5bsz.com> <339884dfbf5e312fa643e036632b518b@mail.student.hs-rm.de> Message-ID: <4FF9F972.8020701@metafly.info> Hi, Am 08.07.2012 12:01, schrieb Steve Markgraf: > I've now pushed a change to librtlsdr that disables the AGC by > default, and added the function rtlsdr_set_agc_mode() that can > be used to re-enable it again. This works well. I use rtlsdr_set_tuner_if_gain() now to compensate for the gain loss and found a bug there: The i2c repeater needs to be enabled. --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -775,7 +775,9 @@ int rtlsdr_set_tuner_if_gain(rtlsdr_dev_t *dev, int stage, int gain) return -1; if (dev->tuner->set_if_gain) { + rtlsdr_set_i2c_repeater(dev, 1); r = dev->tuner->set_if_gain(dev, stage, gain); + rtlsdr_set_i2c_repeater(dev, 0); } return r; From Steve.Markgraf at student.hs-rm.de Sun Jul 8 21:39:20 2012 From: Steve.Markgraf at student.hs-rm.de (Steve Markgraf) Date: Sun, 08 Jul 2012 23:39:20 +0200 Subject: Fix for =?UTF-8?Q?rtlsdr=5Fset=5Ftuner=5Fif=5Fgain=28=29?= In-Reply-To: <4FF9F972.8020701@metafly.info> References: <20120707202759.90d59d32.leif@sm5bsz.com> <339884dfbf5e312fa643e036632b518b@mail.student.hs-rm.de> <4FF9F972.8020701@metafly.info> Message-ID: Hi, On 08.07.2012 23:19, Stefan Sydow wrote: > This works well. I use rtlsdr_set_tuner_if_gain() now to compensate > for the gain loss and found a bug there: The i2c repeater needs to > be enabled. Indeed, thanks for noticing. Fixed now. Regards, Steve From jsalsburg at bellsouth.net Mon Jul 9 15:21:13 2012 From: jsalsburg at bellsouth.net (Jay Salsburg) Date: Mon, 9 Jul 2012 10:21:13 -0500 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: <20120708212910.a948b0a4.leif@sm5bsz.com> References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> <20120708212910.a948b0a4.leif@sm5bsz.com> Message-ID: Well, this is interesting. Think out of the box. Ask yourself if a 8 bit NFM is high fidelity. I do high fidelity; 6 channel, 24 bit Wav files, that is high fidelity. When you have high conversion rates and high bit depth signals you get high fidelity. Audio NFM signals are only meant to satisfy walky-talky radio communication (Trunk Radio). The high value targets in Radio technology today is Data Services. Look in the (Data Stream) Mine for the Gold, Data is Gold. Data is wideband, multiple channel, and frequency diverse (not NFM), then there are all those wideband RADAR Signals. With high fidelity conversion you do not need anti-aliasing. Anti-Aliasing is a technique to filter, the very word means to take something away. Data services count on the fact that the Data is difficult to intercept. The object of any great effort is to rise above all the rest. To get the most out of the Tuner the ADC must be improved. All you guys have so much to offer and you have spent so much of your time and money to get the most out of this $20 Dongle, all because the Manufacturer refuses to open Source the Chip. Jump ahead and make better use of it. Go to the next level and hack the circuit, not just the Operating Code. The most extensive effort should be in acquiring intelligence from the Either, not listening to high power squawking Police channels. This requires very high granularity, the RTL2832 is low granularity. If you want to drop in on intelligence from over the horizon, very good selectivity is required and the RTL2832 is just not that; highly selective, intentionally by design. -----Original Message----- From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of Leif Asbrink Sent: Sunday, July 08, 2012 2:29 PM To: osmocom-sdr at lists.osmocom.org Subject: Re: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? On Sun, 8 Jul 2012 12:30:05 -0500 "Jay Salsburg" wrote: > The E4000 Tuner offers a stepping stone into the world of SDRs. > It does the heavy lifting, significantly reducing the size, cost, and > complexity of a SDR. It does not do any programmable signal > processing, which is where SDRs are strongest. > Quantization has been left out of the discussion because the > RTL2832 is so bad at it (to conserve size and cost). The RTL2832 > hamstrings the usefulness of the E4000 significantly narrowing the > application of DSP. If you want high fidelity reception, you must > apply a high fidelity ADC. I do not understand how you think to arrive at this conclusion. The RTL2832/E4000 dongels allow superior quality demodulation of FM signals. The suppression of neighbouring channels is limited due to aliasing, but it is not bad and interference can be avoided by changing the LO frequency. There is also a mirror image but if you use Linrad you can apply the calibration procedure that eliminates image spurs. Now that AGC is eliminated these dongles allow a pretty good general purpose SDR at small cost. http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The high fidelity reception is in no way limited by the ADC in these dongles as long as the desired signal is not much weaker than surrounding signals. (Much means 50 dB or so.) Regards Leif / SM5BSZ From peter at stuge.se Mon Jul 9 15:35:19 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 9 Jul 2012 17:35:19 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> <20120708212910.a948b0a4.leif@sm5bsz.com> Message-ID: <20120709153519.5208.qmail@stuge.se> Jay Salsburg wrote: > Go to the next level and hack the circuit, not just the Operating Code. Buy an OsmoSDR. //Peter From leif at sm5bsz.com Mon Jul 9 21:26:36 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Mon, 9 Jul 2012 23:26:36 +0200 Subject: stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ? In-Reply-To: References: <20120706095240.0a8d3012@dhcp-221.lpmo.priv> <20120708212910.a948b0a4.leif@sm5bsz.com> Message-ID: <20120709232636.f85b9d43.leif@sm5bsz.com> Hello Jay, > Well, this is interesting. Think out of the box. Ask yourself if a 8 bit NFM > is high fidelity. You have to specify what you mean by this. The NFM signal carries information by the instantaneous frequeny of the signal. When sampled with 8 bit frequently enough the frequency can be determined with great precision. > I do high fidelity; 6 channel, 24 bit Wav files, that is > high fidelity. This statement is basically false. There is no way that you could have 24 bit accuracy in a .wav file (unless the waveforms are synthetized in the computer from mathematical functions.) A good 24 bit soundcard like the Delta 44 provides 18 bit data. Bits 19 to 24 contain only noise and can be truncated without any effect on the recorded information. The best modern A/D converters may provide nearly 20 bits, but providing 24 bit is not possible. The noise floor is set by the thermal noise of any resistor at room temperature. The 8 bit data in RTL2832 is from two separate A/D converters and together they provide 8 bit at 4MHz sampling rate. That is the same as 9 bit at 1MHz or 10 bit at 250 kHz or 11 bit at 62.5 kHz. I was thinking you were referring to FM broadcast in which case the FM detector would improve S/N by about 20 dB. (3 bit) > When you have high conversion rates and high bit depth > signals you get high fidelity. Audio NFM signals are only meant to satisfy > walky-talky radio communication (Trunk Radio). Hmmm, "Audio NFM"? do you mean the audio signal delivered by an FM detector? They would have about 13 bit accuracy when produced from the 8 bit 2*2 MHz data stream from a rtl2832. In real life the S/N would limit performance and it would be identical to what you observe on a better radio unless you have really strong interferring signals. > The high value targets in > Radio technology today is Data Services. Look in the (Data Stream) Mine for > the Gold, Data is Gold. Data is wideband, multiple channel, and frequency > diverse (not NFM), then there are all those wideband RADAR Signals. With > high fidelity conversion you do not need anti-aliasing. Anti-Aliasing is a > technique to filter, the very word means to take something away. Data > services count on the fact that the Data is difficult to intercept. It does not matter at all whether we do anti-aliasing in analog hardware or whether we sample at a higher rate and do it by a digital filter. The result is identical. The effective bandwidth is what matters. > The object of any great effort is to rise above all the rest. To get the > most out of the Tuner the ADC must be improved. All you guys have so much to > offer and you have spent so much of your time and money to get the most out > of this $20 Dongle, all because the Manufacturer refuses to open Source the > Chip. Jump ahead and make better use of it. Go to the next level and hack > the circuit, not just the Operating Code. Well, I did that and came to the conclusion it would be a good idea until the AGC problem was solved. Now, without the AGC, the RTL2832 chip matches the performance of the E4000 tuner pretty well. Adding a much better A/D converter will not improve performance significantly. We would need a better tuner to motivate a better A/D converter. > The most extensive effort should be in acquiring intelligence from the > Either, not listening to high power squawking Police channels. This requires > very high granularity, the RTL2832 is low granularity. Are you sure you know what you are saying here? The RTL2832/E4000 dongle provides a dynamic range of 80 dB. You might tell us what the received power levels are from the stations you want to hear - and what is the signal level of the stations that might interfere (high power squawking Police channels...) > If you want to drop > in on intelligence from over the horizon, very good selectivity is required > and the RTL2832 is just not that; highly selective, intentionally by design. The RTL2832 is just a dual A/D converter. (As operated for SDR) Replacing it with something 2 or 3 times faster would allow us to remove the alias signals that we see in the DVB dongles. It would not improve performance much in other respects however because the minimum noise floor from the E4000 is about 1 bit on the RTL2832 and running the E4000 at higher output levels would make the harmonic distortion unacceptable. Surely performance of the DVB dongle is limited, but it is not bad. Quite respectable actually. (But you need the latest software - or maybe even a little later than what you can download today. I have not evaluated the latest changes so I do not know.) Regards Leif / SM5BSZ From leif at sm5bsz.com Mon Jul 9 23:04:55 2012 From: leif at sm5bsz.com (Leif Asbrink) Date: Tue, 10 Jul 2012 01:04:55 +0200 Subject: RTLSDR Philosophy. Message-ID: <20120710010455.d03f19af.leif@sm5bsz.com> Hi All, A device with limited dynamic range like the RTL2832/E4000 dongle needs a carefully designed gain control to allow the user to move the dynamic range up or down to fit the current RF environment. The latest version has the required gain controls, but to write an application that optimizes the performance one has to know the dongle. I would like to use the standard library for Linrad. The purpose would be to get support for other tuners than the E4000 that are available today or that that may become available in the future. There is rtlsdr_get_tuner_gains that returns the lna gain in the case of e4000. The gain values it returns for the other tuners has a small range which means that somehow (AGC or manual) one can set a much wider gain range. In the case of E4000 there is IF gain and mixer gain. I can not find those in the other tuners even though they have to be present in the hardware - but maybe only in the form of AGC. The application program needs to have: get_mixer_gains() get_no_of_if_gain_controls() get_if_gains(no) Or something equivalent to run the E4000. To me this does not look right. Having each gain block as a separate object for the application program to figure out how to handle means that the application programmer needs to know the details of each tuner that might become available. I think a much better approach would be to see the entire tuner chip as an object. That would imply that the "set tuner gain" would use all the gain controls inside the tuner chip in the proper order. In the case of the E4000 tuner it would be like this: Max gain: lna gain set to max. IF and mixer gain set to levels that produce 6 to 10 dB above minimum noise at the RTL2832 input. Reduced gain 1 to 10 dB: The lna should be left at max gain while mixer and/or IF gain is reduced. Further reduced gain: Reduce lna gain. The contribution from IF and mixer is already negligible. Even lower gain: When lna is at minimum we can still reduce IF gain. The strategy would allow the application program to ask for the gain range. Whether the gain setting would accept any value and set the closest possible or whether it would require the user to query what gain levels the system allows is a matter of convenience. The fundamental problem is whether the application program needs to know the internals of every supported chip. A peace of hardware like the RTL2832/E4000 dongle needs a gain control that spans at least 40 dB. The other tuners need the same but in case itis only available as AGC they are not suitable for SDR. At the moment Linrad works well with the E4000, but I do not think it would work with other tuners. I will wait for progress on the librtlsdr library. Hopefully it will be clear how an application program can set the system gain over a range of at least 40 dB without knowledge of the internald? of the tuners. 73 Leif / SM5BSZ From f.gugliuzza at hacklabproject.org Tue Jul 10 00:27:37 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Tue, 10 Jul 2012 02:27:37 +0200 Subject: RTLSDR Philosophy. In-Reply-To: <20120710010455.d03f19af.leif@sm5bsz.com> References: <20120710010455.d03f19af.leif@sm5bsz.com> Message-ID: 2012/7/10 Leif Asbrink : > Reduced gain 1 to 10 dB: The lna should be left at max gain while > mixer and/or IF gain is reduced. My two cents are that it's better to play with the multiple stage gains when possible and raise the LNA gain only when necessary, since it's before the VHF2/VHF3/UHF/L-band bandpass and if you have strong signals in other bands you could get intermods virtually everywhere. -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From sandor.szilvasi at gmail.com Tue Jul 10 15:05:30 2012 From: sandor.szilvasi at gmail.com (Sandor Szilvasi) Date: Tue, 10 Jul 2012 10:05:30 -0500 Subject: OsmoSDR Hardware Design Questions Message-ID: Hi OsmoCom, I was going to start a home project *very similar* to yours, when I bumped into the OsmoSDR. So, I'd like to ask a few questions regarding the OsmoSDR hardware. 1. Based on the photoyour fab could handle BGA packages. Why didn't you use the BGA packaged Atmel SAM3U MCU instead of the LQFP one? 2. The Lattice LatticeXP2 FPGA is available in the same package but in larger size at almost identical price. Why did you pick the smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E ($20)? 3. You are using the SAM3U SSC to transfer data from the FPGA. Before seeing your design I had the idea to use the EBI to interface with the FPGA. After all, the EBI is on the AHB and I assume you have a bunch of FPGA I/Os left. What do you think the drawbacks of using the EBI would be? 4. The differential clock output oscillator was connected in a weird way, but I can see that it has been corrected in Rev 2. 5. My understanding is that you configure the FPGA using the JTAG lines in bit-bang mode through SAM3U GPIOs. Why don't you use the sysConfig port of the Lattice FPGA? It's faster, easier to implement with the SAM3U SPI peripheral (and it's also a feature I haven't seen with other FPGAs). See Lattice TN1141 . 6. The board seems to be powered from the USB only, but the oscillator already draws ~100mA and it's always enabled. Adding the consumption of the MCU and the FPGA you are already above 100mA. If it's really powered only from the USB, how is it ensured that you stay below the 100mA limit specified by the USB standard until you ask for a higher current, say 500mA? I hope you didn't mind my questions above, I didn't mean to be nosy. I just got a little excited about this project. Cheers, Sandor -------------- next part -------------- An HTML attachment was scrubbed... URL: From cd at maintech.de Tue Jul 10 17:04:35 2012 From: cd at maintech.de (Christian Daniel -- maintech GmbH) Date: Tue, 10 Jul 2012 19:04:35 +0200 Subject: OsmoSDR Hardware Design Questions In-Reply-To: References: Message-ID: <4FFC60A3.6010505@maintech.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sandor, I'll write my answers directly into your mail: On 10.07.2012 17:05, Sandor Szilvasi wrote: > Hi OsmoCom, > > I was going to start a home project /very similar/ to yours, when > I bumped into the OsmoSDR. So, I'd like to ask a few questions > regarding the OsmoSDR hardware. > > 1. Based on the photo > your fab > could handle BGA packages. Why didn't you use the BGA packaged > Atmel SAM3U MCU instead of the LQFP one? That was an option, but we decided to go for a part with actual pins because these are easier to debug and we had the space (at the time). > 2. The Lattice LatticeXP2 FPGA is available in the same package but > in larger size at almost identical price. Why did you pick the > smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E > ($20)? Because it was on stock and is big enough for the task at hand. > 3. You are using the SAM3U SSC to transfer data from the FPGA. > Before seeing your design I had the idea to use the EBI to > interface with the FPGA. After all, the EBI is on the AHB and I > assume you have a bunch of FPGA I/Os left. What do you think the > drawbacks of using the EBI would be? The SSC is too slow to handle the full 4MHz bandwith - a problem we only discovered after the first prototypes were built. We're currently investigating a redesign to switch to EBI. > 4. The differential clock output oscillator was connected in a > weird way, but I can see that it has been corrected in Rev 2. Yep, embarrassing mistake that... > 5. My understanding is that you configure the FPGA using the JTAG > lines in bit-bang mode through SAM3U GPIOs. Why don't you use the > sysConfig port of the Lattice FPGA? It's faster, easier to > implement with the SAM3U SPI peripheral (and it's also a feature I > haven't seen with other FPGAs). See Lattice TN1141 > . Good point. Well - the current method works well and is fast (about 30 seconds to flash via USB). No need to change it again... My guess is, that it won't get much faster since the bottleneck is USB and flash write time. Perhaps we'll have to change it when we switch to EBI to free some SAM3U pins. > 6. The board seems to be powered from the USB only, but the > oscillator already draws ~100mA and it's always enabled. Adding the > consumption of the MCU and the FPGA you are already above 100mA. If > it's really powered only from the USB, how is it ensured that you > stay below the 100mA limit specified by the USB standard until you > ask for a higher current, say 500mA? We violate the 100mA limit by a small amount. FPGA and E4K can be switched off and the ADC doesn't consume much when no clock is applied. I don't see a problem here - at least after we fixed the power sequence to stop it from using the full 400mA directly on power up. Also a diode for external power supply is on the board. But yes - it will not be USB certified. But so far this is not a real-world problem. > I hope you didn't mind my questions above, I didn't mean to be > nosy. I just got a little excited about this project. Just keep on asking - this is open hardware and open software and the more the merrier! > Cheers, > > Sandor 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://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP/GCdAAoJEHkgzUIsAWri8sgH/RJatmt6EX6azQT3esDoDFGK OSpFDwcuNpPVthT0VUpFapn3et/HwzoW7ZHUUe0DnAorFY7oNVtEtZfj5AIOIJ4H aPN1Pw8H+tXTZebxURjr44IGLjavVlUXlDvlzuOuMTcypysjkj8806/KbXi7gLJ0 9NfLwDPv/2kJVi1Ys6FITO1waXz8jC6qzvziGijPlNO3BHOvQecjbINhqmcLzhFO s7g4FuNZJPMbGu/jT/YG3WkxhAb23ibipS7YA8h/DZa4osgAoEYNcVi58zt4V1yz cDFBHm9P/a2m3WqEHar8Npd62Eqwi+0UzKoxfHjKVbeAconKQI1Xrkmu2vS9wbw= =JCC2 -----END PGP SIGNATURE----- From laforge at gnumonks.org Tue Jul 10 17:26:10 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 10 Jul 2012 19:26:10 +0200 Subject: OsmoSDR Hardware Design Questions In-Reply-To: <4FFC60A3.6010505@maintech.de> References: <4FFC60A3.6010505@maintech.de> Message-ID: <20120710172610.GD30822@prithivi.gnumonks.org> Hi Christian, On Tue, Jul 10, 2012 at 07:04:35PM +0200, Christian Daniel -- maintech GmbH wrote: > We violate the 100mA limit by a small amount. FPGA and E4K can be > switched off and the ADC doesn't consume much when no clock is > applied. I don't see a problem here - at least after we fixed the > power sequence to stop it from using the full 400mA directly on power > up. Also a diode for external power supply is on the board. But yes - > it will not be USB certified. But so far this is not a real-world problem. Actually, now that you're doing a re-design for the SSC -> EBI change, it might be an idea to make the oscillator power supply switchable and controlled by a GPIO from the SAM3U or FPGA. At that point, there's no problem booting at < 100mA. I wouldn't expect a small low-Rds_on mosefet switch to cause any problem for the oscillator, especially since it's constant current/power... 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 sandor.szilvasi at gmail.com Wed Jul 11 15:16:46 2012 From: sandor.szilvasi at gmail.com (Sandor Szilvasi) Date: Wed, 11 Jul 2012 10:16:46 -0500 Subject: OsmoSDR Hardware Design Questions In-Reply-To: <20120710172610.GD30822@prithivi.gnumonks.org> References: <4FFC60A3.6010505@maintech.de> <20120710172610.GD30822@prithivi.gnumonks.org> Message-ID: Hi, On Tue, Jul 10, 2012 at 12:26 PM, Harald Welte wrote: > Hi Christian, > > On Tue, Jul 10, 2012 at 07:04:35PM +0200, Christian Daniel -- maintech > GmbH wrote: > > We violate the 100mA limit by a small amount. FPGA and E4K can be > > switched off and the ADC doesn't consume much when no clock is > > applied. I don't see a problem here - at least after we fixed the > > power sequence to stop it from using the full 400mA directly on power > > up. Also a diode for external power supply is on the board. But yes - > > it will not be USB certified. But so far this is not a real-world > problem. > > Actually, now that you're doing a re-design for the SSC -> EBI change, > it might be an idea to make the oscillator power supply switchable and > controlled by a GPIO from the SAM3U or FPGA. At that point, there's no > problem booting at < 100mA. > > The Si570 has an OE pin, but even in tri-state mode it still consumes ~60mA. So, I second Harald: it makes sense to have an option to make the oscillator power supply switchable and to keep the overall consumption (including the RF IC, ADC, FPGA, TCXO and MCU) below 100mA until higher currents are negotiated. Connect the switch input to a SAM3U I/O rather than one of the FPGA. By the way, the FPGA seems to have only one clock input, 'CLKPO'. Is this the case? > 2. The Lattice LatticeXP2 FPGA is available in the same package but > in larger size at almost identical price. Why did you pick the > smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E > ($20)? Because it was on stock and is big enough for the task at hand. It can never be too big for a prototype. :) The two models ought to be pin-compatible, so the upgrade might be worth it if the LFXP-8E is available. > 5. My understanding is that you configure the FPGA using the JTAG > lines in bit-bang mode through SAM3U GPIOs. Why don't you use the > sysConfig port of the Lattice FPGA? It's faster, easier to > implement with the SAM3U SPI peripheral (and it's also a feature I > haven't seen with other FPGAs). See Lattice TN1141 > . Good point. Well - the current method works well and is fast (about 30 seconds to flash via USB). No need to change it again... My guess is, that it won't get much faster since the bottleneck is USB and flash write time. Perhaps we'll have to change it when we switch to EBI to free some SAM3U pins. The other advantage of using the sysConfig Port is that you can save the JTAG lines for a pin header. If the pin header is compatible with the Lattice programmer, you might be able to use the Lattice's ChipScope equivalent for debugging the FPGA. Cheers, Sandor -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmosdr at mkarcher.dialup.fu-berlin.de Sat Jul 14 19:23:20 2012 From: osmosdr at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Sat, 14 Jul 2012 21:23:20 +0200 Subject: RTL2832U FIR filter Message-ID: <1342293800.5539.42.camel@localhost> Hello people, in some experiments with my RTL2832 stick, I managed to find out how the FIR filter works. The FIR filter is running at the XTAL frequency (typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR filter with 32 real-number-valued taps. Using the symmetry, only 16 coefficients need to be specified. The coefficients are stored in the 20 bytes written to the FIR register. The first coefficient describes the outermost tap, the last one the tap 0.5 taps away from the symmetry axis. The first 8 values are 8-bit numbers, the second 8 values are 12 bit numbers, resulting in 64 + 96 = 160 bits (20 bytes). The first 8 bytes written to the chip are the first 8 coefficients. The 12-bit coefficients are stored like this pairwise in three bytes: In the byte sequence "12 34 56", the first coefficient is 0x123 and the second coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be interpreted as two's complement signed numbers (thus the 8-bit coefficients range from -128 to +127, while the 12-bit coefficients range from -2048 to +2047). The resolution of all 16 coefficients is the same. I furthermore found out that this is not the only filtering going on in the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing filter before the DAC, making signals disappear that are at frequencies above 0.7 times the sample rate (in the baseband), even if the programmable FIR filter lets them pass. As an example, I provide the decoded default coefficients: -54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421 421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54 This filter has a quite flat passband in the interesting range for DAB (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory adjacent channel rejection. The experimentally observed alias rejection is good enough, which lead to the conclusion that there is another low-pass filter, which might be part of the resampling unit. Regards, Michael Karcher From osmocom at mkarcher.dialup.fu-berlin.de Sat Jul 14 17:46:48 2012 From: osmocom at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Sat, 14 Jul 2012 19:46:48 +0200 Subject: RTL2832U FIR filter Message-ID: <1342288008.5539.39.camel@localhost> Hello people, in some experiments with my RTL2832 stick, I managed to find out how the FIR filter works. The FIR filter is running at the XTAL frequency (typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR filter with 32 real-number-valued taps. Using the symmetry, only 16 coefficients need to be specified. The coefficients are stored in the 20 bytes written to the FIR register. The first coefficient describes the outermost tap, the last one the tap 0.5 taps away from the symmetry axis. The first 8 values are 8-bit numbers, the second 8 values are 12 bit numbers, resulting in 64 + 96 = 160 bits (20 bytes). The first 8 bytes written to the chip are the first 8 coefficients. The 12-bit coefficients are stored like this pairwise in three bytes: In the byte sequence "12 34 56", the first coefficient is 0x123 and the second coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be interpreted as two's complement signed numbers (thus the 8-bit coefficients range from -128 to +127, while the 12-bit coefficients range from -2048 to +2047). The resolution of all 16 coefficients is the same. I furthermore found out that this is not the only filtering going on in the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing filter before the DAC, making signals disappear that are at frequencies above 0.7 times the sample rate (in the baseband), even if the programmable FIR filter lets them pass. As an example, I provide the decoded default coefficients: -54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421 421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54 This filter has a quite flat passband in the interesting range for DAB (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory adjacent channel rejection. The experimentally observed alias rejection is good enough, which lead to the conclusion that there is another low-pass filter, which might be part of the resampling unit. BTW: the 900kHz low sample rate limit seems to be valid for a 36MHz XTAL, not the common 28.8MHz XTAL. Regards, Michael Karcher From osmosdr at mkarcher.dialup.fu-berlin.de Sat Jul 14 19:57:01 2012 From: osmosdr at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Sat, 14 Jul 2012 21:57:01 +0200 Subject: RTL2832U FIR filter In-Reply-To: <1342288008.5539.39.camel@localhost> References: <1342288008.5539.39.camel@localhost> Message-ID: <1342295821.5539.66.camel@localhost> Am Samstag, den 14.07.2012, 19:46 +0200 schrieb Michael Karcher: > BTW: the 900kHz low sample rate limit seems to be valid for a 36MHz > XTAL, not the common 28.8MHz XTAL. Please ignore this comment, it is plain wrong. You might choose to ignore the whole mail, too, as I resent it with my subscribed address and without that comment some hours later. Regards, Michael Karcher From laforge at gnumonks.org Sat Jul 14 19:56:19 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 14 Jul 2012 21:56:19 +0200 Subject: RTL2832U FIR filter In-Reply-To: <1342293800.5539.42.camel@localhost> References: <1342293800.5539.42.camel@localhost> Message-ID: <20120714195619.GF28634@prithivi.gnumonks.org> Hi Michael, On Sat, Jul 14, 2012 at 09:23:20PM +0200, Michael Karcher wrote: > in some experiments with my RTL2832 stick, I managed to find out how the > FIR filter works. [...] congratulations, it's really great to see that this has been figured out. Thanks for sharing your results. ... and seeing that you're from a fu-berlin.de address: Did you consider joining our Osmocom Berlin User Group meetings at some point? (http://openbsc.osmocom.org/trac/wiki/OsmoUserGroup/Berlin) [my apologies if you've already been there and I don't remember the name...] 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 f.gugliuzza at hacklabproject.org Sat Jul 14 23:22:37 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Sun, 15 Jul 2012 01:22:37 +0200 Subject: RTL2832U FIR filter In-Reply-To: <1342293800.5539.42.camel@localhost> References: <1342293800.5539.42.camel@localhost> Message-ID: 2012/7/14 Michael Karcher : > I furthermore found out that this is not the only filtering going on in > the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing > filter before the DAC, making signals disappear that are at frequencies > above 0.7 times the sample rate (in the baseband), even if the > programmable FIR filter lets them pass. That's probably an effect of the E4000 output filter. You can see the filter bandwidth being set in the tuner initalization code. -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From st at metafly.info Sat Jul 14 23:59:55 2012 From: st at metafly.info (Stefan Sydow) Date: Sun, 15 Jul 2012 01:59:55 +0200 Subject: RTL2832U FIR filter In-Reply-To: <1342293800.5539.42.camel@localhost> References: <1342293800.5539.42.camel@localhost> Message-ID: <500207FB.4010905@metafly.info> Hello Michael, Am 14.07.2012 21:23, schrieb Michael Karcher: > This filter has a quite flat passband in the interesting range for DAB > (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which > will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory > adjacent channel rejection. The experimentally observed alias rejection > is good enough, which lead to the conclusion that there is another > low-pass filter, which might be part of the resampling unit. I've got a passband of nearly 2MHz with the original coefficients. Did I miss a factor 2 somewhere? I tried to construct a narrower filter using the gnuradio function. Here is a python script to construct the FIR register and plot the frequency response. Maybe the script is also helpful to you. Regards, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: fir_coeff.py Type: text/x-python Size: 2520 bytes Desc: not available URL: From osmosdr at mkarcher.dialup.fu-berlin.de Sun Jul 15 07:16:20 2012 From: osmosdr at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Sun, 15 Jul 2012 09:16:20 +0200 Subject: RTL2832U FIR filter In-Reply-To: References: <1342293800.5539.42.camel@localhost> Message-ID: <1342336580.5539.79.camel@localhost> Am Sonntag, den 15.07.2012, 01:22 +0200 schrieb Francesco Gugliuzza: > 2012/7/14 Michael Karcher : > > I furthermore found out that this is not the only filtering going on in > > the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing > > filter before the DAC, making signals disappear that are at frequencies > > above 0.7 times the sample rate (in the baseband), even if the > > programmable FIR filter lets them pass. > That's probably an effect of the E4000 output filter. You can see the > filter bandwidth being set in the tuner initalization code. Good point, but actually, I am sure it is not an effect of the tuner output filter. My USB stick contains a fc0012 tuner, which is always set to 6MHz bandwidth. The bandwidth of the suspected anti-alias filter changes clearly when I change the sample rate, though, on the other hand, if I manipulate the FIR coefficients to contain sharp dips in the range of hundred kHz, the dip position does not change when I change the sample rate. This makes me cofident that the suspected anti-alias filter has to be located in or after the resampling unit. Regards, Michael Karcher From f.gugliuzza at hacklabproject.org Sun Jul 15 10:40:33 2012 From: f.gugliuzza at hacklabproject.org (Francesco Gugliuzza) Date: Sun, 15 Jul 2012 12:40:33 +0200 Subject: RTL2832U FIR filter In-Reply-To: <1342336580.5539.79.camel@localhost> References: <1342293800.5539.42.camel@localhost> <1342336580.5539.79.camel@localhost> Message-ID: 2012/7/15 Michael Karcher : > Good point, but actually, I am sure it is not an effect of the tuner > output filter. My USB stick contains a fc0012 tuner, which is always set > to 6MHz bandwidth. The bandwidth of the suspected anti-alias filter > changes clearly when I change the sample rate, though, on the other > hand, if I manipulate the FIR coefficients to contain sharp dips in the > range of hundred kHz, the dip position does not change when I change the > sample rate. This makes me cofident that the suspected anti-alias filter > has to be located in or after the resampling unit. The only thing I can think of now is the raised cosine filter used in digital modulation receivers, but IMHO that should be implemented in the FIR filter. -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza at hacklabproject.org From osmosdr at mkarcher.dialup.fu-berlin.de Sun Jul 15 11:35:15 2012 From: osmosdr at mkarcher.dialup.fu-berlin.de (Michael Karcher) Date: Sun, 15 Jul 2012 13:35:15 +0200 Subject: RTL2832U FIR filter In-Reply-To: <500207FB.4010905@metafly.info> References: <1342293800.5539.42.camel@localhost> <500207FB.4010905@metafly.info> Message-ID: <1342352115.5539.92.camel@localhost> Am Sonntag, den 15.07.2012, 01:59 +0200 schrieb Stefan Sydow: > Hello Michael, > > This filter has a quite flat passband in the interesting range for DAB > > (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which > > will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory > > adjacent channel rejection. The experimentally observed alias rejection > > is good enough, which lead to the conclusion that there is another > > low-pass filter, which might be part of the resampling unit. > I've got a passband of nearly 2MHz with the original coefficients. > Did I miss a factor 2 somewhere? I tried to construct a narrower filter > using the gnuradio function. No, I don't think you missed a factor of 2. I get a -3dB bandwidth of 1.2MHz, and the stopband rejection of -35dB indeed starts at around 2MHz. The actual required DAB range (768kHz) has a flatness of 0.55dB, if I calculated all the stuff correctly. > Here is a python script to construct the FIR register and plot the > frequency > response. Maybe the script is also helpful to you. Thanks for the script, just some minor notes: SAMP_RATE should be 28.8e6, not 28e6. Also you don't seem to do any overflow checking on the conversion. If you are trying to build narrow filters, I expect you might hit the 1/16 limit on the outer 8 coefficients, so the filter coefficients might need to be shrunk (reducing the filter gain, of course) before converting to integers. I'm afraid that constructing a filter using gnuradio firdes and then truncating it to 32 coefficients is likely not resulting in a good filter. In my oppinion (not backed by math knowledge in that area, though), the filter length should already be considered during coefficient generation. It looks like your plot uses the convention that 10dB is a factor of 10. As the filter affects amplitude values and not power values, you should use 20dB for a factor of 10, if I understand the dB scale correctly. Regards, Michael Karcher From st at metafly.info Sun Jul 15 13:36:06 2012 From: st at metafly.info (Stefan Sydow) Date: Sun, 15 Jul 2012 15:36:06 +0200 Subject: RTL2832U FIR filter In-Reply-To: <1342352115.5539.92.camel@localhost> References: <1342293800.5539.42.camel@localhost> <500207FB.4010905@metafly.info> <1342352115.5539.92.camel@localhost> Message-ID: <5002C746.8030508@metafly.info> Hi Michael, > Thanks for the script, just some minor notes: SAMP_RATE should be > 28.8e6, not 28e6. Also you don't seem to do any overflow checking on the > conversion. If you are trying to build narrow filters, I expect you > might hit the 1/16 limit on the outer 8 coefficients, so the filter > coefficients might need to be shrunk (reducing the filter gain, of > course) before converting to integers. Good point. Thanks > I'm afraid that constructing a filter using gnuradio firdes and then > truncating it to 32 coefficients is likely not resulting in a good > filter. In my oppinion (not backed by math knowledge in that area, > though), the filter length should already be considered during > coefficient generation. Yes that's right. Using gnuradio firdes was a first hack with acceptable error as the fft shows. A better way is to use sinc() and a window function. Had a look into my "Signale and Systeme" script. There is also a software called winfilter if you want a 'classic' filter. It works well under wine. http://www.winfilter.20m.com/ > It looks like your plot uses the convention that 10dB is a factor of 10. > As the filter affects amplitude values and not power values, you should > use 20dB for a factor of 10, if I understand the dB scale correctly. I missed that too. A fix version is attached. Regards, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: fir_coeff.py Type: text/x-python Size: 3417 bytes Desc: not available URL: From antoine at monte-stello.com Tue Jul 24 20:19:07 2012 From: antoine at monte-stello.com (Antoine Sirinelli) Date: Tue, 24 Jul 2012 21:19:07 +0100 Subject: gr-ais for rtl-sdr Message-ID: <20120724201906.GA6561@speedy> Hi, I have tried to modify the AIS decoding implementation from Nick Foster (https://cgran.org/wiki/AIS) in order to be able to use an rtl dongle as a source. Unfortunately I am not living by the sea and I cannot test it before a couple of week. Is there anybody able to receive AIS messages willing to test my changes? You can find it on github: https://github.com/asirinelli/gr-ais The 2 main assumptions I made are: - Nick first implementation is working - rtl-sdr is able to have a sample rate of 256 kHz. Many thanks, Antoine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From horiz0n at gmx.net Tue Jul 24 21:52:44 2012 From: horiz0n at gmx.net (Dimitri Stolnikov) Date: Tue, 24 Jul 2012 23:52:44 +0200 Subject: gr-ais for rtl-sdr In-Reply-To: <20120724201906.GA6561@speedy> References: <20120724201906.GA6561@speedy> Message-ID: Hi Antoine, > I have tried to modify the AIS decoding implementation from Nick Foster > (https://cgran.org/wiki/AIS) in order to be able to use an rtl dongle as > a source. Unfortunately I am not living by the sea and I cannot test it > before a couple of week. Is there anybody able to receive AIS messages > willing to test my changes? You can find it on github: > https://github.com/asirinelli/gr-ais If someone provides a standard gnuradio-format cfile of AIS you can run it offline using a device argument of the form --args "file=/path/to/your.cfile,rate=2048e3,repeat=true,throttle=true" in the osmosdr block. Note the mandatory rate argument and optional repeat & throttle arguments. > The 2 main assumptions I made are: > - Nick first implementation is working Never had a chance to test it myself. > - rtl-sdr is able to have a sample rate of 256 kHz. Unfortunately this is not the case. You still could use a higher sample rate here (1024e3 or 2048e3) and then apply decimation/resampling until you reach your required samplerate. Best regards, Dimitri