[Discuss-gnuradio] Displaying phase and amplitude variation of filter / transformer?

[Ralph A. Schmid, dk5ras]

Hi,

Are there any grc flowgraphs out in the wild that visualize the phase and
amplitude variation of a given system like some LC filter or transformer,
when you tweak with it? My idea is to output a sinoidal signal of maybe some
hundred kHz, feed it through the system of interest, and then watch it on a
xy scope. Not a big deal, a matter of putting together some standard blocks,
but maybe there is already a neat and tidy example available, with some gain
control, agc, band filter and such?

With best regards

Ralph.



--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Runtime Error

[Sohaib Khan]

I am using DVB-T dongle RTLSDR2832U with gnu radio, i have installed all the 
required files, but when i compile my flowgraph I get an error.
Runtime Error:Failed to open rtlsdr device.
What is the problem and its solution??

Sohaib bin Altaf
pakistan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Runtime Error

[Marcus Müller]

Hello Sohaib,
from http://sdr.osmocom.org/trac/wiki/rtl-sdr:

If the device can't be opened, make sure you have the appropriate rights 
to access the device (install udev-rules from the repository, or run it 
as root).



The osmo project has for your conveniences generated a rule that assigns 
correct access rights to your device as soon as you plug it in.  So in 
your rtl-sdr build folder, run


sudo make install-udev-rules

to install them.

Hopefully that fixed your problem,
Greetings,

Marcus M



I am using DVB-T dongle RTLSDR2832U with gnu radio, i have installed all the 
required files, but when i compile my flowgraph I get an error.
Runtime Error:Failed to open rtlsdr device.
What is the problem and its solution??

Sohaib bin Altaf
pakistan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Passive radar using my hacked dual coherent channel rtl_sdr dongle

[M Dammer]

This is awesome. How did you analyze the data ? Is the software/source
(both grc setup and data analysis) available ?
Mark

On 25/09/13 23:23, Juha Vierinen wrote:
> I hooked up my dual coherent channel rtl_sdr dongle into two of our
> passive radar antennas that we have here (log-periodic antennas
> pointing North and South). After fine tuning gains and signal levels,
> I acquired some FM radio data (WWLI 105.1 MHz). To my surprise, I got
> passive radar echoes from airplanes when I analyzed the data. Passive
> radar is one of the most challenging types of radar because the
> requirements for dynamic range are larger than those for eg., pulsed
> radar, I really didn't expect much from my test. 
>
> I expect the $16 system to also be able to see specular meteor echoes
> (typically stronger than airplanes) and ionospheric field aligned
> irregularity echoes. Not bad for something that required about
> $10k-$100k investment in a digital receivers ten years ago, and a $2k
> investment yesterday. 
>
> Visually, the rtl_sdr dongle system has a little bit more noise than
> the usrp n200 with a tvrx2. And also, there is the hassle of aligning
> samples. So I would still use the usrp if given a choice, as it does
> perform better and requires no hacking.
>
> Here is the passive radar video I just made using my $16 dual channel
> rtl_sdr (the timestamp is broken, but I just did the measurement an
> hour ago):
> http://youtu.be/KRqtqtCVRR0
>
> For comparison, here is an example passive radar video of airplanes
> and specular meteor echoes done using a usrp n200 + tvrx2. This was
> earlier, so the targets aren't the same:
> http://youtu.be/-k2ZuhAz0ac
>
> Does anyone know who manufactures these dongles, or who designed it?
>
> PS. I ordered a seven port usb hub, in anticipation of adding more
> coherent channels (to do interferometry and maybe imaging). It seems
> that every time I browse ebay, I end up ordering a few dongles. 
>
> juha
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Enable QT multi threading in the qtgui template

[Tom Rondeau]

On Wed, Sep 25, 2013 at 6:10 PM, Sylvain Munaut <246...@gmail.com> wrote:
>> I also tried creating the QWidget subclass separately, like it's done
>> in the qtgui elements but I also have a problem on destruction because
>> there is a tight link between the two (exchanging a lot of data ..)
>> and they're destroyed independently by two completely different path
>> ...
>
> Ah, at least I found how to deal with that.
>
> The default top level generated by GRC does something like this :
>
> qapp = Qt.QApplication(sys.argv)
> tb = top_block()
> tb.start()
> tb.show()
> qapp.exec_()
> tb.stop()
> tb = None
>
> Now the problem is that the Qt stuff will start to get cleaned up
> before all the block stop() methods have run and so some processing
> might still be going on while some Qt element get destroyed and then
> all hell breaks loose ( abort / segfaults / exceptions / ... )
>
> Adding a tb.wait() right after the tb.stop() seems to fix the problem.
> But it might even be better to register an "aboutToQuit()" signal
> handler and issue the stop() & wait() to the flowgraph before any of
> the Qt app cleanup even begins.
> And this seems to fit the recommended usage
> http://doc.qt.digia.com/4.7/qcoreapplication.html#aboutToQuit
>
> And you get something like this :
>
> qapp = Qt.QApplication(sys.argv)
> tb = top_block()
> tb.start()
> tb.show()
> def quitting():
> tb.stop()
> tb.wait()
> qapp.connect(qapp, SIGNAL("aboutToQuit()"), quitting)
> qapp.exec_()
>
> Where the order of destruction makes more sense. You end up having :
>
> - All stop() method called and wait for completion of all
> - Destruction of all QWidgets by Qt
> - Destruction of all blocks themselves
>
> This at least gives the opportunity to blocks that create some Qt
> widget to _know_ that they should stop accessing them because they
> might not be there anymore ... (in my case I start/stop a worker
> thread in the gr::sync_block start/stop methods and that thread
> accesses the QWidget create by the block)
>
>
> Cheers,
>
> Sylvain

Excellent, Sylvain!

Yes, the destruction of objects with QT being "good" and doing its own
garbage collection was a hassle for me at the beginning, too. This
looks like a nice solution, especially if it solves your issues.

Once you've settled everything and have your OOT module working and
tested, can you send us a couple of patches for these things? Or you
and I can work offline to make sure things are fixed correctly.

Thanks!

-- 
Tom
GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Constellations in OOT projects

[Tom Rondeau]

On Tue, Sep 24, 2013 at 7:56 PM, Michael Berman  wrote:
> Upon looking at the generated *_swig.py files, I am seeing more of the
> differences.  For some reason my OOT module is not generating the python
> wrapper for the constellation_theta class, it is only creating the wrapper
> for the shared pointer object.  I am curious now as to what the gnuradio
> swig interface files are doing elsewhere that are causing that build to pick
> up the object files when only the shared pointer is called out in the swig
> .i file.
>
> Thank you very much for the help,
>
> Michael Berman

