Re: [Discuss-gnuradio] GRC Reacting Slowly

[Marcus Müller]

Hi Richard,

I'll pitch `perf` here (you're on Ubuntu, so it's in the linux-tools,
probably).
Build GNU Radio with the debugging symbols enabled, i.e. call CMake with
the build type specified:

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ..

Then, allow normal users to sniff around processes' calls:

sudo sysctl kernel/perf_event_paranoid=-1   

Run GRC to see where time is spent (-a is for "all CPUs")

perf record -a gnuradio-companion

play around in GRC. Close it and interpret the result as shown by

perf report

Greetings,
Marcus

On 05/28/2015 01:17 AM, Richard Bell wrote:
> Andreas,
>
> No I'm not using an embedded system to develop on. I'm using an HP
> Core i7 laptop with 16Gig of RAM, Ubuntu 14.04 with GNU Radio 3.7.8.
>
> The delay also occurs everytime I want to make a change to a blocks
> paramters. I have to wait >2 seconds for the blocks paramter window to
> open and then another >2 seconds for it to close. It all adds up. If
> the reason is what Murray said, I would agree it would be nice to have
> the option of checking only when you click the play button or
> something similar.
>
> v/r,
> Rich
>
> On Wed, May 27, 2015 at 12:08 PM, Murray Thomson
> mailto:murraythomson...@gmail.com>> wrote:
>
> I had this problem for a while when using a large number of
> blocks. The cause, I think, is that the companion checks if the
> flowgraph is correct after every change. You will only be able to
> compile if it's correct (blocks are connected, variable names
> exist...).
> If this is really the reason, It would be nice to have an icon
> that, when unselected disables this check and when selected it
> checks the flowgraph and enables the compile and run options if
> everything is ok.
>
> Regards,
> Murray
>
> 2015-05-27 16:08 GMT+01:00 Andreas Ladanyi
> mailto:andreas.lada...@gmx.net>>:
>
> Hi rich,
>
> on which hardware platform are you working ? Is this a PC or
> embedded device ?
>
> cheers,
> Andy
>
>
> Am 27.05.2015 um 01:09 schrieb Richard Bell:
>> GNU Radio 3.7.8, Ubuntu 14.04
>>
>> I have an admittedly large number of blocks in my current
>> flow graph because I'm in the middle of some hardcore
>> debugging. Every time I select a block to enable/disable it,
>> there is a > 2 second delay between the block becoming
>> enabled/disabled and hitting the E/D keys. The same is true
>> when connecting new ports together with wires. I've been
>> working with this for a while, but it's annoying enough now
>> that I'd like to know if there is a workaround to this or
>> simply understand the cause of it?
>>
>> v/r,
>> Rich
>>
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ESA SOCIS project Announcement

[Johannes Demel]

Hey GNU Radio community!

Thanks for choosing my project for this year's ESA Summer of Code in
Space. I will implement a POLAR code encoder decoder chain as well as
channel construction.

I would like to introduce myself a bit today.
I am a Master degree student at Karlsruhe Institute of Technology
(KIT), Germany. My major is focused on Communication at Communications
Engineering Lab (CEL). Also, I was a student research assistant at CEL
up until the start of ESA SOCIS. During my studies and work I acquired
advanced skills in digital signal processing, waveform design and
software engineering. My fields of interest are Software-Defined Radio
development and system optimization.
I got in touch with GNU Radio back in 2012 when I started my Bachelor
thesis on LTE signal reception with GNU Radio. The outcome of this
thesis is available on Github. I continued working on this project
afterwards. During the course of gr-lte development I touched a great
variety of different parts of GNU Radio. Firstly adopting and
integrating existing blocks into the project. Secondly learning a lot
about GNU Radio internals like scheduler specifics, class inheritance
structures and VOLK usage. Also, I improved my knowledge to write test
code in order to improve code quality.
Besides my studies at KIT I did an internship at Ettus Research in
2013/14, fostering my programming skills and deepening my GNU Radio
knowledge. During that time I contributed to Ettus’ UHD driver and
developed tools for use with GNU Radio. Recently I contributed to GNU
Radio by adding a rename capability to its modtool tool.
Besides my experience with GNU Radio and thus with C ++ and Python, I
also did several smaller projects. That includes closed source
projects at university level with Java and Java for Android. I did
microcontroller programming in ANSI C and Assembler. This included
integration of an IP microcontroller into an existing VHDL project.
During the course of the project, I will have access to CEL’s labs and
equipment. And Sebastian Koslowski, who is currently with CEL, agreed
on mentoring my project. Thus I will always be able to talk to him
personally about project progress and pitfalls.
I read GNU Radio’s Code of Conduct and understood and agree to it,
including the three strikes rule. They are natural to follow and
essential for a positive and prospering community. I am looking
forward to publish my weekly project updates.

I will host my project on Github [1]. In case you are curious about
the project goals and haven't already read my proposal, you can find
it on Github too [2].

I am happy to get started with the project now. Stay tuned for weekly
updates. In case you have questions or feedback, don't hesitate to
email me. I am grateful to get more input and suggestions on the project.

My goal for the upcoming weeks is to implement a encoder decoder chain
in Python which shall serve as testcode later on.

Cheers
Johannes

[1] https://github.com/jdemel/gnuradio
[2] https://github.com/jdemel/socis-proposal

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

[Discuss-gnuradio] bfile sink base undefined symbol error

[Nemanja Savic]

Hi all guys,

I encounter following error when running my test:

ImportError: /usr/local/lib/libgnuradio-TPMS.so: undefined symbol:
_ZN2gr6blocks14file_sink_baseC2EPKcb

There was a similar problem explained here:
http://stackoverflow.com/questions/28859517/gnuradio-importerror-undefined-symbol

I use gnuradio 3.6.5.1.
After doing suggested c++filter I got:
gr::blocks::file_sink_base::file_sink_base(char const*, bool)

And yes, one of my blocks is derived from file sink base class in the
similar way as it was donein default gnuradio file sink:

class RDK_API file_sink_lim_b : virtual public gr_sync_block,
virtual public
blocks::file_sink_base

In the suggested solution,the guy sugest adding extra lines in cmake file,
which I did:

set(GR_REQUIRED_COMPONENTS BLOCKS)
find_package(Gnuradio "3.6.5.1")

later
${GNURADIO_ALL_INCLUDE_DIRS}

and
${GNURADIO_ALL_LIBRARIES}

Then, after running cmake in my build folder, it can be seen that
everything was found:
Checking for GNU Radio Module: BLOCKS
 * INCLUDES=/usr/local/include/gnuradio
 * LIBS=/usr/local/lib/libgnuradio-blocks.so
GNURADIO_BLOCKS_FOUND = TRUE

But still I have the same error. What else could be done. If worth of
mentioning, my module is made on RHEL6 maschine, while this error occures
on ubuntu after copying my source files (basically everything except build
folder)

Thanx

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

Re: [Discuss-gnuradio] Is file sink block resetting USRP?

[Martin Braun]

On 27.05.2015 18:30, Marcus D. Leech wrote:
> On 05/27/2015 05:52 PM, Carl Olsson wrote:
>> Hi all,
>>
>> I use a file sink block in my flow graph to record samples from a USRP
>> N210. I start the flow graph and then after some time starts to record
>> using the file sink block by switching it on using a selector block.
>>
> My recollection is that the selector blocks stop the graph, reconfigure
> it, and start it again, which means source streams probably get restarted.

That's right: lock() and unlock() are called, which reset the blocks.
Marcus' suggestion is the easiest and most effective solution to this;
we also have another block (matrix_multiply_xx) which can act as a
selector that doesn't call lock() if you require this.

M


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

Re: [Discuss-gnuradio] Fast, Single-Sample Phase Rotation

[Sylvain Munaut]

Hi John,

> I have a  complex phase rotation function that uses a pre-generated sin/cos
> LUT and some basic multiple/adds.
>
> As it turns out, the rotation calc, which uses "straight" C/C++ math is
> still the bottleneck in a demod.

I don't quite get what you need ...

Rotating a single sample by a given angle is one sin/cos (for which
you use LUT) and a single complex multiply (and gcc is going to have a
pretty optimized version of that).

Doing stuff for single samples at a time, the bottleneck isn't going
to be the computation, it's going to be the load/store from/to memory.

Also are we talking changing the phase by a fixed amount , or an
amount that change after each sample (like the rotator kernel does) ?

Need more info ... In optimization the devil is in the details :p
Also lack of alignement doesn't mean SIMD is out if you have several
of them to do at once ...

Cheers,

   Sylvain

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

[Discuss-gnuradio] modtool noblock and xml files and grc

[John Murphy]

Hello again,

I tried to add a C++ noblock to my OOT module. In this particular case I
wanted to provide a reusable "n of m" counter class (for non-signal stuff
to count) in C++ code that I could use within various C++ blocks in the
module. And I did not know of a better way to manage that with the ins and
outs of the gnuradio OOT module make system.

Anyhow, it unexpectedly generated an xml file to import the non-block into
GRC.
Is there a best way to just remove that xml file without causing other
issues?

Also when I tried to drag and drop the non-block into GRC, presumably from
the default created xml file with no edits (curiosity always gets one in
trouble?) GRC went to a blank screen. Of course I was able to close and
restart and pick up at the last save which was fine. Okay none of that is
really unexpected.

I guess there must be a reason you would have a noblock that can be added
to a flowgraph? But if I do not want anyone to accidentally drag my class
onto the flowgraph how would I best just remove the GRC interface without
breaking everything?

Am I even using the modtool noblock in an intended fashion?

Many thanks as always folks,
- John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fwd: modtool noblock and xml files and grc

[Johnathan Corgan]

On Thu, May 28, 2015 at 8:26 AM, John Murphy <
mr.john.joseph.mur...@gmail.com> wrote:


> Anyhow, it unexpectedly generated an xml file to import the non-block into
> GRC.
> Is there a best way to just remove that xml file without causing other
> issues?
>

First, do a 'make uninstall' from your build directory, to remove the file
from where GRC finds it.

Then, edit grc/CMakeLists.txt and remove the line that has the XML filename
in it.

Finally, rerun the build (cmake, make, sudo make install, etc.).

Also when I tried to drag and drop the non-block into GRC, presumably from
> the default created xml file with no edits (curiosity always gets one in
> trouble?) GRC went to a blank screen. Of course I was able to close and
> restart and pick up at the last save which was fine. Okay none of that is
> really unexpected.
>

In general, gr_modtool creates XML files that need further editing before
being usable in GRC; in this case, GRC didn't handle the mis-parse very
well.


> I guess there must be a reason you would have a noblock that can be added
> to a flowgraph?
>

You can create generic functions with parameters that you can set up as
variables in GRC.  They aren't blocks added to the flowgraph but are still
"GRC blocks".

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 150, Issue 31

[John Murphy]

Okay.
Tried this, then deleted the xml file before attempting to make again
without it.
Got the following error when re-making (the line with the xml file had a
destination which I had thought was just for that file)
What do I need to do to fix this?
Thanks,
- John


CMake Error at grc/CMakeLists.txt:19 (install):
  install FILES given no DESTINATION!


-- Configuring incomplete, errors occurred!
See also
"/usr/local/share/gnuradio-OutOfTree-modules/gr-comso/build/CMakeFiles/CMakeOutput.log".
See also
"/usr/local/share/gnuradio-OutOfTree-modules/gr-comso/build/CMakeFiles/CMakeError.log".
make: *** [cmake_check_build_system] Error 1


From: Johnathan Corgan 
>
>
> On Thu, May 28, 2015 at 8:26 AM, John Murphy <
> mr.john.joseph.mur...@gmail.com> wrote:
>
>
> > Anyhow, it unexpectedly generated an xml file to import the non-block
into
> > GRC.
> > Is there a best way to just remove that xml file without causing other
> > issues?
> >
>
> First, do a 'make uninstall' from your build directory, to remove the file
> from where GRC finds it.
>
> Then, edit grc/CMakeLists.txt and remove the line that has the XML
filename
> in it.
>
> Finally, rerun the build (cmake, make, sudo make install, etc.).
>
> Also when I tried to drag and drop the non-block into GRC, presumably from
> > the default created xml file with no edits (curiosity always gets one in
> > trouble?) GRC went to a blank screen. Of course I was able to close and
> > restart and pick up at the last save which was fine. Okay none of that
is
> > really unexpected.
> >
>
> In general, gr_modtool creates XML files that need further editing before
> being usable in GRC; in this case, GRC didn't handle the mis-parse very
> well.
>
>
> > I guess there must be a reason you would have a noblock that can be
added
> > to a flowgraph?
> >
>
> You can create generic functions with parameters that you can set up as
> variables in GRC.  They aren't blocks added to the flowgraph but are still
> "GRC blocks".
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 150, Issue 31

[Johnathan Corgan]

On Thu, May 28, 2015 at 9:17 AM, John Murphy <
mr.john.joseph.mur...@gmail.com> wrote:


> Tried this, then deleted the xml file before attempting to make again
> without it.
> Got the following error when re-making (the line with the xml file had a
> destination which I had thought was just for that file)
>

That looks like the error you would get if it were the only XML file to
install.  In that case, just delete the entire INSTALL clause.  If not, can
you post the CMakeLists.txt file?

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] modtool noblock and xml files and grc

[John Murphy]

Nevermind, figured out (by looking at another module, fortunately had one
handy although one could probably find such on git somewhere now that I
think about it instead of hitting the panic button)
for posterity, you just have to add the following to the end of the line
listing the last xml file
 DESTINATION share/gnuradio/grc/blocks

Thanks,
all that worked great now.

On Thu, May 28, 2015 at 12:17 PM, John Murphy <
mr.john.joseph.mur...@gmail.com> wrote:
>
> Okay.
> Tried this, then deleted the xml file before attempting to make again
without it.
> Got the following error when re-making (the line with the xml file had a
destination which I had thought was just for that file)
> What do I need to do to fix this?
> Thanks,
> - John
>
>
> CMake Error at grc/CMakeLists.txt:19 (install):
>   install FILES given no DESTINATION!
>
>
> -- Configuring incomplete, errors occurred!
> See also
"/usr/local/share/gnuradio-OutOfTree-modules/gr-comso/build/CMakeFiles/CMakeOutput.log".
> See also
"/usr/local/share/gnuradio-OutOfTree-modules/gr-comso/build/CMakeFiles/CMakeError.log".
> make: *** [cmake_check_build_system] Error 1
>
>
> From: Johnathan Corgan 
> >
> >
> > On Thu, May 28, 2015 at 8:26 AM, John Murphy <
> > mr.john.joseph.mur...@gmail.com> wrote:
> >
> >
> > > Anyhow, it unexpectedly generated an xml file to import the non-block
into
> > > GRC.
> > > Is there a best way to just remove that xml file without causing other
> > > issues?
> > >
> >
> > First, do a 'make uninstall' from your build directory, to remove the
file
> > from where GRC finds it.
> >
> > Then, edit grc/CMakeLists.txt and remove the line that has the XML
filename
> > in it.
> >
> > Finally, rerun the build (cmake, make, sudo make install, etc.).
> >
> > Also when I tried to drag and drop the non-block into GRC, presumably
from
> > > the default created xml file with no edits (curiosity always gets one
in
> > > trouble?) GRC went to a blank screen. Of course I was able to close
and
> > > restart and pick up at the last save which was fine. Okay none of
that is
> > > really unexpected.
> > >
> >
> > In general, gr_modtool creates XML files that need further editing
before
> > being usable in GRC; in this case, GRC didn't handle the mis-parse very
> > well.
> >
> >
> > > I guess there must be a reason you would have a noblock that can be
added
> > > to a flowgraph?
> > >
> >
> > You can create generic functions with parameters that you can set up as
> > variables in GRC.  They aren't blocks added to the flowgraph but are
still
> > "GRC blocks".
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Reacting Slowly

