Re: explaining i/q

[Aditya Arun Kumar]

So did that answer your question?



[image: Mailtrack]

Sender
notified by
Mailtrack

11/03/20,
08:23:36 AM

On Tue, Nov 3, 2020 at 7:50 AM Anon Lister  wrote:

> I always come back to the Lyons explaination: the pictures really help for
> the visual learners among us. If you did a workshop I’d definitely include
> a link to this in reference material:
>
> http://www.dspguru.com/files/QuadSignals.pdf
>
> There’s actually some of us who don’t come from formal electrical
> engineering backgrounds who learned this first and find equations and such
> more difficult when expressed in the “real“ interpretation of a signal. Heh.
>
>
>
> On Nov 2, 2020, at 18:06, Kristoff  wrote:
>
> Hi all,
>
> I was watching the webinar of Heather on GNU Radio today, when it came to
> me that one of the most difficult part doing a presentation of GNU Radio is
> the data-types, .. and especially these 'complex numbers'.
> The problem, or at least for me, is that when you mention 'GNU Radio
> complex numbers', you also have to mention iq-signals, which is a topic
> that is very difficult to explain in 10 seconds to an audience who has
> never seen anything about i/q sampling before.
>
>
> I have been thinking on how to explain the concept of I/Q signalling in
> just a few lines, e.g. in the context of -say- a workshop on GR.
>
>
> I have this idea in my head:
>
> Statement:
> The main difference between sampling with reals ('floats') and i/q
> sampling with complex numbers, is that the latter does not only provide
> the  instantaneous value (voltage) of a signal at a certain point of time,
> but also includes phase information (i.e. the slope of the signal at that
> point).
>
>
> To make this visual:
> Take half a sine-wave and plot it out for every 45 degrees.
> This gives you 5 points: 0 (0 degrees), sqrt(2)/2 (45 degrees), 1 (90
> degrees), sqrt(2)/2 (135 degrees) and 0 (180 degrees).
>
> Now look at the 2nd and the 4th point (45 degrees and 135 degrees), if you
> sample this using only real/float values, these two points are exactly the
> same (sqrt(2)/2). Just based on these values by themselves (i.e. remove all
> other points from the graph), there is no way you can tell that at the
> first point (45 degrees) the graph was going up, while at the 135-degrees
> point the graph was going down.
>
> So, ... what i/q sampling does, is for every point "x", it not only
> provide the value of the graph at that point of time, but also information
> of the slope of the graphs at that time.
>
>
> This also explains while i/q sampling is done by not just taking the value
> of a signal at point "t", but also at 1/4 period later (which is the
> information you need to determine the 'slope' of that graph at point 't')
>
>
> So, ... is this statement correct?
>
> If it is more-or-less correct and it can help provide a basic mental image
> of the concept of i/q sampling, I would be more then happy! :-)
>
>
>
>
> 73
> kristoff - ON1ARF
>
>
>
>
>

-- 
S. Aditya Arun Kumar
Security Researcher, Comms
+919123517465

Re: explaining i/q

[Anon Lister]

I always come back to the Lyons explaination: the pictures really help for the 
visual learners among us. If you did a workshop I’d definitely include a link 
to this in reference material:

http://www.dspguru.com/files/QuadSignals.pdf

There’s actually some of us who don’t come from formal electrical engineering 
backgrounds who learned this first and find equations and such more difficult 
when expressed in the “real“ interpretation of a signal. Heh.



> On Nov 2, 2020, at 18:06, Kristoff  wrote:
> 
> Hi all,
> 
> I was watching the webinar of Heather on GNU Radio today, when it came to me 
> that one of the most difficult part doing a presentation of GNU Radio is the 
> data-types, .. and especially these 'complex numbers'.
> The problem, or at least for me, is that when you mention 'GNU Radio complex 
> numbers', you also have to mention iq-signals, which is a topic that is very 
> difficult to explain in 10 seconds to an audience who has never seen anything 
> about i/q sampling before.
> 
> 
> I have been thinking on how to explain the concept of I/Q signalling in just 
> a few lines, e.g. in the context of -say- a workshop on GR.
> 
> 
> I have this idea in my head:
> 
> Statement:
> The main difference between sampling with reals ('floats') and i/q sampling 
> with complex numbers, is that the latter does not only provide the  
> instantaneous value (voltage) of a signal at a certain point of time, but 
> also includes phase information (i.e. the slope of the signal at that point).
> 
> 
> To make this visual:
> Take half a sine-wave and plot it out for every 45 degrees.
> This gives you 5 points: 0 (0 degrees), sqrt(2)/2 (45 degrees), 1 (90 
> degrees), sqrt(2)/2 (135 degrees) and 0 (180 degrees).
> 
> Now look at the 2nd and the 4th point (45 degrees and 135 degrees), if you 
> sample this using only real/float values, these two points are exactly the 
> same (sqrt(2)/2). Just based on these values by themselves (i.e. remove all 
> other points from the graph), there is no way you can tell that at the first 
> point (45 degrees) the graph was going up, while at the 135-degrees point the 
> graph was going down.
> 
> So, ... what i/q sampling does, is for every point "x", it not only provide 
> the value of the graph at that point of time, but also information of the 
> slope of the graphs at that time.
> 
> 
> This also explains while i/q sampling is done by not just taking the value of 
> a signal at point "t", but also at 1/4 period later (which is the information 
> you need to determine the 'slope' of that graph at point 't')
> 
> 
> So, ... is this statement correct?
> 
> If it is more-or-less correct and it can help provide a basic mental image of 
> the concept of i/q sampling, I would be more then happy! :-)
> 
> 
> 
> 
> 73
> kristoff - ON1ARF
> 
> 
> 
> 

Re: explaining i/q

[David Hagood]

The main difference between sampling with reals ('floats') and i/q 
sampling with complex numbers, is that the latter does not only 
provide the  instantaneous value (voltage) of a signal at a certain 
point of time, but also includes phase information (i.e. the slope of 
the signal at that point).


The phase is not the slope of the signal - the slope of the signal is 
the first derivative with respect to time of the signal.



The phase is something completely different - it's the angle of the 
signal. So, what does "angle" mean?


Imagine a sine wave - it's zero at zero degrees, 1 at ninety degrees, 0 
at 180 degrees, and -1 at 270 degrees. OK, so if I tell you the signal 
is 1, you know the phase angle is 90, because that's the only place 
sin(x) = 1. But what if I tell you it's at 0 - is the angle 0, or 180? 
There's literally no way to tell. But, what if I also give you the 
cosine of the angle? Cosine is 1 at zero, zero at ninety, -1 at 180, and 
zero again at 270. If I tell you that sin(x) is 1, and cos(x) is zero, 
the angle HAS to be 90. I and Q, or in phase and quadrature, are sine 
and cosine (or rather, usually cosine and sine, due to the way math 
works). Getting rid of that ambiguity about what the angle of the signal 
does all sorts of nice things when doing the math - it allows you to get 
rid of the negative frequency part of a signal (or more accurately, it 
allows you to unambiguously represent a negative frequency vs. a 
positive frequency).


Another way to visualize it - you may have seen the GIF of the ballet 
dancer silhouette , which can appear to be spinning left-to-right or 
right-to-left, just depending upon how you choose to interpret it. 
That's because you only have one part of the signal - you have the X 
part, or the in-phase part, but you don't have the Y part or quadrature 
part. Now, if you had both parts - if you saw not only the image along 
the Y axis (you see x and z), but you also saw the image along the X 
axis (seeing y and z - seeing the figure from the left or right side), 
then you would immediately know which way she was spinning.





OpenPGP_0x5B9DC79986207D69.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

explaining i/q

[Kristoff]

Hi all,

I was watching the webinar of Heather on GNU Radio today, when it came 
to me that one of the most difficult part doing a presentation of GNU 
Radio is the data-types, .. and especially these 'complex numbers'.
The problem, or at least for me, is that when you mention 'GNU Radio 
complex numbers', you also have to mention iq-signals, which is a topic 
that is very difficult to explain in 10 seconds to an audience who has 
never seen anything about i/q sampling before.



I have been thinking on how to explain the concept of I/Q signalling in 
just a few lines, e.g. in the context of -say- a workshop on GR.



I have this idea in my head:

Statement:
The main difference between sampling with reals ('floats') and i/q 
sampling with complex numbers, is that the latter does not only provide 
the  instantaneous value (voltage) of a signal at a certain point of 
time, but also includes phase information (i.e. the slope of the signal 
at that point).



To make this visual:
Take half a sine-wave and plot it out for every 45 degrees.
This gives you 5 points: 0 (0 degrees), sqrt(2)/2 (45 degrees), 1 (90 
degrees), sqrt(2)/2 (135 degrees) and 0 (180 degrees).


Now look at the 2nd and the 4th point (45 degrees and 135 degrees), if 
you sample this using only real/float values, these two points are 
exactly the same (sqrt(2)/2). Just based on these values by themselves 
(i.e. remove all other points from the graph), there is no way you can 
tell that at the first point (45 degrees) the graph was going up, while 
at the 135-degrees point the graph was going down.


So, ... what i/q sampling does, is for every point "x", it not only 
provide the value of the graph at that point of time, but also 
information of the slope of the graphs at that time.



This also explains while i/q sampling is done by not just taking the 
value of a signal at point "t", but also at 1/4 period later (which is 
the information you need to determine the 'slope' of that graph at point 
't')



So, ... is this statement correct?

If it is more-or-less correct and it can help provide a basic mental 
image of the concept of i/q sampling, I would be more then happy! :-)





73
kristoff - ON1ARF

Re: Maximum Number of Bins

[Marcus D. Leech]

On 11/02/2020 12:39 PM, Criss Swaim wrote:

Thank you Marcus & Marcus - your insights are greatly appreciated.

I am looking at the suggestions, exp the fft conversion and we are
considering upgrading, but need to see if the system will scale, as is.
BTW, I am maintaining the code and not the original developer, so I am
not familiar with all the pieces, esp. the ones that have been working.
I look at this as an opportunity to dig deeper into GnuRadio.

1) for clarification, we have been running the 3.7 code for 4 -5 years -
not sure when we upgraded to 3.7.9.  The system runs with 2 million fft
bins, but at 3 or 4 million, it fails.  M. Leach has demonstrated that
without our custom block, GnuRadio can process the high bin levels.  I
have run various configurations of our model (without the bin_sub_avg
python block) but I still receive the error.

2) Both of you have mentioned we are using old message queues...Can you
point me to some documentation that explains this. We are using the
blocks.add_const_vff and connect functions to remove background constant
(a numpy array) from the signal stream.  What would be a better
approach? I have not looked at this for several years, so I need to
refresh and this would be a good time to look at alternate options.  It
is bit of a black box for me and I would like to research alternate
approaches as I dig into this process.

using add_const is fine as a way to remove backgrounds.


3) M. Leach: you indicated that the conversions from a
stream->string->numpy array is very inefficient.  Can you point to
another approach to convert a stream to numpy array?  This is done once
every 60 minutes, but still if it could be improved, that would help.

A gnu radio sample stream is already numpy compatible, so turning it into
  a string first (maybe that's what is going into the message queue?) isn't
  necessary.



4) Finally, I have also been looking for a change log for the 3.7 to 3.8
system. Moving from 3.6 to 3.7 was a significant change and was
wondering if 3.7 to 3.8 is the same level of effort for custom blocks.
Also, is there a timeline for 3.9?
I have one application that straddles between 3.7 and 3.9 -- there were 
some gotchas, and
  I'm not going to recommend anyone convert to 3.9 yet.  The 3.7--3.8 
conversion should be

  quite a bit smoother than 3.6 to 3.7



Again, thanks for any guidance.

Criss Swaim
csw...@tpginc.net
cell: 505.301.5701

On 10/31/2020 9:55 AM, Marcus Müller wrote:

Hi Craig, hi Marcus,

Also, just because I need to point that out:

GNU Radio 3.7 is really a legacy series of releases by now. You should
avoid using it for new developments - it's getting harder and harder to
even build it on modern versions of Linux. In fact, a lot of its
dependencies simply don't exist for modern systems anymore.
Developing for 3.7 is hence dangerous in terms of lifetime. That's among
the chief reasons why we released 3.8. Took us long enough!

3.7.9.2 is positively ancient. A 3.7.13.4 or later should be the oldest
version of GNU Radio you work with, even when maintaining old code.

Other than that:


Oct 29 10:45:07 tf kernel: analysis_sink_1[369]: segfault at
7f9c5a7fd000 ip 7f9dd9361d43 sp 7f9c5a48a638 error 6 in
libgnuradio-vandevender.so[7f9dd9336000+4d000]

This really looks like a bug in your code!
These happen easily with the older style msgq that you seem to be using
(we've basically all but removed these in current development versions
of GNU Radio), especially if directly interfacing with Python land,
which has different ideas of object lifetime than your C++ code might
have...
I think a slight reconsideration of your software architecture might
help here, but I've not seen your overall code.


With an FFT size of 2**22 bins.  This took about 20 seconds for the
FFTW3 "planner" to crunch on, but after that, worked
   just fine within the flow-graph.


Not quite 20s for me, but yes, single-threaded FFT performance was about
14 transforms of that size per second, 2 threads allowed for ~23
transforms a second, 4 threads for about 28. Knowing GNU Radio, I'd
recommend you rather stick with a single thread per transform, because
other block also have CPU requirements (if you really want to increase
throughput, deinterleave vectors and have multiple single-threaded FFTs
run in parallel, then recombine after).

Seeing that you you only need 20 MS/s, and 14 transform are 14 · 2²² =
7·2²³ samples a second and that would be roughly 56 MS/s, I think you
are fine. If you're not, get a faster PC, honestly!

Best regards,
Marcus M (the younger Marcus)

On 29.10.20 23:53, Marcus D. Leech wrote:

On 10/29/2020 06:03 PM, Criss Swaim wrote:

we are running version 3.7.9.2


I constructed a simple flow-graph in GR 3.7.13.5

osmosdr_source--->stream-to-vector-->fft-->null-sink

With an FFT size of 2**22 bins.  This took about 20 seconds for the
FFTW3 "planner" to crunch on, but after that, worked
   just fine within the flow-graph.

You should really keep your FFT 

Re: Maximum Number of Bins

[Criss Swaim]

Thank you Marcus & Marcus - your insights are greatly appreciated.

I am looking at the suggestions, exp the fft conversion and we are
considering upgrading, but need to see if the system will scale, as is. 
BTW, I am maintaining the code and not the original developer, so I am
not familiar with all the pieces, esp. the ones that have been working. 
I look at this as an opportunity to dig deeper into GnuRadio.

1) for clarification, we have been running the 3.7 code for 4 -5 years -
not sure when we upgraded to 3.7.9.  The system runs with 2 million fft
bins, but at 3 or 4 million, it fails.  M. Leach has demonstrated that
without our custom block, GnuRadio can process the high bin levels.  I
have run various configurations of our model (without the bin_sub_avg
python block) but I still receive the error.

2) Both of you have mentioned we are using old message queues...Can you
point me to some documentation that explains this. We are using the
blocks.add_const_vff and connect functions to remove background constant
(a numpy array) from the signal stream.  What would be a better
approach? I have not looked at this for several years, so I need to
refresh and this would be a good time to look at alternate options.  It
is bit of a black box for me and I would like to research alternate
approaches as I dig into this process.

3) M. Leach: you indicated that the conversions from a
stream->string->numpy array is very inefficient.  Can you point to
another approach to convert a stream to numpy array?  This is done once
every 60 minutes, but still if it could be improved, that would help.

4) Finally, I have also been looking for a change log for the 3.7 to 3.8
system. Moving from 3.6 to 3.7 was a significant change and was
wondering if 3.7 to 3.8 is the same level of effort for custom blocks. 
Also, is there a timeline for 3.9?

Again, thanks for any guidance.

Criss Swaim
csw...@tpginc.net
cell: 505.301.5701

On 10/31/2020 9:55 AM, Marcus Müller wrote:
> Hi Craig, hi Marcus,
>
> Also, just because I need to point that out:
>
> GNU Radio 3.7 is really a legacy series of releases by now. You should
> avoid using it for new developments - it's getting harder and harder to
> even build it on modern versions of Linux. In fact, a lot of its
> dependencies simply don't exist for modern systems anymore.
> Developing for 3.7 is hence dangerous in terms of lifetime. That's among
> the chief reasons why we released 3.8. Took us long enough!
>
> 3.7.9.2 is positively ancient. A 3.7.13.4 or later should be the oldest
> version of GNU Radio you work with, even when maintaining old code.
>
> Other than that:
>
>> Oct 29 10:45:07 tf kernel: analysis_sink_1[369]: segfault at
>> 7f9c5a7fd000 ip 7f9dd9361d43 sp 7f9c5a48a638 error 6 in
>> libgnuradio-vandevender.so[7f9dd9336000+4d000]
> This really looks like a bug in your code!
> These happen easily with the older style msgq that you seem to be using
> (we've basically all but removed these in current development versions
> of GNU Radio), especially if directly interfacing with Python land,
> which has different ideas of object lifetime than your C++ code might
> have...
> I think a slight reconsideration of your software architecture might
> help here, but I've not seen your overall code.
>
>> With an FFT size of 2**22 bins.  This took about 20 seconds for the
>> FFTW3 "planner" to crunch on, but after that, worked
>>   just fine within the flow-graph.
>>
> Not quite 20s for me, but yes, single-threaded FFT performance was about
> 14 transforms of that size per second, 2 threads allowed for ~23
> transforms a second, 4 threads for about 28. Knowing GNU Radio, I'd
> recommend you rather stick with a single thread per transform, because
> other block also have CPU requirements (if you really want to increase
> throughput, deinterleave vectors and have multiple single-threaded FFTs
> run in parallel, then recombine after).
>
> Seeing that you you only need 20 MS/s, and 14 transform are 14 · 2²² =
> 7·2²³ samples a second and that would be roughly 56 MS/s, I think you
> are fine. If you're not, get a faster PC, honestly!
>
> Best regards,
> Marcus M (the younger Marcus)
>
> On 29.10.20 23:53, Marcus D. Leech wrote:
>> On 10/29/2020 06:03 PM, Criss Swaim wrote:
>>> we are running version 3.7.9.2
>>>
>> I constructed a simple flow-graph in GR 3.7.13.5
>>
>> osmosdr_source--->stream-to-vector-->fft-->null-sink
>>
>> With an FFT size of 2**22 bins.  This took about 20 seconds for the
>> FFTW3 "planner" to crunch on, but after that, worked
>>   just fine within the flow-graph.
>>
>> You should really keep your FFT sizes to a power-of-2, particularly at
>> this size range.  That's not related to your problem
>>   directly, but power-of-2 FFTs have lower computational complexity. 
>> Among other things, the FFTW2 "planner" for
>>   non-power-of-2 FFTs at these eye-watering FFT sizes seems to take a
>> LONG time to compute a "plan".
>>
>> You should probably look at restructuring 

Re: Issue in file sink block

[Marcus Müller]

Again, the file sink is fine.

On 02.11.20 04:39, Maitry Raval wrote:
> Hello,
> 
> I understand, I think, I need to use PSK demod using below link.
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
> 
> But, as I have a requirement of storing the demod data in file , how is it 
> possible using file sink or any other way, please guide. 
> 
> With Best Regards,
> Maitry Raval,
> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "discuss-gnuradio" 
> Sent: Saturday, October 31, 2020 9:06:22 PM
> Subject: Re: Issue in file sink block
> 
> Hi Maitry,
> 
> I doubt it's the file sink. That tutorial used DPSK Mod, and that's
> among the buggy packet_encoder tooling that we deprecated a long time
> ago, and finally banished two-ish years ago. It just dropped data.
> 
> See the more modern packet examples that come with your GNU Radio 3.8.
> 
> Cheers,
> Marcus
> 
> On 31.10.20 09:34, Maitry Raval wrote:
>> Hello ,
>>
>> I am using GNU radio along with ADRV9361-Z7035 Board for data reception
>> and demodulation. I have faced an issue of using file sink block along
>> with QPSK demod blocks. when I am attaching dpsk/PSK demod block with
>> file sink, I have not received data in binary format. it gives some
>> trunk values. when I am doing wrong, please guide us.
>> I have taken a reference of below link.
>> https://courses.washington.edu/ee420/projects/lab2_gnuradio.pdf
>>
>> The only difference is that I am using receiving section only. as I am
>> transmitting from other source. so I have attached fmcommsource block
>> with dpsk demod followed by file sink.
>>
>> Please guide
>>
>> With Best Regards,
>> Maitry Raval,
>> R& D engineer|Azista Industries Pvt Ltd|
>> 079-40605800|www.azistaaerospace.com
> 

Re: Issue in file sink block

[Marcus Müller]

File Sink is fine.

DISCLAIMER: Any attached Code is provided As Is. It has not been tested or 
validated as a product, for use in a deployed application or system, or for use 
in hazardous environments. You assume all risks for use of the Code. Use of the 
Code is subject to terms of the licenses to the UHD or RFNoC code with which 
the Code is used. Standard licenses to UHD and RFNoC can be found at 
https://www.ettus.com/sdr-software/licenses/.

NI will only perform services based on its understanding and condition that the 
goods or services (i) are not for the use in the production or development of 
any item produced, purchased, or ordered by any entity with a footnote 1 
designation in the license requirement column of Supplement No. 4 to Part 744, 
U.S. Export Administration Regulations and (ii) such a company is not a party 
to the transaction.  If our understanding is incorrect, please notify us 
immediately because a specific authorization may be required from the U.S. 
Commerce Department before the transaction may proceed further.

On 02.11.20 04:39, Maitry Raval wrote:
> Hello,
>
> I understand, I think, I need to use PSK demod using below link.
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
>
> But, as I have a requirement of storing the demod data in file , how is it 
> possible using file sink or any other way, please guide. 
>
> With Best Regards,
> Maitry Raval,
> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com
>
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "discuss-gnuradio" 
> Sent: Saturday, October 31, 2020 9:06:22 PM
> Subject: Re: Issue in file sink block
>
> Hi Maitry,
>
> I doubt it's the file sink. That tutorial used DPSK Mod, and that's
> among the buggy packet_encoder tooling that we deprecated a long time
> ago, and finally banished two-ish years ago. It just dropped data.
>
> See the more modern packet examples that come with your GNU Radio 3.8.
>
> Cheers,
> Marcus
>
> On 31.10.20 09:34, Maitry Raval wrote:
>> Hello ,
>>
>> I am using GNU radio along with ADRV9361-Z7035 Board for data reception
>> and demodulation. I have faced an issue of using file sink block along
>> with QPSK demod blocks. when I am attaching dpsk/PSK demod block with
>> file sink, I have not received data in binary format. it gives some
>> trunk values. when I am doing wrong, please guide us.
>> I have taken a reference of below link.
>> https://courses.washington.edu/ee420/projects/lab2_gnuradio.pdf
>>
>> The only difference is that I am using receiving section only. as I am
>> transmitting from other source. so I have attached fmcommsource block
>> with dpsk demod followed by file sink.
>>
>> Please guide
>>
>> With Best Regards,
>> Maitry Raval,
>> R& D engineer|Azista Industries Pvt Ltd|
>> 079-40605800|www.azistaaerospace.com

Re: RTL-SDRV3-GNURadio Comp.-Win10

[gilles rubin]

 Hi Gabriel,
Thanks a lot. I use GNURadio 3.7 but ok.I tryed and change for 0 and 1 the 
device arguments but nothing change.
Thanks anyway !Gil.
Le lundi 2 novembre 2020 à 15:11:37 UTC+1, Gabriel Pinheiro 
 a écrit :  
 
 Hi Gilles,
I've recently bought a RTL-SDR v3 device as well and believe I've had the same 
problem as you on Win10. It worked on SDR# but wasn't recognized on GNURadio 
3.8.
I can't remember where now, but I found a solution that worked both on the 
RTL-SDR Source and the osmocom Source. It requires you to give an input for the 
"Device Arguments" of "rtl=0" in your source block. Alternatively, also try 
"rtl=1", but mine worked with "rtl=0". Hope it helps!

Best regards,
Gabriel Pinheiro

Em dom., 1 de nov. de 2020 às 15:19, Christophe Seguinot 
 escreveu:

  
Hi 
 
 
Which version of GR are you using? 
 
 
If using 3.8.x see here 
:https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00123.html
 
Sincerely, Christophe
 

 
 On 01/11/2020 15:43, gilles rubin wrote:
  

Hello,
 
Maybe could you help me...
 
I’m using a RTL SDRV3, it works well on my laptop (Win10) with SDRSharp, 
RTL1090 etc.. but GNU Radio Companion doesn't recognized it ? 
 
My GNU Radio flowcharts without using RTL SDR as a source works perfectly.
 
I have some initialization trouble with my RTL SDRV3 on my laptop. The driver 
is ok. It looks Python have some troubles, what do you think about it ?
 My RTL-SDRV3 works on my other computer, here (below) you can see the 
difference with the same flowchart on my laptop. 
  Here when it's working 
  
 
  
and here at start the same but at the end, just "done" and nothing about 
RTL2838 ?!
 

   

 
When I use rtl_test.exe, it seems ok.
 
 
 
Thanks for your help.
 
Best regards.
 
Gil.
  
   
 
  

Re: RTL-SDRV3-GNURadio Comp.-Win10

[Gabriel Pinheiro]

Hi Gilles,

I've recently bought a RTL-SDR v3 device as well and believe I've had the
same problem as you on Win10. It worked on SDR# but wasn't recognized on
GNURadio 3.8.

I can't remember where now, but I found a solution that worked both on the
RTL-SDR Source and the osmocom Source. It requires you to give an input for
the "Device Arguments" of "rtl=0" in your source block. Alternatively, also
try "rtl=1", but mine worked with "rtl=0". Hope it helps!

Best regards,

Gabriel Pinheiro


Em dom., 1 de nov. de 2020 às 15:19, Christophe Seguinot <
christophe.segui...@orange.fr> escreveu:

> Hi
>
> Which version of GR are you using?
>
> If using 3.8.x see here :
> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00123.html
>
> Sincerely, Christophe
>
>
> On 01/11/2020 15:43, gilles rubin wrote:
>
> Hello,
>
> Maybe could you help me...
>
> I’m using a RTL SDRV3, it works well on my laptop (Win10) with SDRSharp,
> RTL1090 etc.. but GNU Radio Companion doesn't recognized it ?
>
> My GNU Radio flowcharts without using RTL SDR as a source works perfectly.
>
> I have some initialization trouble with my RTL SDRV3 on my laptop. The
> driver is ok. It looks Python have some troubles, what do you think about
> it ?
> My RTL-SDRV3 works on my other computer, here (below) you can see the
> difference with the same flowchart on my laptop.
>
> Here when it's working
>
> [image: Image en ligne]
>
> and here at start the same but at the end, just "done" and nothing about
> RTL2838 ?!
>
>  [image: Image en ligne]
>
> When I use rtl_test.exe, it seems ok.
>
>
>
> Thanks for your help.
>
> Best regards.
>
> Gil.
>
>