Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal

[Harry Zhang]

Dear Miklos,
I'm glad to hear from you.
The idea of this experiment is quite similar to the core of your 
honored paper "The flooding time synchronization protocol". It's a 
transmitter-receiver sync method using precious tx/rx timestamp to 
synchronize transmitter's and receiver's local timer.
On the transmitter side, sync message is transmitted every 1 sec. 
Using rx tags, it's easy to get the average receive interval is 
1.0003sec and the jitter is around 320us. Considering the interval 
jitter is 2*(rx jitter+rx jitter), the sync accuracy is 160us.
I wanna break into USRP FPGA to achieve 1us or less accuracy. And I 
don't understand your "continuously transmission". Could give me some 
details.


2013/10/12 9:03, Miklos Maroti wrote:

Hi Harrz,

What do you mean by 160us precision? How did you measure it or compute
it exactly? I do not understand your goal, but it is quite simple to
synchronize two usrps with continuous transmission to within one
sample and if you continuously receive the transmitted signal on the
transmitter side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.

Miklos

On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang  wrote:

Hi,
I have implemented time synchronization between two USRPs without GPSDO,
MIMO cable or referring to computer's time.It's a sender-receiver method
based on message exchange. It will be included in my next paper soon.
I use the tx_time and tx_sob tag to transmit the message at the planned
time. When this message researches the receiver, I can get the receive
time via rx_time tags. The transmit and receive time of tx tags and rx
tags are recorded in USRP motherboard without the jitter of Ethernet
cable or operating system. So I think it could achieve the best accuracy
without modifying FPGA.
The experiment shows the accuracy is around 160us. I think it's mostly
caused by the jitter of the tx tag's time. I wanna achieve better
accuracy than this and the best way is adding a hardware timestamp
module in FPGA. Is this way feasible?
As for now, I wanna get a depth understanding of the implementing of tx
tag,so I will know the accuracy limit of this method. But I'm not
familiar with the FPGA, so could anyone describe how tx_time tag
implemented or give me some documents about this?
Thanks in advance.

___
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] liquid-dsp in gnuradio... why?

[Alexandru Csete]

On Fri, Oct 11, 2013 at 6:51 PM, Johnathan Corgan
 wrote:
> On 10/11/2013 04:23 AM, Alexandru Csete wrote:
>
>> I am probably missing something or just misunderstand the situation,
>> so please enlighten me :)
>
> This is more Tom's area, but I'll comment since he's off enjoying life
> and (hopefully) ignoring GNU Radio for a bit.
>
> While there is a lot of overlap between existing signal processing
> capabilities in GNU Radio and liquid-dsp, we are interested in wrapping
> some portions of it into the GNU Radio SDR framework.  In particular,
> the library has a number of FEC codecs and low-level math routines that
> would help round-out GNU Radio's functionality.
>
> Also of interest is the liquid-fpm fixed-point math library, which could
> help GNU Radio operate in embedded environments that do not have
> floating point capabilities.
>
> The experimental work done with gr-liquiddsp is being done out-of-tree
> and we have *not* yet worked out a development plan to incorporate it.
>

Thanks for the information.

Alex

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

Re: [Discuss-gnuradio] What conditions will cause block destructor to be skipped?

[Marcus Müller]

Hi Tim,

you're entering a minefield there...
Since you've built your flowgraph using GRC, you have a python-constructed 
flowgraph. That's why things start to get confusing for the c++ developer.
First of all, destructors of python objects are called whenever the python 
runtime feels like it - this often happens when you do something like
object_name = None
but it doesn't necessarily has to happen right away. The Garbage Collector can 
choose when to do it, and sometimes, it decides not to do it at all - if your 
program terminates first, this might be the case. Furthermore, if it decides 
that at the end of runtime, it should destruct its output stream file handles 
before destructing your block, your printf output might be lost.
Then: You have a C++ object wrapped by SWIG. So, what you're seeing in Python 
is not actually an instance of your block, it is a SWIG object holding a 
reference to such an instance. Usually, when that Swig Object's python 
destructor is called, it should delete the block instance, too, but then again, 
if I knew what really happens inside SWIG, I'd feel a lot wiser.
Lastly: Destructors doing actual work is a tricky thing. Mostly, because, what does the 
runtime (both, c++ or python) do when a destructor throws an exception? In that case, 
should the runtime ignore it and just think "meh, whatever, it's dead anyway" 
or should it cause the program to exit with a failure state? And: what if a C++ 
destructor fails that got called by the python garbage collector? That shouldn't crash 
the global python interpreter, should it?

So these are the pitfalls I could think of. Maybe the situation is a lot 
easier, though :) Post some code, maybe a github gist or a pastebin!

Happy Hacking,
Marcus

On 10/12/2013 12:24 AM, Monahan-Mitchell, Tim wrote:

Rarely, I'm seeing evidence that my custom source block destructor is not being 
called.

My flowgraph was built with "No GUI" and "Prompt for Exit" options (GR 3.7.1+)

The condition is that my source block's work function has moved to a state 
returning WORK_DONE, and will stay in that state.

When I press Enter to end the flowgraph, I sometimes don't see the usual ending 
printf() outputs. Fortunately, it does not happen often.

This article cites such a case: 
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00055.html, but 
my flowgraph only has my custom source block and a File Sink block.

Regards,
Tim

___
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] Time synchronization between two USRPs without external signal

[Miklos Maroti]

Hi Harry,

First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision (better than 1us). Once you can do this, then transmit some
pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
and it is possible to synchronize to that with sampling rate precision
again. Now comes the trick: node A not only transmits continuously,
but it also receives continuously just like node B (with an antenna or
just overhearing in the board). Both A and B synchronizes to the
signal transmitted by A. In case of node A you do not have to worry of
slightly different clocks, so once you are synchronized you will never
get out of sync if you count the number of samples. In the case of
node B it is harder, since node A might run a little faster or slower,
so you will get out of sync, so you have to maintain synchronization.
At this point, you have achieved synchronization of the two USRP
nodes: you can stop sending periodically (continue spending close to
zero samples) and then you can sample some data from node C, doing
beam forming (depends on modulation), or whatever. You can correlate
the received samples at node B with the received samples at node A
with close to one sample precision (better than 1us).

If you do not want to transmit all the time, then you can use TX tags,
but it gets a little trickier, and I think there is some bug in the
FPGA hardware to cause very rarely one sample shift between the TX and
RX chain. I am not absolutely sure about this, but I could not explain
something in any other way.

Best,
Miklos

On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang  wrote:
> Dear Miklos,
> I'm glad to hear from you.
> The idea of this experiment is quite similar to the core of your honored
> paper "The flooding time synchronization protocol". It's a
> transmitter-receiver sync method using precious tx/rx timestamp to
> synchronize transmitter's and receiver's local timer.
> On the transmitter side, sync message is transmitted every 1 sec. Using
> rx tags, it's easy to get the average receive interval is 1.0003sec and the
> jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx
> jitter), the sync accuracy is 160us.
> I wanna break into USRP FPGA to achieve 1us or less accuracy. And I
> don't understand your "continuously transmission". Could give me some
> details.
>
>
> 2013/10/12 9:03, Miklos Maroti wrote:
>
> Hi Harrz,
>
> What do you mean by 160us precision? How did you measure it or compute
> it exactly? I do not understand your goal, but it is quite simple to
> synchronize two usrps with continuous transmission to within one
> sample and if you continuously receive the transmitted signal on the
> transmitter side, then you can avoid all time stamping problems and
> effectively synchronize the tx and rx chains of a single usrp.
>
> Miklos
>
> On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang  wrote:
>
> Hi,
> I have implemented time synchronization between two USRPs without GPSDO,
> MIMO cable or referring to computer's time.It's a sender-receiver method
> based on message exchange. It will be included in my next paper soon.
> I use the tx_time and tx_sob tag to transmit the message at the planned
> time. When this message researches the receiver, I can get the receive
> time via rx_time tags. The transmit and receive time of tx tags and rx
> tags are recorded in USRP motherboard without the jitter of Ethernet
> cable or operating system. So I think it could achieve the best accuracy
> without modifying FPGA.
> The experiment shows the accuracy is around 160us. I think it's mostly
> caused by the jitter of the tx tag's time. I wanna achieve better
> accuracy than this and the best way is adding a hardware timestamp
> module in FPGA. Is this way feasible?
> As for now, I wanna get a depth understanding of the implementing of tx
> tag,so I will know the accuracy limit of this method. But I'm not
> familiar with the FPGA, so could anyone describe how tx_time tag
> implemented or give me some documents about this?
> Thanks in advance.
>
> ___
> 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] Time synchronization between two USRPs without external signal

[Harry Zhang]

Dear Miklos,
Thank you for your inspiring reply.
1.I do think this method sounds like a receiver-receiver sync while 
sync message's transmitter A also doing beacon node C's function ( 
(1)sending sync message and (2)recording receive time which would be 
sended to B for sync).Is it correct?

2.For 1us accuracy, does it mean the sample rate must be more than 1e6?
3.Does "close to zero samples" means the sample_rate*sample_offset 
produces larger error when I use it for getting sync message's receive time?
4.The 1us is the jitter caused by sample duration.What about the 
jitter produced by tx/rx tags? I do think 160us is mainly caused by the 
difference between actual time when message leaving/arriving antenna and 
tx/rx tags's time.What's your opinion?


Best,
Harry

2013/10/12 19:17, Miklos Maroti wrote:

Hi Harry,

First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision (better than 1us). Once you can do this, then transmit some
pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
and it is possible to synchronize to that with sampling rate precision
again. Now comes the trick: node A not only transmits continuously,
but it also receives continuously just like node B (with an antenna or
just overhearing in the board). Both A and B synchronizes to the
signal transmitted by A. In case of node A you do not have to worry of
slightly different clocks, so once you are synchronized you will never
get out of sync if you count the number of samples. In the case of
node B it is harder, since node A might run a little faster or slower,
so you will get out of sync, so you have to maintain synchronization.
At this point, you have achieved synchronization of the two USRP
nodes: you can stop sending periodically (continue spending close to
zero samples) and then you can sample some data from node C, doing
beam forming (depends on modulation), or whatever. You can correlate
the received samples at node B with the received samples at node A
with close to one sample precision (better than 1us).

If you do not want to transmit all the time, then you can use TX tags,
but it gets a little trickier, and I think there is some bug in the
FPGA hardware to cause very rarely one sample shift between the TX and
RX chain. I am not absolutely sure about this, but I could not explain
something in any other way.

Best,
Miklos

On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang  wrote:

Dear Miklos,
 I'm glad to hear from you.
 The idea of this experiment is quite similar to the core of your honored
paper "The flooding time synchronization protocol". It's a
transmitter-receiver sync method using precious tx/rx timestamp to
synchronize transmitter's and receiver's local timer.
 On the transmitter side, sync message is transmitted every 1 sec. Using
rx tags, it's easy to get the average receive interval is 1.0003sec and the
jitter is around 320us. Considering the interval jitter is 2*(rx jitter+rx
jitter), the sync accuracy is 160us.
 I wanna break into USRP FPGA to achieve 1us or less accuracy. And I
don't understand your "continuously transmission". Could give me some
details.


2013/10/12 9:03, Miklos Maroti wrote:

Hi Harrz,

What do you mean by 160us precision? How did you measure it or compute
it exactly? I do not understand your goal, but it is quite simple to
synchronize two usrps with continuous transmission to within one
sample and if you continuously receive the transmitted signal on the
transmitter side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.

Miklos

On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang  wrote:

Hi,
I have implemented time synchronization between two USRPs without GPSDO,
MIMO cable or referring to computer's time.It's a sender-receiver method
based on message exchange. It will be included in my next paper soon.
I use the tx_time and tx_sob tag to transmit the message at the planned
time. When this message researches the receiver, I can get the receive
time via rx_time tags. The transmit and receive time of tx tags and rx
tags are recorded in USRP motherboard without the jitter of Ethernet
cable or operating system. So I think it could achieve the best accuracy
without modifying FPGA.
The experiment shows the accuracy is around 160us. I think it's mostly
caused by the jitter of the tx tag's time. I wanna achieve better
accuracy than this and the best way is adding a hardware timestamp
module in FPGA. Is this way feasible?
As for now, I wanna get a depth understanding of the implementing of tx
tag,so I will know the accuracy limit of this method. But I'm not
familiar with the FPGA, so could anyone describe how tx_time tag
implemented or give me some documents about this?
Tha

Re: [Discuss-gnuradio] What conditions will cause block destructor to be skipped?

[Monahan-Mitchell, Tim]

> you're entering a minefield there...

Thanks for helping me navigate :)

> First of all, destructors of python objects are called whenever the python 
> runtime feels like it - this often happens when you do something like 
> object_name = None but it doesn't necessarily has to happen right away.
> The Garbage Collector can choose when to do it, and sometimes, it decides not 
> to do it at all - if your program terminates first, this might be the case.
> Furthermore, if it decides that at the end of runtime, it should destruct its 
> output stream file handles before destructing your block, your printf output 
> might be lost.

So I know it isn't just dropping printf output, as other "clean-up" code does 
not execute.

> So these are the pitfalls I could think of. Maybe the situation is a lot 
> easier, though :) Post some code, maybe a github gist or a pastebin!

All excellent ideas, especially the GC that rightfully  turns up its nose at 
any destructor complaints.

So it is good to know that it is a bit out of my hands, but I can certainly 
move my "clean-up" code to the point where the work() method signals WORK_DONE. 
Sorry, I can't possibly air my dirty laundry on a pastebin :(.

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

[Discuss-gnuradio] GRC problems

[Johannes Demel]

Hi list,

I discovered 2 problems with GRC recently.

1. I have a custom block with a message port (with a fixed port name)
and some stream ports which include a ... definition.
The whole thing works fine as long as I have a fixed number of ports.
Each declared separately. But as soon as I use a nport statement GRC
won't display this block correctly [1]. Even worse if I enter values
which affect the number of ports, the whole flowgraph will disappear.
Just a grey flowgraph page.

2. To make things easier for me (and to not create a well known kind of
artwork) I use hier blocks. This works fine as long as I have fixed size
vector ports. But adding a parameter block, say vlen, for vector size to
dynamically change the hier block doesn't work. The python generator
does not generate the hier block python file with vlen as vector size.
Instead it puts in the default value. A parameter block without default
value results in an error. A hard coded vector size is not exactly
helpful in this case.

I didn't have time to dig into it yet. Thus I thought I share my
experience with you. Maybe I am not the only one with this problem and
someone already knows how to fix it.

Happy hacking
Johannes

[1]

  msg
  message
  1



  in
  complex
  $vlen
  $ports


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

Re: [Discuss-gnuradio] GRC problems

[Jared Clements]

I'll confirm that #2 is either a bug or merely unexpected behavior.  I work
around it by prototyping hier blocks as custom GRC blocks, then using that
to build an OOT module block that actually works.  Being unable to enter
parameters at run time is severely limiting.

I've not experienced #1, that functionality seems to work once I get the
python file and the GRC file matching.  I was getting the same errors for a
while until I found the right idiom.

Jared
On Oct 12, 2013 11:18 AM, "Johannes Demel"  wrote:

> Hi list,
>
> I discovered 2 problems with GRC recently.
>
> 1. I have a custom block with a message port (with a fixed port name)
> and some stream ports which include a ... definition.
> The whole thing works fine as long as I have a fixed number of ports.
> Each declared separately. But as soon as I use a nport statement GRC
> won't display this block correctly [1]. Even worse if I enter values
> which affect the number of ports, the whole flowgraph will disappear.
> Just a grey flowgraph page.
>
> 2. To make things easier for me (and to not create a well known kind of
> artwork) I use hier blocks. This works fine as long as I have fixed size
> vector ports. But adding a parameter block, say vlen, for vector size to
> dynamically change the hier block doesn't work. The python generator
> does not generate the hier block python file with vlen as vector size.
> Instead it puts in the default value. A parameter block without default
> value results in an error. A hard coded vector size is not exactly
> helpful in this case.
>
> I didn't have time to dig into it yet. Thus I thought I share my
> experience with you. Maybe I am not the only one with this problem and
> someone already knows how to fix it.
>
> Happy hacking
> Johannes
>
> [1]
> 
>   msg
>   message
>   1
> 
>
> 
>   in
>   complex
>   $vlen
>   $ports
> 
>
> ___
> 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] possible bug with hier_block2_detail::msg_disconnect

[Johnathan Corgan]

On 09/29/2013 09:27 PM, Mark Cottrell wrote:

> I am working with gnuradio 3.7.2git-28-g639e154d and I have a
> hierarchical block with a message output that I have been using as part
> of a larger flowgraph.  Yesterday I found that whenever I call
> msg_disconnect on the top block with the hier block as the source, I get
> an error logged about it having no subscribers.  I verified this by
> printing out the subscribers in calls to message_port_sub and
> message_port_unsub.
> 
> It seems that when you call msg_connect, the call to message_port_sub is
> not made until the flowgraph has been flattened, so the subscription
> does not belong to the hier block, it belongs to the block inside the
> hier block that has the message output.  However, when you call
> msg_disconnect, it simply attempts to call message_port_unsub on on the
> hier block, which fails, as the hier block has no subscriptions.
> 
> To get around this, I simply commented out the call to
> message_port_unsub in msg_disconnect, but this isn't ideal and won't fix
> the problem in all cases.
> 
> So my question is, is this a bug? If so, is it known about, and if not
> can an issue please be raised to track it?

(Sorry for the delay in getting to this.)

This indeed sounds like a bug.  Can you create a ticket for this on the
gnuradio.org website, and attach a script that creates the error for you?

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC problems

[West, Nathan]

Re: #1, if the block's xml is malformed then GRC will basically show
nothing (that grey flowgraph page you describe). Are you defining $ports in
the make node? Compare to a similar block to make sure everything is
defined properly.
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_streams_to_stream.xml

I'm not sure of a way to debug what section might be wrong, so compare
against other blocks with message ports too.



On Sat, Oct 12, 2013 at 12:58 PM, Jared Clements
wrote:

> I'll confirm that #2 is either a bug or merely unexpected behavior.  I
> work around it by prototyping hier blocks as custom GRC blocks, then using
> that to build an OOT module block that actually works.  Being unable to
> enter parameters at run time is severely limiting.
>
> I've not experienced #1, that functionality seems to work once I get the
> python file and the GRC file matching.  I was getting the same errors for a
> while until I found the right idiom.
>
> Jared
> On Oct 12, 2013 11:18 AM, "Johannes Demel"  wrote:
>
>> Hi list,
>>
>> I discovered 2 problems with GRC recently.
>>
>> 1. I have a custom block with a message port (with a fixed port name)
>> and some stream ports which include a ... definition.
>> The whole thing works fine as long as I have a fixed number of ports.
>> Each declared separately. But as soon as I use a nport statement GRC
>> won't display this block correctly [1]. Even worse if I enter values
>> which affect the number of ports, the whole flowgraph will disappear.
>> Just a grey flowgraph page.
>>
>> 2. To make things easier for me (and to not create a well known kind of
>> artwork) I use hier blocks. This works fine as long as I have fixed size
>> vector ports. But adding a parameter block, say vlen, for vector size to
>> dynamically change the hier block doesn't work. The python generator
>> does not generate the hier block python file with vlen as vector size.
>> Instead it puts in the default value. A parameter block without default
>> value results in an error. A hard coded vector size is not exactly
>> helpful in this case.
>>
>> I didn't have time to dig into it yet. Thus I thought I share my
>> experience with you. Maybe I am not the only one with this problem and
>> someone already knows how to fix it.
>>
>> Happy hacking
>> Johannes
>>
>> [1]
>> 
>>   msg
>>   message
>>   1
>> 
>>
>> 
>>   in
>>   complex
>>   $vlen
>>   $ports
>> 
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC problems

[Johannes Demel]

Hi Nathan,

My guess is that the problem is a bit more tricky.

The XML block definition works fine as long as the message port is not
present. I can use nports as shown in stream_to_streams.

It also works fine as long as the nports statement is not used and a
message port is defined. This means copy and paste the stream port
definition for every port. Assign a port name manually etc.

Nevertheless the combination using nports and message ports in one XML
definition fails. I hope that clarifies my problem description.

Johannes

On 12.10.2013 13:43, West, Nathan wrote:
> Re: #1, if the block's xml is malformed then GRC will basically show
> nothing (that grey flowgraph page you describe). Are you defining $ports
> in the make node? Compare to a similar block to make sure everything is
> defined properly.
> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_streams_to_stream.xml
> 
> I'm not sure of a way to debug what section might be wrong, so compare
> against other blocks with message ports too.
> 
> 
> 
> On Sat, Oct 12, 2013 at 12:58 PM, Jared Clements
> mailto:jared.cleme...@gmail.com>> wrote:
> 
> I'll confirm that #2 is either a bug or merely unexpected behavior. 
> I work around it by prototyping hier blocks as custom GRC blocks,
> then using that to build an OOT module block that actually works. 
> Being unable to enter parameters at run time is severely limiting.
> 
> I've not experienced #1, that functionality seems to work once I get
> the python file and the GRC file matching.  I was getting the same
> errors for a while until I found the right idiom.
> 
> Jared
> 
> On Oct 12, 2013 11:18 AM, "Johannes Demel"  > wrote:
> 
> Hi list,
> 
> I discovered 2 problems with GRC recently.
> 
> 1. I have a custom block with a message port (with a fixed port
> name)
> and some stream ports which include a ...
> definition.
> The whole thing works fine as long as I have a fixed number of
> ports.
> Each declared separately. But as soon as I use a nport statement GRC
> won't display this block correctly [1]. Even worse if I enter values
> which affect the number of ports, the whole flowgraph will
> disappear.
> Just a grey flowgraph page.
> 
> 2. To make things easier for me (and to not create a well known
> kind of
> artwork) I use hier blocks. This works fine as long as I have
> fixed size
> vector ports. But adding a parameter block, say vlen, for vector
> size to
> dynamically change the hier block doesn't work. The python generator
> does not generate the hier block python file with vlen as vector
> size.
> Instead it puts in the default value. A parameter block without
> default
> value results in an error. A hard coded vector size is not exactly
> helpful in this case.
> 
> I didn't have time to dig into it yet. Thus I thought I share my
> experience with you. Maybe I am not the only one with this
> problem and
> someone already knows how to fix it.
> 
> Happy hacking
> Johannes
> 
> [1]
> 
>   msg
>   message
>   1
> 
> 
> 
>   in
>   complex
>   $vlen
>   $ports
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 



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

Re: [Discuss-gnuradio] GRC problems

[Johannes Demel]

On 12.10.2013 10:58, Jared Clements wrote:
> I'll confirm that #2 is either a bug or merely unexpected behavior.  I
> work around it by prototyping hier blocks as custom GRC blocks, then
> using that to build an OOT module block that actually works.  Being
> unable to enter parameters at run time is severely limiting.

For now this is the solution of choice. But in my opinion a graphical
representation helps to understand a flowgraph and I want to create
everything as self-explanatory as possible.

> 
> I've not experienced #1, that functionality seems to work once I get the
> python file and the GRC file matching.  I was getting the same errors
> for a while until I found the right idiom.

Can you share your setup? Or point to a repository? That would be very
helpful.

Johannes

> 
> Jared
> 
> On Oct 12, 2013 11:18 AM, "Johannes Demel"  > wrote:
> 
> Hi list,
> 
> I discovered 2 problems with GRC recently.
> 
> 1. I have a custom block with a message port (with a fixed port name)
> and some stream ports which include a ... definition.
> The whole thing works fine as long as I have a fixed number of ports.
> Each declared separately. But as soon as I use a nport statement GRC
> won't display this block correctly [1]. Even worse if I enter values
> which affect the number of ports, the whole flowgraph will disappear.
> Just a grey flowgraph page.
> 
> 2. To make things easier for me (and to not create a well known kind of
> artwork) I use hier blocks. This works fine as long as I have fixed size
> vector ports. But adding a parameter block, say vlen, for vector size to
> dynamically change the hier block doesn't work. The python generator
> does not generate the hier block python file with vlen as vector size.
> Instead it puts in the default value. A parameter block without default
> value results in an error. A hard coded vector size is not exactly
> helpful in this case.
> 
> I didn't have time to dig into it yet. Thus I thought I share my
> experience with you. Maybe I am not the only one with this problem and
> someone already knows how to fix it.
> 
> Happy hacking
> Johannes
> 
> [1]
> 
>   msg
>   message
>   1
> 
> 
> 
>   in
>   complex
>   $vlen
>   $ports
> 
> 
> ___
> 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] GRC problems

[Jared Clements]

Check the order, there's apparently only one tag order that works.  I
brought it up last week and was told it was known behavior.

Jared
On Oct 12, 2013 2:59 PM, "Johannes Demel"  wrote:

> Hi Nathan,
>
> My guess is that the problem is a bit more tricky.
>
> The XML block definition works fine as long as the message port is not
> present. I can use nports as shown in stream_to_streams.
>
> It also works fine as long as the nports statement is not used and a
> message port is defined. This means copy and paste the stream port
> definition for every port. Assign a port name manually etc.
>
> Nevertheless the combination using nports and message ports in one XML
> definition fails. I hope that clarifies my problem description.
>
> Johannes
>
> On 12.10.2013 13:43, West, Nathan wrote:
> > Re: #1, if the block's xml is malformed then GRC will basically show
> > nothing (that grey flowgraph page you describe). Are you defining $ports
> > in the make node? Compare to a similar block to make sure everything is
> > defined properly.
> >
> https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_streams_to_stream.xml
> >
> > I'm not sure of a way to debug what section might be wrong, so compare
> > against other blocks with message ports too.
> >
> >
> >
> > On Sat, Oct 12, 2013 at 12:58 PM, Jared Clements
> > mailto:jared.cleme...@gmail.com>> wrote:
> >
> > I'll confirm that #2 is either a bug or merely unexpected behavior.
> > I work around it by prototyping hier blocks as custom GRC blocks,
> > then using that to build an OOT module block that actually works.
> > Being unable to enter parameters at run time is severely limiting.
> >
> > I've not experienced #1, that functionality seems to work once I get
> > the python file and the GRC file matching.  I was getting the same
> > errors for a while until I found the right idiom.
> >
> > Jared
> >
> > On Oct 12, 2013 11:18 AM, "Johannes Demel"  > > wrote:
> >
> > Hi list,
> >
> > I discovered 2 problems with GRC recently.
> >
> > 1. I have a custom block with a message port (with a fixed port
> > name)
> > and some stream ports which include a ...
> > definition.
> > The whole thing works fine as long as I have a fixed number of
> > ports.
> > Each declared separately. But as soon as I use a nport statement
> GRC
> > won't display this block correctly [1]. Even worse if I enter
> values
> > which affect the number of ports, the whole flowgraph will
> > disappear.
> > Just a grey flowgraph page.
> >
> > 2. To make things easier for me (and to not create a well known
> > kind of
> > artwork) I use hier blocks. This works fine as long as I have
> > fixed size
> > vector ports. But adding a parameter block, say vlen, for vector
> > size to
> > dynamically change the hier block doesn't work. The python
> generator
> > does not generate the hier block python file with vlen as vector
> > size.
> > Instead it puts in the default value. A parameter block without
> > default
> > value results in an error. A hard coded vector size is not
> exactly
> > helpful in this case.
> >
> > I didn't have time to dig into it yet. Thus I thought I share my
> > experience with you. Maybe I am not the only one with this
> > problem and
> > someone already knows how to fix it.
> >
> > Happy hacking
> > Johannes
> >
> > [1]
> > 
> >   msg
> >   message
> >   1
> > 
> >
> > 
> >   in
> >   complex
> >   $vlen
> >   $ports
> > 
> >
> > ___
> > 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] GR-RADAR-MONO module

[Arturo Rinaldi]

Hi folks,

I was wondering if I am currently able to use the latest revision of the 
GR module, the one from the 3.4.2 tarball, with the 3.6.4.1 source 
tarball and the UHD driver of course.


I have browsed through python code and at a first glance it shouldn't be 
so difficult to update it by replacing the USRP objects with the UHD 
ones. However, I have some questions about it :


1) Can I use the included firmware to set up the FPGA of the usrp1 with 
the UHD driver (by which I mean the *fifo_1clk.v*, *radar_tb.v* and 
*usrp_radar_mono.v* fpga code) ?


2) Is the generated waveform the *CHIRP* one ?

3) Can I modify its frequency and amplitude according to my needs ?

Thank you in advance.

Kind Regards,

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

[Discuss-gnuradio] Link in README to build instructions has moved but is 404

[Heath Hunnicutt]

The link in the git README is

http://gnuradio.org/doc/doxygen/page_build.html

to the detailed build instructions, however, the link should be:

http://gnuradio.org/doc/doxygen-3.7/build_guide.html

and this could be fixed with a redirect at the web server or a change to
the readme.  I would suggest the version-independent redirect.

I would have opened an issue to track this, but I don't seem to have the
ability to do so after creating my gnuradio.org account.

It's a small thing, but it may impede contributors to the project, so worth
fixing.

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