[Johnathan Corgan]

On Thu, May 28, 2015 at 12:05 AM, Marcus Müller 
wrote:


> I'll pitch `perf` here (you're on Ubuntu, so it's in the linux-tools,
> probably).
>


I'm pretty sure the issue is as Murray Thomson described above.  We've had
to optimize this area in the past in GRC.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
Intro to SDR Classes - June 4-5, Columbia MD, June 29-30, El Segundo, CA
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] dual receiver setup for interferometry measurements

[jean-michel . friedt]

I have a question concerning connecting two DVB-T dongles on the same clock
source for interferometric (or passive radar) measurements, as described at
http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
I have assembled the same system with one dongle used as oscillator on a 28.8 
MHz resonator
and the second one as a slave to this clock. All works fine, solved the issue
when the oscillator would not start, now I have a reliable source of 
measurements.

Initial tests (these are R820T-based dongles) exhibits significant random phase 
drift
which I attributed to heating of the chips (they get above 50 degC when running 
continuously),
so after gluing two heat sink with heat-conducting epoxy, I more or less 
managed to
get a stable phase measurement when recording a same oscillator (200 MHz) with 
the
two dongles and displaying the phase as angle(conjugate(signal1)*signal2).

The question is as follows: at http://jmfriedt.sequanux.org/ph_tout.pdf I have 
shown one
graph, quite representative of all my experiments, displaying the evolution of 
the phase
difference between both dongles connected to the same 200 MHz oscillator. I 
*always* 
start with a quite stable phase difference (red curve -- inset in a zoom of 
this particular
measurement) after plugging in my USB hub fitted with the two dongles and 
starting gnuradio-companion
for recording the dongle I/Q stream (notice the abscissa sampling rate of 10 Hz 
=> the full
graph is about 1-hour long). After about an hour, I stop recording the red 
curve, and
all I do is switch off gnuradio-companion and start it back => green curve with 
a quickly falling
phase. Switch off again, disconnect-reconnect USB hub, restart an acquisition 
=> blue curve.
Same procedure => magenta curve.

Can anyone hint at an explanation as to why I always start with a reasonably 
stable phase
difference (yet not constant -- is the phase fluctuation indeed due to heating 
of the fractional
PLL in each RF frontend, drifting below the feedback loop time constant ?), but 
more worrisome
why I always get this huge drift after launching a new acquisition ? The fact 
that I always
get the same slope hints at a sofware/hardware communication issue, but how it 
is possible
since both dongles are clocked by the same source and receive the same commands 
from the
software ?

Thanks, JM

-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

Re: [Discuss-gnuradio] dual receiver setup for interferometry measurements

[mleech]

 

This is largely because this $10.00-apiece hardware was never designed
for this class of application. When you're doings things that require
phase-coherence, you have to design your radios to support it. 

There are at least two PLLs involved here--one on the R820T chip, and
another, as far as I can tell, in the RTL2832U chip, which does the
conversion to baseband from the low-IF of the R820T. 

I was never able to get my RTL receivers to be phase-coherent in any
useful way, there was always a slow phase drift, that was unpredictable.


On 2015-05-28 14:18, jean-michel.fri...@femto-st.fr wrote: 

> I have a question concerning connecting two DVB-T dongles on the same clock
> source for interferometric (or passive radar) measurements, as described at
> http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html [1]
> I have assembled the same system with one dongle used as oscillator on a 28.8 
> MHz resonator
> and the second one as a slave to this clock. All works fine, solved the issue
> when the oscillator would not start, now I have a reliable source of 
> measurements.
> 
> Initial tests (these are R820T-based dongles) exhibits significant random 
> phase drift
> which I attributed to heating of the chips (they get above 50 degC when 
> running continuously),
> so after gluing two heat sink with heat-conducting epoxy, I more or less 
> managed to
> get a stable phase measurement when recording a same oscillator (200 MHz) 
> with the
> two dongles and displaying the phase as angle(conjugate(signal1)*signal2).
> 
> The question is as follows: at http://jmfriedt.sequanux.org/ph_tout.pdf [2] I 
> have shown one
> graph, quite representative of all my experiments, displaying the evolution 
> of the phase
> difference between both dongles connected to the same 200 MHz oscillator. I 
> *always* 
> start with a quite stable phase difference (red curve -- inset in a zoom of 
> this particular
> measurement) after plugging in my USB hub fitted with the two dongles and 
> starting gnuradio-companion
> for recording the dongle I/Q stream (notice the abscissa sampling rate of 10 
> Hz => the full
> graph is about 1-hour long). After about an hour, I stop recording the red 
> curve, and
> all I do is switch off gnuradio-companion and start it back => green curve 
> with a quickly falling
> phase. Switch off again, disconnect-reconnect USB hub, restart an acquisition 
> => blue curve.
> Same procedure => magenta curve.
> 
> Can anyone hint at an explanation as to why I always start with a reasonably 
> stable phase
> difference (yet not constant -- is the phase fluctuation indeed due to 
> heating of the fractional
> PLL in each RF frontend, drifting below the feedback loop time constant ?), 
> but more worrisome
> why I always get this huge drift after launching a new acquisition ? The fact 
> that I always
> get the same slope hints at a sofware/hardware communication issue, but how 
> it is possible
> since both dongles are clocked by the same source and receive the same 
> commands from the
> software ?
> 
> Thanks, JM
 

Links:
--
[1] http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
[2] http://jmfriedt.sequanux.org/ph_tout.pdf
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dual receiver setup for interferometry measurements

[jean-michel . friedt]

Thanks for your reply. Indeed designing phase coherent receivers is my daily
job activity (partly), but the fun of hacking DVB-T receivers is to find ways 
of using 
these for applications they were never intended for. I have indeed read your 
posts 
concerning the difficulties in reproducing interferometric measurements, a great
source of inspiration. At the moment we are considering quantifying the phase
drift (switching from a reference oscillator to the unknown signal), but I 
wonder
nevertheless why some have achieved excellent coherence and some (including 
myself)
are failing. Nevertheless I'd like to actually identify the source of the drift
(PLL bandpass, temperature-related setpoint drift, software configuration ?).

Thanks, JM

> This is largely because this $10.00-apiece hardware was never designed
> for this class of application. When you're doings things that require
> phase-coherence, you have to design your radios to support it. 
> 
> There are at least two PLLs involved here--one on the R820T chip, and
> another, as far as I can tell, in the RTL2832U chip, which does the
> conversion to baseband from the low-IF of the R820T. 
> 
> I was never able to get my RTL receivers to be phase-coherent in any
> useful way, there was always a slow phase drift, that was unpredictable.
> 
> 
> On 2015-05-28 14:18, jean-michel.fri...@femto-st.fr wrote: 
> 
> > I have a question concerning connecting two DVB-T dongles on the same clock
> > source for interferometric (or passive radar) measurements, as described at
> > http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html [1]
> > I have assembled the same system with one dongle used as oscillator on a 
> > 28.8 MHz resonator
> > and the second one as a slave to this clock. All works fine, solved the 
> > issue
> > when the oscillator would not start, now I have a reliable source of 
> > measurements.
> > 
> > Initial tests (these are R820T-based dongles) exhibits significant random 
> > phase drift
> > which I attributed to heating of the chips (they get above 50 degC when 
> > running continuously),
> > so after gluing two heat sink with heat-conducting epoxy, I more or less 
> > managed to
> > get a stable phase measurement when recording a same oscillator (200 MHz) 
> > with the
> > two dongles and displaying the phase as angle(conjugate(signal1)*signal2).
> > 
> > The question is as follows: at http://jmfriedt.sequanux.org/ph_tout.pdf [2] 
> > I have shown one
> > graph, quite representative of all my experiments, displaying the evolution 
> > of the phase
> > difference between both dongles connected to the same 200 MHz oscillator. I 
> > *always* 
> > start with a quite stable phase difference (red curve -- inset in a zoom of 
> > this particular
> > measurement) after plugging in my USB hub fitted with the two dongles and 
> > starting gnuradio-companion
> > for recording the dongle I/Q stream (notice the abscissa sampling rate of 
> > 10 Hz => the full
> > graph is about 1-hour long). After about an hour, I stop recording the red 
> > curve, and
> > all I do is switch off gnuradio-companion and start it back => green curve 
> > with a quickly falling
> > phase. Switch off again, disconnect-reconnect USB hub, restart an 
> > acquisition => blue curve.
> > Same procedure => magenta curve.
> > 
> > Can anyone hint at an explanation as to why I always start with a 
> > reasonably stable phase
> > difference (yet not constant -- is the phase fluctuation indeed due to 
> > heating of the fractional
> > PLL in each RF frontend, drifting below the feedback loop time constant ?), 
> > but more worrisome
> > why I always get this huge drift after launching a new acquisition ? The 
> > fact that I always
> > get the same slope hints at a sofware/hardware communication issue, but how 
> > it is possible
> > since both dongles are clocked by the same source and receive the same 
> > commands from the
> > software ?
> > 
> > Thanks, JM
>  
> 
> Links:
> --
> [1] http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
> [2] http://jmfriedt.sequanux.org/ph_tout.pdf


-- 
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 
Besancon, France

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

Re: [Discuss-gnuradio] Fast, Single-Sample Phase Rotation

[Douglas Geiger]

On Tue, May 26, 2015 at 7:37 PM, John Malsbury  wrote:

> I have a  complex phase rotation function that uses a pre-generated
> sin/cos LUT and some basic multiple/adds.
>
> As it turns out, the rotation calc, which uses "straight" C/C++ math is
> still the bottleneck in a demod.
>
> I was wondering, is there some uber-efficient rotation block/class I
> should be using?   I notice there is a volk kernel for the job and
> gr_rotator.  But I also should mention that the phase rotation operation
> must happen one sample at a time.  This is due to the sequential nature of
> the algorithm - ie.  I can't align and call a kernel with hundreds of
> nicely-aligned samples.
>
> Any advice?
>
> -John
>

 To follow-up on Sylvain's questions: is the restriction really on doing