All I can suggest right now is to make sure your .h file is properly
included in the swig.i file. Notice that in digital_swig.i, it's
included twice, once in line 51 (#include inside the %{ and %}) and
line 121 (as %include).

But also note the %include of constellation.i. This is needed to
Python-ize some of the interfaces.

Tom



> On Tue, Sep 24, 2013 at 1:16 PM, Michael Berman 
> wrote:
>>
>> I am having issues implementing what was discussed previously.  I have
>> created an OOT module (constellation_theta), and placed it within the
>> gr::digital namespace.  All of the cpp code is written and working fine.  As
>> I am attempting to add a custom constellation, I used the existing instances
>> of constellations (bpsk, qpsk, etc.) as an example for my constellation
>> object as far as the swig .i files and the cpp files from the gr-digital
>> section of the gnuradio gr-digital source for my new module.  When I attempt
>> to run this module, I get the following python runtime error:
>>
>> 
>>   File
>> "/usr/local/lib/python2.7/dist-packages/constellation_theta/constellation_theta_swig.py",
>> line 102, in 
>> constellation_theta = constellation_theta.make;
>> NameError: name 'constellation_theta' is not defined
>>
>> This line is driven directly from the swig .i file, of which I copied the
>> format from the .../gnuradio/gr-digital/swig/constellation.i file.
>> Comparing the generated .py files from the installed swig generated code, I
>> also do not understand why I have so many differences from this.  The
>> gnuradio code has the cpp class laid out inside the .py file perfectly, with
>> all of the exposed methods; however, my code has none of that, just the
>> basic constructor (which I don't even want exposed to preserve the shared
>> pointer structure).
>>
>> I am not sure where to go from this point on getting this up and running,
>> any help would be greatly appreciated.
>>
>>
>> Thank you very much,
>>
>> Michael Berman
>>
>>
>> On Mon, Sep 23, 2013 at 9:21 AM, Michael Berman 
>> wrote:
>>>
>>> Tom,
>>>
>>> Thanks for the response.  This is what i was thinking was the appropriate
>>> action, I just wanted to make sure.  As for the header, I didn't realize I
>>> didn't add one until after I sent the email out; I'll try to not let that
>>> one happen again.
>>>
>>>
>>> Thanks,
>>>
>>> Michael Berman
>>>
>>>
>>> On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau  wrote:

 On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman 
 wrote:
 > I am attempting to add a custom constellation class to be used with
 > the
 > generic_mod_demod object for digital PSK.  I have the code working as
 > a
 > simple addition to the gnuradio source with a re-compilation, however
 > I
 > would like to set this up similar to an Out Of Tree module (although
 > it
 > isn't entirely a standalone module).  Would the way I go about
 > approaching
 > this be the same as the adding an Out Of Tree module tutorial on the
 > gnuradio website?  Or would there be a preferred method than the
 > gr_modtool.
 > I would like to set this up so that the code I add sits in the
 > gr::digital
 > scope and have everything look as though it all sits in the
 > constellation.{cc, h, i} files.  Does anybody have recommendations for
 > attacking this task?
 >
 >
 > Thank you very much,
 >
 > Michael Berman

 Hi Michael,
 Please use a proper subject line in the future to help us sort and
 keep track of things.

 As to your question, that shouldn't be a problem. You should be able
 to create a class in your OOT module and inherit from
 gr::digital::constellation (or one of it's children). And just putting
 it inside the gr::digital namespace. This will obviously now exist in
 your own lib.so and not in libgnuradio-digital.so. So I'm
 not sure what you mean by "sits inside constellation.{cc,h,i}". If you
 are in an OOT project, you wouldn't be able to add this directly to
 the gnuradio-digital library or Python module (ok, there's a way to do
 the latter by smashing it in during install, but that's seriously ugly
 business that you want no part of).

 And use gr_modtool. Definitely the best, easiest, and preferred way of
 setting things up. When creating your new class, use 'gr_modtool add'
 and for the

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Juha Vierinen]

Hi,

I modified my clock sharing so that I only insert a signal in the Xtal_In
pin of other dongle. This way I won't have two circuits driving the same
crystal, as Ian pointed out. The pin next to the edge of the dongle turned
out to be the Xtal_In pin (the input of the opamp on the slave dongle). The
dual coherent rtlsdr dongle still works the same. I guess I was lucky to
get it working the first time.

I am working towards setting up a fanout buffer, to do this properly.

juha


On Tue, Sep 24, 2013 at 4:54 PM, Ian Buckley  wrote:

> On Sep 24, 2013, at 11:41 AM, Marcus D. Leech  wrote:
>
> > On 09/23/2013 10:59 AM, Juha Vierinen wrote:
> >>
> >> I was playing around with the rtl_sdr dongles and came up with a
> trivial hack to build a receiver with multiple coherent channels. I do this
> basically by unsoldering the quartz clock on the slave units and cable the
> clock from the master rtl dongle to the slave units (I've attached some
> pictures).
> >>
> >> You still have to do sample alignment in software, but this is
> relatively easy. There are a lot of cool applications, such as a dual
> frequency beacon satellite receiver, interferometry, or passive radar that
> you can now do with $16.
> >>
> >> juha
> >>
> >>
> > So, what were your test conditions?
> >
> > I'm feeding a +3.3dBm signal from a high-precision communications test
> set at 28.8Mhz to two of those dongles.
> >
> > Then I'm feeding in a 45Mhz sine wave into the two devices RF input
> through a splitter and variable attenuator.
> >
> > The result is horrible relative-phase-noise between the two channels.
>  They dance all over the place on the scope display.
> >
> > In comparision, a B100 with TVRX2, under the same conditions, works
> flawlessly, with no appreciable relative phase jitter between the
> >   two channels.
> >
> > --
> > Marcus Leech
>
> Marcus, (appreciate you may have done a lot more than your brief
> description above, but just in case….)
>
> The type of cheap 2 pin oscillator used with the Realtek chips will be
> connected across an internal inverting buffer amplifier in the IC with
> shunt capacitance and all the circuit goodness that makes such thinks work.
> If you are going to replace that with a buffered clock source such as a
> bench signal source or expensive TXCO you're normally going to only drive
> the crystal input pin and leave the other unconnected….now which pin that
> is I can;t tell you because the data sheet/schematic isn't available to my
> knowledge…but hey, its $8 so trial and error!
> Might also want to consider series termination for each cable to the
> boards to minimize SI issues also.
> Of course in Juha's case he's just using the original clock-osc and
> getting lucky that it's still oscillating cleanly with the two IC's driving
> the crystal.
>
> -Ian
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Constellations in OOT projects

[Michael Berman]

Thank you for the advice,  I have gotten this working now.  It was a user
error in that I was not including the gnuradio/digital/constellation.h file
in the swig .i.  Also to note for anybody in the future, I also had to link
the libgnuradio-digital.so into the CMakeLists.txt file in the lib
directory at the end of the target_link_libraries line.  This was due to a
runtime python error about not being able to find the constellation object
in the OOT .so object.

Thank you very much,

Michael Berman


On Thu, Sep 26, 2013 at 8:14 AM, Tom Rondeau  wrote:

> On Tue, Sep 24, 2013 at 7:56 PM, Michael Berman 
> wrote:
> > Upon looking at the generated *_swig.py files, I am seeing more of the
> > differences.  For some reason my OOT module is not generating the python
> > wrapper for the constellation_theta class, it is only creating the
> wrapper
> > for the shared pointer object.  I am curious now as to what the gnuradio
> > swig interface files are doing elsewhere that are causing that build to
> pick
> > up the object files when only the shared pointer is called out in the
> swig
> > .i file.
> >
> > Thank you very much for the help,
> >
> > Michael Berman
>
> All I can suggest right now is to make sure your .h file is properly
> included in the swig.i file. Notice that in digital_swig.i, it's
> included twice, once in line 51 (#include inside the %{ and %}) and
> line 121 (as %include).
>
> But also note the %include of constellation.i. This is needed to
> Python-ize some of the interfaces.
>
> Tom
>
>
>
> > On Tue, Sep 24, 2013 at 1:16 PM, Michael Berman 
> > wrote:
> >>
> >> I am having issues implementing what was discussed previously.  I have
> >> created an OOT module (constellation_theta), and placed it within the
> >> gr::digital namespace.  All of the cpp code is written and working
> fine.  As
> >> I am attempting to add a custom constellation, I used the existing
> instances
> >> of constellations (bpsk, qpsk, etc.) as an example for my constellation
> >> object as far as the swig .i files and the cpp files from the gr-digital
> >> section of the gnuradio gr-digital source for my new module.  When I
> attempt
> >> to run this module, I get the following python runtime error:
> >>
> >> 
> >>   File
> >>
> "/usr/local/lib/python2.7/dist-packages/constellation_theta/constellation_theta_swig.py",
> >> line 102, in 
> >> constellation_theta = constellation_theta.make;
> >> NameError: name 'constellation_theta' is not defined
> >>
> >> This line is driven directly from the swig .i file, of which I copied
> the
> >> format from the .../gnuradio/gr-digital/swig/constellation.i file.
> >> Comparing the generated .py files from the installed swig generated
> code, I
> >> also do not understand why I have so many differences from this.  The
> >> gnuradio code has the cpp class laid out inside the .py file perfectly,
> with
> >> all of the exposed methods; however, my code has none of that, just the
> >> basic constructor (which I don't even want exposed to preserve the
> shared
> >> pointer structure).
> >>
> >> I am not sure where to go from this point on getting this up and
> running,
> >> any help would be greatly appreciated.
> >>
> >>
> >> Thank you very much,
> >>
> >> Michael Berman
> >>
> >>
> >> On Mon, Sep 23, 2013 at 9:21 AM, Michael Berman 
> >> wrote:
> >>>
> >>> Tom,
> >>>
> >>> Thanks for the response.  This is what i was thinking was the
> appropriate
> >>> action, I just wanted to make sure.  As for the header, I didn't
> realize I
> >>> didn't add one until after I sent the email out; I'll try to not let
> that
> >>> one happen again.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Michael Berman
> >>>
> >>>
> >>> On Sat, Sep 21, 2013 at 8:09 AM, Tom Rondeau  wrote:
> 
>  On Fri, Sep 20, 2013 at 7:55 PM, Michael Berman  >
>  wrote:
>  > I am attempting to add a custom constellation class to be used with
>  > the
>  > generic_mod_demod object for digital PSK.  I have the code working
> as
>  > a
>  > simple addition to the gnuradio source with a re-compilation,
> however
>  > I
>  > would like to set this up similar to an Out Of Tree module (although
>  > it
>  > isn't entirely a standalone module).  Would the way I go about
>  > approaching
>  > this be the same as the adding an Out Of Tree module tutorial on the
>  > gnuradio website?  Or would there be a preferred method than the
>  > gr_modtool.
>  > I would like to set this up so that the code I add sits in the
>  > gr::digital
>  > scope and have everything look as though it all sits in the
>  > constellation.{cc, h, i} files.  Does anybody have recommendations
> for
>  > attacking this task?
>  >
>  >
>  > Thank you very much,
>  >
>  > Michael Berman
> 
>  Hi Michael,
>  Please use a proper subject line in the future to help us sort and
>  keep track of things.
> 
>  As to your question, that shouldn't be a

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Marcus Leech]

Well, I certainly would be keen to hear your further reports on this.
One thing to consider is that if you're going to build a fan-out buffer, you might as well build a 28.8MHz source using one of the easily-available 14.4Mhz TCXOs that are "out there", and design
  a doubler--this will give you a clock source that's about 2.5PPM, instead of the 100-150PPM of the "native" crystal.
 
I've found that the dongles require about 0dBm on the Xtal_In pin to work reliably, so you need about +3dBm for two of them, etc.
 
 
on Sep 26, 2013, Juha Vierinen  wrote:

Hi, 
 
I modified my clock sharing so that I only insert a signal in the Xtal_In pin of other dongle. This way I won't have two circuits driving the same crystal, as Ian pointed out. The pin next to the edge of the dongle turned out to be the Xtal_In pin (the input of the opamp on the slave dongle). The dual coherent rtlsdr dongle still works the same. I guess I was lucky to get it working the first time.
 
I am working towards setting up a fanout buffer, to do this properly.  
 
juha


On Tue, Sep 24, 2013 at 4:54 PM, Ian Buckley  wrote:


On Sep 24, 2013, at 11:41 AM, Marcus D. Leech  wrote:  > On 09/23/2013 10:59 AM, Juha Vierinen wrote: >> >> I was playing around with the rtl_sdr dongles and came up with a trivial hack to build a receiver with multiple coherent channels. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master rtl dongle to the slave units (I've attached some pictures). >> >> You still have to do sample alignment in software, but this is relatively easy. There are a lot of cool applications, such as a dual frequency beacon satellite receiver, interferometry, or passive radar that you can now do with $16. >> >> juha >> >> > So, what were your test conditions? > > I'm feeding a +3.3dBm signal from a high-precision communications test set at 28.8Mhz to two of those dongles. > > Then I'm feeding in a 45Mhz sine wave into the two devices RF input through a splitter and variable attenuator. > > The result is horrible relative-phase-noise between the two channels.  They dance all over the place on the scope display. > > In comparision, a B100 with TVRX2, under the same conditions, works flawlessly, with no appreciable relative phase jitter between the >   two channels. > > -- > Marcus Leech 

Marcus, (appreciate you may have done a lot more than your brief description above, but just in case….)  The type of cheap 2 pin oscillator used with the Realtek chips will be connected across an internal inverting buffer amplifier in the IC with shunt capacitance and all the circuit goodness that makes such thinks work. If you are going to replace that with a buffered clock source such as a bench signal source or expensive TXCO you're normally going to only drive the crystal input pin and leave the other unconnected….now which pin that is I can;t tell you because the data sheet/schematic isn't available to my knowledge…but hey, its $8 so trial and error! Might also want to consider series termination for each cable to the boards to minimize SI issues also. Of course in Juha's case he's just using the original clock-osc and getting lucky that it's still oscillating cleanly with the two IC's driving the crystal.  -Ian 

  ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio






 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 49MHz Rtl_sdr receiver

[William Pretty Security]

Hello list;

 

I have been following a thread by Marcus and others about coherent
receivers, etc.

I have a question: Is it possible to change the clock frequency to receive a
slightly lower frequency?

 

I have some ~ 49.89MHz wireless mic's that I would like to reuse, and an SDR
seems like a cool solution.

My current RTL dongle bottoms out at exactly 50MHz L Can I just change the
clock or are their firmware issues as well?

Right now if a try and set the frequency to say 45MHz, I get a "device not
found" error from the Windoze software.

 

Thanks;

 

Bill

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Monahan-Mitchell, Tim]

> On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
>> The solution I found was to set the Fixed Frame Length parameter to 1 
>> on the OFDM Frame Equalizer block of the "Header Stream".

> 1 is the correct setting. I'm currently adding a tx into the example so it 
> runs as-is (like benchmark).

It would be interesting to keep the original diagram, and then also show a 
replacement diagram that instead uses the OFDM Demod block and any other newer 
ones that consolidate the equivalent function.

> The reason: The headers have constant length, therefore it is not necessary 
> to propagate them as tagged streams. The way the header/paylod demux work, it 
> splits off the header and passes that regularly. There's no need to generate 
> a length tag.

Maybe that explains why my earlier issue about the Length Tag Key value for 
that same block does not matter (see GR issue # 593), since "1" implies it is 
not needed.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 49MHz Rtl_sdr receiver

[Ashworth Payne]

The simplest solution might be to transvert using something like the ham-it-up. 
When not doing wireless mic duty, you'll also have a general coverage receiver 
to tinker with. 

Kindest regards,
Ashworth Payne

On Sep 26, 2013, at 1:44 PM, "William Pretty Security" 
 wrote:

> Hello list;
>  
> I have been following a thread by Marcus and others about coherent receivers, 
> etc.
> I have a question: Is it possible to change the clock frequency to receive a 
> slightly lower frequency?
>  
> I have some ~ 49.89MHz wireless mic’s that I would like to reuse, and an SDR 
> seems like a cool solution.
> My current RTL dongle bottoms out at exactly 50MHz L Can I just change the 
> clock or are their firmware issues as well?
> Right now if a try and set the frequency to say 45MHz, I get a “device not 
> found” error from the Windoze software.
>  
> Thanks;
>  
> Bill
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 49MHz Rtl_sdr receiver

[Alexandru Csete]

On Thu, Sep 26, 2013 at 7:44 PM, William Pretty Security
 wrote:
> Hello list;
>
> I have been following a thread by Marcus and others about coherent
> receivers, etc.
>
> I have a question: Is it possible to change the clock frequency to receive a
> slightly lower frequency?
>
> I have some ~ 49.89MHz wireless mic’s that I would like to reuse, and an SDR
> seems like a cool solution.
>
> My current RTL dongle bottoms out at exactly 50MHz L Can I just change the
> clock or are their firmware issues as well?
>
> Right now if a try and set the frequency to say 45MHz, I get a “device not
> found” error from the Windoze software.
>

The clock has nothing to do with the RF range (not directly anyway)
since there is an integrated tuner that converts the RF to DC or a low
IF. Thew exact RF range depends on the tuner and if you get a device
with the R820T tuner it will work down to 24 MHz or so.

Alex

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Monahan-Mitchell, Tim]

>>> The solution I found was to set the Fixed Frame Length parameter to 1 
>>> on the OFDM Frame Equalizer block of the "Header Stream".

>> 1 is the correct setting.

With this fix, now I see a new error:

INFO: Detected an invalid packet at item 0
INFO: Parser returned #f
thread[thread-per-block[18]: ]: Buffer too 
small for min_noutput_items

I'll look into this, but just in case this is familiar to anyone...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Heath Hunnicutt]

Juha,

Ordinarily, I would choose to feed a clock into xtal_in, this seems logical. 
However check out the Elonics patent:

http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html

The main thing to note is that square-wave clock input should be fed to
xtal_in for the elonics chip.

If you read that patent, it may give you some ideas about feeding a clock to
xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
the linear region of voltage swing, not rail-to-rail square wave.  Note the
comments in that patent on jitter at square wave, etc.,

Nobody on this thread has stated whether they are using e4000 or r820.  That
would probably be helpful.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43851.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Heath Hunnicutt]

Bah!!!  The main thing to note is that the e4000 expects a clock input on
XTAL_OUT.  That's right, the patent says that out can be an in, for the
e4000.  Sorry I made a post in which I made a thought mistake and typed the
opposite.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43852.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Marcus D. Leech]

On 09/26/2013 06:32 PM, Heath Hunnicutt wrote:

Juha,

Ordinarily, I would choose to feed a clock into xtal_in, this seems logical.
However check out the Elonics patent:

http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html

The main thing to note is that square-wave clock input should be fed to
xtal_in for the elonics chip.

If you read that patent, it may give you some ideas about feeding a clock to
xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
the linear region of voltage swing, not rail-to-rail square wave.  Note the
comments in that patent on jitter at square wave, etc.,

Nobody on this thread has stated whether they are using e4000 or r820.  That
would probably be helpful.




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43851.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Well, my tests have been with R820T, which has a clock output that goes 
to the RTL2832U chip.


I've actually tried both sides of Xtal_I and Xtal_O on the R820T, and it 
makes no difference.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[juha]

I use R820T. It has nonzero IF and the noise is relatively flat. 

The clock looks sawtooth-like on the scope.

Juha

On 26.9.2013, at 18.32, Heath Hunnicutt  wrote:

> Juha,
> 
> Ordinarily, I would choose to feed a clock into xtal_in, this seems logical. 
> However check out the Elonics patent:
> 
> http://www.uspto.gov/web/patents/patog/week49/OG/html/1385-1/US08324978-20121204.html
> 
> The main thing to note is that square-wave clock input should be fed to
> xtal_in for the elonics chip.
> 
> If you read that patent, it may give you some ideas about feeding a clock to
> xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
> the linear region of voltage swing, not rail-to-rail square wave.  Note the
> comments in that patent on jitter at square wave, etc.,
> 
> Nobody on this thread has stated whether they are using e4000 or r820.  That
> would probably be helpful.
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/dual-coherent-channel-rtl-sdr-tp43784p43851.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual coherent channel rtl_sdr

[Heath Hunnicutt]

I wonder, since you are emulating the crystal output, if the R820T would
ordinarily drive the crystal to rail-to-rail, square wave output.  It might
be worthwhile using a high impedence probe to see what the signal you are
replacing looks like.

I say this because the elonics patent suggests that staying in the linear
region of the amplifiers in the feedback circuit (not rail to rail) reduces
jitter.



On Thu, Sep 26, 2013 at 3:41 PM, Marcus D. Leech  wrote:

> On 09/26/2013 06:32 PM, Heath Hunnicutt wrote:
>
>> Juha,
>>
>> Ordinarily, I would choose to feed a clock into xtal_in, this seems
>> logical.
>> However check out the Elonics patent:
>>
>> http://www.uspto.gov/web/**patents/patog/week49/OG/html/**
>> 1385-1/US08324978-20121204.**html
>>
>> The main thing to note is that square-wave clock input should be fed to
>> xtal_in for the elonics chip.
>>
>> If you read that patent, it may give you some ideas about feeding a clock
>> to
>> xtal_in of other chips.  Maybe other chips will also expect a sawtooth in
>> the linear region of voltage swing, not rail-to-rail square wave.  Note
>> the
>> comments in that patent on jitter at square wave, etc.,
>>
>> Nobody on this thread has stated whether they are using e4000 or r820.
>>  That
>> would probably be helpful.
>>
>>
>>
>>
>> --
>> View this message in context: http://gnuradio.4.n7.nabble.**
>> com/dual-coherent-channel-rtl-**sdr-tp43784p43851.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>>
>>  Well, my tests have been with R820T, which has a clock output that goes
> to the RTL2832U chip.
>
> I've actually tried both sides of Xtal_I and Xtal_O on the R820T, and it
> makes no difference.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Noise/random sources

[Marcus D. Leech]

When I use multiple noise sources in a flow-graph, each with a different 
seed, are they actually independent, or do they just call "random" or 
"lrand" or

  something, and thus setting different seeds has no effect?





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Passive radar using my hacked dual coherent channel rtl_sdr dongle

[Juha Vierinen]

Hi,

I'm just using a simple script to dump data to disk. I then have another
program that analyzes the files. It is not too complicated. The measurement
equation is a convolution with the assumption that the target is stationary
over ~20 ms and that the ground clutter is stationary over ~1 second.

My code is a mess at the moment and it depends on other unpublished
libraries that I have written, which are also a mess.  I might release this
once I have cleaned it up a bit.

juha


On Thu, Sep 26, 2013 at 9:00 AM, M Dammer  wrote:

>  This is awesome. How did you analyze the data ? Is the software/source
> (both grc setup and data analysis) available ?
> Mark
>
>
> On 25/09/13 23:23, Juha Vierinen wrote:
>
>  I hooked up my dual coherent channel rtl_sdr dongle into two of our
> passive radar antennas that we have here (log-periodic antennas pointing
> North and South). After fine tuning gains and signal levels, I acquired
> some FM radio data (WWLI 105.1 MHz). To my surprise, I got passive radar
> echoes from airplanes when I analyzed the data. Passive radar is one of the
> most challenging types of radar because the requirements for dynamic range
> are larger than those for eg., pulsed radar, I really didn't expect much
> from my test.
>
>  I expect the $16 system to also be able to see specular meteor echoes
> (typically stronger than airplanes) and ionospheric field aligned
> irregularity echoes. Not bad for something that required about $10k-$100k
> investment in a digital receivers ten years ago, and a $2k investment
> yesterday.
>
>  Visually, the rtl_sdr dongle system has a little bit more noise than the
> usrp n200 with a tvrx2. And also, there is the hassle of aligning samples.
> So I would still use the usrp if given a choice, as it does perform better
> and requires no hacking.
>
>  Here is the passive radar video I just made using my $16 dual channel
> rtl_sdr (the timestamp is broken, but I just did the measurement an hour
> ago):
> http://youtu.be/KRqtqtCVRR0
>
>  For comparison, here is an example passive radar video of airplanes and
> specular meteor echoes done using a usrp n200 + tvrx2. This was earlier, so
> the targets aren't the same:
> http://youtu.be/-k2ZuhAz0ac
>
>  Does anyone know who manufactures these dongles, or who designed it?
>
>  PS. I ordered a seven port usb hub, in anticipation of adding more
> coherent channels (to do interferometry and maybe imaging). It seems that
> every time I browse ebay, I end up ordering a few dongles.
>
>   juha
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Noise/random sources

[Jared Clements]

Forgot to cc the list.
-- Forwarded message --
From: "Jared Clements" 
Date: Sep 26, 2013 7:27 PM
Subject: Re: [Discuss-gnuradio] Noise/random sources
To: "Marcus D. Leech" 

Calling them with a seed of zero or greater will give the same "random"
stream, seeding with different negative numbers gives different random
sequences.

Jared
On Sep 26, 2013 7:17 PM, "Marcus D. Leech"  wrote:

> When I use multiple noise sources in a flow-graph, each with a different
> seed, are they actually independent, or do they just call "random" or
> "lrand" or
>   something, and thus setting different seeds has no effect?
>
>
>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Passive radar using my hacked dual coherent channel rtl_sdr dongle

[Jared Clements]

Since they're clocked together I would assume that your alignment would
consist of interpolation on the primary FM signal, what do you do to remove
it later?  If your code is too messy to release can you share a block
diagram?

Thanks,

Jared
On Sep 26, 2013 7:21 PM, "Juha Vierinen"  wrote:

> Hi,
>
> I'm just using a simple script to dump data to disk. I then have another
> program that analyzes the files. It is not too complicated. The measurement
> equation is a convolution with the assumption that the target is stationary
> over ~20 ms and that the ground clutter is stationary over ~1 second.
>
> My code is a mess at the moment and it depends on other unpublished
> libraries that I have written, which are also a mess.  I might release this
> once I have cleaned it up a bit.
>
> juha
>
>
> On Thu, Sep 26, 2013 at 9:00 AM, M Dammer  wrote:
>
>>  This is awesome. How did you analyze the data ? Is the software/source
>> (both grc setup and data analysis) available ?
>> Mark
>>
>>
>> On 25/09/13 23:23, Juha Vierinen wrote:
>>
>>  I hooked up my dual coherent channel rtl_sdr dongle into two of our
>> passive radar antennas that we have here (log-periodic antennas pointing
>> North and South). After fine tuning gains and signal levels, I acquired
>> some FM radio data (WWLI 105.1 MHz). To my surprise, I got passive radar
>> echoes from airplanes when I analyzed the data. Passive radar is one of the
>> most challenging types of radar because the requirements for dynamic range
>> are larger than those for eg., pulsed radar, I really didn't expect much
>> from my test.
>>
>>  I expect the $16 system to also be able to see specular meteor echoes
>> (typically stronger than airplanes) and ionospheric field aligned
>> irregularity echoes. Not bad for something that required about $10k-$100k
>> investment in a digital receivers ten years ago, and a $2k investment
>> yesterday.
>>
>>  Visually, the rtl_sdr dongle system has a little bit more noise than
>> the usrp n200 with a tvrx2. And also, there is the hassle of aligning
>> samples. So I would still use the usrp if given a choice, as it does
>> perform better and requires no hacking.
>>
>>  Here is the passive radar video I just made using my $16 dual channel
>> rtl_sdr (the timestamp is broken, but I just did the measurement an hour
>> ago):
>> http://youtu.be/KRqtqtCVRR0
>>
>>  For comparison, here is an example passive radar video of airplanes and
>> specular meteor echoes done using a usrp n200 + tvrx2. This was earlier, so
>> the targets aren't the same:
>> http://youtu.be/-k2ZuhAz0ac
>>
>>  Does anyone know who manufactures these dongles, or who designed it?
>>
>>  PS. I ordered a seven port usb hub, in anticipation of adding more
>> coherent channels (to do interferometry and maybe imaging). It seems that
>> every time I browse ebay, I end up ordering a few dongles.
>>
>>   juha
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1

[Martin Braun (CEL)]

On Thu, Sep 26, 2013 at 06:25:50PM +, Monahan-Mitchell, Tim wrote:
> > On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote:
> >> The solution I found was to set the Fixed Frame Length parameter to 1 
> >> on the OFDM Frame Equalizer block of the "Header Stream".
> 
> > 1 is the correct setting. I'm currently adding a tx into the example so it 
> > runs as-is (like benchmark).
> 
> It would be interesting to keep the original diagram, and then also show a 
> replacement diagram that instead uses the OFDM Demod block and any other 
> newer ones that consolidate the equivalent function.

Nothing's going to change with the original diagram. I'll just add an
ofdm_tx so it runs in loopback mode.

> > The reason: The headers have constant length, therefore it is not necessary 
> > to propagate them as tagged streams. The way the header/paylod demux work, 
> > it splits off the header and passes that regularly. There's no need to 
> > generate a length tag.
> 
> Maybe that explains why my earlier issue about the Length Tag Key value for 
> that same block does not matter (see GR issue # 593), since "1" implies it is 
> not needed.

Yep, exactly.


MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpunLNhLaTTJ.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio