From alancorey at yahoo.com  Wed May  1 02:34:34 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 30 Apr 2013 19:34:34 -0700 (PDT)
Subject: rtl_fm scanning
In-Reply-To: <29247AB4-B695-4C87-BF70-6C201F0FA15E@gmail.com>
Message-ID: <1367375674.3067.YahooMailClassic@web161504.mail.bf1.yahoo.com>

Under OpenBSD only sync mode works, and that's only with Stuart Henderson's patches from http://www.openbsd.org/cgi-bin/cvsweb/ports/comms/rtl-sdr/patches/.? I'm scanning a bunch of 120 MHz AM aircraft freqs right now and I don't hear the noise, but scanning FM I do.? rtl_adsb, rtl_tcp, etc. aren't fixed yet.

I'm running libusb 1.0.9p3 from the OpenBSD ports collection under 5.2.? I have a 5.0 machine with 1.0.9 built from a tarball that works a few minutes and gives a "library -99" error.

? Alan

-----

Radio Astronomy - the ultimate DX

--- On Tue, 4/30/13, Ben Moore <benjamin.n.moore at gmail.com> wrote:

From: Ben Moore <benjamin.n.moore at gmail.com>
Subject: Re: rtl_fm scanning
To: osmocom-sdr at lists.osmocom.org
Date: Tuesday, April 30, 2013, 3:16 PM

I haven't had a chance to check on the Raspberry Pi to see if this issue is fixed by forcing synchronous mode, but I suspect it is.
http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-April/000588.html
- Ben

On Apr 30, 2013, at 11:07 AM, Alan Corey wrote:
Mine doesn't hang, it just makes a noise.? If I change just the demodulator to AM instead of FM, it doesn't do it. If I set the squelch level up around 1000 it takes out the signals, but not the noise.

OpenBSD 5.2, ftl_fm from git about 4/23/2013

? Alan

-----

Radio Astronomy - the ultimate DX

--- On Tue, 4/30/13, Chourico <lists at the-reapers.com> wrote:

From: Chourico <lists at the-reapers.com>
Subject: Re: rtl_fm scanning
To: osmocom-sdr at lists.osmocom.org
Date: Tuesday, April 30, 2013, 7:53 AM

Colin Stagner <cbs228 <at> gmail.com> writes:

> 
> I am also having the rtl_fm scanning bug which was first reported in
> http://lists.gnumonks.org/pipermail/osmocom-sdr/2013-February/000485.html
> 

> 
> Can anyone else reproduce this bug?
> 
> 

I am having the same problem.

EzTV666, Ubuntu 12.04, kernel 3.2.0-23,
latest rtl_sdr from git, 2013-04-30

rtl_fm
 works fine when only one frequency is specified, hangs after first
frequency is skipped.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130430/c29235be/attachment.htm>

From oz9aec at gmail.com  Wed May  1 11:21:54 2013
From: oz9aec at gmail.com (Alexandru Csete)
Date: Wed, 1 May 2013 13:21:54 +0200
Subject: Compiling on osx - solved...
In-Reply-To: <CAKQd66W+zN96v4GH3_gQdw+qSFsyJfUAgwoe=6es3mz_kQF5iw@mail.gmail.com>
References: <CAKQd66W+zN96v4GH3_gQdw+qSFsyJfUAgwoe=6es3mz_kQF5iw@mail.gmail.com>
Message-ID: <CAHG=S_e=N3WPB+HbUsCeptUn=Rnc8V=DpctomzViO86NcnYiMA@mail.gmail.com>

On Fri, Apr 26, 2013 at 8:40 PM, Alberto Albiol <alalbiol at iteam.upv.es> wrote:
> Hello
> I have been fighting to compile the gr-osmosdr package in my osx
>
> These are the minor fixes I had to do:
> 1- Change in Cmakelists.txt:  find_package(Boost COMPONENTS thread system),
> If thread and system is not included then there are linking problems.
> Although I see that this was removed recently...
>
>  2- cmake -DCMAKE_INSTALL_PREFIX=/opt/local (so it is installed together wit
> my ports intallation, this is really optional)
> 3- Before compiling I manually edit CmakeCache.txt, and change all the
> references of /usr/lib/python to /opt/local/lib/python. If not it links
> agains the system python instead of the ports's python!
> 4- Add this line in my .bashrc so python can find the package
>           export PYTHONPATH="/opt/local/lib/python2.7/site-packages/"
>
> I am aware that this is not the most elegant way to solve the problem but is
> the only one that I was able to come up. Hope it helps
>

Hi Alberto,

Perhaps the gr-osmosdr package in macports can be of some help for how
to compile without manually editing the build files:
https://trac.macports.org/browser/trunk/dports/science/gr-osmosdr/Portfile

Alex



From mjmdavis at gmail.com  Wed May  1 13:01:23 2013
From: mjmdavis at gmail.com (Michael Davis)
Date: Wed, 1 May 2013 15:01:23 +0200
Subject: Compiling on osx - solved...
In-Reply-To: <CAHG=S_e=N3WPB+HbUsCeptUn=Rnc8V=DpctomzViO86NcnYiMA@mail.gmail.com>
References: <CAKQd66W+zN96v4GH3_gQdw+qSFsyJfUAgwoe=6es3mz_kQF5iw@mail.gmail.com>
	<CAHG=S_e=N3WPB+HbUsCeptUn=Rnc8V=DpctomzViO86NcnYiMA@mail.gmail.com>
Message-ID: <D8F239FB-ECE6-4E63-97F3-910E78D65E24@gmail.com>

Hi,

Sorry for the rather abrupt email. I should have just waited 'til I got home.

I recently fixed the homebrew formula for gnuradio and gr-osmosdr, as well as the gr-osmosdr CMakeLists.txt.

They can be found here:
https://github.com/mjmdavis/homebrew-gnuradio
https://github.com/mjmdavis/gr-osmosdr

I had to implement the same fix as you did in the CMakeLists.txt.
I'm not sure how people have been building it without that step. 
Hopefully the changes can be pulled back into the main repo.

To install using brew on mac is dead easy. Just have a look here: https://github.com/mjmdavis/homebrew-gnuradio

I will be updating the formula to reference the latest gnuradio sometime later today.
There is currently a bug with the --with-qt option that I am looking into but in most cases the Qt stuff is not necessary.

This probably isn't much help for you if you already use macports though, I'm not a fan of having multiple package managers.

Best,
Mike

On 1 May 2013, at 13:21, Alexandru Csete <oz9aec at gmail.com> wrote:

> On Fri, Apr 26, 2013 at 8:40 PM, Alberto Albiol <alalbiol at iteam.upv.es> wrote:
>> Hello
>> I have been fighting to compile the gr-osmosdr package in my osx
>> 
>> These are the minor fixes I had to do:
>> 1- Change in Cmakelists.txt:  find_package(Boost COMPONENTS thread system),
>> If thread and system is not included then there are linking problems.
>> Although I see that this was removed recently...
>> 
>> 2- cmake -DCMAKE_INSTALL_PREFIX=/opt/local (so it is installed together wit
>> my ports intallation, this is really optional)
>> 3- Before compiling I manually edit CmakeCache.txt, and change all the
>> references of /usr/lib/python to /opt/local/lib/python. If not it links
>> agains the system python instead of the ports's python!
>> 4- Add this line in my .bashrc so python can find the package
>>          export PYTHONPATH="/opt/local/lib/python2.7/site-packages/"
>> 
>> I am aware that this is not the most elegant way to solve the problem but is
>> the only one that I was able to come up. Hope it helps
>> 
> 
> Hi Alberto,
> 
> Perhaps the gr-osmosdr package in macports can be of some help for how
> to compile without manually editing the build files:
> https://trac.macports.org/browser/trunk/dports/science/gr-osmosdr/Portfile
> 
> Alex
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130501/da8956b6/attachment.htm>

From alalbiol at iteam.upv.es  Wed May  1 13:05:58 2013
From: alalbiol at iteam.upv.es (Alberto Albiol)
Date: Wed, 1 May 2013 15:05:58 +0200
Subject: Compiling on osx - solved...
In-Reply-To: <CAHG=S_e=N3WPB+HbUsCeptUn=Rnc8V=DpctomzViO86NcnYiMA@mail.gmail.com>
References: <CAKQd66W+zN96v4GH3_gQdw+qSFsyJfUAgwoe=6es3mz_kQF5iw@mail.gmail.com>
	<CAHG=S_e=N3WPB+HbUsCeptUn=Rnc8V=DpctomzViO86NcnYiMA@mail.gmail.com>
Message-ID: <CAKQd66XorEBo76FVU6gcy+GR-35rpjV7wZYwaFZHvQkWrHk2RQ@mail.gmail.com>

Thanks Alex for your reply. Actually in the time being it looks that all
the dependencies in
macports have been fixed and now gr-osmosdr can be complied without any
issue!

One more thing for those installing gnu radio I found that this tricky
option can be useful
since the default compiler is clang:
sudo port install gnuradio-devel +full configure.compiler=gcc

It seems that the use of gcc improves performance on vector operations......

Regards

On Wed, May 1, 2013 at 1:21 PM, Alexandru Csete <oz9aec at gmail.com> wrote:

> On Fri, Apr 26, 2013 at 8:40 PM, Alberto Albiol <alalbiol at iteam.upv.es>
> wrote:
> > Hello
> > I have been fighting to compile the gr-osmosdr package in my osx
> >
> > These are the minor fixes I had to do:
> > 1- Change in Cmakelists.txt:  find_package(Boost COMPONENTS thread
> system),
> > If thread and system is not included then there are linking problems.
> > Although I see that this was removed recently...
> >
> >  2- cmake -DCMAKE_INSTALL_PREFIX=/opt/local (so it is installed together
> wit
> > my ports intallation, this is really optional)
> > 3- Before compiling I manually edit CmakeCache.txt, and change all the
> > references of /usr/lib/python to /opt/local/lib/python. If not it links
> > agains the system python instead of the ports's python!
> > 4- Add this line in my .bashrc so python can find the package
> >           export PYTHONPATH="/opt/local/lib/python2.7/site-packages/"
> >
> > I am aware that this is not the most elegant way to solve the problem
> but is
> > the only one that I was able to come up. Hope it helps
> >
>
> Hi Alberto,
>
> Perhaps the gr-osmosdr package in macports can be of some help for how
> to compile without manually editing the build files:
> https://trac.macports.org/browser/trunk/dports/science/gr-osmosdr/Portfile
>
> Alex
>



-- 
Alberto Albiol
Departamento de Comunicaciones
Universidad Politecnica de Valencia
Tel. +34 96 387 97 38
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130501/493e3d6c/attachment.htm>

From jsalsburg at bellsouth.net  Thu May  2 03:19:05 2013
From: jsalsburg at bellsouth.net (Jay Salsburg)
Date: Wed, 1 May 2013 22:19:05 -0500
Subject: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE
	soft	modem from Icera
In-Reply-To: <CA+=kK2+8Mb00yExjZe=V++TsrT5unV593xreK4uDbr3xtOs-1w@mail.gmail.com>
References: <CA+=kK2JmM3dCLbimRH1WrD5BVjD7=kbN_+w6Bq=DduDYNcD8OA@mail.gmail.com>	<CA+SzT6gHCe-AcWi-eXk-AD5xs1xd78A93OB7MJMwCjWMu5yyhQ@mail.gmail.com>	<CAKo12-nSZVkP_DjUHkq_Bf=tpLUvz4DoxUrdwmUzCqvUprCb2A@mail.gmail.com>	<50EB0609.9090202@ripnet.com>	<CA+FEAncFvHRdDtMdKLJFbgeNzG73fF=TmV5y=vtE96DEt_rReQ@mail.gmail.com>	<lz4nirk218.fsf@gmail.com>	<CAP2dER2y0_mkZ71XyRy1dH+=vqK4bZgazykQ=Hxej+4RcYFRkA@mail.gmail.com>	<lzd2x76d86.fsf@gmail.com>	<CAP2dER33nLsDbbaMadNWLYoohNXxjC4kQeOtpahj+sHM7JgQQw@mail.gmail.com>	<CA+=kK2LuvTBMkZ4=bNXYZNqvtUfMosd_=_5SBciNpZyiaTzZNw@mail.gmail.com>	<CAP2dER2pwPRuW8n4WFjF0gMMnBKTuHfyDGo3SNrmWG=9LCrktA@mail.gmail.com>	<CA+=kK2KE2+FHzG12qvogyDjnaMpQjorzh2VxXJSALxqrruEc_Q@mail.gmail.com>
	<CA+=kK2+8Mb00yExjZe=V++TsrT5unV593xreK4uDbr3xtOs-1w@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAOkzSsXsYUxLvfsEB0fpoPEBAAAAAA==@bellsouth.net>

This chip is a Cell Phone Radio mostly for the 2 to 4 GHz band. The announcement below is a press release for the rollout of the chip to cell phone manufacturers. The technical specifications are probably proprietary and any development boards, if any, will probably be only for licensed developers, translation; ?for those who can afford it.? To HACK this device would require sophisticated Laboratory equipment, again, it is all about money.

 

From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of est
Sent: Wednesday, April 24, 2013 8:51 PM
To: ultra-cheap-sdr at googlegroups.com; osmocom-sdr at lists.osmocom.org
Subject: Re: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft modem from Icera

 

Hello group,

 

What do you guys think of the nVidia Tegra 4's i500 SDR?

 

http://www.engadget.com/2013/01/07/nvidia-i500-soft-modem/

 

http://www.nvidia.com/docs/IO/116757/NVIDIA_i500_whitepaper_FINALv3.pdf

 

Is it hackable?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130501/1e6b6d32/attachment.htm>

From mjmdavis at gmail.com  Thu May  2 07:10:36 2013
From: mjmdavis at gmail.com (Michael Davis)
Date: Thu, 2 May 2013 09:10:36 +0200
Subject: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft
	modem from Icera
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAOkzSsXsYUxLvfsEB0fpoPEBAAAAAA==@bellsouth.net>
References: <CA+=kK2JmM3dCLbimRH1WrD5BVjD7=kbN_+w6Bq=DduDYNcD8OA@mail.gmail.com>	<CA+SzT6gHCe-AcWi-eXk-AD5xs1xd78A93OB7MJMwCjWMu5yyhQ@mail.gmail.com>	<CAKo12-nSZVkP_DjUHkq_Bf=tpLUvz4DoxUrdwmUzCqvUprCb2A@mail.gmail.com>	<50EB0609.9090202@ripnet.com>	<CA+FEAncFvHRdDtMdKLJFbgeNzG73fF=TmV5y=vtE96DEt_rReQ@mail.gmail.com>	<lz4nirk218.fsf@gmail.com>	<CAP2dER2y0_mkZ71XyRy1dH+=vqK4bZgazykQ=Hxej+4RcYFRkA@mail.gmail.com>	<lzd2x76d86.fsf@gmail.com>	<CAP2dER33nLsDbbaMadNWLYoohNXxjC4kQeOtpahj+sHM7JgQQw@mail.gmail.com>	<CA+=kK2LuvTBMkZ4=bNXYZNqvtUfMosd_=_5SBciNpZyiaTzZNw@mail.gmail.com>	<CAP2dER2pwPRuW8n4WFjF0gMMnBKTuHfyDGo3SNrmWG=9LCrktA@mail.gmail.com>	<CA+=kK2KE2+FHzG12qvogyDjnaMpQjorzh2VxXJSALxqrruEc_Q@mail.gmail.com>
	<CA+=kK2+8Mb00yExjZe=V++TsrT5unV593xreK4uDbr3xtOs-1w@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAOkzSsXsYUxLvfsEB0fpoPEBAAAAAA==@bellsouth.net>
Message-ID: <2C48D348-8A93-45E6-A5A4-E3E0AA716010@gmail.com>

Hey,

This is not a Radio per se. It's a modem chip built in the style of a modern Graphics Card (GPU).
It's effectively a DSP chip under another name. It requires the frontend and ADC, from an rtlsdr for example, before it can do anything.

This kind of device takes the fun out of SDR in some respects. The wonderful thing about SDR as we know it is that modern computers are fast enough to do all the processing on the CPU in real time (for many applications). This makes developing software etc far easier since you can use languages and tools that you are familiar with, are easily debuggable and don't require as much specialist knowledge.

That said, it might require less effort to program than one of the FPGA's onboard an Ettus or something like that so for embedded systems it's an attractive proposition. You might one day be able to flash your phone to make it into a TV receiver or something like that.

Interesting stuff.



On 2 May 2013, at 05:19, Jay Salsburg <jsalsburg at bellsouth.net> wrote:

> This chip is a Cell Phone Radio mostly for the 2 to 4 GHz band. The announcement below is a press release for the rollout of the chip to cell phone manufacturers. The technical specifications are probably proprietary and any development boards, if any, will probably be only for licensed developers, translation; ?for those who can afford it.? To HACK this device would require sophisticated Laboratory equipment, again, it is all about money.
>  
> From: osmocom-sdr-bounces at lists.osmocom.org [mailto:osmocom-sdr-bounces at lists.osmocom.org] On Behalf Of est
> Sent: Wednesday, April 24, 2013 8:51 PM
> To: ultra-cheap-sdr at googlegroups.com; osmocom-sdr at lists.osmocom.org
> Subject: Re: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft modem from Icera
>  
> Hello group,
>  
> What do you guys think of the nVidia Tegra 4's i500 SDR?
>  
> http://www.engadget.com/2013/01/07/nvidia-i500-soft-modem/
>  
> http://www.nvidia.com/docs/IO/116757/NVIDIA_i500_whitepaper_FINALv3.pdf
>  
> Is it hackable?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130502/b898a502/attachment.htm>

From electronixtar at gmail.com  Thu May  2 10:14:55 2013
From: electronixtar at gmail.com (est)
Date: Thu, 2 May 2013 18:14:55 +0800
Subject: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE soft
	modem from Icera
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAOkzSsXsYUxLvfsEB0fpoPEBAAAAAA==@bellsouth.net>
References: <CA+=kK2JmM3dCLbimRH1WrD5BVjD7=kbN_+w6Bq=DduDYNcD8OA@mail.gmail.com>
	<CA+SzT6gHCe-AcWi-eXk-AD5xs1xd78A93OB7MJMwCjWMu5yyhQ@mail.gmail.com>
	<CAKo12-nSZVkP_DjUHkq_Bf=tpLUvz4DoxUrdwmUzCqvUprCb2A@mail.gmail.com>
	<50EB0609.9090202@ripnet.com>
	<CA+FEAncFvHRdDtMdKLJFbgeNzG73fF=TmV5y=vtE96DEt_rReQ@mail.gmail.com>
	<lz4nirk218.fsf@gmail.com>
	<CAP2dER2y0_mkZ71XyRy1dH+=vqK4bZgazykQ=Hxej+4RcYFRkA@mail.gmail.com>
	<lzd2x76d86.fsf@gmail.com>
	<CAP2dER33nLsDbbaMadNWLYoohNXxjC4kQeOtpahj+sHM7JgQQw@mail.gmail.com>
	<CA+=kK2LuvTBMkZ4=bNXYZNqvtUfMosd_=_5SBciNpZyiaTzZNw@mail.gmail.com>
	<CAP2dER2pwPRuW8n4WFjF0gMMnBKTuHfyDGo3SNrmWG=9LCrktA@mail.gmail.com>
	<CA+=kK2KE2+FHzG12qvogyDjnaMpQjorzh2VxXJSALxqrruEc_Q@mail.gmail.com>
	<CA+=kK2+8Mb00yExjZe=V++TsrT5unV593xreK4uDbr3xtOs-1w@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAALO4+13dC3JEngpmoHTALLLCgAAAEAAAAOkzSsXsYUxLvfsEB0fpoPEBAAAAAA==@bellsouth.net>
Message-ID: <CA+=kK2L7YcqsJ231dmL38-h-+FY+UzOv=k8XaSNytect5aDFug@mail.gmail.com>

> This chip is a Cell Phone Radio mostly for the 2 to 4 GHz band.

hmm, what if i500 could also receive FM radio, I presume FM radio is way
under 2GHz band?

The i500 chip is advertised can be "upgraded" to receive future LTE
signals, so I guess it's some kind of SDR.


On Thu, May 2, 2013 at 11:19 AM, Jay Salsburg <jsalsburg at bellsouth.net>wrote:

> This chip is a Cell Phone Radio mostly for the 2 to 4 GHz band. The
> announcement below is a press release for the rollout of the chip to cell
> phone manufacturers. The technical specifications are probably proprietary
> and any development boards, if any, will probably be only for licensed
> developers, translation; ?for those who can afford it.? To HACK this device
> would require sophisticated Laboratory equipment, again, it is all about
> money.****
>
> ** **
>
> *From:* osmocom-sdr-bounces at lists.osmocom.org [mailto:
> osmocom-sdr-bounces at lists.osmocom.org] *On Behalf Of *est
> *Sent:* Wednesday, April 24, 2013 8:51 PM
> *To:* ultra-cheap-sdr at googlegroups.com; osmocom-sdr at lists.osmocom.org
> *Subject:* Re: [Discuss-gnuradio] nVidia's Tegra 4 has SDR - the i500 LTE
> soft modem from Icera****
>
> ** **
>
> Hello group,****
>
> ** **
>
> What do you guys think of the nVidia Tegra 4's i500 SDR?****
>
> ** **
>
> http://www.engadget.com/2013/01/07/nvidia-i500-soft-modem/****
>
> ** **
>
> http://www.nvidia.com/docs/IO/116757/NVIDIA_i500_whitepaper_FINALv3.pdf***
> *
>
> ** **
>
> Is it hackable?****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130502/a82bafa1/attachment.htm>

From simon at purpleplanet.org  Thu May  2 23:57:30 2013
From: simon at purpleplanet.org (Simon PurplePlaNET)
Date: Thu, 2 May 2013 23:57:30 +0000 (GMT)
Subject: Raspberry Pi based remote SDR head
Message-ID: <17882632.81367539050870.JavaMail.root@zimbra>

Hi folks,

I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO.

I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to.

I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO.

Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish.

http://www.purpleplanet.org/?q=rtl-robot

Cheers,

Simon




From raretalent at btinternet.com  Thu May  2 22:37:41 2013
From: raretalent at btinternet.com (raretalent BT)
Date: Thu, 2 May 2013 23:37:41 +0100
Subject: R820T register map available
In-Reply-To: <513E39FA.2010700@shikadi.net>
Message-ID: <46B0EFA96E3248D9A21AE05BE4519000@MikePC>

Hello Adam,
                    Apologies  for this cold calling message out of the blue but  I have been searching the internet for sometime seeking information on the Rafael Micro R820T tuner. 

Unlike the other members listed on the SDR user groups I would like to use the tuner chip independently from the Realtek  RTL2832U chip.  Possibly, with an HF receiver tuned to 4.57MHz or connected to a 16bit ADC and capture board. As a result, I have been searching for information on the control registers within the device to control the device independently.

During my search I came across your listing shown below and would like to request if possible, a copy of the register list.  I would like to point out that this is for private use and I have no intention of making any of this data available on the web.

I would be grateful if you could consider my request.

Kind regards

Mike

Hi all,

One of the designers of the R820T tuner has recently been posting on the 
ultra-cheap-sdr group, and has kindly supplied a map of the R820T registers 
for private use only within the SDR community.  He has asked that it not be 
posted on any website, but only be forwarded around privately.

To that end, if anyone would like a copy of this spreadsheet and would be 
willing to likewise not publish it on the web, let me know off-list and I'll 
send it to you.

There's not a huge amount in the way of explanations, but it lists all the 
registers and a very brief description of what they do.

Cheers,
Adam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130502/6f471316/attachment.htm>

From Ronny.Kunze at gmx.net  Mon May  6 08:10:56 2013
From: Ronny.Kunze at gmx.net (Ronny Kunze)
Date: Mon, 6 May 2013 10:10:56 +0200 (CEST)
Subject: OsmoSDR Upgrade Board news ?
Message-ID: <trinity-3cfac238-73d2-40fd-b3ef-2cd12cbcd873-1367827856711@3capp-gmx-bs56>

An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130506/78c91915/attachment.htm>

From noselasd at fiane.dyndns.org  Thu May  9 11:30:56 2013
From: noselasd at fiane.dyndns.org (noselasd at fiane.dyndns.org)
Date: Thu, 09 May 2013 13:30:56 +0200
Subject: OpenBSD: crashing
In-Reply-To: <1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
	<1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
Message-ID: <518B88F0.2060400@fiane.dyndns.org>

On 04/20/2013 05:59 AM, Alan Corey wrote:
>  > I've just got hold of a card and looking into this.
>
> Do you mean a dongle?  I got one of the $20 ones, which works pretty
> well in Windows with SDR# and RTL1090, so I bought a second one.
>
>  >
>  > By specification, pthread_mutex_unlock() has undefined behaviour when
>  > unlocking a mutex which is already unlocked.

Note also that rtl_fm uses mutexes as semaphores/condition variables,
it locks mutexes in one thread and unlocks them in another thread -
which is undefined behavior (Except if the mutex is recursive or error
checking, in which case pthread_mutex_unlock must detect this situation 
and return an error).

You're only supposed to unlock a mutex by the same thread that locked
it, and it's possible OpenBSD bails out if you do otherwise.





From smile_k at libero.it  Thu May  9 16:37:26 2013
From: smile_k at libero.it (Favati)
Date: Thu, 09 May 2013 18:37:26 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <17882632.81367539050870.JavaMail.root@zimbra>
References: <17882632.81367539050870.JavaMail.root@zimbra>
Message-ID: <kmgjc2$3ph$1@ger.gmane.org>

Il 03/05/2013 01:57, Simon PurplePlaNET ha scritto:
> Hi folks,
>
> I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO.
>
> I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to.
>
> I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO.
>
> Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish.
>
> http://www.purpleplanet.org/?q=rtl-robot
>
> Cheers,
>
> Simon
>
>
>

Great job!
I wrote an external program to control gpio, i'll try to implement your 
solution!
Many thanks!





From smile_k at libero.it  Thu May  9 17:18:06 2013
From: smile_k at libero.it (Favati)
Date: Thu, 09 May 2013 19:18:06 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <17882632.81367539050870.JavaMail.root@zimbra>
References: <17882632.81367539050870.JavaMail.root@zimbra>
Message-ID: <kmglo9$soo$1@ger.gmane.org>

Hi!
It's me again...
I've taken a look at the source code...
It does a "grep" on the output of "set freq"...the problem is that my 
latest git pull from rtl-sdr does not output any "set freq" to 
stdout....any idea?





From smile_k at libero.it  Thu May  9 17:25:25 2013
From: smile_k at libero.it (Favati)
Date: Thu, 09 May 2013 19:25:25 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <kmglo9$soo$1@ger.gmane.org>
References: <17882632.81367539050870.JavaMail.root@zimbra>
	<kmglo9$soo$1@ger.gmane.org>
Message-ID: <kmgm60$2gk$1@ger.gmane.org>

Il 09/05/2013 19:18, Favati ha scritto:
> Hi!
> It's me again...
> I've taken a look at the source code...
> It does a "grep" on the output of "set freq"...the problem is that my
> latest git pull from rtl-sdr does not output any "set freq" to
> stdout....any idea?
>
>
>
>
my fault...just "git pull" again and recompiled....it output the correct 
string...gonna try your software :)




From smile_k at libero.it  Thu May  9 17:30:51 2013
From: smile_k at libero.it (Favati)
Date: Thu, 09 May 2013 19:30:51 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <17882632.81367539050870.JavaMail.root@zimbra>
References: <17882632.81367539050870.JavaMail.root@zimbra>
Message-ID: <kmgmg6$4fm$1@ger.gmane.org>

Il 03/05/2013 01:57, Simon PurplePlaNET ha scritto:
> Hi folks,
>
> I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO.
>
> I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to.
>
> I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO.
>
> Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish.
>
> http://www.purpleplanet.org/?q=rtl-robot
>
> Cheers,
>
> Simon
>
>
>

Just tryed this command:

stdbuf --output=0 rtl_tcp -a 192.168.2.15 -p 1234 > rtl.data

I don't have anything connected to the gpio pins...but i cannot see any 
output from your script while changing freqs...(yes, i've gone below 
100mhz and above 500mhz).
It's quite strange....the rtl.data is created in the same folder of your 
script...
Taking a look at rtl.data, it contains the correct output of the 
standard output of rtl_tcp.

Any idea?





From alancorey at yahoo.com  Fri May 10 02:39:55 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Thu, 9 May 2013 19:39:55 -0700 (PDT)
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <17882632.81367539050870.JavaMail.root@zimbra>
Message-ID: <1368153595.87160.YahooMailClassic@web161503.mail.bf1.yahoo.com>

To no one in particular: The usefulness of doing this escapes me. Sure you'd want to put the receiver up high, but in an attic?? There are all kinds of temperature extremes up there, from very hot most of the year to below freezing in colder climates in the winter.

Something like a 1-transistor preamp feeding some RG-6 seems like a more practical solution.? You can buy 500 feet of RG-6 for about $32 at Home Depot and good low-noise transistors are available under $1.? You just need enough gain to offset the cable loss and RG-6 is pretty good.

? Alan
-----

Radio Astronomy - the ultimate DX

--- On Thu, 5/2/13, Simon PurplePlaNET <simon at purpleplanet.org> wrote:

From: Simon PurplePlaNET <simon at purpleplanet.org>
Subject: Raspberry Pi based remote SDR head
To: osmocom-sdr at lists.osmocom.org
Date: Thursday, May 2, 2013, 7:57 PM

Hi folks,

I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO.

I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to.

I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO.

Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish.

http://www.purpleplanet.org/?q=rtl-robot

Cheers,

Simon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130509/25ce5dc3/attachment.htm>

From zaitcev at kotori.zaitcev.us  Fri May 10 03:07:55 2013
From: zaitcev at kotori.zaitcev.us (Pete Zaitcev)
Date: Thu, 9 May 2013 21:07:55 -0600
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <1368153595.87160.YahooMailClassic@web161503.mail.bf1.yahoo.com>
References: <17882632.81367539050870.JavaMail.root@zimbra>
	<1368153595.87160.YahooMailClassic@web161503.mail.bf1.yahoo.com>
Message-ID: <20130509210755.0dd75e8f@lembas.zaitcev.lan>

On Thu, 9 May 2013 19:39:55 -0700 (PDT)
Alan Corey <alancorey at yahoo.com> wrote:

> Something like a 1-transistor preamp feeding some RG-6 seems like a more practical solution.

Two things:
 #1 designing this preamp may be beyond the practical for most hobbyists
 #2 does nothing to create a selectable direction of the gain that Simon wanted

-- Pete




From stu at spacehopper.org  Fri May 10 07:24:56 2013
From: stu at spacehopper.org (Stuart Henderson)
Date: Fri, 10 May 2013 08:24:56 +0100
Subject: OpenBSD: crashing
In-Reply-To: <518B88F0.2060400@fiane.dyndns.org>
References: <1366172088.84920.YahooMailNeo@web161502.mail.bf1.yahoo.com>
	<slrnkn2ek2.9sa.stu@naiad.spacehopper.org>
	<1366430374.52532.YahooMailNeo@web161504.mail.bf1.yahoo.com>
	<518B88F0.2060400@fiane.dyndns.org>
Message-ID: <20130510072456.GN28210@symphytum.spacehopper.org>

On 2013/05/09 13:30, noselasd at fiane.dyndns.org wrote:
> On 04/20/2013 05:59 AM, Alan Corey wrote:
> > > I've just got hold of a card and looking into this.
> >
> >Do you mean a dongle?  I got one of the $20 ones, which works pretty
> >well in Windows with SDR# and RTL1090, so I bought a second one.
> >
> > >
> > > By specification, pthread_mutex_unlock() has undefined behaviour when
> > > unlocking a mutex which is already unlocked.
> 
> Note also that rtl_fm uses mutexes as semaphores/condition variables,
> it locks mutexes in one thread and unlocks them in another thread -
> which is undefined behavior (Except if the mutex is recursive or error
> checking, in which case pthread_mutex_unlock must
> detect this situation and return an error).
> 
> You're only supposed to unlock a mutex by the same thread that locked
> it, and it's possible OpenBSD bails out if you do otherwise.

Is there a reason for doing it this way rather than using sem_post
and sem_wait?



From myles at madpilot.com.au  Fri May 10 10:00:19 2013
From: myles at madpilot.com.au (Myles Eftos)
Date: Fri, 10 May 2013 18:00:19 +0800
Subject: Confirmation that the QuadDVBT works
Message-ID: <0F481046-4912-48D3-9FBA-AC24810BD405@madpilot.com.au>

Hello,

I just wanted to let you guys know that the Digital Now Quad DVB-T Receiver (http://digitalnow.com.au/product_pages/Quad.html) works. It's a PCI-e card with 4 tuners on it, linked up internally via USB. This has pleased me no-end - I might finally be able to get DAB+ working on my media centre!

I had to add the following line to librtlsdr.c

{ 0x0413, 0x6680, "QuadDVBT" }

Do I need to let anyone else know?

Thanks!

----------------------------------------------
Myles Eftos
Mobile: +61-409-293-183

MadPilot Productions - Created to be Different
URL: http://www.madpilot.com.au
Phone: +618-9227-5616
Fax: +618-9467-6289

Try our time tracking system: 88 Miles!
http://www.88miles.net




From martin at windycitysdr.com  Fri May 10 13:27:10 2013
From: martin at windycitysdr.com (Martin O'Shield)
Date: Fri, 10 May 2013 08:27:10 -0500
Subject: Confirmation that the QuadDVBT works
In-Reply-To: <0F481046-4912-48D3-9FBA-AC24810BD405@madpilot.com.au>
References: <0F481046-4912-48D3-9FBA-AC24810BD405@madpilot.com.au>
Message-ID: <CAMeuOX9vThfLBcDyF=TdRA+povJ8sKWw6zKR_faXCz5a7PnXAA@mail.gmail.com>

Myles,



Thank you for the update.



On Fri, May 10, 2013 at 5:00 AM, Myles Eftos <myles at madpilot.com.au> wrote:

> Hello,
>
> I just wanted to let you guys know that the Digital Now Quad DVB-T
> Receiver (http://digitalnow.com.au/product_pages/Quad.html) works. It's a
> PCI-e card with 4 tuners on it, linked up internally via USB. This has
> pleased me no-end - I might finally be able to get DAB+ working on my media
> centre!
>
> I had to add the following line to librtlsdr.c
>
> { 0x0413, 0x6680, "QuadDVBT" }
>
> Do I need to let anyone else know?
>
> Thanks!
>
> ----------------------------------------------
> Myles Eftos
> Mobile: +61-409-293-183
>
> MadPilot Productions - Created to be Different
> URL: http://www.madpilot.com.au
> Phone: +618-9227-5616
> Fax: +618-9467-6289
>
> Try our time tracking system: 88 Miles!
> http://www.88miles.net
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130510/8c7c684b/attachment.htm>

From smile_k at libero.it  Fri May 10 13:43:29 2013
From: smile_k at libero.it (Favati)
Date: Fri, 10 May 2013 15:43:29 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <1368153595.87160.YahooMailClassic@web161503.mail.bf1.yahoo.com>
References: <17882632.81367539050870.JavaMail.root@zimbra>
	<1368153595.87160.YahooMailClassic@web161503.mail.bf1.yahoo.com>
Message-ID: <kmithr$ke9$1@ger.gmane.org>

Il 10/05/2013 04:39, Alan Corey ha scritto:
> To no one in particular: The usefulness of doing this escapes me. Sure
> you'd want to put the receiver up high, but in an attic?  There are all
> kinds of temperature extremes up there, from very hot most of the year
> to below freezing in colder climates in the winter.
>
> Something like a 1-transistor preamp feeding some RG-6 seems like a more
> practical solution.  You can buy 500 feet of RG-6 for about $32 at Home
> Depot and good low-noise transistors are available under $1.  You just
> need enough gain to offset the cable loss and RG-6 is pretty good.
>
>    Alan

IMHO, for those like me that has a lot of radio interferences in the 
house, remoting the raspberry is very very very good!
My raspi is in the attic since september 2012...NEVER powered 
off...temperature of raspy never reached more than 50?.
Of course...this is only my situation!






From simon at purpleplanet.org  Fri May 10 22:39:13 2013
From: simon at purpleplanet.org (Simon PurplePlaNET)
Date: Fri, 10 May 2013 22:39:13 +0000 (GMT)
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <15461044.391368225427340.JavaMail.root@zimbra>
Message-ID: <7310206.411368225553800.JavaMail.root@zimbra>



Hi there, 



That's odd - do you have WiringPi installed? 



https://projects.drogon.net/raspberry-pi/wiringpi/download-and-install/ 



The script makes use of this excellent program to control the GPIO and also to report on the pin status.?Originally I was using the native method of controlling the GPIO using export and echoing a value to the files on the pi. I stumbled onto WiringPi, which makes controlling the pins far simpler and does not require root privs to set them up. 



Simon 


----- Original Message ----- 
From: "Favati" <smile_k at libero.it> 
To: osmocom-sdr at lists.osmocom.org 
Sent: Thursday, 9 May, 2013 18:30:51 GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: Raspberry Pi based remote SDR head 

Il 03/05/2013 01:57, Simon PurplePlaNET ha scritto: 
> Hi folks, 
> 
> I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO. 
> 
> I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to. 
> 
> I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO. 
> 
> Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish. 
> 
> http://www.purpleplanet.org/?q=rtl-robot 
> 
> Cheers, 
> 
> Simon 
> 
> 
> 

Just tryed this command: 

stdbuf --output=0 rtl_tcp -a 192.168.2.15 -p 1234 > rtl.data 

I don't have anything connected to the gpio pins...but i cannot see any 
output from your script while changing freqs...(yes, i've gone below 
100mhz and above 500mhz). 
It's quite strange....the rtl.data is created in the same folder of your 
script... 
Taking a look at rtl.data, it contains the correct output of the 
standard output of rtl_tcp. 

Any idea? 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130510/fbd2f409/attachment.htm>

From simon at purpleplanet.org  Fri May 10 23:06:16 2013
From: simon at purpleplanet.org (Simon PurplePlaNET)
Date: Fri, 10 May 2013 23:06:16 +0000 (GMT)
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <16408900.501368226590494.JavaMail.root@zimbra>
Message-ID: <7082269.521368227176355.JavaMail.root@zimbra>

Hi Alan, 

Where I live, the temperature extremes inside my attic are not so bad. ? 

If you look at devices such as the Kinetic SBS 3, you will see that Ethernet ports are becoming quite normal on SDR gear these days. This not only allows you to minimise the cable run to the antenna (important at 1090MHz) but also to use the device from anywhere with an adequate network connection to it. 

http://www.kinetic-avionics.com/ 

A 500 foot drum of RG-6 may only cost $32 at Home Depot, but you would need over 30,000 such drums to reach the closest Home Depot from my home. Quite an outlay when we already have the wealth of a global telecommunications industry at our fingertips and begging to be used!

My main reason for doing this however, is really to make a better radio than the RTL dongle provides on it's own. I am interested in front end filtering and an LNA and want to use the rPi to control this. You could still run 500' of lossy co-ax to the antenna if you wanted to... :-)

I could buy a Funcube Pro+ Dongle for ?150 instead, but where is the fun in that? 

Simon


----- Original Message ----- 
From: "Alan Corey" <alancorey at yahoo.com> 
To: osmocom-sdr at lists.osmocom.org 
Sent: Friday, 10 May, 2013 03:39:55 GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: Raspberry Pi based remote SDR head 

To no one in particular: The usefulness of doing this escapes me. Sure you'd want to put the receiver up high, but in an attic?? There are all kinds of temperature extremes up there, from very hot most of the year to below freezing in colder climates in the winter. 

Something like a 1-transistor preamp feeding some RG-6 seems like a more practical solution.? You can buy 500 feet of RG-6 for about $32 at Home Depot and good low-noise transistors are available under $1.? You just need enough gain to offset the cable loss and RG-6 is pretty good. 

? Alan 
----- 
Radio Astronomy - the ultimate DX 

--- On Thu, 5/2/13, Simon PurplePlaNET <simon at purpleplanet.org> wrote: 



From: Simon PurplePlaNET <simon at purpleplanet.org> 
Subject: Raspberry Pi based remote SDR head 
To: osmocom-sdr at lists.osmocom.org 
Date: Thursday, May 2, 2013, 7:57 PM 


Hi folks, 

I've been messing around with rtl_tcp and an RTL2832 device on a Raspberry Pi and want to add a bank of front end filters and a LNA that can be controlled by the GPIO. 

I want to allow manual control of the signal path via a web page hosted on the Pi, but also want to be able to have the filters selected automatically based on the frequency that the RTL device is tuned to. 

I noticed that rtl_tcp helpfully echos the frequency changes to the console, so I wrote a simple shell script to gather this data and control the GPIO. 

Somebody may have already done this and there is probably a better way to achieve it but, if this would be of any use to you, please feel free to copy and use as you wish. 

http://www.purpleplanet.org/?q=rtl-robot 

Cheers, 

Simon 





From smile_k at libero.it  Sat May 11 06:17:36 2013
From: smile_k at libero.it (Favati)
Date: Sat, 11 May 2013 08:17:36 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <7310206.411368225553800.JavaMail.root@zimbra>
References: <15461044.391368225427340.JavaMail.root@zimbra>
	<7310206.411368225553800.JavaMail.root@zimbra>
Message-ID: <kmknpr$r3r$1@ger.gmane.org>

Il 11/05/2013 00:39, Simon PurplePlaNET ha scritto:
> Hi there,
>
> That's odd - do you have WiringPi installed?
>
> https://projects.drogon.net/raspberry-pi/wiringpi/download-and-install/
>
> The script makes use of this excellent program to control the GPIO and
> also to report on the pin status. Originally I was using the native
> method of controlling the GPIO using export and echoing a value to the
> files on the pi. I stumbled onto WiringPi, which makes controlling the
> pins far simpler and does not require root privs to set them up.
>
> Simon
>

yes,i've installed wiringpi :\
Any other idea?






From simon at purpleplanet.org  Sat May 11 17:10:53 2013
From: simon at purpleplanet.org (Simon PurplePlaNET)
Date: Sat, 11 May 2013 17:10:53 +0000 (GMT)
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <kmknpr$r3r$1@ger.gmane.org>
Message-ID: <23095402.551368292253542.JavaMail.root@zimbra>

Could you describe exactly the steps you have taken?

----- Original Message ----- 
From: "Favati" <smile_k at libero.it> 
To: osmocom-sdr at lists.osmocom.org 
Sent: Saturday, 11 May, 2013 07:17:36 GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: Raspberry Pi based remote SDR head 

Il 11/05/2013 00:39, Simon PurplePlaNET ha scritto: 
> Hi there, 
> 
> That's odd - do you have WiringPi installed? 
> 
> https://projects.drogon.net/raspberry-pi/wiringpi/download-and-install/ 
> 
> The script makes use of this excellent program to control the GPIO and 
> also to report on the pin status. Originally I was using the native 
> method of controlling the GPIO using export and echoing a value to the 
> files on the pi. I stumbled onto WiringPi, which makes controlling the 
> pins far simpler and does not require root privs to set them up. 
> 
> Simon 
> 

yes,i've installed wiringpi :\ 
Any other idea? 







From smile_k at libero.it  Sat May 11 19:14:36 2013
From: smile_k at libero.it (Favati)
Date: Sat, 11 May 2013 21:14:36 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <23095402.551368292253542.JavaMail.root@zimbra>
References: <kmknpr$r3r$1@ger.gmane.org>
	<23095402.551368292253542.JavaMail.root@zimbra>
Message-ID: <kmm5an$nah$1@ger.gmane.org>


> Could you describe exactly the steps you have taken?

1) installed wiringpi (and tested as described on the developer site)
2) created your script
3) launched this command:

stdbuf --output=0 rtl_tcp -a 192.168.2.15 -p 1234 > rtl.data

4) used sdrsharp to connect to my raspberry (192.168.2.15, and it 
connect ok, i can use sdrsharp ok)

5) nothing is displayed on the console of my raspy except the first 2 
lines of rtl_tcp output

The rtl_data is created ok and looking inside that file i can see the 
normal output of "rtl_tcp" (set freq blablablabla, etc...)

At the moment i've taken another approach...i've patched the rtl_tcp.c 
to set the gpio directly...i'll post my "project" asap somewhere...




From simon at purpleplanet.org  Sat May 11 20:31:27 2013
From: simon at purpleplanet.org (Simon PurplePlaNET)
Date: Sat, 11 May 2013 20:31:27 +0000 (GMT)
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <5015644.611368304218900.JavaMail.root@zimbra>
Message-ID: <20169426.631368304287061.JavaMail.root@zimbra>

Ah, OK - I've got you.

You also need to run the script once you have launched rtl_tcp using the command in step 3) below. 

The simplest way to do this would be to add a step:

6) Sign in to rPi with a new terminal session, leaving the old one open for now. cd to the directory where you created the script and then run it using this command: 

./rtl-robot (or whatever you called the script)


You could run the script from the same terminal that you launched rtl_tcp from if you used & to force rtl_tcp to detach from the console and run in the background. 

I'll edit the comments on the script to make that a bit clearer...

Thanks!

Simon

----- Original Message ----- 
From: "Favati" <smile_k at libero.it> 
To: osmocom-sdr at lists.osmocom.org 
Sent: Saturday, 11 May, 2013 20:14:36 GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: Raspberry Pi based remote SDR head 


> Could you describe exactly the steps you have taken? 

1) installed wiringpi (and tested as described on the developer site) 
2) created your script 
3) launched this command: 

stdbuf --output=0 rtl_tcp -a 192.168.2.15 -p 1234 > rtl.data 

4) used sdrsharp to connect to my raspberry (192.168.2.15, and it 
connect ok, i can use sdrsharp ok) 

5) nothing is displayed on the console of my raspy except the first 2 
lines of rtl_tcp output 

The rtl_data is created ok and looking inside that file i can see the 
normal output of "rtl_tcp" (set freq blablablabla, etc...) 

At the moment i've taken another approach...i've patched the rtl_tcp.c 
to set the gpio directly...i'll post my "project" asap somewhere... 





From smile_k at libero.it  Sun May 12 07:01:04 2013
From: smile_k at libero.it (Favati)
Date: Sun, 12 May 2013 09:01:04 +0200
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <20169426.631368304287061.JavaMail.root@zimbra>
References: <5015644.611368304218900.JavaMail.root@zimbra>
	<20169426.631368304287061.JavaMail.root@zimbra>
Message-ID: <kmnena$tak$1@ger.gmane.org>

my fault...i called your script stdbuf :P   (never used that command in 
my life! and didn't know it was a linux command!!!) aha ahahahahah!!!!)

Anyway....I'll try again asap!





From smile_k at libero.it  Sun May 12 15:12:16 2013
From: smile_k at libero.it (Favati)
Date: Sun, 12 May 2013 17:12:16 +0200
Subject: rtl_tcp problem or not?
Message-ID: <kmobga$m3u$1@ger.gmane.org>

Hi there!
I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another 
machine (quad core.... 3gb ram...good machine!)

The problem occour at 00:57

http://www.youtube.com/watch?v=4E2MPfEzEi8

and at 1:34 in this video:

http://www.youtube.com/watch?v=8snz1wQSRpw


If i stop and start sdrsharp, it works ok for some minutes...then the 
problem is up again!


No errors appear on the console of raspberry/rtl_tcp

I'm not able to understand if it's a problem of rtl_tcp,raspberry or 
whatelse...


Things i've tryed:

1) Changed the samplerate
2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!)
3) Changed the dongle
4) Updated sdrsharp

The dongles tryed work ok on a pc

I've no more idea....

Anyone can help me?

PS: If someone know a program that works in linux and is similar to 
sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...




From ranickel at comcast.net  Sun May 12 15:28:42 2013
From: ranickel at comcast.net (Robert Nickels)
Date: Sun, 12 May 2013 10:28:42 -0500
Subject: rtl_tcp problem or not?
In-Reply-To: <kmobga$m3u$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org>
Message-ID: <518FB52A.3090905@comcast.net>

On 5/12/2013 10:12 AM, Favati wrote:
>
> No errors appear on the console of raspberry/rtl_tcp
>
> I'm not able to understand if it's a problem of rtl_tcp,raspberry or 
> whatelse...
>
Hi Favati,

I knew what your videos would should before even watching them, because 
I have the exact same problem here when using SDR# to connect via 
rtl_tcp to a Raspberry Pi.

Recent improvements to rtl_tcp have helped a lot with re-starting but 
this a new problem, as I'm accustomed to running the tcp connection for 
hours without such failures.   I'm fairly certain the problem is on the 
sending (i.e. R-Pi) end, but haven't got data to prove this theory.   
However, since you can see in the video that SDR# continues to run, 
producing both audio and spectrum and waterfall displays, I think this 
shows that it is processing the IQ data which it is receiving (which is 
no longer correct).

Hopefully a fix will be forthcoming, as this is a pretty big problem for 
remote users.   I'll certainly be happy to provide any data or help with 
evaluation.

73, Bob W9RAN



From smile_k at libero.it  Sun May 12 15:41:35 2013
From: smile_k at libero.it (Favati)
Date: Sun, 12 May 2013 17:41:35 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <518FB52A.3090905@comcast.net>
References: <kmobga$m3u$1@ger.gmane.org> <518FB52A.3090905@comcast.net>
Message-ID: <kmod79$6qt$1@ger.gmane.org>

> Hi Favati,
>
> I knew what your videos would should before even watching them, because
> I have the exact same problem here when using SDR# to connect via
> rtl_tcp to a Raspberry Pi.
>
> Recent improvements to rtl_tcp have helped a lot with re-starting but
> this a new problem, as I'm accustomed to running the tcp connection for
> hours without such failures.   I'm fairly certain the problem is on the
> sending (i.e. R-Pi) end, but haven't got data to prove this theory.
> However, since you can see in the video that SDR# continues to run,
> producing both audio and spectrum and waterfall displays, I think this
> shows that it is processing the IQ data which it is receiving (which is
> no longer correct).
>
> Hopefully a fix will be forthcoming, as this is a pretty big problem for
> remote users.   I'll certainly be happy to provide any data or help with
> evaluation.
>
> 73, Bob W9RAN

So...there are 2 possible problem (my english is not good at all!)

-the raspberry (maybe something relating to the tcp/ip)

or

-rtl_tcp bug

Or i've not understood you?

I'm investigating a lot...

I don't think it's a raspberry problem... when the problem occour (only 
in that moment!!), i can stress the raspberry with file transfer...the 
files are transfered ok.

I think it's a problem of rtl_tcp...

What kind of tests do you suggest now?

I've never seen that problem elsewhere (can you point me to other having 
this issue???????).






From peter at stuge.se  Sun May 12 15:51:48 2013
From: peter at stuge.se (Peter Stuge)
Date: Sun, 12 May 2013 17:51:48 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <518FB52A.3090905@comcast.net>
References: <kmobga$m3u$1@ger.gmane.org> <518FB52A.3090905@comcast.net>
Message-ID: <20130512155148.3001.qmail@stuge.se>

Robert Nickels wrote:
> Hopefully a fix will be forthcoming, as this is a pretty big problem
> for remote users.

The way open source works is typically that those who experience big
problems solve them and share their solutions.


//Peter



From smile_k at libero.it  Sun May 12 18:03:36 2013
From: smile_k at libero.it (Favati)
Date: Sun, 12 May 2013 20:03:36 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <kmobga$m3u$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org>
Message-ID: <kmolhj$m9t$1@ger.gmane.org>

I can do a lot of testing...just tell me what can i do to help.
Sorry but i'm not a programmer :?(




From shaun at shaunhey.com  Sun May 12 18:39:51 2013
From: shaun at shaunhey.com (Shaun Hey)
Date: Sun, 12 May 2013 14:39:51 -0400
Subject: rtl_tcp problem or not?
In-Reply-To: <kmobga$m3u$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org>
Message-ID: <BCFB28EB-BC79-4E6E-9F9A-3BF978B67AF5@shaunhey.com>

Hi Favati,

Are you by chance using a wifi dongle on the Raspberry Pi?  I also have this problem, but it seemed to be a lot worse when I was trying to use wifi instead of ethernet.  Just a thought...

Shaun

On May 12, 2013, at 11:12 AM, Favati <smile_k at libero.it> wrote:

> Hi there!
> I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another machine (quad core.... 3gb ram...good machine!)
> 
> The problem occour at 00:57
> 
> http://www.youtube.com/watch?v=4E2MPfEzEi8
> 
> and at 1:34 in this video:
> 
> http://www.youtube.com/watch?v=8snz1wQSRpw
> 
> 
> If i stop and start sdrsharp, it works ok for some minutes...then the problem is up again!
> 
> 
> No errors appear on the console of raspberry/rtl_tcp
> 
> I'm not able to understand if it's a problem of rtl_tcp,raspberry or whatelse...
> 
> 
> Things i've tryed:
> 
> 1) Changed the samplerate
> 2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!)
> 3) Changed the dongle
> 4) Updated sdrsharp
> 
> The dongles tryed work ok on a pc
> 
> I've no more idea....
> 
> Anyone can help me?
> 
> PS: If someone know a program that works in linux and is similar to sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...
> 
> 



From smile_k at libero.it  Sun May 12 19:37:32 2013
From: smile_k at libero.it (Favati)
Date: Sun, 12 May 2013 21:37:32 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <BCFB28EB-BC79-4E6E-9F9A-3BF978B67AF5@shaunhey.com>
References: <kmobga$m3u$1@ger.gmane.org>
	<BCFB28EB-BC79-4E6E-9F9A-3BF978B67AF5@shaunhey.com>
Message-ID: <kmor1m$8re$1@ger.gmane.org>

Il 12/05/2013 20:39, Shaun Hey ha scritto:
> Hi Favati,
>
> Are you by chance using a wifi dongle on the Raspberry Pi?  I also have this problem, but it seemed to be a lot worse when I was trying to use wifi instead of ethernet.  Just a thought...
>
> Shaun
>

I'm using ethernet :)







From smile_k at libero.it  Mon May 13 17:07:35 2013
From: smile_k at libero.it (Favati)
Date: Mon, 13 May 2013 19:07:35 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <kmobga$m3u$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org>
Message-ID: <kmr6kh$4t9$1@ger.gmane.org>

It SEEMS that lowering the buffer to 16 (option -b 16) solved the 
problem...(it's up since 30mins atm).

I'll let you know...





From smile_k at libero.it  Mon May 13 19:02:37 2013
From: smile_k at libero.it (Favati)
Date: Mon, 13 May 2013 21:02:37 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <kmr6kh$4t9$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org> <kmr6kh$4t9$1@ger.gmane.org>
Message-ID: <kmrdc8$gnh$1@ger.gmane.org>

Il 13/05/2013 19:07, Favati ha scritto:
> It SEEMS that lowering the buffer to 16 (option -b 16) solved the
> problem...(it's up since 30mins atm).
>
> I'll let you know...
>
>
>
>
2,5h up and running...(while scanning a lot...)





From simon at purpleplanet.org  Mon May 13 20:33:15 2013
From: simon at purpleplanet.org (Simon PurplePlaNET)
Date: Mon, 13 May 2013 20:33:15 +0000 (GMT)
Subject: Raspberry Pi based remote SDR head
In-Reply-To: <kmnena$tak$1@ger.gmane.org>
Message-ID: <33182253.661368477195393.JavaMail.root@zimbra>

:-)

Without using stdbuf when launching rtl_tcp, the redirected console messages are buffered and do not appear in the text file rtl.data right away.

Using this option means that each message is logged in the text file as soon as it is generated by rtl_tcp.


----- Original Message ----- 
From: "Favati" <smile_k at libero.it> 
To: osmocom-sdr at lists.osmocom.org 
Sent: Sunday, 12 May, 2013 08:01:04 GMT +00:00 GMT Britain, Ireland, Portugal 
Subject: Re: Raspberry Pi based remote SDR head 

my fault...i called your script stdbuf :P ? (never used that command in 
my life! and didn't know it was a linux command!!!) aha ahahahahah!!!!) 

Anyway....I'll try again asap! 






From ldz10565 at gmail.com  Mon May 13 21:31:51 2013
From: ldz10565 at gmail.com (LD Zhang)
Date: Mon, 13 May 2013 14:31:51 -0700
Subject: FW: A question on osmoSDR new version
Message-ID: <00eb01ce5021$49b71080$dd253180$@gmail.com>

From: LD Zhang [mailto:ldz10565 at gmail.com] 
Sent: Monday, May 13, 2013 2:23 PM
To: 'osmocom-sdr at lists.osmocom.org'
Subject: A question on osmoSDR new version

 

Hello,

 

I am very interested in the new osmoSDR that has 4MS/s rate and a 14bit ADC.
Is this new version available for purchase?

 

Thanks,

 

LD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130513/9fa8345c/attachment.htm>

From smile_k at libero.it  Wed May 15 18:44:15 2013
From: smile_k at libero.it (Favati)
Date: Wed, 15 May 2013 20:44:15 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <kmr6kh$4t9$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org> <kmr6kh$4t9$1@ger.gmane.org>
Message-ID: <kn0l1p$1ur$1@ger.gmane.org>

Il 13/05/2013 19:07, Favati ha scritto:
> It SEEMS that lowering the buffer to 16 (option -b 16) solved the
> problem...(it's up since 30mins atm).
>
> I'll let you know...
>
>
>
>
no way...re-happened today...

I've no more ideas :(




From davidb-sdr at rcpt.to  Thu May 16 02:07:08 2013
From: davidb-sdr at rcpt.to (David Basden)
Date: Thu, 16 May 2013 12:07:08 +1000
Subject: rtl_tcp problem or not?
In-Reply-To: <kn0l1p$1ur$1@ger.gmane.org>
References: <kmobga$m3u$1@ger.gmane.org> <kmr6kh$4t9$1@ger.gmane.org>
	<kn0l1p$1ur$1@ger.gmane.org>
Message-ID: <20130516020708.GF27372@faith.oztechninja.com>

On Wed, May 15, 2013 at 08:44:15PM +0200, Favati wrote:
> Il 13/05/2013 19:07, Favati ha scritto:
> >It SEEMS that lowering the buffer to 16 (option -b 16) solved the
> >problem...(it's up since 30mins atm).
> >
> >I'll let you know...
> >
> >
> >
> >
> no way...re-happened today...
> 
> I've no more ideas :(
> 

Run 'vmstat 1' in a different terminal on the RPi while running
stuff, and paste the first dozen lines? (You can just CTRL-C
vmstat after this)

I ran rtl-tcp a while ago on the RPi and it was really pushing
the limits of the IO bandwidth and CPU, but there has been a
lot of optimisation in the RPi stack kernels etc since. Using a
USB network interface would just push the RPi's limited USB IO
even harder.

Reducing the samplerate for rtl-tcp might help a bit if you
aren't looking at a wideband signal.

David



From smile_k at libero.it  Fri May 17 15:59:42 2013
From: smile_k at libero.it (Favati)
Date: Fri, 17 May 2013 17:59:42 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <20130516020708.GF27372@faith.oztechninja.com>
References: <kmobga$m3u$1@ger.gmane.org> <kmr6kh$4t9$1@ger.gmane.org>
	<kn0l1p$1ur$1@ger.gmane.org>
	<20130516020708.GF27372@faith.oztechninja.com>
Message-ID: <kn5k59$tfn$1@ger.gmane.org>

> Run 'vmstat 1' in a different terminal on the RPi while running
> stuff, and paste the first dozen lines? (You can just CTRL-C
> vmstat after this)
>
> I ran rtl-tcp a while ago on the RPi and it was really pushing
> the limits of the IO bandwidth and CPU, but there has been a
> lot of optimisation in the RPi stack kernels etc since. Using a
> USB network interface would just push the RPi's limited USB IO
> even harder.
>
> Reducing the samplerate for rtl-tcp might help a bit if you
> aren't looking at a wideband signal.
>
> David
>
>

I've run vmstat 1, but nothing special change when the problem occour.
The cpu NEVER goes more than 50%.
Lowering the samplerate didn't change anything (except a very little cpu 
load lowered).

Still investigating...if someone have some ideas to let me try.... :)





From smile_k at libero.it  Fri May 17 16:02:11 2013
From: smile_k at libero.it (Favati)
Date: Fri, 17 May 2013 18:02:11 +0200
Subject: rtl_tcp problem or not?
In-Reply-To: <20130516020708.GF27372@faith.oztechninja.com>
References: <kmobga$m3u$1@ger.gmane.org> <kmr6kh$4t9$1@ger.gmane.org>
	<kn0l1p$1ur$1@ger.gmane.org>
	<20130516020708.GF27372@faith.oztechninja.com>
Message-ID: <kn5k9t$tfn$2@ger.gmane.org>

> Run 'vmstat 1' in a different terminal on the RPi while running
> stuff, and paste the first dozen lines? (You can just CTRL-C
> vmstat after this)

procs -----------memory---------- ---swap-- -----io---- -system-- 
----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy 
id wa

  0  0      0 124928  16680  61392    0    0     0     0 4120  552  3 40 
57  0
  0  0      0 124896  16680  61392    0    0     0     0 4315  542  4 41 
55  0
  1  0      0 124864  16680  61392    0    0     0     0 4220  549  3 40 
57  0
  0  0      0 124748  16680  61392    0    0     0     0 4079  544  3 39 
58  0

The problem occoured at the second line





From david.jacobowitz at gmail.com  Fri May 17 18:56:44 2013
From: david.jacobowitz at gmail.com (David Jacobowitz)
Date: Fri, 17 May 2013 11:56:44 -0700
Subject: rtl-sdr offset tuning and other questions
Message-ID: <51967D6C.1080304@gmail.com>


Hi guys,

I'm new to this list (and to radio) so I hope you will please indulge me 
if I ask something that is a FAQ. Also, some of these questions are 
about the dongle, not the library.


I am working on a personal project to use SDR techniques to decode 
aviation navigation signals (VOR). I've got the signal processing mostly 
working from recorded signals, but am now trying to integrate my SW with 
the radio in real time.


I have a few questions:

  - What exactly is offset tuning? How is offset tuning different from 
tuning to an offset?

Is this a feature that mostly benefits people who are not going to put 
their IF through another mixer? In my application I am already tuning to 
an offset, and pulling down a wide enough IF that actually holds many 
channels of interest.  (VOR channels have 50kHz spacing). I then use a 
software mixer/channelizer to choose the channel I want. Am I correct in 
assuming that offset tuning is of no use to me?


- regarding AGC, what is the difference between AGC and auto gain?

That is, the library API has

RTLSDR_API int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int manual)

RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_dev_t *dev, int on);

I'm guessing that these affect different AGCs. One for the tuner and one 
for the RTL device.

What are the benefits and costs of having either or both on?



- regarding rtlsdr_read_async(...) and related functions.

I take it that the library is setting up a ring buffer and calling me 
back when it has a new buffer of data for me.

How long to I have to work with this buffer? Obviously, if I want to 
work in real-time I need to keep up with the sample rate. But my 
application can afford to throw away buffers since it can decode a few 
ms of data from one station and then revisit it much later. However, I'd 
like to know how long I have until the buffer gets clobbered. I'm 
presuming it's stable until all the n-1 other buffers have been hit.


- generally how fast can the RTL devices tune? I know, this is not an 
rtlsdr question per se, but I'm curious. I noticed that when I tune, I 
get a delay.



This is a great library and I'm so glad it's out there! I was not 
looking forward to plumbing the depths of USB drivers to understand how 
to pull data from the RTL dongle! I think rtl-sdr.h could use perhaps a 
smidge more documentation.  I'd be happy to submit a comments-only patch 
if there's interest. :-)

Regards,
Dave Jacobowitz






From mike.ihde at randomwalking.com  Sun May 19 12:25:40 2013
From: mike.ihde at randomwalking.com (Michael Ihde)
Date: Sun, 19 May 2013 13:25:40 +0100
Subject: RTL-SDR component for REDHAWK SDR
Message-ID: <CAMAToK9vjb-F1SxbN-1GysKHv05C=DqEQdNku=vMmWDJqc0Cqw@mail.gmail.com>

I've recently developed a RTL-SDR component for REDHAWK that uses the
RTL-TCP server.

https://github.com/Axios-Engineering/acquisition-components

I'm guessing that this mailing list is the correct address to use for this
component to be listed on the "Known Apps" page for the RTL driver.

~Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/c3b3f4f4/attachment.htm>

From horiz0n at gmx.net  Sun May 19 13:28:19 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 19 May 2013 15:28:19 +0200
Subject: RTL-SDR component for REDHAWK SDR
In-Reply-To: <CAMAToK9vjb-F1SxbN-1GysKHv05C=DqEQdNku=vMmWDJqc0Cqw@mail.gmail.com>
References: <CAMAToK9vjb-F1SxbN-1GysKHv05C=DqEQdNku=vMmWDJqc0Cqw@mail.gmail.com>
Message-ID: <op.wxb2dhkyvay7ep@wopr.artelis.net>

Hi Michael,

thanks a lot, added it to the list.

Best regards,
Dimitri

On Sun, 19 May 2013 14:25:40 +0200, Michael Ihde  
<mike.ihde at randomwalking.com> wrote:

> I've recently developed a RTL-SDR component for REDHAWK that uses the
> RTL-TCP server.
>
> https://github.com/Axios-Engineering/acquisition-components
>
> I'm guessing that this mailing list is the correct address to use for  
> this
> component to be listed on the "Known Apps" page for the RTL driver.
>
> ~Michael



From horiz0n at gmx.net  Sun May 19 13:28:20 2013
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Sun, 19 May 2013 15:28:20 +0200
Subject: rtl-sdr offset tuning and other questions
In-Reply-To: <51967D6C.1080304@gmail.com>
References: <51967D6C.1080304@gmail.com>
Message-ID: <op.wxb2dilwvay7ep@wopr.artelis.net>

Hi David,

> I am working on a personal project to use SDR techniques to decode  
> aviation navigation signals (VOR). I've got the signal processing mostly  
> working from recorded signals, but am now trying to integrate my SW with  
> the radio in real time.

>   - What exactly is offset tuning? How is offset tuning different from  
> tuning to an offset?

For E4000 tuners only this will shift thei 0-IF point outside of RTL  
sampling bandwidth which may help if you have a wideband (DECT or such)  
signal you want to sample but don't want it to be distorted by the usual  
LO-leakage peak in the middle. The drawback is that you might get hit by a  
image signal.

> Is this a feature that mostly benefits people who are not going to put  
> their IF through another mixer? In my application I am already tuning to  
> an offset, and pulling down a wide enough IF that actually holds many  
> channels of interest.  (VOR channels have 50kHz spacing). I then use a  
> software mixer/channelizer to choose the channel I want. Am I correct in  
> assuming that offset tuning is of no use to me?

For narrowband signals you are good to do offset tuning yourself.

> - regarding AGC, what is the difference between AGC and auto gain?

AGC is for RTL chip, auto gain is for the tuner (if implemented).

> RTLSDR_API int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int manual)

Works for E4000 tuners only AFAIR.

Steve: do other tuners provide AGC functions as well?

> RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_dev_t *dev, int on);
>
> I'm guessing that these affect different AGCs. One for the tuner and one  
> for the RTL device.

Yes.

> What are the benefits and costs of having either or both on?

It depends on the application. While in presence of strong interference  
the tuner auto gain seems to perform well on E4000 devices, the RTL gain  
 from my understanding only scales the signal to optimally use the dynamic  
range of 8 bits. Within controlled environment (narrowband  
antenna/LNA/filters) i usually let them off entirely and set the gains for  
best SNR manually.

Historically we have implemented them with some time in between so now  
both gains have their own setters.

>
> - regarding rtlsdr_read_async(...) and related functions.
>
> I take it that the library is setting up a ring buffer and calling me  
> back when it has a new buffer of data for me.

Yes.

> How long to I have to work with this buffer? Obviously, if I want to  
> work in real-time I need to keep up with the sample rate. But my  
> application can afford to throw away buffers since it can decode a few  
> ms of data from one station and then revisit it much later. However, I'd  
> like to know how long I have until the buffer gets clobbered. I'm  
> presuming it's stable until all the n-1 other buffers have been hit.

You should spend as little time as possible inside a callback, this is a  
libusb requirement. You might copy some buffers to be passed to a worker  
thread later on and keep skipping buffers inside the callback until your  
worker thread is ready for the next shot.

> - generally how fast can the RTL devices tune? I know, this is not an  
> rtlsdr question per se, but I'm curious. I noticed that when I tune, I  
> get a delay.

Can't tell, never evaluated that myself. But again, this largely depends  
on the tuner interactions involved.

> smidge more documentation.  I'd be happy to submit a comments-only patch  
> if there's interest. :-)

This would be appreciated.


Best regards,
Dimitri



From smile_k at libero.it  Sun May 19 15:49:08 2013
From: smile_k at libero.it (Favati)
Date: Sun, 19 May 2013 17:49:08 +0200
Subject: rtl_fm....external interface...any way?
Message-ID: <knas9f$13k$1@ger.gmane.org>

Hi there!
I would like to know if is it possible to change the freq. of rtl_fm "on 
the fly" without cloning the process and restart it with a a different 
freq. parameter.

Any idea?




From peter at stuge.se  Sun May 19 19:27:27 2013
From: peter at stuge.se (Peter Stuge)
Date: Sun, 19 May 2013 21:27:27 +0200
Subject: rtl_fm....external interface...any way?
In-Reply-To: <knas9f$13k$1@ger.gmane.org>
References: <knas9f$13k$1@ger.gmane.org>
Message-ID: <20130519192727.7294.qmail@stuge.se>

Favati wrote:
> I would like to know if is it possible to change the freq. of rtl_fm
> "on the fly"

It isn't. Someone would have to implement some portable IPC to allow it.

TCP or stdin is probably the lowest common denominator.


//Peter



From david.jacobowitz at gmail.com  Mon May 20 04:18:41 2013
From: david.jacobowitz at gmail.com (David Jacobowitz)
Date: Sun, 19 May 2013 21:18:41 -0700
Subject: rtl-sdr offset tuning and other questions
In-Reply-To: <op.wxb2dilwvay7ep@wopr.artelis.net>
References: <51967D6C.1080304@gmail.com> <op.wxb2dilwvay7ep@wopr.artelis.net>
Message-ID: <CACuAV7T1pi=VjiAAsO6A+5NwwizWRq0O6o=HzU+kVjY+ayR5jA@mail.gmail.com>

Thanks, Dimitri. This helps a lot.

I tried to make some suggested additional comments to the header file,
which I have attached. You can take them or leave them. I think perhaps for
a sophisticated c programmer the API is obvious, but for me I needed a bit
more help.

I have also written a small program that uses the async API to serve as a
minimalist working example on how to use the library which folks might find
helpful. Based on your answers below, I just copy the buffer in the
callback into my own ring of buffers, then work on the buffers in a
separate thread.

The program just writes captured data directly to disk. It works on my
computer, but I haven't tested it extensively.


Both files are attached.

Regards,
Dave J



On Sun, May 19, 2013 at 6:28 AM, Dimitri Stolnikov <horiz0n at gmx.net> wrote:

> Hi David,
>
>
>  I am working on a personal project to use SDR techniques to decode
>> aviation navigation signals (VOR). I've got the signal processing mostly
>> working from recorded signals, but am now trying to integrate my SW with
>> the radio in real time.
>>
>
>    - What exactly is offset tuning? How is offset tuning different from
>> tuning to an offset?
>>
>
> For E4000 tuners only this will shift thei 0-IF point outside of RTL
> sampling bandwidth which may help if you have a wideband (DECT or such)
> signal you want to sample but don't want it to be distorted by the usual
> LO-leakage peak in the middle. The drawback is that you might get hit by a
> image signal.
>
>
>  Is this a feature that mostly benefits people who are not going to put
>> their IF through another mixer? In my application I am already tuning to an
>> offset, and pulling down a wide enough IF that actually holds many channels
>> of interest.  (VOR channels have 50kHz spacing). I then use a software
>> mixer/channelizer to choose the channel I want. Am I correct in assuming
>> that offset tuning is of no use to me?
>>
>
> For narrowband signals you are good to do offset tuning yourself.
>
>
>  - regarding AGC, what is the difference between AGC and auto gain?
>>
>
> AGC is for RTL chip, auto gain is for the tuner (if implemented).
>
>
>  RTLSDR_API int rtlsdr_set_tuner_gain_mode(**rtlsdr_dev_t *dev, int
>> manual)
>>
>
> Works for E4000 tuners only AFAIR.
>
> Steve: do other tuners provide AGC functions as well?
>
>
>  RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_**dev_t *dev, int on);
>>
>> I'm guessing that these affect different AGCs. One for the tuner and one
>> for the RTL device.
>>
>
> Yes.
>
>
>  What are the benefits and costs of having either or both on?
>>
>
> It depends on the application. While in presence of strong interference
> the tuner auto gain seems to perform well on E4000 devices, the RTL gain
> from my understanding only scales the signal to optimally use the dynamic
> range of 8 bits. Within controlled environment (narrowband
> antenna/LNA/filters) i usually let them off entirely and set the gains for
> best SNR manually.
>
> Historically we have implemented them with some time in between so now
> both gains have their own setters.
>
>
>
>> - regarding rtlsdr_read_async(...) and related functions.
>>
>> I take it that the library is setting up a ring buffer and calling me
>> back when it has a new buffer of data for me.
>>
>
> Yes.
>
>
>  How long to I have to work with this buffer? Obviously, if I want to work
>> in real-time I need to keep up with the sample rate. But my application can
>> afford to throw away buffers since it can decode a few ms of data from one
>> station and then revisit it much later. However, I'd like to know how long
>> I have until the buffer gets clobbered. I'm presuming it's stable until all
>> the n-1 other buffers have been hit.
>>
>
> You should spend as little time as possible inside a callback, this is a
> libusb requirement. You might copy some buffers to be passed to a worker
> thread later on and keep skipping buffers inside the callback until your
> worker thread is ready for the next shot.
>
>
>  - generally how fast can the RTL devices tune? I know, this is not an
>> rtlsdr question per se, but I'm curious. I noticed that when I tune, I get
>> a delay.
>>
>
> Can't tell, never evaluated that myself. But again, this largely depends
> on the tuner interactions involved.
>
>
>  smidge more documentation.  I'd be happy to submit a comments-only patch
>> if there's interest. :-)
>>
>
> This would be appreciated.
>
>
> Best regards,
> Dimitri
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/57ee5cba/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl-sdr-annotated.h
Type: text/x-chdr
Size: 15349 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/57ee5cba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trivial.c
Type: text/x-csrc
Size: 7613 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/57ee5cba/attachment-0001.bin>

From carbone144 at orange.fr  Fri May 17 20:02:53 2013
From: carbone144 at orange.fr (laurent)
Date: Fri, 17 May 2013 22:02:53 +0200
Subject: osmosdr block
Message-ID: <1368820973.3506.11.camel@lucie-desktop>

Hi all,

I need some help to resolve my problem with GNURADIO.
I Built and installed rtl-sdr and it works well with the dongle
terratec.
Built and install also the osmosdr package, but when I open grc the
block sources rtl does'nt appear.

Any ideas?

GNUradio for debian package v.3.5.3.2-1 installed.

Best regards 
Laurent





From alancorey at yahoo.com  Wed May 22 02:24:11 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Tue, 21 May 2013 19:24:11 -0700 (PDT)
Subject: osmosdr block
In-Reply-To: <1368820973.3506.11.camel@lucie-desktop>
Message-ID: <1369189451.23958.YahooMailClassic@web161505.mail.bf1.yahoo.com>

rtl-sdr, etc. and gr-osmosdr are 2 different packages from Osmocom.

Either OsmoSDR or RTLSDR is probably what you want.? They're about the same and contained in gr-osmosdr.

? Alan

-----

Radio Astronomy - the ultimate DX

--- On Fri, 5/17/13, laurent <carbone144 at orange.fr> wrote:

From: laurent <carbone144 at orange.fr>
Subject: osmosdr block
To: osmocom-sdr at lists.osmocom.org
Date: Friday, May 17, 2013, 4:02 PM

Hi all,

I need some help to resolve my problem with GNURADIO.
I Built and installed rtl-sdr and it works well with the dongle
terratec.
Built and install also the osmosdr package, but when I open grc the
block sources rtl does'nt appear.

Any ideas?

GNUradio for debian package v.3.5.3.2-1 installed.

Best regards 
Laurent



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130521/973f23a7/attachment.htm>

From david.jacobowitz at gmail.com  Wed May 22 16:53:52 2013
From: david.jacobowitz at gmail.com (David Jacobowitz)
Date: Wed, 22 May 2013 09:53:52 -0700
Subject: rtl-sdr offset tuning and other questions
In-Reply-To: <CACuAV7T1pi=VjiAAsO6A+5NwwizWRq0O6o=HzU+kVjY+ayR5jA@mail.gmail.com>
References: <51967D6C.1080304@gmail.com> <op.wxb2dilwvay7ep@wopr.artelis.net>
	<CACuAV7T1pi=VjiAAsO6A+5NwwizWRq0O6o=HzU+kVjY+ayR5jA@mail.gmail.com>
Message-ID: <CACuAV7TRZ4RtUapbvAdFRmRPsXpaTG2hjjOppMVX_bCdzkvExg@mail.gmail.com>

Some slight cleanup of the trivial example and fix for correctly letting
threads return / join.




On Sun, May 19, 2013 at 9:18 PM, David Jacobowitz <
david.jacobowitz at gmail.com> wrote:

> Thanks, Dimitri. This helps a lot.
>
> I tried to make some suggested additional comments to the header file,
> which I have attached. You can take them or leave them. I think perhaps for
> a sophisticated c programmer the API is obvious, but for me I needed a bit
> more help.
>
> I have also written a small program that uses the async API to serve as a
> minimalist working example on how to use the library which folks might find
> helpful. Based on your answers below, I just copy the buffer in the
> callback into my own ring of buffers, then work on the buffers in a
> separate thread.
>
> The program just writes captured data directly to disk. It works on my
> computer, but I haven't tested it extensively.
>
>
> Both files are attached.
>
> Regards,
> Dave J
>
>
>
> On Sun, May 19, 2013 at 6:28 AM, Dimitri Stolnikov <horiz0n at gmx.net>wrote:
>
>> Hi David,
>>
>>
>>  I am working on a personal project to use SDR techniques to decode
>>> aviation navigation signals (VOR). I've got the signal processing mostly
>>> working from recorded signals, but am now trying to integrate my SW with
>>> the radio in real time.
>>>
>>
>>    - What exactly is offset tuning? How is offset tuning different from
>>> tuning to an offset?
>>>
>>
>> For E4000 tuners only this will shift thei 0-IF point outside of RTL
>> sampling bandwidth which may help if you have a wideband (DECT or such)
>> signal you want to sample but don't want it to be distorted by the usual
>> LO-leakage peak in the middle. The drawback is that you might get hit by a
>> image signal.
>>
>>
>>  Is this a feature that mostly benefits people who are not going to put
>>> their IF through another mixer? In my application I am already tuning to an
>>> offset, and pulling down a wide enough IF that actually holds many channels
>>> of interest.  (VOR channels have 50kHz spacing). I then use a software
>>> mixer/channelizer to choose the channel I want. Am I correct in assuming
>>> that offset tuning is of no use to me?
>>>
>>
>> For narrowband signals you are good to do offset tuning yourself.
>>
>>
>>  - regarding AGC, what is the difference between AGC and auto gain?
>>>
>>
>> AGC is for RTL chip, auto gain is for the tuner (if implemented).
>>
>>
>>  RTLSDR_API int rtlsdr_set_tuner_gain_mode(**rtlsdr_dev_t *dev, int
>>> manual)
>>>
>>
>> Works for E4000 tuners only AFAIR.
>>
>> Steve: do other tuners provide AGC functions as well?
>>
>>
>>  RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_**dev_t *dev, int on);
>>>
>>> I'm guessing that these affect different AGCs. One for the tuner and one
>>> for the RTL device.
>>>
>>
>> Yes.
>>
>>
>>  What are the benefits and costs of having either or both on?
>>>
>>
>> It depends on the application. While in presence of strong interference
>> the tuner auto gain seems to perform well on E4000 devices, the RTL gain
>> from my understanding only scales the signal to optimally use the dynamic
>> range of 8 bits. Within controlled environment (narrowband
>> antenna/LNA/filters) i usually let them off entirely and set the gains for
>> best SNR manually.
>>
>> Historically we have implemented them with some time in between so now
>> both gains have their own setters.
>>
>>
>>
>>> - regarding rtlsdr_read_async(...) and related functions.
>>>
>>> I take it that the library is setting up a ring buffer and calling me
>>> back when it has a new buffer of data for me.
>>>
>>
>> Yes.
>>
>>
>>  How long to I have to work with this buffer? Obviously, if I want to
>>> work in real-time I need to keep up with the sample rate. But my
>>> application can afford to throw away buffers since it can decode a few ms
>>> of data from one station and then revisit it much later. However, I'd like
>>> to know how long I have until the buffer gets clobbered. I'm presuming it's
>>> stable until all the n-1 other buffers have been hit.
>>>
>>
>> You should spend as little time as possible inside a callback, this is a
>> libusb requirement. You might copy some buffers to be passed to a worker
>> thread later on and keep skipping buffers inside the callback until your
>> worker thread is ready for the next shot.
>>
>>
>>  - generally how fast can the RTL devices tune? I know, this is not an
>>> rtlsdr question per se, but I'm curious. I noticed that when I tune, I get
>>> a delay.
>>>
>>
>> Can't tell, never evaluated that myself. But again, this largely depends
>> on the tuner interactions involved.
>>
>>
>>  smidge more documentation.  I'd be happy to submit a comments-only patch
>>> if there's interest. :-)
>>>
>>
>> This would be appreciated.
>>
>>
>> Best regards,
>> Dimitri
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130522/923e458e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trivial.c
Type: text/x-csrc
Size: 8315 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130522/923e458e/attachment.bin>

From jonathanpieman at gmail.com  Thu May 23 21:27:40 2013
From: jonathanpieman at gmail.com (Jonathan Rawlinson)
Date: Thu, 23 May 2013 22:27:40 +0100
Subject: RTL SDR LNAs
Message-ID: <CABogfyL0_tGYYCFtgyh4LGn2ih=7eUNs8mDgA0Q3w5Rbk=e2rw@mail.gmail.com>

Hello All

This is the first time I have posted on this list, sorry if I have done it
wrong

I would like to use a line powered "cheap and nasty" LNA with an RTL dongle.

E.g.
http://www.amazon.co.uk/Satellite-Signal-Amplifier-Booster-electrosmart%C2%AE/dp/B003S5LBVQ/ref=pd_sim_sbs_ce_1

This may seem a like stupid question (I will ask it anyway) but will the
dongle need protecting from the 18V going down the antenna line. I have
seen some diagrams with protection and some without.

If protection is required, has anyone got any suggestions on how I should
do it???

Many thanks

Jonathan, M0ZJO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130523/e2ee81a2/attachment.htm>

From alancorey at yahoo.com  Fri May 24 02:49:16 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Thu, 23 May 2013 19:49:16 -0700 (PDT)
Subject: Weird rtl_fm bug
Message-ID: <1369363756.54541.YahooMailClassic@web161501.mail.bf1.yahoo.com>

This only affects scanning, or specifically searching a range of frequencies.? I could hear it in the example from usage -f 118M:137M:25k.? For some reason the step changes as the loop executes so the frequencies look like:

118950000
118975000
119000000? ok to here
119257000
119282000
119307000
119332000
119357000
119382000
119407000
119432000
119457000
119482000
119507000
119532000
119789000
119814000
119839000
119864000

The frequencies should be at 25 KHz intervals.

I don't have a diff because I have several other changes in my version, but my frequency_range() now looks like:

void frequency_range(struct fm_state *fm, char *arg)
{
??????? char *start, *stop, *step;
??????? int i;
??????? int frst, frstp, frdelta;
??????? start = arg;
??????? stop = strchr(start, ':') + 1;
??????? stop[-1] = '\0';
??????? step = strchr(stop, ':') + 1;
??????? step[-1] = '\0';
??????? frst = (int)atofs(start);
??????? frstp = (int)atofs(stop);
??????? frdelta = (int)atofs(step);
??????? fprintf(stderr,"start: %i, stop: %i, step: %i\n",frst,frstp,frdelta);
// step was changing here somehow:
//????? for(i=(int)atofs(start); i<=(int)atofs(stop); i+=(int)atofs(step))
??????? for (i=frst; i<=frstp; i+=frdelta)
??????? {
??????????????? fm->freqs[fm->freq_len] = (uint32_t)i;
??????????????? fm->freq_len++;
??????? }
??????? stop[-1] = ':';
??????? step[-1] = ':';
}

I added the fr* variables and used them in the loop.? It sounds better now that none of the frequencies are off.? I'm also logging and those frequencies look OK.

? Alan


-----

Radio Astronomy - the ultimate DX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130523/78b847dc/attachment.htm>

From alancorey at yahoo.com  Fri May 24 03:18:32 2013
From: alancorey at yahoo.com (Alan Corey)
Date: Thu, 23 May 2013 20:18:32 -0700 (PDT)
Subject: rtl_fm scanning mods
Message-ID: <1369365512.74999.YahooMailClassic@web161506.mail.bf1.yahoo.com>

This diff below is actually 2 changes.? When scanning it will print the frequency to stderr every time something breaks squelch.? When searching/scanning a range it logs active frequencies into a file in /tmp.

Two notes: there's an extra \n at the start of each frequency announcement, that's to get around sox's output.? If you use something like aucat that doesn't write to the console you don't need that.

The file path should be ifdefed and an appropriate Windows path added.

This diff was taken before my fix to the scanning step, which may change the context slightly.

Alan

*** rtl_fm_original.c	Wed May 22 13:18:00 2013
--- rtl_fm.c	Wed May 22 13:32:53 2013
***************
*** 76,82 ****
--- 76,86 ----
  static int *atan_lut = NULL;
  static int atan_lut_size = 131072; /* 512 KB */
  static int atan_lut_coef = 8;
+ static int f_ann = 0;  /* freq announced  */
+ static int searching = 0;
+ static FILE *flog; /* frequency log */
  
+ 
  struct fm_state
  {
  	int      now_r, now_j;
***************
*** 587,592 ****
--- 591,603 ----
  		return;
  	}
  	sr = post_squelch(fm);
+ 	if ((sr > 0) && (f_ann == 0) && (fm->freq_len > 1)) {
+ 	  fprintf(stderr, "\n%f\n",(double)fm->freqs[fm->freq_now]/1000000.0);
+ 	  f_ann = 1;  /* reset next hop */
+ 	  if (searching > 0) {
+ 	    fprintf(flog,"%f\n",(double)fm->freqs[fm->freq_now]/1000000.0);
+ 	    fflush(flog);
+           }
  	if (!sr && fm->squelch_hits > fm->conseq_squelch) {
  		if (fm->terminate_on_squelch) {
  			fm->exit_flag = 1;}
***************
*** 609,614 ****
--- 620,626 ----
  	/* ignore under runs for now */
  	fwrite(fm->signal2, 2, fm->signal2_len, fm->file);
  	if (hop) {
+           f_ann = 0;
  		freq_next = (fm->freq_now + 1) % fm->freq_len;
  		optimal_settings(fm, freq_next, 1);
  		fm->squelch_hits = fm->conseq_squelch + 1;  /* hair trigger */
***************
*** 676,681 ****
--- 688,696 ----
  	stop[-1] = '\0';
  	step = strchr(stop, ':') + 1;
  	step[-1] = '\0';
+ 	flog = fopen("/tmp/freqlog.txt","a");
+ 	if (flog != NULL)
+ 	  searching = 1;
  	for(i=(int)atofs(start); i<=(int)atofs(stop); i+=(int)atofs(step))
  	{
  		fm->freqs[fm->freq_len] = (uint32_t)i;


-----

Radio Astronomy - the ultimate DX
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130523/772ba069/attachment.htm>

From aaron at askforjoy.com  Sat May 25 01:49:26 2013
From: aaron at askforjoy.com (Aaron Rossetto)
Date: Fri, 24 May 2013 20:49:26 -0500
Subject: Regarding offset tuning in rtl_fm.c - the math
Message-ID: <CADzKoUn5H2e62smNP4i+n6TV9-4iAPGZ8AXxd7z_69hgdfvj+A@mail.gmail.com>

Hi all,

I recently got a Raspberry Pi and an RTL2832 USB card and have been
successful in compiling rtl-sdr and running the associated examples, piping
the data up into LabVIEW for analysis with their Demodulation Toolkit. I'm
a little weak on the signal processing math knowledge here, so I was
wondering if someone could explain the math behind the offset tuning code
in rtl_fm's optimal_settings() function.

It looks like the function takes the desired center tuning frequency and
calculates an integer decimation ratio based on a "capture rate" near 1 MHz
and the desired final sampling rate. Then the center frequency is offset by
a quarter of the capture rate, and this and the capture rate are used to
program the radio. Then in the receive callback, the I/Q data is shifted 90
degrees in rotate_90(). At this point, the I/Q data represents (I presume!)
the spectrum around the original desired center frequency and at the
original sample rate.

How do I get, mathematically speaking, from the oversampled I/Q data
centered at the offset frequency to *my* desired center frequency and
sample rate? I'm especially curious as to the effect of the frequency
offset using that particular value (capture rate/4) and what role the
rotation plays in the transformation.

Thanks,
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130524/5cd50c55/attachment.htm>

From andreas+osmocom at gate450.dyndns.org  Wed May 29 15:53:00 2013
From: andreas+osmocom at gate450.dyndns.org (Andreas Seltenreich)
Date: Wed, 29 May 2013 17:53:00 +0200
Subject: [rtl-sdr] store frequency correction in eeprom?
In-Reply-To: <CAFXU+zHQ2tiHB0TDFqZP-p4r-P0ZbjJtdxadN2cUCrwvioCJNQ@mail.gmail.com>
	(Benedikt Heinz's message of "Sat, 16 Mar 2013 21:27:39 +0100")
References: <CAFXU+zHQ2tiHB0TDFqZP-p4r-P0ZbjJtdxadN2cUCrwvioCJNQ@mail.gmail.com>
Message-ID: <87vc61dbqb.fsf@gate450.dyndns.org>

Hi,

I just found this discussion on the topic after sending some patches to
the list (pending moderation)...

Benedikt Heinz writes:

> Another option might be storing the value in a non-used eeprom
> location and adding get/set functions to librtlsdr.

I modified my copy of librtlsdr to use the last four bytes of the eeprom
as the default XTAL frequency instead of the compiled-in 28800000Hz, if
it is within ?1kHz.  That way applications don't have to deal with the
calibration aspect at all.  Also, rtl_eeprom got an -x parameter to
store a value there.

    git://gate450.dyndns.org/git/rtl-sdr

> Is it possible to write arbitrary values to unused eeprom locations
> without fucking up the realtek eeprom handling?

Well, my two sticks do still enumerate nicely with the change.  I wonder
if eeproms other than 2kbit ones are in use though, as that would make
"last four bytes" slightly ambiguous...

> (Of course the ppm value still changes with temperature, but having a
> base value is still closer to the truth than 0ppm I'd say.
> I measured the offset directly after grabbing samples for 20 minutes
> at room-temperature and jitter is <1ppm.)

After warmup, plotting the output of kalibrate-rtl[1] with my specimens
indicates an accuracy of about 0.1ppm as long as the room temperature
doesn't deviate more than 1K.

Alan Corey writes:

> While you're at it it would be nice to use maybe at least a 16 bit
> value if possible.? I had mine all worked out to about 5 or 6 places
> then found I could only? store what might be an 8 bit integer.? SDR
> Sharp would only store mine as 102 instead of about 102.4567.? Since
> the correction is done in software there shouldn't be a limit on the
> size (data type) of the number.

Hmm, my solution would yield a resolution of about 0.035ppm.  A better
resolution is probably not meaningful when calibrating a plain XO.

regards,
andreas

Footnotes: 
[1]  https://github.com/steve-m/kalibrate-rtl



From steve at steve-m.de  Thu May 30 15:08:08 2013
From: steve at steve-m.de (Steve Markgraf)
Date: Thu, 30 May 2013 17:08:08 +0200
Subject: [rtl-sdr] store frequency correction in eeprom?
In-Reply-To: <87vc61dbqb.fsf@gate450.dyndns.org>
References: <CAFXU+zHQ2tiHB0TDFqZP-p4r-P0ZbjJtdxadN2cUCrwvioCJNQ@mail.gmail.com>
	<87vc61dbqb.fsf@gate450.dyndns.org>
Message-ID: <51A76B58.8060008@steve-m.de>

Hi,

On 29.05.2013 17:53, Andreas Seltenreich wrote:
> I just found this discussion on the topic after sending some patches to
> the list (pending moderation)...

I didn't see them yet, I guess Harald has to manually approve them
because you weren't subscribed yet when you sent them?

> Well, my two sticks do still enumerate nicely with the change.  I wonder
> if eeproms other than 2kbit ones are in use though, as that would make
> "last four bytes" slightly ambiguous...

All sticks I've seen so far use a 24C02 with 256 Bytes, so that should
be fine.

>> (Of course the ppm value still changes with temperature, but having a
>> base value is still closer to the truth than 0ppm I'd say.
>> I measured the offset directly after grabbing samples for 20 minutes
>> at room-temperature and jitter is <1ppm.)
> 
> After warmup, plotting the output of kalibrate-rtl[1] with my specimens
> indicates an accuracy of about 0.1ppm as long as the room temperature
> doesn't deviate more than 1K.
> 
> Alan Corey writes:
> 
>> While you're at it it would be nice to use maybe at least a 16 bit
>> value if possible.  I had mine all worked out to about 5 or 6 places
>> then found I could only  store what might be an 8 bit integer.  SDR
>> Sharp would only store mine as 102 instead of about 102.4567.  Since
>> the correction is done in software there shouldn't be a limit on the
>> size (data type) of the number.
> 
> Hmm, my solution would yield a resolution of about 0.035ppm.  A better
> resolution is probably not meaningful when calibrating a plain XO.

I'm not entirely sure if storing the absolute frequency is the right
way to go. The benefit that the application doesn't need to do anything
is nice on the one hand, but it doesn't really know about the
compensation as well. Okay, it could call rtlsdr_get_tuner_clock()...

Also, for correcting the sample clock it's better to use
rtlsdr_set_sample_freq_correction() instead of changing the value of
rtl_xtal, because it has (in theory) a much finer granularity than
rtlsdr_set_sample_rate. But right now we only pass an integer as
parameter for the ppm-value, so we can't use that granularity. Changing
it to ppb would make sense in my opinion.

My initial idea was storing the correction value in ppb in the eeprom,
along with some redundancy or a 'magic' check value (so that seemingly
random data on unprogrammed sticks isn't interpreted as a correct
correction value). But then there's the question on how applications
should deal with that, as in: should a call to
rtlsdr_set_freq_correction() override the setting which has been read
from the eeprom, or should it be applied 'on-top'?

I'd go for override, and try to make sure that applications call
rtlsdr_get_freq_correction() to get the initial value first.

Regards,
Steve



From tom at trondeau.com  Sat May 25 16:48:43 2013
From: tom at trondeau.com (Tom Rondeau)
Date: Sat, 25 May 2013 12:48:43 -0400
Subject: Updated gr-osmosdr for GNU Radio 3.7
Message-ID: <CA+SzT6h+r5ic9XUSpO422iKykSUZ7HYFZ5WG1XEDwfqmwnsxKw@mail.gmail.com>

Not sure if anyone else had worked on this, but I couldn't find
anything. I updated gr-osmosdr to work with GNU Radio 3.7 (currently
the next branch). You can find it here:

https://github.com/trondeau/gr-osmosdr

I didn't redo the code to be in the 3.7 API style, just made sure that
it could build off gnuradio and run properly.

Tom



From andreas+git at gate450.dyndns.org  Wed May 29 11:29:06 2013
From: andreas+git at gate450.dyndns.org (Andreas Seltenreich)
Date: Wed, 29 May 2013 13:29:06 +0200
Subject: [PATCH 1/2] rtl_eeprom: Add -x to store exact xtal frequency in Hz.
Message-ID: <87ip22dl5b.fsf@gate450.dyndns.org>

Stored in the last four bytes of the eeprom in network byte order.
---
 src/rtl_eeprom.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/rtl_eeprom.c b/src/rtl_eeprom.c
index 35191de..51024d6 100644
--- a/src/rtl_eeprom.c
+++ b/src/rtl_eeprom.c
@@ -23,8 +23,10 @@
 
 #ifndef _WIN32
 #include <unistd.h>
+#include <arpa/inet.h>
 #else
 #include <Windows.h>
+#include <WinSock2.h>
 #include "getopt/getopt.h"
 #endif
 
@@ -84,6 +86,7 @@ void usage(void)
 		"\t[   terratec_plus\tTerratec T Stick+ (DVB-T/DAB)]\n"
 		"\t[-w <filename> write dumped file to device]\n"
 		"\t[-r <filename> dump EEPROM to file]\n"
+		"\t[-x <Hz> store calibrated XTAL frequency]\n"
 		"\t[-h display this help text]\n"
 		"\nUse on your own risk, especially -w!\n");
 	exit(1);
@@ -262,9 +265,10 @@ int main(int argc, char **argv)
 	int default_config = 0;
 	int change = 0;
 	int ir_endpoint = 0;
+	uint32_t xtal_freq = 0;
 	char ch;
 
-	while ((opt = getopt(argc, argv, "d:m:p:s:i:g:w:r:h?")) != -1) {
+	while ((opt = getopt(argc, argv, "d:m:p:s:i:g:w:r:x:h?")) != -1) {
 		switch (opt) {
 		case 'd':
 			dev_index = atoi(optarg);
@@ -306,6 +310,9 @@ int main(int argc, char **argv)
 		case 'r':
 			filename = optarg;
 			break;
+		case 'x':
+			xtal_freq = htonl(atol(optarg));
+			break;
 		default:
 			usage();
 			break;
@@ -347,6 +354,14 @@ int main(int argc, char **argv)
 	if (r < 0)
 		return -1;
 
+	if(xtal_freq) {
+	  	r = rtlsdr_write_eeprom(dev, (void*)&xtal_freq, EEPROM_SIZE-4, 4);
+		if (r < 0)
+		  	fprintf(stderr, "Error while writing XTAL frequency to EEPROM: %i\n", r);
+		else
+		  	fprintf(stderr, "XTAL frequency successfully written.\n");
+	}
+
 	fprintf(stderr, "Current configuration:\n");
 	parse_eeprom_to_conf(&conf, buf);
 	dump_config(&conf);
-- 
1.7.10.4





From andreas+git at gate450.dyndns.org  Wed May 29 11:36:03 2013
From: andreas+git at gate450.dyndns.org (Andreas Seltenreich)
Date: Wed, 29 May 2013 13:36:03 +0200
Subject: [PATCH 2/2] lib: Try reading xtal calibration from EEPROM.
Message-ID: <87d2sadl5a.fsf@gate450.dyndns.org>

Interpret last four bytes of EEPROM as value in Hz using network byte
order and use it as default if it is between MIN_RTL_XTAL_FREQ and
MAX_RTL_XTAL_FREQ.
---
 src/librtlsdr.c |   21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 2f5d90a..c986018 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -25,6 +25,9 @@
 #ifndef _WIN32
 #include <unistd.h>
 #define min(a, b) (((a) < (b)) ? (a) : (b))
+#include <arpa/inet.h>
+#else
+#include <WinSock2.h>
 #endif
 
 #include <libusb.h>
@@ -279,6 +282,7 @@ static rtlsdr_dongle_t known_devices[] = {
 #define BULK_TIMEOUT	0
 
 #define EEPROM_ADDR	0xa0
+#define EEPROM_SIZE	256
 
 enum usb_reg {
 	USB_SYSCTL		= 0x2000,
@@ -1365,14 +1369,27 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
 		goto err;
 	}
 
-	dev->rtl_xtal = DEF_RTL_XTAL_FREQ;
-
 	/* perform a dummy write, if it fails, reset the device */
 	if (rtlsdr_write_reg(dev, USBB, USB_SYSCTL, 0x09, 1) < 0) {
 		fprintf(stderr, "Resetting device...\n");
 		libusb_reset_device(dev->devh);
 	}
 
+	dev->rtl_xtal = DEF_RTL_XTAL_FREQ;
+
+	/* Allow for the last four bytes of the EEPROM to contain a
+	   calibration frequency. */
+	{
+	  uint32_t rtl_freq;
+
+	  if (0 < rtlsdr_read_eeprom(dev, (void *)&rtl_freq, EEPROM_SIZE-4, 4))
+	    rtl_freq = ntohl(rtl_freq);
+	    if (rtl_freq >= MIN_RTL_XTAL_FREQ && rtl_freq <= MAX_RTL_XTAL_FREQ) {
+	      fprintf(stderr, "Found valid XTAL calibration in EEPROM: %u Hz\n",
+		      dev->rtl_xtal = rtl_freq);
+	    }
+	}
+
 	rtlsdr_init_baseband(dev);
 	dev->dev_lost = 0;
 
-- 
1.7.10.4




From andreas+git at gate450.dyndns.org  Wed May 29 12:26:19 2013
From: andreas+git at gate450.dyndns.org (Andreas Seltenreich)
Date: Wed, 29 May 2013 14:26:19 +0200
Subject: [PATCH 0/2] Store frequency calibration in EEPROM
Message-ID: <87obbudl5c.fsf@gate450.dyndns.org>

Hi,

I modified my copy of rtl-sdr to be able to store frequency calibration
on the sticks themselves.  Maybe this change is generally useful?

Thanks,
andreas

Andreas Seltenreich (2):
  rtl_eeprom: Add -x to store exact xtal frequency in Hz.
  lib: Try reading xtal calibration from EEPROM.

 src/librtlsdr.c  |   21 +++++++++++++++++++--
 src/rtl_eeprom.c |   17 ++++++++++++++++-
 2 files changed, 35 insertions(+), 3 deletions(-)

-- 
1.7.10.4