single-sample rotation (because of some intermediate calculation to
generate the phase advance for the next sample), or on the alignment? I'll
note that *in general* intel doesn't take much (including, often, a
non-measurable) hit on non-aligned SIMD operations. Also - even if you
aren't operating in the hundreds of sample range, that the SIMD kernel can
save you if you're operating on e.g. several sample as a time (for SSE it's
only doing two at a time anyways, with a clean-up loop for an odd-number of
samples, and AVX does four at a time, with a clean-up loop for
non-multiples of four).
 Besides, who can resist looking at something called the rotatorpuppet for
inspiration on how to call the main kernel?

 I'll also point out that the gr::blocks::rotator (which is not a block,
i.e. separate from the rotator_cc, which is a block) has both a rotate()
method that operates on a single sample, and a rotateN() method that
operates on n samples. It is the later that calls down into the volk
rotator kernel.

-- 
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fast, Single-Sample Phase Rotation

[Tom Tsou]

On Thu, May 28, 2015 at 1:52 PM, Douglas Geiger
 wrote:
>  To follow-up on Sylvain's questions: is the restriction really on doing
> single-sample rotation (because of some intermediate calculation to generate
> the phase advance for the next sample), or on the alignment?

Based on available information, I'm guessing the prior scenario with
something like a filtered sequence feeding a phase modulator to
generate GMSK or similar non-linear CPM signal. In cases like these,
is the phase modulator really necessary?

Many non-linear digital modulations in use these days have some form
of linear representation that is more efficient to implement on
vector-capable hardware. One solution to the rotator inefficiency
might be to get rid of it entirely.

  -TT

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

Re: [Discuss-gnuradio] dual receiver setup for interferometry measurements

[Juha Vierinen]

Hi,

I guess I should respond, as I'm responsible for the blog posting that you
linked.

I tested the relative phase stability using amplified noise that was fed
via a splitter onto the two dongles. I cross-correlated the noise and found
that there was a deterministic frequency difference between the channels. I
recall this was a fraction of a radian per second. I just calculated what
this small deterministic frequency difference was and removed it. I found
that I could use the same constant during the whole experiment and it also
didn't change after power cycling the dongles. This is how I produced the
flat line IQ plot that is in the blog posting.

Based on your plots, you are mostly also seeing a constant deterministic
frequency difference (the linear slope on traces 3 and 4). Trace 3 has a
phase jump for some reason and I don't know what is happening with trace 1.

In my tests, I only measured data for several hours at a time. I didn't see
any loss of lock or weird behavior during my experiments other than what I
indicated above. I have heard from several people that they have managed to
reproduce the dual rtl_sdr dongle configuration and to even use it for
passive radar. I have even seen people taking the proper engineering
approach and feeding a clock with a fanout buffer. I haven't seen any
cross-correlation plots from these devices though.

I have had issues with heating on the smaller dongles. In these cases the
down converter stops working. A heat sink fixed this issue.

Keep trying, I think you are almost there. Try recabling the clock
differently or try using another pair of dongles -- there is a lot of
variability between the dongles. Try looking at the clock signal with a
scope to see what the levels are with a working individual dongle.

I assume you are doing this for fun (that's why I did it at least). There
are much easier ways to get multiple coherent channels into your computer
with much better fidelity.

juha

On Thu, May 28, 2015 at 6:18 PM,  wrote:

> I have a question concerning connecting two DVB-T dongles on the same clock
> source for interferometric (or passive radar) measurements, as described at
> http://kaira.sgo.fi/2013/09/16-dual-channel-coherent-digital.html
> I have assembled the same system with one dongle used as oscillator on a
> 28.8 MHz resonator
> and the second one as a slave to this clock. All works fine, solved the
> issue
> when the oscillator would not start, now I have a reliable source of
> measurements.
>
> Initial tests (these are R820T-based dongles) exhibits significant random
> phase drift
> which I attributed to heating of the chips (they get above 50 degC when
> running continuously),
> so after gluing two heat sink with heat-conducting epoxy, I more or less
> managed to
> get a stable phase measurement when recording a same oscillator (200 MHz)
> with the
> two dongles and displaying the phase as angle(conjugate(signal1)*signal2).
>
> The question is as follows: at http://jmfriedt.sequanux.org/ph_tout.pdf I
> have shown one
> graph, quite representative of all my experiments, displaying the
> evolution of the phase
> difference between both dongles connected to the same 200 MHz oscillator.
> I *always*
> start with a quite stable phase difference (red curve -- inset in a zoom
> of this particular
> measurement) after plugging in my USB hub fitted with the two dongles and
> starting gnuradio-companion
> for recording the dongle I/Q stream (notice the abscissa sampling rate of
> 10 Hz => the full
> graph is about 1-hour long). After about an hour, I stop recording the red
> curve, and
> all I do is switch off gnuradio-companion and start it back => green curve
> with a quickly falling
> phase. Switch off again, disconnect-reconnect USB hub, restart an
> acquisition => blue curve.
> Same procedure => magenta curve.
>
> Can anyone hint at an explanation as to why I always start with a
> reasonably stable phase
> difference (yet not constant -- is the phase fluctuation indeed due to
> heating of the fractional
> PLL in each RF frontend, drifting below the feedback loop time constant
> ?), but more worrisome
> why I always get this huge drift after launching a new acquisition ? The
> fact that I always
> get the same slope hints at a sofware/hardware communication issue, but
> how it is possible
> since both dongles are clocked by the same source and receive the same
> commands from the
> software ?
>
> Thanks, JM
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044
> Besancon, France
>
> ___
> 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] SDRA, Programme complete

[Markus Heller]

Dear List,

please note that the programme of the SDRA-2015 is now complete. 

http://www.sdra-2015.de/pages/programme.html

We have also finalized the timetable now. 

I'll be happy to welcome many of you at Friedrichshafen! The SDRA will
take place on June 27. 

vy73
markus
dl8rds


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

Re: [Discuss-gnuradio] Fast, Single-Sample Phase Rotation

[John Malsbury]

It really does need to happen on one sample at a time - at least assuming I
use the same algorithm I'm using now.  I am pretty much using the method
Sylvain suggests.  The rotation is one operation of many inside a block -
ie. many rotations happen per call to work(), but one rotation per input
sample as the rotation is dependent on what happened with previous samples.

Still processing what Tom/Doug are suggesting otherwise. The mod is
generally product by something that isnt on GNU Radio.  When we recreate
the mod in  software we definitely use a form that is easily done in vector
form.  Haven't quite wrapped my head on how to do the same on the receiving
end while achieving optimum detection... Got any good papers?

Converting everything to phase might be a half-way reasonable approach.

Imminently, I only need to make this ~22% faster.  It's possible this might
work on a faster processor.

-John

On Thu, May 28, 2015 at 2:50 PM, Tom Tsou  wrote:

> On Thu, May 28, 2015 at 1:52 PM, Douglas Geiger
>  wrote:
> >  To follow-up on Sylvain's questions: is the restriction really on doing
> > single-sample rotation (because of some intermediate calculation to
> generate
> > the phase advance for the next sample), or on the alignment?
>
> Based on available information, I'm guessing the prior scenario with
> something like a filtered sequence feeding a phase modulator to
> generate GMSK or similar non-linear CPM signal. In cases like these,
> is the phase modulator really necessary?
>
> Many non-linear digital modulations in use these days have some form
> of linear representation that is more efficient to implement on
> vector-capable hardware. One solution to the rotator inefficiency
> might be to get rid of it entirely.
>
>   -TT
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Installation

[Gerome Jan L]

I'm installing gnuradio again on my ubuntu 14.04 installed in VMware
11.1.0. I tried it several times, but I can't seem to pass this step:

Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...

It's been almost 12 hours and it's not getting anywhere.

What should I change in my installation steps?

I am following this steps below:

1) mkdir ~/gnuradio
2) cd ~/gnuradio
3) wget http://www.sbrac.org/files/build-gnuradio
4) chmod a+x build-gnuradio
5) ./build-gnuradio --verbose all

Thanks in advance.


*Gerome Jan M. Llames *
Engineering Research and Development for Technology (ERDT) Scholar
University of San Carlos - Technological Campus
Nasipit Talamban, Cebu City, Philippines, 6000
Mobile: +639271525124
Email: geromejanlla...@gmail.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Installation

[Marcus D. Leech]

On 05/28/2015 07:31 PM, Gerome Jan L wrote:
I'm installing gnuradio again on my ubuntu 14.04 installed in VMware 
11.1.0. I tried it several times, but I can't seem to pass this step:


Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...

It's been almost 12 hours and it's not getting anywhere.

What should I change in my installation steps?

I am following this steps below:

1) mkdir ~/gnuradio
2) cd ~/gnuradio
3) wget http://www.sbrac.org/files/build-gnuradio
4) chmod a+x build-gnuradio
5) ./build-gnuradio --verbose all

Thanks in advance.



*
My guess is that your institution blocks GIT, or you have some 
network-stack issue that's preventing GIT from making forward progress 
in your VM.



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

Re: [Discuss-gnuradio] GNU Radio Installation

[Silverfox]

The fixes to Ubuntu installed IPV6 which basically kills the network opens.  
Disable it and reboot.

73,

Alan - W6ARH

 

 

From: discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org 
[mailto:discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] On Behalf Of 
Gerome Jan L
Sent: Thursday, May 28, 2015 4:31 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] GNU Radio Installation

 

I'm installing gnuradio again on my ubuntu 14.04 installed in VMware 11.1.0. I 
tried it several times, but I can't seem to pass this step:

 

Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)

via the Internet

===> THIS MAY TAKE QUITE SOME TIME <=

Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...

 

It's been almost 12 hours and it's not getting anywhere.

 

What should I change in my installation steps?

 

I am following this steps below:

 

1) mkdir ~/gnuradio

2) cd ~/gnuradio

3) wget http://www.sbrac.org/files/build-gnuradio

4) chmod a+x build-gnuradio

5) ./build-gnuradio --verbose all

 

Thanks in advance.

 




Gerome Jan M. Llames 

Engineering Research and Development for Technology (ERDT) Scholar

University of San Carlos - Technological Campus

Nasipit Talamban, Cebu City, Philippines, 6000

Mobile: +639271525124

Email:   geromejanlla...@gmail.com

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

Re: [Discuss-gnuradio] GNU Radio Installation

[Gerome Jan L]

What do you mean IPv6? I'm using IPv4. Sorry, but I don't quiet get your
suggestion. Please elaborate. Thanks.

*Gerome Jan M. Llames *
Engineering Research and Development for Technology (ERDT) Scholar
University of San Carlos - Technological Campus
Nasipit Talamban, Cebu City, Philippines, 6000
Mobile: +639271525124
Email: geromejanlla...@gmail.com

On Fri, May 29, 2015 at 7:49 AM, Silverfox  wrote:

> The fixes to Ubuntu installed IPV6 which basically kills the network
> opens.  Disable it and reboot.
>
> 73,
>
> Alan - W6ARH
>
>
>
>
>
> *From:* discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org [mailto:
> discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org] *On Behalf Of *Gerome
> Jan L
> *Sent:* Thursday, May 28, 2015 4:31 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] GNU Radio Installation
>
>
>
> I'm installing gnuradio again on my ubuntu 14.04 installed in VMware
> 11.1.0. I tried it several times, but I can't seem to pass this step:
>
>
>
> Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
>
> via the Internet
>
> ===> THIS MAY TAKE QUITE SOME TIME <=
>
> Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...
>
>
>
> It's been almost 12 hours and it's not getting anywhere.
>
>
>
> What should I change in my installation steps?
>
>
>
> I am following this steps below:
>
>
>
> 1) mkdir ~/gnuradio
>
> 2) cd ~/gnuradio
>
> 3) wget http://www.sbrac.org/files/build-gnuradio
>
> 4) chmod a+x build-gnuradio
>
> 5) ./build-gnuradio --verbose all
>
>
>
> Thanks in advance.
>
>
>
>
> *Gerome Jan M. Llames *
>
> Engineering Research and Development for Technology (ERDT) Scholar
>
> University of San Carlos - Technological Campus
>
> Nasipit Talamban, Cebu City, Philippines, 6000
>
> Mobile: +639271525124
>
> Email: geromejanlla...@gmail.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Installation

[Silverfox]

Check the internet for suggestions on how to cure slow internet connections in 
Ubuntu.  You do not have to be using it to have it active.

Alan

 

 

From: Gerome Jan L [mailto:geromejanlla...@gmail.com] 
Sent: Thursday, May 28, 2015 5:10 PM
To: Silverfox
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNU Radio Installation

 

What do you mean IPv6? I'm using IPv4. Sorry, but I don't quiet get your 
suggestion. Please elaborate. Thanks.




Gerome Jan M. Llames 

Engineering Research and Development for Technology (ERDT) Scholar

University of San Carlos - Technological Campus

Nasipit Talamban, Cebu City, Philippines, 6000

Mobile: +639271525124

Email:   geromejanlla...@gmail.com

 

On Fri, May 29, 2015 at 7:49 AM, Silverfox  wrote:

The fixes to Ubuntu installed IPV6 which basically kills the network opens.  
Disable it and reboot.

73,

Alan - W6ARH

 

 

From: discuss-gnuradio-bounces+alan.r.hill=gmail@gnu.org 
[mailto:discuss-gnuradio-bounces+alan.r.hill 
 =gmail@gnu.org] On Behalf 
Of Gerome Jan L
Sent: Thursday, May 28, 2015 4:31 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] GNU Radio Installation

 

I'm installing gnuradio again on my ubuntu 14.04 installed in VMware 11.1.0. I 
tried it several times, but I can't seem to pass this step:

 

Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)

via the Internet

===> THIS MAY TAKE QUITE SOME TIME <=

Fetching Gnu Radio via GIT...Cloning into 'gnuradio'...

 

It's been almost 12 hours and it's not getting anywhere.

 

What should I change in my installation steps?

 

I am following this steps below:

 

1) mkdir ~/gnuradio

2) cd ~/gnuradio

3) wget http://www.sbrac.org/files/build-gnuradio

4) chmod a+x build-gnuradio

5) ./build-gnuradio --verbose all

 

Thanks in advance.

 




Gerome Jan M. Llames 

Engineering Research and Development for Technology (ERDT) Scholar

University of San Carlos - Technological Campus

Nasipit Talamban, Cebu City, Philippines, 6000

Mobile: +639271525124  

Email:   geromejanlla...@gmail.com

 

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

[Discuss-gnuradio] Spectral survey with USRP and GRC

[Ivan]

Hello, 

I am trying to make a simple spectral survey with a USRP and GRC. I want to 
create a flowgraph that runs for a fixed number of iterations. In each 
iteration, I need to set a new center frequency in the uhd source, read data 
from the uhd source, run fft on it, and write results to a file. 

I have two problems I don't know how to solve. The first one is how to run a 
grc flowgraph for a fixed number of iterations. The second one, which looks 
harder to me, is how to change the center frequency in the uhd source between 
iterations. This would be easy if the center frequency could be passed through 
an input port. I've done something like this many times in Labview. However, 
the center frequency can only be set as a variable in the uhd source. 

Can this be done in grc or do I have to create the top level graph in Python or 
C++ to be able to reconfigure it after every iteration?
Regards,Ivan

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

Re: [Discuss-gnuradio] Integration of python's time.time() and work() calls

[Anil Kumar Yerrapragada]

>>Or is there a way to make sure that the in-buffer gets updated multiple
times within the same work call?

Will placing the work function inside a while 1 do the trick? But I guess
the issue with that is, as long as data is available, the scheduler calls
work function again and again anyway.


I'm still a little muddled up about this. I have read a lot of the posts on
the forum and the tutorials on the website as well.

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