Re: [Discuss-gnuradio] header_payload_demux

[Martin Braun]

On 30.05.2014 03:28, xianda wrote:

Hi Thanks for your kindly reply. 1.The second
question is:I see the fft block,it has one option:shift,and you set
yes. And in the transmit part,we should do the ifft.And in
the receive part,we should do the fft. They all set the
shift:yes. And now I want to save the data to file and
analyse the data by matlab. In the transmit maybe
ifft(fftshift(symbol)),but in the receive what command? 2.I
see maybe you don't use the pilot in the receive part.Am I
right? 3.I see maybe the cyclic prefix is dropped in the
header_payload_demux block.Am I right? Thank you.Can you
explain it?Thank you.Best regards At 2014-05-30 05:05:54,



Xianda,

sorry, I still have troubles understanding your question. It depends on 
where in the flow graph you're actually saving the file. If shift is set 
to yes, the output is shifted, or the input is regarded as shifted.


M

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

Re: [Discuss-gnuradio] header_payload_demux

[Marcus Müller]

> The second question is:I see the fft block,it has one option:shift,and
you set yes.
The FFT block is able to shift the left half of your vector to the end.
It's basically identical to the fftshift function in Matlab: With shift,
f=0 is the middle bin (and not the first one) .

> And now I want to save the data to file and analyse the data by matlab.
> In the transmit maybe ifft(fftshift(symbol))

ifft(Ifftshift()), iff you want to have the pre-fft data.

> but in the receive what command?
What receiver?
You don't really tell us how and under what aspect you want to analyze the 
data; this seems to more of an communications engineering/design question, than 
GNU Radio-related?

> I see maybe you don't use the pilot in the receive part. Am I right?

Sorry, I did not understand. Receive part of what? So long, we have only been 
talking about header_payload_demux, which does exactly that: demuxing packet 
header and payload.

I think that generally you are on a good way of analyzing what the individual 
blocks do!
I think it would be easier for us to understand you, if you asked only one or 
two questions in the same mail and explained more exactly what you are 
considering.

Greetings,
Marcus

On 30.05.2014 03:28, xianda wrote:
> Hi Thanks for your kindly reply. 1.The second question is:I 
> see the fft block,it has one option:shift,and you set yes. And in 
> the transmit part,we should do the ifft.And in the receive part,we should do 
> the fft. They all set the shift:yes. And now I want to save 
> the data to file and analyse the data by matlab. In the transmit 
> maybe ifft(fftshift(symbol)),but in the receive what command? 2.I 
> see maybe you don't use the pilot in the receive part.Am I right? 
> 3.I see maybe the cyclic prefix is dropped in the header_payload_demux 
> block.Am I right? Thank you.Can you explain it?Thank you.Best 
> regards
> At 2014-05-30 05:05:54, "Martin Braun"  wrote:
>> On 05/29/2014 08:07 PM, xianda wrote:
>>> Hi:
>>>   Thank you in advance.
>>>   I have two simple question:
>>>  1.In the grc,i see a block: header_payload_demux  
>>>   It has 3 input:in,trigger,header_data.But i see
>>> the header_payload_demux_impl.cc:iosignature::make2(1,2,..,..).But it
>>> has 3 input,why?
>> Why 3 inputs or how come only 2 are in the io signature?
>> header_data is a message port, I guess that's what you're after.
>>
>>>  Thank you.
>>>  2.fft:I see the shift:yes.
>>>   I want to save the symbol to file sink and analyse by matlab.But
>>> now i don't know it's shift earlier or fft earlier?
>> Can you rephrase that question?
>>
>> M
>>
>> ___
>> 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] Dynamically changing input index of Selector block.

[dushyant.marathe]

Hi Activecat,

I used both "Head" and "Skip Head" blocks in parallel to separate out
multiplexed input stream.
The Head block correctly gives me first 240k elements  but, "Skip Head"
block doesn't give me any elements after skipping 240k elements. For your
reference I have attached image of my flow graph (Head_Skip_Head.jpg).

 

Moreover when I used "Skip Head" block alone, it gives me correctly all the
elements after skipping 240k elements.

Why is it so ? I could not find out. Please give me some insight.

Thanks & Regards,
Dushyant





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Dynamically-changing-input-index-of-Selector-block-tp48550p48637.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] Dynamically changing input index of Selector block.

[Activecat]

On Fri, May 30, 2014 at 4:57 PM, dushyant.marathe  wrote:

> Hi Activecat,
>
> I used both "Head" and "Skip Head" blocks in parallel to separate out
> multiplexed input stream.
> The Head block correctly gives me first 240k elements  but, "Skip Head"
> block doesn't give me any elements after skipping 240k elements. For your
> reference I have attached image of my flow graph (Head_Skip_Head.jpg).
>
> 
>
> Moreover when I used "Skip Head" block alone, it gives me correctly all the
> elements after skipping 240k elements.
>
> Why is it so ? I could not find out. Please give me some insight.
>


Try with "File Sink" first instead of "Wave File Sink", this may make a
difference.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dynamically changing input index of Selector block.

[Mike Jameson]

FYI, the head block "copies the first N items to the output then signals
done":

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

Instead of using the "Head" block, the "Keep M in N" block should do the
trick.

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com


On Fri, May 30, 2014 at 10:15 AM, Activecat  wrote:

>
>
> On Fri, May 30, 2014 at 4:57 PM, dushyant.marathe <
> dushyantmara...@gmail.com> wrote:
>
>> Hi Activecat,
>>
>> I used both "Head" and "Skip Head" blocks in parallel to separate out
>> multiplexed input stream.
>> The Head block correctly gives me first 240k elements  but, "Skip Head"
>> block doesn't give me any elements after skipping 240k elements. For your
>> reference I have attached image of my flow graph (Head_Skip_Head.jpg).
>>
>> 
>>
>> Moreover when I used "Skip Head" block alone, it gives me correctly all
>> the
>> elements after skipping 240k elements.
>>
>> Why is it so ? I could not find out. Please give me some insight.
>>
>
>
> Try with "File Sink" first instead of "Wave File Sink", this may make a
> difference.
>
>
> ___
> 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] question on 802.15.4 implementation

[Sahoo, Anirudha]

oops, I just found out that the code I have been working with, has been 
modified in-house. So, the debug message is coming from changes made to your 
code. Sorry about that. 

thanks and regards

-Anirud

Anirudha "Anirud"  Sahoo
National Institute of Standards and Technology
Advanced Network Technologies Division
100 Bureau Drive, Stop 8920
Gaithersburg, MD  20899-8920


-Original Message-
From: Bastian Bloessl [mailto:bloe...@ccs-labs.org] 
Sent: Thursday, May 29, 2014 5:58 AM
To: Sahoo, Anirudha
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] question on 802.15.4 implementation

Hi Anirud,

On 28 May 2014, at 18:47, Sahoo, Anirudha  wrote:

> mac.cc:mac_in: pmt_is_pair
> mac.cc::mac_in: data_len = 30
> CRC at Reception: 0
> MAC: Dropping packet self routed
>  
> I poked around mac.cc code a bit. It looks like the message received has the 
> same mac id as the mac id of the receiver. It seems that the MAC layer does 
> not use the *real* MAC id, rather it generates mac id using "rand() % 100". 
> My understanding is that the receiver is also getting the same mac-id as the 
> sender and hence dropping packet.
> Any idea how to fix the problem?

Which code are you using? I can neither find the debug output nor the "rand() % 
100" code. Also what do you mean with MAC id? Sequence number or MAC address?

Best,
Bastian


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

[Discuss-gnuradio] Using file descriptor sink ?

[Ruecan]

Hello GR,

Can anyone please give me some hints on how to use gr-file descriptor sink
in a gnuradio python flowgraph.  

Regards,
Ruecan



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640.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] Using file descriptor sink ?

[Marcus Müller]

Hi Ruecan,

if you're asking this question, you probably shouldn't use
file_descriptor_sink.
It works quite like file_sink, but instead of a filename, you pass a
file descriptor, which is the int handler the open() syscall will return.

Greetings,
Marcus

On 30.05.2014 17:19, Ruecan wrote:
> Hello GR,
>
> Can anyone please give me some hints on how to use gr-file descriptor sink
> in a gnuradio python flowgraph.  
>
> Regards,
> Ruecan
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] Using file descriptor sink ?

[Marcus Müller]

Ah sorry, forgot the important part: If you have opened a file from
python, let's say by:

myfile = open("/home/ruecan/secretplanforworlddominance.pdf", "r")

you can get the file descriptor by doing
fd = myfile.fileno()

Greetings,
Marcus

On 30.05.2014 17:50, Marcus Müller wrote:
> Hi Ruecan,
>
> if you're asking this question, you probably shouldn't use
> file_descriptor_sink.
> It works quite like file_sink, but instead of a filename, you pass a
> file descriptor, which is the int handler the open() syscall will return.
>
> Greetings,
> Marcus
>
> On 30.05.2014 17:19, Ruecan wrote:
>> Hello GR,
>>
>> Can anyone please give me some hints on how to use gr-file descriptor sink
>> in a gnuradio python flowgraph.  
>>
>> Regards,
>> Ruecan
>>
>>
>>
>> --
>> View this message in context: 
>> http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] Using file descriptor sink ?

[Ruecan]

My question is let say I have this socket 

 self.blocks_socket_pdu_0_Rx = blocks.socket_pdu("UDP_CLIENT",
"localhost", "4000", 1)

And then I need to associate a file descriptor to it. 
How can I have the int handler like the open() syscall would  return ?

 self.myFileDescriptor = blocks.file_descriptor_sink(2048, ??)

Ruecan.






--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640p48644.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] Using file descriptor sink ?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry, I don't understand. Could you rephrase/elaborate on that?
Where does the file descriptor come into play?

On 30.05.2014 18:15, Ruecan wrote:
> My question is let say I have this socket
> 
> self.blocks_socket_pdu_0_Rx = blocks.socket_pdu("UDP_CLIENT", 
> "localhost", "4000", 1)
> 
> And then I need to associate a file descriptor to it. How can I
> have the int handler like the open() syscall would  return ?
> 
> self.myFileDescriptor = blocks.file_descriptor_sink(2048, ??)
> 
> Ruecan.
> 
> 
> 
> 
> 
> 
> -- View this message in context:
> http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640p48644.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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTiLDtAAoJEBQ6EdjyzlHtsaQIAKlg6oAbSxm+MM7U5nkDm1sQ
ppsjH7wuLB1IjocpLjDonIrXDEJDzzTpOxdT7p3LJUgujUHs9pKAq+W7IdccRy+u
J1KzKYrvbdjOoWbpBVMymJ6IjkuTOYrlQKEOB9Z1sd73Y3zkhKYk8+HYx+nPXd2O
76BY6AqvWEAlBl7VQTqR+dx/v5M5rU90eyanBN25A+V8lieUeU7s6D0qvcpsNuQZ
35Qfdg5mTIcduc0k5k02l7HQAr+dXkTveqhRKlnffXIFPccMp1vrrYbQQlLMCKPJ
vSlfc+a7+uYvSOzjV6Tckbiux5oGOMn3EiTUhgJzLX8UY67a9VzKmd7YGnrwxmw=
=NeMU
-END PGP SIGNATURE-

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

[Discuss-gnuradio] Embedded Update

[Philip Balister]

I've update the OpenEmbedded Manifest to track the Daisy release
branches of the various layers. This should create a stable baseline for
people doing embedded work.

I update the README at:

https://github.com/balister/oe-gnuradio-manifest

to reflect this.

Please test and send feedback.

Thanks,

Philip

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

Re: [Discuss-gnuradio] Using file descriptor sink ?

[Ruecan]

I mean if I try this:

> self.blocks_socket_pdu_0_Rx = blocks.socket_pdu("UDP_CLIENT", "localhost",
> "4000", 1) 
self.myFileDescriptor = blocks.file_descriptor_sink(2048,
open(self.blocks_socket_pdu_0_Rx, 'r+b'))

I got:
TypeError: coercing to Unicode: need string or buffer, socket_pdu_sptr found

I don't know how to get a file descriptor out of that to read it and
retrieve packets received.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640p48647.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] Using file descriptor sink ?

[Marcus Müller]

I think you're mixing things up.
open() like you use it is a call to generate a python "file" object,
which is not the file descriptor a file_destructor_sink needs.
open() expects a string, but you offer a socket_pdu shared pointer (ie.
the python (swig) representation of the C++ block of that name).

I don't really understand what you are trying to do; could you explain?
I'm fairly certain file_descriptor_sink is not what you want...

Greetings,
Marcus

On 30.05.2014 19:46, Ruecan wrote:
> I mean if I try this:
>
>> self.blocks_socket_pdu_0_Rx = blocks.socket_pdu("UDP_CLIENT", "localhost",
>> "4000", 1) 
> self.myFileDescriptor = blocks.file_descriptor_sink(2048,
> open(self.blocks_socket_pdu_0_Rx, 'r+b'))
>
> I got:
> TypeError: coercing to Unicode: need string or buffer, socket_pdu_sptr found
>
> I don't know how to get a file descriptor out of that to read it and
> retrieve packets received.
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Using-file-descriptor-sink-tp48640p48647.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] sampling rate of a customized signal source

[Pengyu Zhang]

Hi All,

How to determine the sampling rate of a customized signal source?

I designed a customized signal source which should output two 1ms pulses
every 10ms. If I do not know the sampling rate of the customized module, I
do not know how many elements I should put into the out* buffer for
generating the two 1ms pulses.

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

Re: [Discuss-gnuradio] Dynamically changing input index of Selector block.

[Activecat]

On Fri, May 30, 2014 at 10:20 PM, Mike Jameson 
wrote:

> FYI, the head block "copies the first N items to the output then signals
> done":
> http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1head.html
>
> Instead of using the "Head" block, the "Keep M in N" block should do the
> trick.
>

You know your requirements well, let's pick whichever suits you best.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] run a top block within a block!

[Mostafa Alizadeh]

Hi GNURadiores,

I was thinking about how to change dynamically the blocks connected in my
top block when it's running!
After a long time, I reach to this point that I may have a top block is
running within *a block*! (Also another top block runs* the block* itself.

is that possible?
If it is, I could change the top block which is in a block.

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

Re: [Discuss-gnuradio] sampling rate of a customized signal source

[Activecat]

Hi Pengyu,
There are few considerations:

 On Sat, May 31, 2014 at 4:19 AM, Pengyu Zhang  wrote:

> Hi All,
> How to determine the sampling rate of a customized signal source?
>
> I designed a customized signal source which should output two 1ms pulses
> every 10ms. If I do not know the sampling rate of the customized module, I
> do not know how many elements I should put into the out* buffer for
> generating the two 1ms pulses.
>


To make the discussion easy, let's assume there is rate-limiting block (eg.
throttle, USRP etc) in your flowgraph.

1).  When your parameters above are described in time (example 1ms, 10ms
etc), it is very likely that you will need to configure "Sample Rate"
(which is samp_rate) as one of the variables of your custom block setting.

2).  If you need 1ms pulses, this means your samp_rate must not be lower
than 1kHz.
  In fact your samp_rate must be multiple of 1kHz.
  You may want to put a runtime check on this.

3).  When you say "should output two 1ms pulses every 10ms", does it mean
it output one 1ms pulse every 5ms ?
  Let me assume yes to proceed with the discussion.

Says, the amplitude of the pulse is 1V.

4).  When samp_rate=1kHz, then your custom block will output one 1V and
four 0V in every five outputs.
 This means you need to "set_output_multiple(5)"

5).  When samp_rate=10kHz, then your custom block will output ten 1V and
forty 0V in every fifty outputs.
  This means you need to "set_output_multiple(50)".

6).  To generalize item 4 and 5 above, you need to
  "set_output_multiple( samp_rate / 200 );"

 (many more)

This gives you some idea to start with, the rest is up to you to figure out.
Good luck.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] run a top block within a block!

[Activecat]

On Sat, May 31, 2014 at 12:11 PM, Mostafa Alizadeh 
wrote:

> Hi GNURadiores,
> I was thinking about how to change dynamically the blocks connected in my
> top block when it's running!
>

What do you want to change; the block parameters, or the links connecting
the blocks (which is the flowgraph itself)?
Basically both are possible, you may need to enhance your flowgraph in
python code by hand. During execution, lock the flowgraph, modify it
accordingly, and then unlock it to proceed with the flowgraph execution.



> After a long time, I reach to this point that I may have a top block is
> running within *a block*!
>

Probably you are referring to "hierarchical block" ..?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio