Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Piotr Krysik]

Hi Juha,

It wouldn't be as simple as it was for me as a developer and as it
(hopefully) is for the end user without your hardware mod.

Can you say something more about the residual center frequency
difference? Where might it come from? I prepared little test of
coherency between the receivers (multi-rtl/examples/test_multirtl.m).
Among all the figures that it shows there is a plot of relative phase
offset of signals coming from the receivers. In fact I have seen linear
phase change on that plot - that corresponds to some central frequency
offset. If I know what is the source of this offset maybe I will be able
to find some way to fix it in software.

--
Piotr

W dniu 25.05.2016 o 08:24, Juha Vierinen pisze:
> This is awesome! I'll definitely try this out soon. I use one off
> python scripts to find the sample offset and the small residual center
> frequency difference. This simplifies the process significantly. 
>
> This should make it much easier to implement a passive radar block, or
> an interferometry block. 
>
> juha
>
> On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik  > wrote:
>
> Hi all,
>
> I want to announce new GNU Radio related project prepared by me -
> Multi-rtl:
> https://github.com/ptrkrysik/multi-rtl
>
> It is a Gnu Radio block that combines multiple RTL-SDR receivers into
> one multi-channel receiver.
>
> Only hardware modification to RTL-SDR dongles required is connecting
> them to a common clock source (i.e. one of the dongles' oscillator as
> Juha Verinen showed once). Each channel can work on a different
> central
> frequency.
>
> Everyone who wants to know how it was achieved is invited to read my
> github page:
>
> https://ptrkrysik.github.io
>
> Best Regards,
> Piotr Krysik
>
> ___
> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[jean-michel.friedt]

>From our own experience with dual-dongle measurements, the phase drift
seems to be strongly related to R820T(2) temperature. We reduced significantly
the phase drift by gluing a large heat sink common to both chips on both
dongles, without completely removing this effect (we aim at measurements lasting
multiple hours). At the moment the only option we could think of (mail to this
mailing list dated 28 May 2015) is switching to a reference clock to calibrate
for the phase difference between the local oscillators, but the actual cause
of the drift remains a mistery (probably due to the implementation of the PLL,
but I cannot understand why Phase Locked Loops would drift in Phase !).

JM

> It wouldn't be as simple as it was for me as a developer and as it
> (hopefully) is for the end user without your hardware mod.
> 
> Can you say something more about the residual center frequency
> difference? Where might it come from? I prepared little test of
> coherency between the receivers (multi-rtl/examples/test_multirtl.m).
> Among all the figures that it shows there is a plot of relative phase
> offset of signals coming from the receivers. In fact I have seen linear
> phase change on that plot - that corresponds to some central frequency
> offset. If I know what is the source of this offset maybe I will be able
> to find some way to fix it in software.
> 
> --
> Piotr
> 
> W dniu 25.05.2016 o 08:24, Juha Vierinen pisze:
> > This is awesome! I'll definitely try this out soon. I use one off
> > python scripts to find the sample offset and the small residual center
> > frequency difference. This simplifies the process significantly. 
> >
> > This should make it much easier to implement a passive radar block, or
> > an interferometry block. 
> >
> > juha
> >
> > On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik  > > wrote:
> >
> > Hi all,
> >
> > I want to announce new GNU Radio related project prepared by me -
> > Multi-rtl:
> > https://github.com/ptrkrysik/multi-rtl
> >
> > It is a Gnu Radio block that combines multiple RTL-SDR receivers into
> > one multi-channel receiver.
> >
> > Only hardware modification to RTL-SDR dongles required is connecting
> > them to a common clock source (i.e. one of the dongles' oscillator as
> > Juha Verinen showed once). Each channel can work on a different
> > central
> > frequency.
> >
> > Everyone who wants to know how it was achieved is invited to read my
> > github page:
> >
> > https://ptrkrysik.github.io
> >
> > Best Regards,
> > Piotr Krysik
> >
> > ___
> > 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


-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 
Besancon, France

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

Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Sylvain Munaut]

Hi,

> of the drift remains a mistery (probably due to the implementation of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !).

If the phase comparator is digital ( i.e. a XOR ) and the input clock
is somewhat analog, the gate thresholds might vary depending on
temperature, thus shifting the cycle a bit.

Just a thought.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Juha Vierinen]

In my testing, this phase rate difference seemed constant and I could
simply calibrate it out by looking at the phase rate term estimated from
the phase of the cross-correlated noise. The samples stay aligned for
hours, so the issue is caused by the tuner or the DDC. One theory that I
had was that the multi-rtl driver somehow sets up the dongles differently,
but I never got around to looking at the code.

I think this was the script I used to figure out what the phase drift was:
https://github.com/jvierine/chirpsounder/blob/master/apps/passive_radar/rnoise.py

Here's the IQ plot to prove that the cross correlated phase is stable over
6000 seconds:

http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html

juha

On Wed, May 25, 2016 at 12:14 PM,  wrote:

> From our own experience with dual-dongle measurements, the phase drift
> seems to be strongly related to R820T(2) temperature. We reduced
> significantly
> the phase drift by gluing a large heat sink common to both chips on both
> dongles, without completely removing this effect (we aim at measurements
> lasting
> multiple hours). At the moment the only option we could think of (mail to
> this
> mailing list dated 28 May 2015) is switching to a reference clock to
> calibrate
> for the phase difference between the local oscillators, but the actual
> cause
> of the drift remains a mistery (probably due to the implementation of the
> PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !).
>
> JM
>
> > It wouldn't be as simple as it was for me as a developer and as it
> > (hopefully) is for the end user without your hardware mod.
> >
> > Can you say something more about the residual center frequency
> > difference? Where might it come from? I prepared little test of
> > coherency between the receivers (multi-rtl/examples/test_multirtl.m).
> > Among all the figures that it shows there is a plot of relative phase
> > offset of signals coming from the receivers. In fact I have seen linear
> > phase change on that plot - that corresponds to some central frequency
> > offset. If I know what is the source of this offset maybe I will be able
> > to find some way to fix it in software.
> >
> > --
> > Piotr
> >
> > W dniu 25.05.2016 o 08:24, Juha Vierinen pisze:
> > > This is awesome! I'll definitely try this out soon. I use one off
> > > python scripts to find the sample offset and the small residual center
> > > frequency difference. This simplifies the process significantly.
> > >
> > > This should make it much easier to implement a passive radar block, or
> > > an interferometry block.
> > >
> > > juha
> > >
> > > On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik  > > > wrote:
> > >
> > > Hi all,
> > >
> > > I want to announce new GNU Radio related project prepared by me -
> > > Multi-rtl:
> > > https://github.com/ptrkrysik/multi-rtl
> > >
> > > It is a Gnu Radio block that combines multiple RTL-SDR receivers
> into
> > > one multi-channel receiver.
> > >
> > > Only hardware modification to RTL-SDR dongles required is
> connecting
> > > them to a common clock source (i.e. one of the dongles' oscillator
> as
> > > Juha Verinen showed once). Each channel can work on a different
> > > central
> > > frequency.
> > >
> > > Everyone who wants to know how it was achieved is invited to read
> my
> > > github page:
> > >
> > > https://ptrkrysik.github.io
> > >
> > > Best Regards,
> > > Piotr Krysik
> > >
> > > ___
> > > 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
>
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000
> Besancon, France
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Marcus Müller]

That, or simply, the output clock VCO changes its reaction to the
control voltage under certain circumstances (temperature, frequency) so
much that the control loop loses the ability to reach stationary
exactness (e.g. due to natural limits on the magnitude of the VCO
voltage). These devices definitely were made with cost in mind – not
with maximum reliability, and hence I can believe that for example with
the Elonics E4000 tuner, the charge pump used to generate the VCO
voltage simply might deteriorate with temperature.

Cheers,
Marcus

On 25.05.2016 14:25, Sylvain Munaut wrote:
> Hi,
>
>> of the drift remains a mistery (probably due to the implementation of the 
>> PLL,
>> but I cannot understand why Phase Locked Loops would drift in Phase !).
> If the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
>
> Just a thought.
>
> Cheers,
>
> Sylvain
>
> ___
> 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] Doubt with file sink with ofdm and CC

[Jose Perez]

Well, I resolved the second point... just put a Unpack K Bits after the File
Source block and then a Pack K Bits block before the File Sink block.


Someone could help me in the first question? The file that I received get a
lot of wrong information with just virtual transmittion... there is no noise
to justify this problem. 

Thank you again.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Doubt-with-file-sink-with-ofdm-and-CC-tp60156p60178.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] Doubt with file sink with ofdm and CC

[Marcus Müller]

Hi Jose,

could you explain the problem a bit more in-depth? I'm afraid I'm not
really understanding.

By the way, if you sign up to the mailing list directly [1], you could
directly attach the "saved to image file" (file->screen capture in GRC)
output so that we can understand what you're doing.

This time delay, why is it a problem? Is it a multiple of the number of
symbols per OFDM symbol?

Best regards,
Marcus


[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 25.05.2016 14:48, Jose Perez wrote:
> Well, I resolved the second point... just put a Unpack K Bits after the File
> Source block and then a Pack K Bits block before the File Sink block.
>
>
> Someone could help me in the first question? The file that I received get a
> lot of wrong information with just virtual transmittion... there is no noise
> to justify this problem. 
>
> Thank you again.
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Doubt-with-file-sink-with-ofdm-and-CC-tp60156p60178.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] [GSoC] gr-inspector update / ask for feedback

[Ben Hilburn]

Hi Sebastian -

Thanks so much for the great update! I have two questions:

You mentioned in your blog post that all adjacent bins will be interpreted
as one signal in your detection block, which then gets passed downstream to
the analysis portion of your design. Can you comment on how this might be
affected by multi-carrier systems, especially if the user has selected a
bin count high enough to push apart the carriers?

You also mentioned the ability to analyze past signals in a waterfall plot.
In this workflow, would you basically be playing back a recorded file and
doing off-line analysis?

It looks like things are coming along really nicely. Great mock-ups, by the
way!

Cheers,
Ben

On Fri, May 20, 2016 at 6:31 AM, Sebastian Müller  wrote:

> Hey list,
>
> there are some news regarding the gr-inspector toolbox, please check out
> my blog if you’re interested:
> https://grinspector.wordpress.com/
>
> The strategy for the first big task, signal detection, is nearly finished
> thanks to the great feedback from my mentors. But still, there are some
> questions remaining on which I would love to get feedback from the
> community. The explicit questions are at the end of the newest blog post.
>
> Beginning with the coding period on monday, weekly updates will be
> published on the blog along with a short mail on the list. Stay tuned!
>
> Cheers,
> Sebastian
>
> ___
> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

There are a couple of issues with the rtlsdr driver used by gr-osmocom
in this regard: 

  (A) The charge-pump loop current is too constrained for the higher
frequencies 

  (B) The "dither" option appears to have a bias that causes a (small)
frequency offset. 

The driver that AirSpy uses fixes both of these, although without
"dither", the tuning granularity is worse.  Not sure this matters. 

On 2016-05-25 09:28, Marcus Müller wrote:

> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind - not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
> 
> Cheers,
> Marcus
> 
> On 25.05.2016 14:25, Sylvain Munaut wrote: Hi,
> 
> of the drift remains a mistery (probably due to the implementation of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !). If 
> the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
> 
> Just a thought.
> 
> Cheers,
> 
> Sylvain
> 
> ___
> 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

[Discuss-gnuradio] GRCon16 Update

[Ben Hilburn]

Hey all -

Planning for GRCon16 continues to go well, and we are looking forward to
another great conference year. Some quick notes:

The current deadline to submit an abstract for a talk is one week from
today, next Wednesday the 1st of June. If you haven't submitted your
abstract yet, please send it as soon as possible! We would like to start
putting together the conference program, and getting everyone's talk
abstracts is obviously a critical part of that.

We have sold 25% of the 304 available seats in the conference, which is
ahead of schedule relative to previous years. We are also ahead of schedule
in sponsorship, and there are only a few spaces left at the levels that
give you a booth.

This year's Dev Summit (the last day) will be a bit different from previous
years. There will be organized talks / walk-through sessions, in addition
to the usual "get into a group and hack". If you haven't attended the Dev
Summit in previous years because you didn't feel ready to jump into code,
we think you'll be very happy with the schedule we are putting together for
this year's Dev Summit.

Please let me know if you have any questions, and otherwise, get those
abstracts in! Thanks, and see you in Colorado.

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

Re: [Discuss-gnuradio] Doubt with file sink with ofdm and CC

[Jose Perez]

Hi Marcus!

Thank you for you reply!

So I am trying to make a OFDM system with and without codification (CC
code)... for this I am using these flowgraphs (simpleOFDM.png and
CodeOFDM.png)


The problem that I saw is: If I use just codification without  modulation
(just to try), the output scope is the same as the input (in this case, I
am using a square waveform).
And when I use just OFDM modulation, the output signal looks stay with a
time delay and also looks not be constant during the whole simulation (see
pics OFDMscope and OFDM2.png).

And when I use CC code + OFDM, I also have a delayed time signal and
sometimes with a lot of wrong peaks but I don't insert on the simulation
any noise signal or use some USRP to transmit and receive through the air.
(see pics OFDM+CC_1 and OFDM+CC_2.png).

after it, I am trying to transmit a CSV or TXT file with both situation
(just OFDM and OFDM+CC code) to compare the results... but as I can check
for now, the situation with OFDM+CC code get a lot of wrong information as
without code... It should be the other way, isn't it?

I hope I made it clear

Thanks!
José





2016-05-25 10:01 GMT-03:00 Marcus Müller-3 [via GnuRadio] <
ml-node+s4n60179...@n7.nabble.com>:

> Hi Jose,
>
> could you explain the problem a bit more in-depth? I'm afraid I'm not
> really understanding.
>
> By the way, if you sign up to the mailing list directly [1], you could
> directly attach the "saved to image file" (file->screen capture in GRC)
> output so that we can understand what you're doing.
>
> This time delay, why is it a problem? Is it a multiple of the number of
> symbols per OFDM symbol?
>
> Best regards,
> Marcus
>
>
> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> On 25.05.2016 14:48, Jose Perez wrote:
>
> > Well, I resolved the second point... just put a Unpack K Bits after the
> File
> > Source block and then a Pack K Bits block before the File Sink block.
> >
> >
> > Someone could help me in the first question? The file that I received
> get a
> > lot of wrong information with just virtual transmittion... there is no
> noise
> > to justify this problem.
> >
> > Thank you again.
> >
> >
> >
> > --
> > View this message in context:
> http://gnuradio.4.n7.nabble.com/Doubt-with-file-sink-with-ofdm-and-CC-tp60156p60178.html
> > Sent from the GnuRadio mailing list archive at Nabble.com.
> >
> > ___
> > Discuss-gnuradio mailing list
> > [hidden email] 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> [hidden email] 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://gnuradio.4.n7.nabble.com/Doubt-with-file-sink-with-ofdm-and-CC-tp60156p60179.html
> To unsubscribe from Doubt with file sink with ofdm and CC, click here
> 
> .
> NAML
> 
>



-- 
.: José Perez Jr


simpleOFDM (65K) 
CodeOFDM (105K) 
OFDMscope (67K) 
OFDMscope2 (68K) 
OFDM+CC_1 (69K) 
OFDM+CC_2 (67K) 




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Doubt-with-file-sink-with-ofdm-and-CC-tp60156p60183.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] [VOLK] VOLK website license

[Marcus Müller]

Hi Raj,

Ben is absolutely right. Feel free to use the logo in your presentations.

Rationale: I made that logo so that people could associate something
visible with VOLK. Now, having a logo that no-one uses is pretty much
stupid, hence, you should feel more than welcome to use it, especially
when talking about GR, VOLK, FOSS DSP & SDR, SIMD etc.

The only thing that I don't want to happen with that logo is that
someone takes it, slaps it onto his product/website/… and (inherently)
claims he "owns" VOLK. So, mandatory attribution is totally sufficient
to solve that issue.

Hence, I put that logo under CC-by-SA;
http://creativecommons.org/licenses/by-sa/4.0/ , so: use it as much as
you want, as long as you refer to libvolk.org as source.

Cheers,
Marcus


On 25.05.2016 02:08, Ben Hilburn wrote:
> Hi Raj -
>
> Thanks so much for checking! We really appreciate it. Yes, you may use
> the logo for that purpose.
>
> We intend to get a page up on the new website that clearly lays out
> the various licenses used for GNU Radio IP, but haven't gotten around
> to it, yet. Your e-mail is a good example of why this would be helpful.
>
> I will also be at the Symposium next week. I look forward to meeting you!
>
> Cheers,
> Ben
>
> On Tue, May 24, 2016 at 6:55 PM, Raj Bhattacharjea  > wrote:
>
> Marcus,
>
> I'm not doing anything sinister :-)
>
> I'm just using it on a slide talking about VOLK. Even if it's for
> the purposes of comment, scholarship, teaching, and research, I
> try to do my due diligence to give proper attribution in such
> talks and just noticed the CC license discrepancy.
>
> See attached for the slide. It's part of a talk to be given here
> https://wireless.vt.edu/agenda.html and I'm looking forward to
> meeting your some of your Ettus colleagues who will be attending.
>
> -- 
> Raj Bhattacharjea, PhD
> Georgia Tech Research Institute
> Information and Communications Laboratory
> http://www.prism.gatech.edu/~rb288/
> 
> 404.407.6622 
>
> ___
> 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] [VOLK] VOLK website license

[Marcus Müller]

Forgot to mention: of course I feel flattered by you mentioning me as
copyright holder, but I'd rather see you use the VOLK project as source.
I made that "being a part of the project" :)

Cheers,
marcus

On 25.05.2016 17:20, Marcus Müller wrote:
> Hi Raj,
>
> Ben is absolutely right. Feel free to use the logo in your presentations.
>
> Rationale: I made that logo so that people could associate something
> visible with VOLK. Now, having a logo that no-one uses is pretty much
> stupid, hence, you should feel more than welcome to use it, especially
> when talking about GR, VOLK, FOSS DSP & SDR, SIMD etc.
>
> The only thing that I don't want to happen with that logo is that
> someone takes it, slaps it onto his product/website/… and (inherently)
> claims he "owns" VOLK. So, mandatory attribution is totally sufficient
> to solve that issue.
>
> Hence, I put that logo under CC-by-SA;
> http://creativecommons.org/licenses/by-sa/4.0/ , so: use it as much as
> you want, as long as you refer to libvolk.org as source.
>
> Cheers,
> Marcus
>
>
> On 25.05.2016 02:08, Ben Hilburn wrote:
>> Hi Raj -
>>
>> Thanks so much for checking! We really appreciate it. Yes, you may
>> use the logo for that purpose.
>>
>> We intend to get a page up on the new website that clearly lays out
>> the various licenses used for GNU Radio IP, but haven't gotten around
>> to it, yet. Your e-mail is a good example of why this would be helpful.
>>
>> I will also be at the Symposium next week. I look forward to meeting you!
>>
>> Cheers,
>> Ben
>>
>> On Tue, May 24, 2016 at 6:55 PM, Raj Bhattacharjea > > wrote:
>>
>> Marcus,
>>
>> I'm not doing anything sinister :-)
>>
>> I'm just using it on a slide talking about VOLK. Even if it's for
>> the purposes of comment, scholarship, teaching, and research, I
>> try to do my due diligence to give proper attribution in such
>> talks and just noticed the CC license discrepancy.
>>
>> See attached for the slide. It's part of a talk to be given here
>> https://wireless.vt.edu/agenda.html and I'm looking forward to
>> meeting your some of your Ettus colleagues who will be attending.
>>
>> -- 
>> Raj Bhattacharjea, PhD
>> Georgia Tech Research Institute
>> Information and Communications Laboratory
>> http://www.prism.gatech.edu/~rb288/
>> 
>> 404.407.6622 
>>
>> ___
>> 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] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Piotr Krysik]

Hi Marcus,

I don't know much about AirSpy.

Does it use the same demodulator chip as current RTL-SDR dongles?
And does it mean that change to low level part of rtlsdr driver might
help to get rid of that frequency offset?

--
Piotr

W dniu 25.05.2016 o 16:35, mle...@ripnet.com pisze:
>
> There are a couple of issues with the rtlsdr driver used by gr-osmocom
> in this regard:
>
>  
>
>   (A) The charge-pump loop current is too constrained for the higher
> frequencies
>
>   (B) The "dither" option appears to have a bias that causes a (small)
> frequency offset.
>
>  
>
> The driver that AirSpy uses fixes both of these, although without
> "dither", the tuning granularity is worse.  Not sure this matters.
>
>  
>
>  
>
>  
>
> On 2016-05-25 09:28, Marcus Müller wrote:
>
>> That, or simply, the output clock VCO changes its reaction to the
>> control voltage under certain circumstances (temperature, frequency) so
>> much that the control loop loses the ability to reach stationary
>> exactness (e.g. due to natural limits on the magnitude of the VCO
>> voltage). These devices definitely were made with cost in mind – not
>> with maximum reliability, and hence I can believe that for example with
>> the Elonics E4000 tuner, the charge pump used to generate the VCO
>> voltage simply might deteriorate with temperature.
>>
>> Cheers,
>> Marcus
>>
>> On 25.05.2016 14:25, Sylvain Munaut wrote:
>>> Hi,
>>>
 of the drift remains a mistery (probably due to the implementation
 of the PLL,
 but I cannot understand why Phase Locked Loops would drift in Phase !).
>>> If the phase comparator is digital ( i.e. a XOR ) and the input clock
>>> is somewhat analog, the gate thresholds might vary depending on
>>> temperature, thus shifting the cycle a bit.
>>>
>>> Just a thought.
>>>
>>> Cheers,
>>>
>>> Sylvain
>>>
>>> ___


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

Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[mleech]

The AirSpy uses the R820T2 chip for the tuner, but a different
sampling/DSP "engine". 

Yes, making the charge-pump and "dither" mods will help with
phase-coherence. 

Somebody needs to "own" the rtlsdr driver, and merge in the last couple
of years of field experience and branching that has gone on with it. 

On 2016-05-25 15:04, Piotr Krysik wrote:

> Hi Marcus,
> 
> I don't know much about AirSpy.
> 
> Does it use the same demodulator chip as current RTL-SDR dongles?
> And does it mean that change to low level part of rtlsdr driver might
> help to get rid of that frequency offset?
> 
> --
> Piotr
> 
> W dniu 25.05.2016 o 16:35, mle...@ripnet.com pisze: 
> There are a couple of issues with the rtlsdr driver used by gr-osmocom
> in this regard:
> 
> (A) The charge-pump loop current is too constrained for the higher
> frequencies
> 
> (B) The "dither" option appears to have a bias that causes a (small)
> frequency offset.
> 
> The driver that AirSpy uses fixes both of these, although without
> "dither", the tuning granularity is worse.  Not sure this matters.
> 
> On 2016-05-25 09:28, Marcus Müller wrote:
> 
> That, or simply, the output clock VCO changes its reaction to the
> control voltage under certain circumstances (temperature, frequency) so
> much that the control loop loses the ability to reach stationary
> exactness (e.g. due to natural limits on the magnitude of the VCO
> voltage). These devices definitely were made with cost in mind - not
> with maximum reliability, and hence I can believe that for example with
> the Elonics E4000 tuner, the charge pump used to generate the VCO
> voltage simply might deteriorate with temperature.
> 
> Cheers,
> Marcus
> 
> On 25.05.2016 14:25, Sylvain Munaut wrote: Hi,
> 
> of the drift remains a mistery (probably due to the implementation
> of the PLL,
> but I cannot understand why Phase Locked Loops would drift in Phase !). If 
> the phase comparator is digital ( i.e. a XOR ) and the input clock
> is somewhat analog, the gate thresholds might vary depending on
> temperature, thus shifting the cycle a bit.
> 
> Just a thought.
> 
> Cheers,
> 
> Sylvain
> 
> ___

___
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] [PyBOMBS] Need your help!

[Richard Bell]

I just installed GR using Pybombs on a fresh Ubuntu 16.04 (16.04 not 14.04)
with no problems.

Rich

On Tue, May 24, 2016 at 5:30 PM, Ben Hilburn  wrote:

> Hi all -
>
> Some great discussion here.
>
> We have talked about adding a "dry-run" option to PyBOMBS a couple of
> times in the past. It sounds like a number of folks think it would be
> useful, here, too.
>
> With regard to using PyBOMBS on 'antiquated' OSes - one of the original
> purposes of PyBOMBS, actually, was to make it easier to maintain GNU Radio
> installations on these old OSes. I believe at its inception PyBOMBS needed
> to support RHEL4, actually.
>
> How long we should support otherwise obsolete OSes is a conversation worth
> having. There are enough users that need to build on legacy systems that I
> think it's an important function to consider.
>
> Cheers,
> Ben
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Custom OOT Module Install Ubuntu 16.04

[Richard Bell]

I'm trying to compile one of my custom OOT modules on this new Ubuntu 16.04
install and I wonder if I'm having compatibility issues. I'm getting what
looks like cmake issues that cause make to error out. I made sure to feed
the prefix location into cmake. There are warnings that I'm not used to
seeing in the cmake output. make says it can't find a few required
libraries that cmake reported it found. Here is the full cmake and make
output:

rbell@rbell:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
-- The CXX compiler identification is GNU 5.3.1
-- The C compiler identification is GNU 5.3.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'cppunit'
--   Found cppunit, version 1.13.2
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11")
Checking for GNU Radio Module: RUNTIME
-- Checking for module 'gnuradio-runtime'
--   Found gnuradio-runtime, version 3.7.10git
 * INCLUDES=/home/rbell/Documents/grprefix/include
 *
LIBS=/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
-- Found GNURADIO_RUNTIME:
/home/rbell/Documents/grprefix/lib/libgnuradio-runtime.so;/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so

GNURADIO_RUNTIME_FOUND = TRUE
CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the
cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target
  "test-add_tagged_stream_once".  Use the target name directly with
  add_custom_command, or use the generator expression $, as
  appropriate.

Call Stack (most recent call first):
  lib/CMakeLists.txt:79 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- 
-- Checking for module SWIG
-- Found SWIG version 2.0.12.
-- Found SWIG: /usr/bin/swig2.0
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
suitable version "2.7.11+", minimum required is "2")
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.11",
minimum required is "2")
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of size_t
-- Check size of size_t - done
-- Check size of unsigned int
-- Check size of unsigned int - done
-- Check size of unsigned long
-- Check size of unsigned long - done
-- Check size of unsigned long long
-- Check size of unsigned long long - done
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the
cmake_policy
  command to set the policy and suppress this warning.

  The LOCATION property should not be read from target
  "gnuradio-add_tagged_stream_once".  Use the target name directly with
  add_custom_command, or use the generator expression $, as
  appropriate.

Call Stack (most recent call first):
  python/CMakeLists.txt:44 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0045 is not set: Error on non-existent target in
  get_target_property.  Run "cmake --help-policy CMP0045" for policy
details.
  Use the cmake_policy command to set the policy and suppress this warning.

  get_target_property() called with non-existent target "/usr/bin/python2".
Call Stack (most recent call first):
  python/CMakeLists.txt:44 (GR_ADD_TEST)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/home/rbell/Documents/grprefix/lib/cmake/gnuradio/GrTest.cmake:45
(get_target_property):
  Policy CMP0045 is not set: Error on non-existent target i

[Discuss-gnuradio] Why add d_nbits two times at ofdm_mapper_bcv ?

[SangHyuk Kim]

Hi all,

I'm tracing how OFDM modulation is done by /ofdm/benchmark_tx.py.

The file, ofdm.py indicates ofdm modulation is composed of like :

modulation - mapper - preamble - IFFT - CP - scale
|- mapper - preamble -|

And I have a question at ofdm_mapper_bcv.

In ofdm_mapper_bcv_impl::work, I can find making symbol part :


*while(..){*

*if((8-d_bit_offset) >= d_nbits) {*




*bits = ((1 << d_nbits)-1) & (d_msgbytes >> d_bit_offset);d_bit_offset +=
d_nbits;d_bit_offset += d_nbits;out[d_subcarrier_map[i]] =
d_constellation[bits];*

*}*


*}*
For example, using BPSK :
- d_nbits = 1
- d_msgbytes = 94 (0101 1110)

1st loop:
- bits = ( 0001) & (0101 1110) = 0  // takes right-most bit
- d_bit_offset = 2
- out[..] = d_constellation[0]

2nd loop:
- bits = ( 0001) & (0001 0111) = 1
- d_bit_offset = 4
- out[..] = d_constellation[1]

3rd & 4th same like above.

In this example, it just takes odd parts of byte (0, 1, 1, 1).

How can receiver deduce even part (1, 1, 0, 0) ?

I don't know why *d_bit_offset += d_nbits* double times, not an one.

Is this related with two mapping & preamble blocks ? (I/Q ch?)

If right, these two mapping handle even or odd part of byte respectively ?

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

[Discuss-gnuradio] some problem about benchmark_tx & benchmark_rx

[Ekko]

hello all
i am using the example of /gr-digital/examples/narrowbands
the benchmark_tx.py and the benchmark_rx.py ,and my devices are two B210
these is my command:
sudo ./benchmark_tx.py -f 175e6 -m bpsk --bitrate 500e3 --tx-gain 60
another computer
sudo ./benchmark_rx.py -f 175e6 -m bpsk --bitrate 500e3 --rx-gain 30

and the result is if i start the rx at first ,then start the tx ,the rx
will recieve nothing ,
if i start the tx at first,then start the rx when the tx is running,the rx
program will recieve the data,

is there someone meet the same problem?and why i start the rx at first then
start the tx, the program will recieve nothing(this means no output in
command line)?


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

Re: [Discuss-gnuradio] Why add d_nbits two times at ofdm_mapper_bcv ?

[SangHyuk Kim]

Dear all,

Sorry, my source code was wrong.

There is only one

*d_bit_offset += d_nbits;*

*Thanks .*

2016-05-26 10:38 GMT+09:00 SangHyuk Kim :

> Hi all,
>
> I'm tracing how OFDM modulation is done by /ofdm/benchmark_tx.py.
>
> The file, ofdm.py indicates ofdm modulation is composed of like :
>
> modulation - mapper - preamble - IFFT - CP - scale
> |- mapper - preamble -|
>
> And I have a question at ofdm_mapper_bcv.
>
> In ofdm_mapper_bcv_impl::work, I can find making symbol part :
>
>
> *while(..){*
>
> *if((8-d_bit_offset) >= d_nbits) {*
>
>
>
>
> *bits = ((1 << d_nbits)-1) & (d_msgbytes >> d_bit_offset);d_bit_offset +=
> d_nbits;d_bit_offset += d_nbits;out[d_subcarrier_map[i]] =
> d_constellation[bits];*
>
> *}*
>
>
> *}*
> For example, using BPSK :
> - d_nbits = 1
> - d_msgbytes = 94 (0101 1110)
>
> 1st loop:
> - bits = ( 0001) & (0101 1110) = 0  // takes right-most bit
> - d_bit_offset = 2
> - out[..] = d_constellation[0]
>
> 2nd loop:
> - bits = ( 0001) & (0001 0111) = 1
> - d_bit_offset = 4
> - out[..] = d_constellation[1]
>
> 3rd & 4th same like above.
>
> In this example, it just takes odd parts of byte (0, 1, 1, 1).
>
> How can receiver deduce even part (1, 1, 0, 0) ?
>
> I don't know why *d_bit_offset += d_nbits* double times, not an one.
>
> Is this related with two mapping & preamble blocks ? (I/Q ch?)
>
> If right, these two mapping handle even or odd part of byte respectively ?
>
> Thanks.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multi-rtl - making multi-channel receiver out of multiple RTL-SDR dongles

[Piotr Krysik]

Juha,

What type of demodulator did you have in the dongles used for the test?

--
Piotr

W dniu 25.05.2016 o 14:46, Juha Vierinen pisze:
> In my testing, this phase rate difference seemed constant and I could
> simply calibrate it out by looking at the phase rate term estimated
> from the phase of the cross-correlated noise. The samples stay aligned
> for hours, so the issue is caused by the tuner or the DDC. One theory
> that I had was that the multi-rtl driver somehow sets up the dongles
> differently, but I never got around to looking at the code. 
>
> I think this was the script I used to figure out what the phase drift was:
> https://github.com/jvierine/chirpsounder/blob/master/apps/passive_radar/rnoise.py
>
> Here's the IQ plot to prove that the cross correlated phase is stable
> over 6000 seconds:
>
> http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
>
> juha
>
> On Wed, May 25, 2016 at 12:14 PM,  > wrote:
>
> From our own experience with dual-dongle measurements, the phase drift
> seems to be strongly related to R820T(2) temperature. We reduced
> significantly
> the phase drift by gluing a large heat sink common to both chips
> on both
> dongles, without completely removing this effect (we aim at
> measurements lasting
> multiple hours). At the moment the only option we could think of
> (mail to this
> mailing list dated 28 May 2015) is switching to a reference clock
> to calibrate
> for the phase difference between the local oscillators, but the
> actual cause
> of the drift remains a mistery (probably due to the implementation
> of the PLL,
> but I cannot understand why Phase Locked Loops would drift in
> Phase !).
>
> JM
>
> > It wouldn't be as simple as it was for me as a developer and as it
> > (hopefully) is for the end user without your hardware mod.
> >
> > Can you say something more about the residual center frequency
> > difference? Where might it come from? I prepared little test of
> > coherency between the receivers
> (multi-rtl/examples/test_multirtl.m).
> > Among all the figures that it shows there is a plot of relative
> phase
> > offset of signals coming from the receivers. In fact I have seen
> linear
> > phase change on that plot - that corresponds to some central
> frequency
> > offset. If I know what is the source of this offset maybe I will
> be able
> > to find some way to fix it in software.
> >
> > --
> > Piotr
> >
> > W dniu 25.05.2016 o 08:24, Juha Vierinen pisze:
> > > This is awesome! I'll definitely try this out soon. I use one off
> > > python scripts to find the sample offset and the small
> residual center
> > > frequency difference. This simplifies the process significantly.
> > >
> > > This should make it much easier to implement a passive radar
> block, or
> > > an interferometry block.
> > >
> > > juha
> > >
> > > On Tue, May 24, 2016 at 4:03 PM, Piotr Krysik  
> > > >> wrote:
> > >
> > > Hi all,
> > >
> > > I want to announce new GNU Radio related project prepared
> by me -
> > > Multi-rtl:
> > > https://github.com/ptrkrysik/multi-rtl
> > >
> > > It is a Gnu Radio block that combines multiple RTL-SDR
> receivers into
> > > one multi-channel receiver.
> > >
> > > Only hardware modification to RTL-SDR dongles required is
> connecting
> > > them to a common clock source (i.e. one of the dongles'
> oscillator as
> > > Juha Verinen showed once). Each channel can work on a
> different
> > > central
> > > frequency.
> > >
> > > Everyone who wants to know how it was achieved is invited
> to read my
> > > github page:
> > >
> > > https://ptrkrysik.github.io
> > >
> > > Best Regards,
> > > Piotr Krysik
> > >
> > > ___
> > > 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
>
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de
> l'Epitaphe, 25000 Besancon, France
>
>


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