[Discuss-gnuradio] error code 0xf

[Baier]

Dear all,

I have increased the buffer frame size from 1472 to 4096 bytes. Than I 
started my grc application and got the following message:
recv buffer smaller than vrt packet offset. UHD source block got error 
code 0xf.

Can somebody help me?
Thanks
A.B.

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

Re: [Discuss-gnuradio] Using USRP to transmit and receive samples

[Martin Braun (CEL)]

On Mon, Oct 21, 2013 at 09:06:24PM -0500, JPL wrote:
> Hello, Martin
> 
> 
> 1. Would you please tell me where the "manual page" is?

It's in the manual.
You go to gnuradio.org, click 'C++ manual', then 'Related Pages', then
'Tagged Stream Blocks'.

> Because I cannot understand 
> 
> How the Vector source works (tagged_streams.make_lengthtags((packet_len,),
> (0,).length_tag_name)?
> 
> and where the "Import"block grab the value from (from gnuradio.digital.utils
> import tagged_streams), (import numpy), and (import random)?
> 
> I just need to know how vector source related to those import block
> 
> 
> 2. And you are saying keep "vector source" block not replace with "file 
> source"
> block.
> 
> How can vector source import and read my *.dat?

You will have to load the .dat into a variable and then pass that to the
vector sink. It's not the most user-friendly method, I admit, but the
tagged stream blocks are still pretty new and we're only just figuring
out use-cases.

MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


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

[Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block

[Sylvain Munaut]

Hi,

So what I'm trying to achieve is to share a lot of code (including the
gr::sync_block implementation for work/start/stop) and a common
interface between several gnuradio blocks.

What I have currently come up with is (short version, see bottom for
more complete version) :

---
class API base_sink_c : virtual public gr::sync_block {};
class API glfw_sink_c : virtual public base_sink_c {};

class base_sink_c_impl : virtual public base_sink_c {};
class glfw_sink_c_impl : public glfw_sink_c, public base_sink_c_impl {};
---

* base_sink_c is a collection of virtual methods that define the
common functionality between subblocks.
* glfw_sink_c is the interface of the 'glfw' variant (only one here
atm) and is a super-set of the one in base_sink_c.
* base_sink_c_impl is the implementation of all the common stuff,
including the start/stop/work of gr::sync_block
* glfw_sink_c_impl is the 'glfw' variant and is the class to be
instanciated, it contains all the glfw specific code.

But this doesn't seem to work ... it crashes when GR tries to attach
the block in the block graph ( backtrace http://pastebin.com/JeBUEgtK
).

This is the resulting C++ layout (dumped with -fdump-class-hierarchy )
http://pastebin.com/raw.php?i=cDWQQwHn

Anyone has a clue what I'm doing wrong ?

Cheers,

Sylvain Munaut


---

More complete version:

class API base_sink_c : virtual public gr::sync_block
{
  /* Common exposed interface stuff (all virtual) */
}

class API glfw_sink_c : virtual public base_sink_c
{
 public:
  typedef boost::shared_ptr sptr;
  static sptr make();

  /* + Interface stuff specific to this variant (all virtual) */
}

class base_sink_c_impl : virtual public base_sink_c
{
  protected:
   base_sink_c_impl(const char *block_name);

  public:
   int work (int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items);
   bool start();
   bool stop();

  private:
/* all private stuff to the base implementation */
}

class glfw_sink_c_impl : public glfw_sink_c, public base_sink_c_impl
{
 public:
  glfw_sink_c_impl();
  virtual ~glfw_sink_c_impl();
}

Then on the implementation side I have :

base_sink_c_impl::base_sink_c_impl(const char *block_name)
  : gr::sync_block(block_name,
   gr::io_signature::make(1, 1, sizeof(gr_complex)),
   gr::io_signature::make(0, 0, 0))
{
  /* block specific stuff */
}

glfw_sink_c::sptr
glfw_sink_c::make()
{
return gnuradio::get_initial_sptr(new glfw_sink_c_impl());
}

glfw_sink_c_impl::glfw_sink_c_impl()
  : base_sink_c_impl("glfw_sink_c")
{
   /* ... */
}

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

Re: [Discuss-gnuradio] Misc questions, regarding Interrupt coalescing

[Marcus Müller]

Hi Naceur,

while questions 1 and 2 definitely are more of material for usrp-users, I'll 
try to answer them as briefly as possible, and puit usrp-users into the CC:.
On 10/21/2013 10:19 PM, Naceur wrote:

1/ Did anyone already tested the effect of Interrupt coalescing on reducing
the latency when host and USRP N2X0 are communicating and how far did he
reduce this latency

I haven't specifically tested that.
However, Interrupt Coalescing should not decrease latency; on the contrary, it 
should increase raw network latency but reduce CPU load. This could even lead 
to decreased overall latency, however, as long as NIC interrupts do not happen 
faster than they can be processed (leading to packet loss in the long run), it 
probably won't.

2/ I want to check first if my NIC got this feature enabled ?
How do I have to proceed to check then how to test ?

Good question. It's not only that your NIC needs to support input moderation, 
your OS needs to do that, too!
ethtool is your friend under recent GNU/linuxes, try ethtool --show-coalesce 
. However, on my devices, that always tells me that it 
cannot get device coalesce settings.

3/ When running a stream of packets over the USRP I got the following error:

thread[thread-per-block[24]: ]: msg length is
not a multiple of d_itemsize
This error is raised after a fixed number N of successfully sent packets
Could you please give me some hints on this issue.

Hm could you give some more hints on this issue? The error has something to do 
with a message source, and you talk about packets, but you don't say anything 
on the actual flowgraph you're using.

Hope I was able to help you a bit,
Marcus

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

Re: [Discuss-gnuradio] error code 0xf

[Marcus Müller]

Hello A.B.!
For the error code, I shall refer you to the UHD source code:
http://files.ettus.com/uhd_docs/doxygen/html/metadata_8hpp_source.html
And thus I saw:
Apparently, you receive bad packets. A quick "git grep 'vrt packet offset'" led 
to host/lib/transport/super_recv_packet_handler.hpp in the UHD source tree. I guess it 
really just checks whether your receive buffer is large enough to contain your header; 
how that could happen beats me.
Maybe if you elaborate on when and how you increased which buffer size, things 
could clear up.
I think follow-ups should be on usrp-us...@lists.ettus.com, however, so I'll 
crosspost this reply there, please sign up for that list.

Greetings,
Marcus



On 10/22/2013 09:18 AM, Baier wrote:

Dear all,

I have increased the buffer frame size from 1472 to 4096 bytes. Than I started 
my grc application and got the following message:
recv buffer smaller than vrt packet offset. UHD source block got error code 0xf.
Can somebody help me?
Thanks
A.B.

___
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] Code re-use in blocks / C++ inheritance with gr::sync_block

[Marcus Müller]

Hi Sylvain,

this is yet another incarnation of the diamond problem I discussed with Nemanja:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00150.html

Your glfw_.._impl is a double indirect subclass to base_sink_c:
glfw_sink_c_impl->glfw_sink_c->base_sink_c
glfw_sink_c_impl->base_sink_c_impl->base_sink_c
and thus, your glfw_sink_c_impl instance holds two separate instances of 
base_sink_c, therefore two instances of gr::basic_block and you won't 
necessarily connect the correct one (whichever that may be), and even if you 
did, the other one will be left unconnected, which also will lead to an error.
So: one of glfw_sink_c or base_sink_c must not inherit from gr::basic_block.
personally, I'd just not let glfw_sink_c_impl inherit from base_sink_c_impl, 
and move the common stuff directly to base_sink_c.

Greetings,
Marcus

On 10/22/2013 10:49 AM, Sylvain Munaut wrote:

Hi,

So what I'm trying to achieve is to share a lot of code (including the
gr::sync_block implementation for work/start/stop) and a common
interface between several gnuradio blocks.

What I have currently come up with is (short version, see bottom for
more complete version) :

---
class API base_sink_c : virtual public gr::sync_block {};
class API glfw_sink_c : virtual public base_sink_c {};

class base_sink_c_impl : virtual public base_sink_c {};
class glfw_sink_c_impl : public glfw_sink_c, public base_sink_c_impl {};
---

* base_sink_c is a collection of virtual methods that define the
common functionality between subblocks.
* glfw_sink_c is the interface of the 'glfw' variant (only one here
atm) and is a super-set of the one in base_sink_c.
* base_sink_c_impl is the implementation of all the common stuff,
including the start/stop/work of gr::sync_block
* glfw_sink_c_impl is the 'glfw' variant and is the class to be
instanciated, it contains all the glfw specific code.

But this doesn't seem to work ... it crashes when GR tries to attach
the block in the block graph ( backtrace http://pastebin.com/JeBUEgtK
).

This is the resulting C++ layout (dumped with -fdump-class-hierarchy )
http://pastebin.com/raw.php?i=cDWQQwHn

Anyone has a clue what I'm doing wrong ?

Cheers,

 Sylvain Munaut


---

More complete version:

class API base_sink_c : virtual public gr::sync_block
{
   /* Common exposed interface stuff (all virtual) */
}

class API glfw_sink_c : virtual public base_sink_c
{
  public:
   typedef boost::shared_ptr sptr;
   static sptr make();

   /* + Interface stuff specific to this variant (all virtual) */
}

class base_sink_c_impl : virtual public base_sink_c
{
   protected:
base_sink_c_impl(const char *block_name);

   public:
int work (int noutput_items,
 gr_vector_const_void_star &input_items,
 gr_vector_void_star &output_items);
bool start();
bool stop();

   private:
 /* all private stuff to the base implementation */
}

class glfw_sink_c_impl : public glfw_sink_c, public base_sink_c_impl
{
  public:
   glfw_sink_c_impl();
   virtual ~glfw_sink_c_impl();
}

Then on the implementation side I have :

base_sink_c_impl::base_sink_c_impl(const char *block_name)
   : gr::sync_block(block_name,
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(0, 0, 0))
{
   /* block specific stuff */
}

glfw_sink_c::sptr
glfw_sink_c::make()
{
 return gnuradio::get_initial_sptr(new glfw_sink_c_impl());
}

glfw_sink_c_impl::glfw_sink_c_impl()
   : base_sink_c_impl("glfw_sink_c")
{
/* ... */
}

___
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] Code re-use in blocks / C++ inheritance with gr::sync_block

[Sylvain Munaut]

Hi,

> this is yet another incarnation of the diamond problem I discussed with
> Nemanja:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-09/msg00150.html
>
> Your glfw_.._impl is a double indirect subclass to base_sink_c:
> glfw_sink_c_impl->glfw_sink_c->base_sink_c
> glfw_sink_c_impl->base_sink_c_impl->base_sink_c

Yeah and that's what the 'virtual' are for in the inheritance tree.

And if you look at the resulting tree according to C++,
http://pastebin.com/raw.php?i=cDWQQwHn

you have in the first path :

gr::fosphor::base_sink_c (0x7f7a522eebc8) 0 nearly-empty virtual

and in the second path, it ends with :

gr::fosphor::base_sink_c (0x7f7a522eebc8) alternative-path

with the same address and "alternative-path" leading me to believe it
did the right thing and pointed to the first instance of it rather
than create a second one.


> So: one of glfw_sink_c or base_sink_c must not inherit from gr::basic_block.

The issue there is that the exposed interface glfw_sink_c must have a
path to gr::sync_block visible to the user.
And I think that base_sink_c_impl also need a path to gr::sync_block
in it's hierarchy because it's the one actually implementing its
virtual methods (start/stop/work/...) and also using some of
gr::sync_block's methods.


> personally, I'd just not let glfw_sink_c_impl inherit from base_sink_c_impl,
> and move the common stuff directly to base_sink_c.

The problem I have with this is that I must expose a bunch of stuff in
the public header that I don't want to.

base_sink_c_impl has plenty of private method and members, none of
which the "user" should see (ie. not be installed in the public
headers)


Cheers,

Sylvain

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

Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block

[Marcus Müller]

Hi Sylvain,
this is getting really interesting :)
On 10/22/2013 11:55 AM, Sylvain Munaut wrote:

Yeah and that's what the 'virtual' are for in the inheritance tree.

And if you look at the resulting tree according to C++,
http://pastebin.com/raw.php?i=cDWQQwHn

I totally agree! So, only one basic_block instance, most probably.
So I dived into gnuradio-runtime/lib/flowgraph.cc, specifically looked at 
check_valid_port (lines 137ff);
could you verify that your program does not output something like "port number X 
exceeds..." or the like upon termination?

If you correctly called the chain of superconstructors, that shouldn't happen 
if you correctly set your io_signatures.

So: one of glfw_sink_c or base_sink_c must not inherit from gr::basic_block.

The issue there is that the exposed interface glfw_sink_c must have a
path to gr::sync_block visible to the user.

It has, by either inheritance detour :) all your inheritance is public.

And I think that base_sink_c_impl also need a path to gr::sync_block
in it's hierarchy because it's the one actually implementing its
virtual methods (start/stop/work/...) and also using some of
gr::sync_block's methods.

That's what I thought; therefore, I suggested moving the code shared among the 
glfw_sink_c_impl and the base_sink_c_impl to the common super class, 
base_sink_c.
If you do not want your flowgraphs to use base_sink_c, there is no sense in 
having base_sink_c_impl as a proxy between base_sink_c and glfw_sink_c_impl. 
Anyway, even if you use that intermediate class, you inheritance will become a 
path without the dreaded inheritance diamond.

personally, I'd just not let glfw_sink_c_impl inherit from base_sink_c_impl,
and move the common stuff directly to base_sink_c.

The problem I have with this is that I must expose a bunch of stuff in
the public header that I don't want to.
base_sink_c_impl has plenty of private method and members, none of
which the "user" should see (ie. not be installed in the public
headers)

I think that's the point of private and protected members, you shouldn't have 
to go to the total extreme of hiding everything away in an impl, if you plan to 
inherit from that impl later

Cheers,

Marcus

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

Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block

[Sylvain Munaut]

Hi Marcus,

> If you correctly called the chain of superconstructors, that shouldn't
> happen if you correctly set your io_signatures.

Yup, that was the issue.

I was defining the call to gr::sync_block constructor as part of the
base_sink_c_impl class constructor since it seemed the most logical
place for it to be.
But given the virtual inheritance , I can only define it as part of
glfw_sink_c_impl constructor and without this, the default constructor
was called (which sets neither the name nor the io signature).

Now, it works as intended :)


>> The problem I have with this is that I must expose a bunch of stuff in
>> the public header that I don't want to.
>> base_sink_c_impl has plenty of private method and members, none of
>> which the "user" should see (ie. not be installed in the public
>> headers)
>
> I think that's the point of private and protected members, you shouldn't
> have to go to the total extreme of hiding everything away in an impl, if you
> plan to inherit from that impl later

Well it's mostly because the private part include plenty of other
headers to define structures and objects that shouldn't be part of the
ABI.


Cheers and thanks for pointing me in the right direction :)

Sylvain

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

Re: [Discuss-gnuradio] Using USRP to transmit and receive samples

[lingeswar]

hi, i tried connecting a file sink at the tag debug place and i found o's and
1's coming. we may have to pack them back like opposite operation in
transmitter GRC. i used REPACK Bits block and tested that the actual data (1
to 96) is not coming back.. and we have to use the "check CRC" in the stream
crc block. but in the examples, it is given generate crc .. is that right?
is there any trick to get back the data  other than this.. looking forward
for reply..





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-USRP-to-transmit-and-receive-samples-tp44221p44306.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] zero ninput_items_required[0]

[Nemanja Savic]

Hello guys again!

Based on Martins suggestion and Marucs' explanation I copied some
principles from sync_interpolator and situation looks much better. I used
function set_output_multiple and set_relative rate and now the outcome of
calling forecast function is much better. For example, for symbol rate of
10k and sampling rate of 500k i get following:

ninput_items_required 8, noutput_items 4000
ninput_items_required 4, noutput_items 2000
ninput_items_required 2, noutput_items 1000
ninput_items_required 1, noutput_items 500
ninput_items_required 8, noutput_items 4000

And as u can see it always offers integer multiple of samp_rate/sym_rate.
The problem comes now when i run the flowgraph with vector source that
repeats the pattern. After calling forecast program executes work function
but it provides me 32768 input samples which is of course silly:

work function, ninput: 32768, noutput: 4000

I don't really get what might be a problem, cause when vecotr source
doesn't repeat the patern everything is fine.

Thank you and best
Nemanja


On Mon, Oct 21, 2013 at 4:36 PM, Marcus Müller  wrote:

>  Hm, I don't know why this should really happen before your source's work
> function is called.
> But basically, maybe this is part of GNU Radio trying to figure out how to
> assign buffers; I haven't dived very deep into that aspect of the runtime.
> However, since your forecast told GR that you're able to produce samples
> without input, I could imagine that your work gets scheduled simultaneously
> with those of your sources.
> To circumvent that, just don't lie ;) and tell the scheduler that you need
> input to produce output.
>
> Greetings,
> Marcus
>
> On 20.10.2013 13:11, Nemanja Savic wrote:
>
>   Thank you Marcus very much. I would like to ask some more questions.
>  For me it looks like the problem is at very begining when source has not
> produced any output, and it looks like forecast of my block is called
> before the work functino of the source? How should one cope with this? By
> checking if required number of input samples is zero and solving that case?
> How is that ensured for interpolator.
>
>  Thanks and kind regards,
>  Nemanja
>
>
> On Sat, Oct 19, 2013 at 10:35 AM, Marcus Müller wrote:
>
>>  Hi Nemanja,
>>
>> Considering following flowgraph, assume your block is A, and assume all
>> blocks work with the same itemsize.
>> [image: $\fbox{\textrm C}\rightarrow\fbox{\textrm
>> B}\rightarrow\fbox{\text{\textbf{A}}}\rightarrow\fbox{\textrm D}$]
>>
>> good question, but basically, when running, when A is done with a run of
>> work, it's thread notifies blocks "upstream" (B in this case) that it has
>> consumed [image: N] input items, making that space available for new
>> output; GNU radio then calls forecast of B with a noutput_items [image:
>> M_i = floor( 2 ** ( floor(log_2 N) - i) <= N, i in {0,1,...,floor(log_2 N)
>> +1}] to fill that space. However, if the upstream block B needs more
>> input items than C has provided, GNU Radio will repeatedly reduce the
>> number of samples it asks for until B needs less or equal samples as C has
>> produced.
>>
>> In your case, this only happens for 0 output items; thus your
>> general_work gets called with 0 input items, as Martin already stated.
>> So what happens then? Since A has not provided any more output items for
>> the blocks downstream, D can't do anything that it has not already been
>> doing. The downstream part of the flowgraph stalls. Upstream part: Since
>> GNU Radio has not been able to supply you with more than 0 input items, we
>> can assume that the upstream part of the flowgraph is stuck, or done.
>> Therefore, execution ends here.
>>
>> Greetings,
>> Marcus
>>
>>
>>
>> On 10/18/2013 03:19 PM, Nemanja Savic wrote:
>>
>>   Thank you Martin, I will try with the sync_decimator, but it is also
>> important for me to unterstand what's happening here.
>>  So, I have vector source -> throttle -> fsk_modulator -> scope sink.
>>  Vector source generates 8 symbols. From where scheduler starts, from
>> source or from the sink? And why it didn't stop for any value before 0?
>> What should I add into general block to avoid this?
>>
>>  Thank you
>>
>>
>> On Fri, Oct 18, 2013 at 2:59 PM, Martin Braun (CEL) > > wrote:
>>
>>> On Fri, Oct 18, 2013 at 02:32:48PM +0200, Nemanja Savic wrote:
>>> > The body of my forecast function is:
>>> >
>>> > ninput_items_required[0] = noutput_items * d_sym_rate /
>>> d_sampling_freq;
>>> > printf("ninput_items_required %d, noutput_items %d\n",
>>> ninput_items_required
>>> > [0], noutput_items);
>>>
>>>  If d_sym_rate and d_sampling_freq are integers, integer division will
>>> cause ninput_items_required to be zero for small values of
>>> noutput_items.
>>>
>>> > when i run execution, the output is following:
>>> >
>>> > ninput_items_required 8, noutput_items 4096
>>> > ninput_items_required 4, noutput_items 2048
>>> > ninput_items_required 2, noutput_items 1024
>>> > ninput_items_required 1, noutput_items 512
>>> > ninput

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Nemanja Savic]

Or maybe the question should be like this: on which parameter to rely when
making general work function, number of iput items or number of output
items?


On Tue, Oct 22, 2013 at 2:20 PM, Nemanja Savic  wrote:

> Hello guys again!
>
> Based on Martins suggestion and Marucs' explanation I copied some
> principles from sync_interpolator and situation looks much better. I used
> function set_output_multiple and set_relative rate and now the outcome of
> calling forecast function is much better. For example, for symbol rate of
> 10k and sampling rate of 500k i get following:
>
> ninput_items_required 8, noutput_items 4000
> ninput_items_required 4, noutput_items 2000
> ninput_items_required 2, noutput_items 1000
> ninput_items_required 1, noutput_items 500
> ninput_items_required 8, noutput_items 4000
>
> And as u can see it always offers integer multiple of samp_rate/sym_rate.
> The problem comes now when i run the flowgraph with vector source that
> repeats the pattern. After calling forecast program executes work function
> but it provides me 32768 input samples which is of course silly:
>
> work function, ninput: 32768, noutput: 4000
>
> I don't really get what might be a problem, cause when vecotr source
> doesn't repeat the patern everything is fine.
>
> Thank you and best
> Nemanja
>
>
> On Mon, Oct 21, 2013 at 4:36 PM, Marcus Müller  wrote:
>
>>  Hm, I don't know why this should really happen before your source's
>> work function is called.
>> But basically, maybe this is part of GNU Radio trying to figure out how
>> to assign buffers; I haven't dived very deep into that aspect of the
>> runtime.
>> However, since your forecast told GR that you're able to produce samples
>> without input, I could imagine that your work gets scheduled simultaneously
>> with those of your sources.
>> To circumvent that, just don't lie ;) and tell the scheduler that you
>> need input to produce output.
>>
>> Greetings,
>> Marcus
>>
>> On 20.10.2013 13:11, Nemanja Savic wrote:
>>
>>   Thank you Marcus very much. I would like to ask some more questions.
>>  For me it looks like the problem is at very begining when source has not
>> produced any output, and it looks like forecast of my block is called
>> before the work functino of the source? How should one cope with this? By
>> checking if required number of input samples is zero and solving that case?
>> How is that ensured for interpolator.
>>
>>  Thanks and kind regards,
>>  Nemanja
>>
>>
>> On Sat, Oct 19, 2013 at 10:35 AM, Marcus Müller wrote:
>>
>>>  Hi Nemanja,
>>>
>>> Considering following flowgraph, assume your block is A, and assume all
>>> blocks work with the same itemsize.
>>> [image: $\fbox{\textrm C}\rightarrow\fbox{\textrm
>>> B}\rightarrow\fbox{\text{\textbf{A}}}\rightarrow\fbox{\textrm D}$]
>>>
>>> good question, but basically, when running, when A is done with a run of
>>> work, it's thread notifies blocks "upstream" (B in this case) that it has
>>> consumed [image: N] input items, making that space available for new
>>> output; GNU radio then calls forecast of B with a noutput_items [image:
>>> M_i = floor( 2 ** ( floor(log_2 N) - i) <= N, i in {0,1,...,floor(log_2 N)
>>> +1}] to fill that space. However, if the upstream block B needs more
>>> input items than C has provided, GNU Radio will repeatedly reduce the
>>> number of samples it asks for until B needs less or equal samples as C has
>>> produced.
>>>
>>> In your case, this only happens for 0 output items; thus your
>>> general_work gets called with 0 input items, as Martin already stated.
>>> So what happens then? Since A has not provided any more output items for
>>> the blocks downstream, D can't do anything that it has not already been
>>> doing. The downstream part of the flowgraph stalls. Upstream part: Since
>>> GNU Radio has not been able to supply you with more than 0 input items, we
>>> can assume that the upstream part of the flowgraph is stuck, or done.
>>> Therefore, execution ends here.
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>>
>>> On 10/18/2013 03:19 PM, Nemanja Savic wrote:
>>>
>>>   Thank you Martin, I will try with the sync_decimator, but it is also
>>> important for me to unterstand what's happening here.
>>>  So, I have vector source -> throttle -> fsk_modulator -> scope sink.
>>>  Vector source generates 8 symbols. From where scheduler starts, from
>>> source or from the sink? And why it didn't stop for any value before 0?
>>> What should I add into general block to avoid this?
>>>
>>>  Thank you
>>>
>>>
>>> On Fri, Oct 18, 2013 at 2:59 PM, Martin Braun (CEL) <
>>> martin.br...@kit.edu> wrote:
>>>
 On Fri, Oct 18, 2013 at 02:32:48PM +0200, Nemanja Savic wrote:
 > The body of my forecast function is:
 >
 > ninput_items_required[0] = noutput_items * d_sym_rate /
 d_sampling_freq;
 > printf("ninput_items_required %d, noutput_items %d\n",
 ninput_items_required
 > [0], noutput_items);

  If d_sym_rate and d_sampling_freq are integers, intege

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Martin Braun (CEL)]

On Tue, Oct 22, 2013 at 02:22:20PM +0200, Nemanja Savic wrote:
> Or maybe the question should be like this: on which parameter to rely when
> making general work function, number of iput items or number of output items?

As I just said, in a sync_interpolator, you're not using general_work(),
and your question goes away.

MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


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

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Martin Braun (CEL)]

On Tue, Oct 22, 2013 at 02:20:04PM +0200, Nemanja Savic wrote:
> Hello guys again!
> 
> 
> Based on Martins suggestion and Marucs' explanation I copied some principles
> from sync_interpolator and situation looks much better. I used function
> set_output_multiple and set_relative rate and now the outcome of calling

FYI: When using sync_interpolator, it will call set_relative_rate for
you (that's why you specify an interpolation rate).

> forecast function is much better. For example, for symbol rate of 10k and
> sampling rate of 500k i get following:
> 
> ninput_items_required 8, noutput_items 4000
> ninput_items_required 4, noutput_items 2000
> ninput_items_required 2, noutput_items 1000
> ninput_items_required 1, noutput_items 500
> ninput_items_required 8, noutput_items 4000
> 
> 
> And as u can see it always offers integer multiple of samp_rate/sym_rate. The
> problem comes now when i run the flowgraph with vector source that repeats the
> pattern. After calling forecast program executes work function but it provides
> me 32768 input samples which is of course silly:
> 
> work function, ninput: 32768, noutput: 4000

Don't worry about that. In all sync blocks, the output buffer is what's
relevant. If you fill up the output buffer in this case, you will
consume 8 input items.
How are you even getting the number of input items?
sync_interpolator::work() doesn't tell you that.

It still seems like you're abusing the API somehow.

MB


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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


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

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Nemanja Savic]

Well, I still didn't try with interpolator, cause it seems that it will
work. I'd rather try to make it with general block and also learn more
about how the stuff work.
That's why I said that I used principles used for interpolator.
Ok, I am now tracking number of produces items and it works ok, from the
buffers point of view.

Thanks guys very much


On Tue, Oct 22, 2013 at 2:26 PM, Martin Braun (CEL) wrote:

> On Tue, Oct 22, 2013 at 02:20:04PM +0200, Nemanja Savic wrote:
> > Hello guys again!
> >
> >
> > Based on Martins suggestion and Marucs' explanation I copied some
> principles
> > from sync_interpolator and situation looks much better. I used function
> > set_output_multiple and set_relative rate and now the outcome of calling
>
> FYI: When using sync_interpolator, it will call set_relative_rate for
> you (that's why you specify an interpolation rate).
>
> > forecast function is much better. For example, for symbol rate of 10k and
> > sampling rate of 500k i get following:
> >
> > ninput_items_required 8, noutput_items 4000
> > ninput_items_required 4, noutput_items 2000
> > ninput_items_required 2, noutput_items 1000
> > ninput_items_required 1, noutput_items 500
> > ninput_items_required 8, noutput_items 4000
> >
> >
> > And as u can see it always offers integer multiple of
> samp_rate/sym_rate. The
> > problem comes now when i run the flowgraph with vector source that
> repeats the
> > pattern. After calling forecast program executes work function but it
> provides
> > me 32768 input samples which is of course silly:
> >
> > work function, ninput: 32768, noutput: 4000
>
> Don't worry about that. In all sync blocks, the output buffer is what's
> relevant. If you fill up the output buffer in this case, you will
> consume 8 input items.
> How are you even getting the number of input items?
> sync_interpolator::work() doesn't tell you that.
>
> It still seems like you're abusing the API somehow.
>
> MB
>
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Marcus Müller]

  
  
To be completely clear:
  In your original post you stated that your block really behaves
  like a sync_interpolator/decimator. Yet, you're reinventing the
  wheel by copying the wheel into your code.
  DO NOT just copy code to you not-sync block from sync_block if you
  want sync_interpolator/decimator's behaviour. That's totally
  confusing, a waste of time, and will lead to code that is badly
  maintanable.
  Instead, just make a subclass of sync_interpolator/decimator and
  replace its work function. You get all the features, free,
  well-tested, and maintained by someone else.
  If you, however, really need to implement something that works
  like sync_interpolator/decimator most of the time but needs to
  drop samples occasionally or something like that, you might be
  better of splitting your functionality to a sync_interpolator that
  does all the processing, and a non-sync block, that wraps the
  state machine (or whatever) to do the dropping (or whatever).
  However, from what you've posted, this does not seem necessary -
  just make a new block with "gr_modtool add", use "decimator" or
  "interpolator" as type, copy over your general work function's
  body to the work function and fix it accordingly, so that it no
  longer manually produces and consumes items.
  
  Greetings,
  Marcus
  
  On 10/22/2013 02:20 PM, Nemanja Savic wrote:


  

  

  
Hello guys again!
  

Based on Martins suggestion and Marucs' explanation I
copied some principles from sync_interpolator and
situation looks much better. I used function
set_output_multiple and set_relative rate and now the
outcome of calling forecast function is much better. For
example, for symbol rate of 10k and sampling rate of
500k i get following:

ninput_items_required 8, noutput_items 4000
ninput_items_required 4, noutput_items 2000
ninput_items_required 2, noutput_items 1000
ninput_items_required 1, noutput_items 500
ninput_items_required 8, noutput_items 4000

  
  And as u can see it always offers integer multiple of
  samp_rate/sym_rate. The problem comes now when i run the
  flowgraph with vector source that repeats the pattern.
  After calling forecast program executes work function but
  it provides me 32768 input samples which is of course
  silly:
  
  work function, ninput: 32768, noutput: 4000
  

I don't really get what might be a problem, cause when
vecotr source doesn't repeat the patern everything is fine.

  
  Thank you and best

Nemanja
  
  

On Mon, Oct 21, 2013 at 4:36 PM, Marcus
  Müller 
  wrote:
  

  Hm, I don't know why this should really happen before
your source's work function is called.
But basically, maybe this is part of GNU Radio trying to
figure out how to assign buffers; I haven't dived very
deep into that aspect of the runtime. 
However, since your forecast told GR that you're able to
produce samples without input, I could imagine that your
work gets scheduled simultaneously with those of your
sources. 
To circumvent that, just don't lie ;) and tell the
scheduler that you need input to produce output.

Greetings,
Marcus

  
On 20.10.2013 13:11, Nemanja Savic wrote:
  

  
  

  

  

  Thank you Marcus very much. I would like
to ask some more questions.
  
  For me it looks like the problem is at very
  begining when source has not produced any
  output, and it looks like forecast of my block
  is called before the work functino of the
  source? How should one cope with this? By
  checking if required number of input samples
  is zero and solving that case? How is that
  ensured for interpolator.
  
  

[Discuss-gnuradio] BladRF

[Muhammad JUNAID]

I am working on bladeRF, dose anyone working on it and facing this error?
Ubuntu 13.04
linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-140-gfb32ed16

<<< Welcome to GNU Radio Companion 3.7.1 >>>

i got this error while running osmocom_fft.

junaid@Junaid:~/gnuradio/gr-osmosdr$ osmocom_fft -a 
bladerf=0,fpga=/opt/bladeRF/fpga/hostedx115.rbf -s 800 -f 44600
linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-140-gfb32ed16

gr-osmosdr v0.1.0-23-g6f4e16ff (0.1.1git) gnuradio 3.7.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf 

FATAL: Failed to open HackRF device (-5) HACKRF_ERROR_NOT_FOUND

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to a gnuradio bug. The maintainers have been informed.

Source has no sample rates (wrong device arguments?).
 
BLADERF CLI info

bladeRF> load fpga /opt/bladeRF/fpga/hostedx115.rbf 
Loading fpga from /opt/bladeRF/fpga/hostedx115.rbf...
Done.
bladeRF> info

  Serial #:                 5cc7c3a07c529478308a9d5424965eb0
  VCTCXO DAC calibration:   0x99d1
  FPGA size:                115 KLE
  FPGA loaded:              yes
  USB bus:                  3
  USB address:              2
  Backend:                  libusb
  Instance:                 0

bladeRF> version

  bladeRF-cli version:        0.5.0-git-130cbba
  libbladeRF version:         0.6.2-git-130cbba

  Firmware version:           1.5.3-git-
  FPGA version:

GR-OSMOCOM enabled components 

-- 
-- ##
-- # gr-osmosdr enabled components                         
-- ##
--   * Python support
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle
--   * IQ File Source
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF Jawbreaker
--   * nuand bladeRF
-- 
-- ##
-- # gr-osmosdr disabled components                        
-- ##
--   * sysmocom OsmoSDR
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
-- 
-- Building for version: v0.1.0-23-g6f4e16ff / 0.1.1git
-- Using install prefix: /opt/gnuradio-3.7.1git
-- Configuring done
-- Generating done
-- Build files have been written to: /home/junaid/gnuradio/gr-osmosdr


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

Re: [Discuss-gnuradio] BladRF

[Ralph A. Schmid, dk5ras]

Yes, I had this problem. As far as I remember I uninstalled bladerf and
gr-osmosdr, then manually deleted all remains of it and of hackrf (what I
never used) from my system, compiled and installed again bladerf, compiled a
fresh version of gr-osmosdr with the cmake-option not to build hackrf
support, installed it, finally everything worked.

 

Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Muhammad JUNAID
Sent: Tuesday, October 22, 2013 3:02 PM
To: discuss-gnuradio@gnu.org
Cc: discuss-gnuradio-requ...@gnu.org
Subject: [Discuss-gnuradio] BladRF

 

I am working on bladeRF, dose anyone working on it and facing this error?

Ubuntu 13.04

linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-140-gfb32ed16

 

<<< Welcome to GNU Radio Companion 3.7.1 >>>

 

i got this error while running osmocom_fft.

 

junaid@Junaid:~/gnuradio/gr-osmosdr$ osmocom_fft -a
bladerf=0,fpga=/opt/bladeRF/fpga/hostedx115.rbf -s 800 -f 44600

linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.004-140-gfb32ed16

 

gr-osmosdr v0.1.0-23-g6f4e16ff (0.1.1git) gnuradio 3.7.1

built-in source types: file fcd rtl rtl_tcp uhd hackrf 

 

FATAL: Failed to open HackRF device (-5) HACKRF_ERROR_NOT_FOUND

 

Trying to fill up 1 missing channel(s) with null source(s).

This is being done to prevent the application from crashing

due to a gnuradio bug. The maintainers have been informed.

 

Source has no sample rates (wrong device arguments?).

 

BLADERF CLI info




bladeRF> load fpga /opt/bladeRF/fpga/hostedx115.rbf 

Loading fpga from /opt/bladeRF/fpga/hostedx115.rbf...

Done.

bladeRF> info

 

  Serial #: 5cc7c3a07c529478308a9d5424965eb0

  VCTCXO DAC calibration:   0x99d1

  FPGA size:115 KLE

  FPGA loaded:  yes

  USB bus:  3

  USB address:  2

  Backend:  libusb

  Instance: 0

 

bladeRF> version

 

  bladeRF-cli version:0.5.0-git-130cbba

  libbladeRF version: 0.6.2-git-130cbba

 

  Firmware version:   1.5.3-git-

  FPGA version:

 

GR-OSMOCOM enabled components 

 

-- 

-- ##

-- # gr-osmosdr enabled components 

-- ##

--   * Python support

--   * Osmocom IQ Imbalance Correction

--   * FUNcube Dongle

--   * IQ File Source

--   * Osmocom RTLSDR

--   * RTLSDR TCP Client

--   * Ettus USRP Devices

--   * HackRF Jawbreaker

--   * nuand bladeRF

-- 

-- ##

-- # gr-osmosdr disabled components

-- ##

--   * sysmocom OsmoSDR

--   * FUNcube Dongle Pro+

--   * Osmocom MiriSDR

-- 

-- Building for version: v0.1.0-23-g6f4e16ff / 0.1.1git

-- Using install prefix: /opt/gnuradio-3.7.1git

-- Configuring done

-- Generating done

-- Build files have been written to: /home/junaid/gnuradio/gr-osmosdr

 

 

Regards

Muhammad Junaid

 

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

[Discuss-gnuradio] Carrier Phase Measurement

[Raydel Abreu (CM2ESP)]

Hello all,

I am new to GNU Radio and I am still learning the basic. I have a quick
question. What blocks and which way can I use in order to "sample" and know
the phase of a tuned carrier at regular intervals.

General idea: Let's suppose there is a carrier, after applying proper
tuning (Freq Xlating FIR Filter, etc), I apply a PLL module (not sure
which: PLL Carrier Tracking or PLL Ref Out) in order to remove possible
drift from the receiver and output a steady carrier. How can I sample at
regular interval that corrected carrier phase. Assuming that intervals are
really equals I guess every time I should obtain the same phase value.

I will really appreciate any help in this matter, perhaps someone could
point me in the right direction.

My purpose is to observe ionospheric phase scintillation from a
geostationary satellite beacon, which outputs a steady carrier. Frequency
drifting should be related to RTL-SDR dongle and part of phase changes
related to ionospheric irregularities.

I attempted something similar with SpectrumLab and an analogue receiver but
due to receiver drifting and sound card poor sampling stability the phase
result was a phase rotation of several degrees by measured interval.
Perhaps GNU Radio and the PLL functions it has could help to overcome the
frequency drift in the measured carrier.

Thanks in advance,

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

Re: [Discuss-gnuradio] Carrier Phase Measurement

[Marcus Müller]

Hi Raydel,
try Keep N in M (keep 1 in N) for the "sampling".
However, if you correctly employ a PLL, your phase will be static; if it's not, 
than the PLL is not doing it's job well.

Greetings,
Marcus

On 10/22/2013 05:21 PM, Raydel Abreu (CM2ESP) wrote:

Hello all,

I am new to GNU Radio and I am still learning the basic. I have a quick question. What 
blocks and which way can I use in order to "sample" and know the phase of a 
tuned carrier at regular intervals.

General idea: Let's suppose there is a carrier, after applying proper tuning 
(Freq Xlating FIR Filter, etc), I apply a PLL module (not sure which: PLL 
Carrier Tracking or PLL Ref Out) in order to remove possible drift from the 
receiver and output a steady carrier. How can I sample at regular interval that 
corrected carrier phase. Assuming that intervals are really equals I guess 
every time I should obtain the same phase value.

I will really appreciate any help in this matter, perhaps someone could point 
me in the right direction.

My purpose is to observe ionospheric phase scintillation from a geostationary 
satellite beacon, which outputs a steady carrier. Frequency drifting should be 
related to RTL-SDR dongle and part of phase changes related to ionospheric 
irregularities.

I attempted something similar with SpectrumLab and an analogue receiver but due 
to receiver drifting and sound card poor sampling stability the phase result 
was a phase rotation of several degrees by measured interval. Perhaps GNU Radio 
and the PLL functions it has could help to overcome the frequency drift in the 
measured carrier.

Thanks in advance,

Raydel.


___
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] Carrier Phase Measurement

[Raydel Abreu (CM2ESP)]

Hi Marcus,

Thanks for the tip. In a previous e-mail Marcus D. Leech recommend me to
use the Quadrature Demodulator Block as something not perfect, but usable
to check for phase changes.

It works for me, as long as there is a pure carrier without phase changes,
and without care the amplitude, the Quadrature Demod outputs a float
number, quite constant, if there is a phase change, the resulting float
number changes.

Now, help me with a doubt regarding PLL. Let's assume the carrier is steady
(zero drift), if there is a phase change (not changing in freq) when passed
through the PLL, the phase changes are not conserved???

The idea of my small project is to correct any possible frequency drift due
to poor receiver stability while conserving the incomming phase changes
which is in part produced by the ionosphere.

So, how can I correct the drift while keeping the incoming changes of phase?

Kind Regards,

Raydel


2013/10/22 Marcus Müller 

>  Hi Raydel,
> try Keep N in M (keep 1 in N) for the "sampling".
> However, if you correctly employ a PLL, your phase will be static; if it's
> not, than the PLL is not doing it's job well.
>
> Greetings,
> Marcus
>
> On 10/22/2013 05:21 PM, Raydel Abreu (CM2ESP) wrote:
>
> Hello all,
>
>  I am new to GNU Radio and I am still learning the basic. I have a quick
> question. What blocks and which way can I use in order to "sample" and know
> the phase of a tuned carrier at regular intervals.
>
>  General idea: Let's suppose there is a carrier, after applying proper
> tuning (Freq Xlating FIR Filter, etc), I apply a PLL module (not sure
> which: PLL Carrier Tracking or PLL Ref Out) in order to remove possible
> drift from the receiver and output a steady carrier. How can I sample at
> regular interval that corrected carrier phase. Assuming that intervals are
> really equals I guess every time I should obtain the same phase value.
>
>  I will really appreciate any help in this matter, perhaps someone could
> point me in the right direction.
>
>  My purpose is to observe ionospheric phase scintillation from a
> geostationary satellite beacon, which outputs a steady carrier. Frequency
> drifting should be related to RTL-SDR dongle and part of phase changes
> related to ionospheric irregularities.
>
>  I attempted something similar with SpectrumLab and an analogue receiver
> but due to receiver drifting and sound card poor sampling stability the
> phase result was a phase rotation of several degrees by measured interval.
> Perhaps GNU Radio and the PLL functions it has could help to overcome the
> frequency drift in the measured carrier.
>
>  Thanks in advance,
>
>  Raydel.
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Carrier Phase Measurement

[Marcus Müller]

PLL stands for phase locked loop. It eliminates phase variations.

On 10/22/2013 06:21 PM, Raydel Abreu (CM2ESP) wrote:

Hi Marcus,

Thanks for the tip. In a previous e-mail Marcus D. Leech recommend me to use 
the Quadrature Demodulator Block as something not perfect, but usable to check 
for phase changes.

It works for me, as long as there is a pure carrier without phase changes, and 
without care the amplitude, the Quadrature Demod outputs a float number, quite 
constant, if there is a phase change, the resulting float number changes.

Now, help me with a doubt regarding PLL. Let's assume the carrier is steady 
(zero drift), if there is a phase change (not changing in freq) when passed 
through the PLL, the phase changes are not conserved???

The idea of my small project is to correct any possible frequency drift due to 
poor receiver stability while conserving the incomming phase changes which is 
in part produced by the ionosphere.

So, how can I correct the drift while keeping the incoming changes of phase?

Kind Regards,

Raydel


2013/10/22 Marcus Müller mailto:mar...@hostalia.de>>

Hi Raydel,
try Keep N in M (keep 1 in N) for the "sampling".
However, if you correctly employ a PLL, your phase will be static; if it's 
not, than the PLL is not doing it's job well.

Greetings,
Marcus

On 10/22/2013 05:21 PM, Raydel Abreu (CM2ESP) wrote:

Hello all,

I am new to GNU Radio and I am still learning the basic. I have a quick question. 
What blocks and which way can I use in order to "sample" and know the phase of 
a tuned carrier at regular intervals.

General idea: Let's suppose there is a carrier, after applying proper 
tuning (Freq Xlating FIR Filter, etc), I apply a PLL module (not sure which: 
PLL Carrier Tracking or PLL Ref Out) in order to remove possible drift from the 
receiver and output a steady carrier. How can I sample at regular interval that 
corrected carrier phase. Assuming that intervals are really equals I guess 
every time I should obtain the same phase value.

I will really appreciate any help in this matter, perhaps someone could 
point me in the right direction.

My purpose is to observe ionospheric phase scintillation from a 
geostationary satellite beacon, which outputs a steady carrier. Frequency 
drifting should be related to RTL-SDR dongle and part of phase changes related 
to ionospheric irregularities.

I attempted something similar with SpectrumLab and an analogue receiver but 
due to receiver drifting and sound card poor sampling stability the phase 
result was a phase rotation of several degrees by measured interval. Perhaps 
GNU Radio and the PLL functions it has could help to overcome the frequency 
drift in the measured carrier.

Thanks in advance,

Raydel.


___
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] Fwd: Carrier Phase Measurement

[Raydel Abreu (CM2ESP)]

One more thing

The Quadrature Demodulator produces a stream of floats. I used as
previously recommended Keep One in N for sample only 5 times by second.
However, which method can I use to save the Float Stream into a plain text
file. The File Sink Block outputs a binary file?

Best wishes,

Raydel

-- Forwarded message --
From: Raydel Abreu (CM2ESP) 
Date: 2013/10/22
Subject: Re: [Discuss-gnuradio] Carrier Phase Measurement
To: Marcus Müller 
Cc: discuss-gnuradio@gnu.org


Hi Marcus,

Thanks for the tip. In a previous e-mail Marcus D. Leech recommend me to
use the Quadrature Demodulator Block as something not perfect, but usable
to check for phase changes.

It works for me, as long as there is a pure carrier without phase changes,
and without care the amplitude, the Quadrature Demod outputs a float
number, quite constant, if there is a phase change, the resulting float
number changes.

Now, help me with a doubt regarding PLL. Let's assume the carrier is steady
(zero drift), if there is a phase change (not changing in freq) when passed
through the PLL, the phase changes are not conserved???

The idea of my small project is to correct any possible frequency drift due
to poor receiver stability while conserving the incomming phase changes
which is in part produced by the ionosphere.

So, how can I correct the drift while keeping the incoming changes of phase?

Kind Regards,

Raydel


2013/10/22 Marcus Müller 

>  Hi Raydel,
> try Keep N in M (keep 1 in N) for the "sampling".
> However, if you correctly employ a PLL, your phase will be static; if it's
> not, than the PLL is not doing it's job well.
>
> Greetings,
> Marcus
>
> On 10/22/2013 05:21 PM, Raydel Abreu (CM2ESP) wrote:
>
> Hello all,
>
>  I am new to GNU Radio and I am still learning the basic. I have a quick
> question. What blocks and which way can I use in order to "sample" and know
> the phase of a tuned carrier at regular intervals.
>
>  General idea: Let's suppose there is a carrier, after applying proper
> tuning (Freq Xlating FIR Filter, etc), I apply a PLL module (not sure
> which: PLL Carrier Tracking or PLL Ref Out) in order to remove possible
> drift from the receiver and output a steady carrier. How can I sample at
> regular interval that corrected carrier phase. Assuming that intervals are
> really equals I guess every time I should obtain the same phase value.
>
>  I will really appreciate any help in this matter, perhaps someone could
> point me in the right direction.
>
>  My purpose is to observe ionospheric phase scintillation from a
> geostationary satellite beacon, which outputs a steady carrier. Frequency
> drifting should be related to RTL-SDR dongle and part of phase changes
> related to ionospheric irregularities.
>
>  I attempted something similar with SpectrumLab and an analogue receiver
> but due to receiver drifting and sound card poor sampling stability the
> phase result was a phase rotation of several degrees by measured interval.
> Perhaps GNU Radio and the PLL functions it has could help to overcome the
> frequency drift in the measured carrier.
>
>  Thanks in advance,
>
>  Raydel.
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Carrier Phase Measurement

[Raydel Abreu (CM2ESP)]

Yes, you are right Marcus.

Well, what other method can I use to compensate a drifting receiver
while conserving the carrier's phase changes? Someone else wants to
jump in and give any thoughs???

Raydel

2013/10/22, Marcus Müller :
> PLL stands for phase locked loop. It eliminates phase variations.
>

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

Re: [Discuss-gnuradio] ATSC decoder example in GR 3.7.1

[Tom Rondeau]

On Tue, Oct 15, 2013 at 10:01 PM, Ethan Trewhitt
 wrote:
> As a part of my quest to understand some of the examples in GR (and
> eventually contribute some well-commented GRC examples of my own),
> I've been messing around with the atsc_rx.py script. Unfortunately,
> since I have a USRP2, I can't sample at 6.4Msps like the script wants.
> Instead, I tried sampling a strong local TV station at 10Msps and
> resampling at 6.4Msps, but the result is a ton of errors in the
> script's output and a large TS file that I can't make sense of.

Hi Ethan,

I just wanted to point out that we've been working with Andrew Davis
on fixing up ATSC to a) work better and b) work with 3.7. He's made a
good start on things here:

https://github.com/glneo/gnuradio/tree/atscfixup

There's still work to be done, and Johnathan and I have been talking
about how to best get this into GNU Radio. If you're pursuing this
project, definitely look here and maybe talk directly with Andrew.
He's apparently gotten pretty busy with school work this semester, so
having another person working on this might be really good to finish
it up.

Thanks,
Tom




> I tried the following steps. First, capture a few seconds of raw TV
> signal (channel 39 in my area is the physical frequency of WSB):
>
>uhd_rx_cfile -f 623M --samp-rate=10M -s wsb.iq
>
> In a local copy of atsc_rx.py, I added the following filter:
>
>resamp = filter.fractional_resampler_cc(0, 10/6.4)
>
> Then I added the resampler to the graph at the bottom of the script:
>
>tb.connect( srcf, is2c, resamp, rrc, ilp, duc, c2f, fpll, lp_filter)
>
> Finally I ran the script:
>
>./atsc_rx.py wsb.iq wsb.ts
>
> The console fills with errors related to the ATSC stream:
>
> 8404
> Using Volk machine: avx_64_mmx_orc
> Setting initial_freq: 3065000.00
> atsc_field_sync_demux: synced (FIELD-1) at 426209 [delta = 426209]
> atsc_viterbi_decoder: new starting offset = 0
> atsc_field_sync_demux: lost sync at  464481
> !!! atsci_equalizer: expected field sync, didn't find one
> atsc_field_sync_demux: segment number overflow
> atsc_viterbi_decoder: new starting offset = 7
> !!! atsci_equalizer: expected field sync, didn't find one
> atsc_field_sync_demux: segment number overflow
> atsc_field_sync_demux: lost sync at 1225761
> atsc_viterbi_decoder: new starting offset = 1...
>
> (and so on, many times over)
>
> I tried playing the output TS in vlc and reading it with avconv, but
> both programs found tons of errors with the file and couldn't do
> anything useful with it. For the record, with some tweaking of the Tx
> settings, I was able to transmit the captured IQ file over the air and
> play the clip on a nearby TV (on a different, unused channel), so I
> know the data is in there somewhere.
>
> My eventual goal is to turn this script into a GRC version, complete
> with GRC xml files for the ATSC blocks currently included in GR.
> However, I can't begin this process without having it working in the
> first place. Is there anyone out there who understands the current
> script and can modify it to work with an adjustable input sample rate?
> That would go a long way toward helping me understand it all. Thanks
> in advance.
>
> Ethan T (courtarro)
>
> ___
> 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] GRCon13 Presentations

[Tom Rondeau]

Hi everyone,

I just wanted to make sure everyone was aware that the all* of the
GRCon13 presentation slides have been uploaded to the website. Enjoy!

http://www.trondeau.com/grcon2013-presentations/

Tom

*Almost all. Missing Balint's slides, but I did link to his YouTube
video of The Balint Show, which is probably better than just the
slides themselves.

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

Re: [Discuss-gnuradio] Code re-use in blocks / C++ inheritance with gr::sync_block

[Johnathan Corgan]

On Tue, Oct 22, 2013 at 6:40 AM, Sylvain Munaut <246...@gmail.com> wrote:


> > I think that's the point of private and protected members, you shouldn't
> > have to go to the total extreme of hiding everything away in an impl, if
> you
> > plan to inherit from that impl later
>
> Well it's mostly because the private part include plenty of other
> headers to define structures and objects that shouldn't be part of the
> ABI.
>

This.  A major goal of the 3.7 refactoring was to expose as little as
possible of the internal needs of individual blocks, so that external users
of block classes wouldn't need to have headers installed, etc.

Glad you got it working.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QT GUI Range - broken in GRC 3.7.2git-107-g636140af ??

[Tom McDermott]

Have updated to the latest git, been a month or two since the last update here.


Previous 3.7.2git (a little back) ran fine.

With the latest, flowgraphs seem to start but immediately exit ('done') when
there is a QT GUI Range control on them.  If the QT GUI Range is deleted and 
replaced with
a QT GUI entry, (selecting the same variable that the Range previously 
selected) then the flow graph runs fine.

Tried it on several different flowgraphs contianing other QT GUI widgets, seems
that the range control breaks all the flowgraphs, and replacing with Entry 
fixes all.


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

Re: [Discuss-gnuradio] Misc questions, regarding Interrupt coalescing

[Johannes Demel]

Unfortunately last nights mail didn't get to the mailing list. But here
it is.


Hi,

first of all you might be interested in [1]. Depending on the actual
setup of your NIC latency depends a lot on interrupt coalescing. There
is also some further reading on this page.

Have fun

[1] http://code.ettus.com/redmine/ettus/projects/public/wiki/Latency

On 21.10.2013 13:19, Naceur wrote:
> Hello GR Forum,
> 
> I got some questions:
> 
> 1/ Did anyone already tested the effect of Interrupt coalescing on reducing
> the latency when host and USRP N2X0 are communicating and how far did he
> reduce this latency
> 
> 2/ I want to check first if my NIC got this feature enabled ?
> How do I have to proceed to check then how to test ? 
> 
> 3/ When running a stream of packets over the USRP I got the following error: 
> 
> thread[thread-per-block[24]: ]: msg length is
> not a multiple of d_itemsize  
> This error is raised after a fixed number N of successfully sent packets
> Could you please give me some hints on this issue.
> 
> Best regards,
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Misc-questions-regarding-Interrupt-coalescing-tp44285.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

[Discuss-gnuradio] forecast and set history function for haar decomposition

[Bharat Mukkala]

I am creating a new gnu radio block for decomposing the signal using haar
wavelet decompostion and includes the option of number of levels of
decompostion. 
In order to write the code, how should i set the set_history or forecast
function because in order to produce output the input signal should be
processed as a whole rather than in chunks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/forecast-and-set-history-function-for-haar-decomposition-tp44327.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