Re: [Discuss-gnuradio] Manually decoding output from ZMQ PUB Sink

2017-07-21 Thread Cinaed Simson
On 07/21/2017 06:09 AM, Kjetil Wormnes wrote:
> Hi everyone,
> 
> Firstly, just a disclaimer. I am  particularly familiar with GnuRadio at
> all. However I need to interface with a GnuRadio project.
> 
> I am trying to manually decode the output of a ZMQ PUB Sink. In other
> words, I have, in a completely different non-gnuradio project, a bit of
> code that uses the standard python-zmq library to subscribe to the zmq
> socket.
> 
> 
> The ZMQ PUB Sink block is sitting just before the USRP block in the Tx
> chain. And what I eventually want to do is effectively replicate the
> spectrum display from Gnu Radio in a web app.

The file should have a complex data type.

You should be able to read file using

#!/usr/bin/env python
import scipy
f=scipy.fromfile(open("filename"),dtype=scipy.complex64)
print f,

which will print out a couple of complex values.

If you only want real data, put a Complex to Real block after the tap in
from of the USRP, and change ZMQ PUB SINK to data type float.

I'm assuming the flowgraph is using complex data types and you know how
to read a binary file containing floats.

I didn't download the binary you sent.

-- Cinaed

> 
> In my long google searches someone said the trick to decode things from
> gnuradio is to use the PMT library. Now from what I could see I should
> use pmt.deserialize_string(). However that does not seem to work.
> 
 pmt.deserialize_str(d)
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/pmt/pmt_swig.py", line 3373, in
> deserialize_str
> return _pmt_swig.deserialize_str(str)
> RuntimeError: pmt::deserialize: malformed input stream, tag value = : 243
> 
> I thought perhaps there would be an alignment issue, but it doesn't seem
> to matter where (in d) I start the deserialize command.
> 
> By the way, d above is a recording of what I saw come out of that ZMQ
> PUB Sink block. I created a python-zmq socket and connected it to the
> ZMQ Sink Block port and recorded everything.You can find the file here:
> https://www.dropbox.com/s/9r6390lwd3kdc9o/port_5551.bin?dl=1
> 
> Any pointers would be most appreciated. Thanks in advance.
> 
> Kjetil
> 
> 
> ___
> 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] [GSoC 2017] gr-bokehgui: Updates week 10

2017-07-21 Thread Kartik Patel
Hello all,

I have finally completed the implementation of the layouts! For more
details, check out my latest blog post here
.

Also, check out a demo video on Youtube
 for an overview of the
project.

If you have any queries/feedbacks, drop me a mail on this list! :)

Thank you.

Regards,
Kartik Patel
ᐧ
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] OOT Block to Automatically adjust Transmit Gain

2017-07-21 Thread Tellrell White
In the attached flow graph, I've created a block, "gain setter" that takes
in a number of input items and after the input items reach a certain
amount, the block will issue a command to the ursp sink to change the gain
to a certain value. I basically did this using a loop. However, it doesn't
seem like the gain of the signal changes according to the freq sink plot of
the received signal. Any ideas??

On Thu, Jul 13, 2017 at 2:48 PM, Bakshi, Arjun <
bakshi...@buckeyemail.osu.edu> wrote:

> Couldn't figure out how to reply from the digest, so I'm making a new
> post. New to this.
>
>
> Original message/context:
>
> ==
>
> *From*: Tellrell White
>
> I'm currently in the process of creating a block in python that does two
> things; takes in? a certain number of input items, and once it reaches a
> certain number of input items 2) it sends a command to the UHD USRP sink
> block to adjust its gain by a certain amount.
>
> I have a few questions. 1) Is it even possible to create a single block
> that can accomplish both these tasks? 2) How exactly do I make this block
> issue the command to adjust the gain after it receives a certain number of
> values??Below is some code that I currently have constructed for this
> purpose. I'm pretty new to python so I'm sure this code is probably not the
> most efficient way but any suggestions are welcome.
>
>
> ===
>
>
> Hey Tellrell,
>
>
> 1) I think it can be achieved using 1 block. The block will need to output
> a * message* with "gain" and the gain value whenever the input matches
> your condition. Connect the output *message* port to the USRP sink's
> command port. Message should be a pmt that looks something like ("gain",
> value).
>
>
> More info on the command port: https://gnuradio.org/doc/
> doxygen/page_uhd.html#uhd_command_syntax
>
>
>
> 2) I went ahead and implemented something as an example. Increases gain
> upto a limit and then starts over again. See attached code, xml for block,
> rxed signal plot, and flowgraph pic.
>
> I'm new to this too, so hopefully other will correct my mistakes.
>
> Regards,
>
> AB
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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


[Discuss-gnuradio] Manually decoding output from ZMQ PUB Sink

2017-07-21 Thread Kjetil Wormnes
Hi everyone,

Firstly, just a disclaimer. I am  particularly familiar with GnuRadio at
all. However I need to interface with a GnuRadio project.

I am trying to manually decode the output of a ZMQ PUB Sink. In other
words, I have, in a completely different non-gnuradio project, a bit of
code that uses the standard python-zmq library to subscribe to the zmq
socket.


The ZMQ PUB Sink block is sitting just before the USRP block in the Tx
chain. And what I eventually want to do is effectively replicate the
spectrum display from Gnu Radio in a web app.


In my long google searches someone said the trick to decode things from
gnuradio is to use the PMT library. Now from what I could see I should use
pmt.deserialize_string(). However that does not seem to work.

>>> pmt.deserialize_str(d)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/pmt/pmt_swig.py", line 3373, in
deserialize_str
return _pmt_swig.deserialize_str(str)
RuntimeError: pmt::deserialize: malformed input stream, tag value = : 243

I thought perhaps there would be an alignment issue, but it doesn't seem to
matter where (in d) I start the deserialize command.

By the way, d above is a recording of what I saw come out of that ZMQ PUB
Sink block. I created a python-zmq socket and connected it to the ZMQ Sink
Block port and recorded everything. You can find the file here:
https://www.dropbox.com/s/9r6390lwd3kdc9o/port_5551.bin?dl=1

Any pointers would be most appreciated. Thanks in advance.

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


Re: [Discuss-gnuradio] Using two USRPs - how to synchronise a receiver (scan a range of frequencies) looking for a transmitter which is transmitting on a specific frequency

2017-07-21 Thread Marcus Müller
Hi Neil,


1) in this case, the method of choice would be to simply generate a 1MHz
wide baseband signal and only fill the channel you're interested in with
payload signal – the "Rotator", or the "Frequency Xlating FIR" or OFDM
or something like a PFB synthesizer would be viable.

2) well, that very much depends on your channel, noise and signal
models!!! Whatever you pick, you will probably need to write down a
mathematical justification, a false alarm rate and a detection rate,
s it might be worth reading into the theory of estimators and
detectors. In any case, this sounds pretty simple to me: Use a PFB
channelizer (the Doxygen explains how they work, and Tom Rondeau's blog
has some info, too) to divide your 1MHz reception into 5 channels, and
do independent detection concurrently on each of those. Detection can be
done in a lot of ways. For your own signal, you'd probably look for
something like a preamble after a matched filter (hint: you can use a
matched filter as prototype filter for your PFB). For the question
whether a channel is occupied by something else or not: uh, you'll need
a signal model for that. That signal model would lead to something like
an average signal power in each band of the same PFB as above, to
something like an estimate for positions of indepent sinusoids in the
whole 1 MHz passband, to cyclostationary estimation of unknown patterns
in the signal to... whatever your signal model indicates might be a good
idea!

3) Well, that sounds like a back channel! In other words, you're
designing a Media Access Control method. A common thing to do is
dividing the channel into time slots. Sender A selects channel, says
"Hello, I use this channel now" on that channel, then switches to
reception mode on the same channel. B hears the "Hello", detects it, and
answers within a limited time window with a "Hey, yeah, sure, let's use
this channel", which A listens for. As soon as it got that, it switches
back to transmission and sends the data it wants to send.

But that's just one out of millions of imaginable schemes for this. If
you think your channel will be seldom used at all, you might want to
omit the handshake completely (assuming your detection probability is
high enough, of course), as it just wastes time (if you just send
whenever you please, that media access scheme would be called ALOHA.
Understanding ALOHA should definitely be in the syllabus for every comms
theory student!).


Best regards,

Marcus

On 07/20/2017 09:04 PM, neil shelley wrote:
>
> Hi all,
>
>
> We are currently doing a project, which aims to look for white space
> over a chosen frequency range,  automatically select the best channel
> (considering a 1 Mhz span with 5 channels, each of 200kHz). The
> transmitter would tune to the centre frequency of this best channel,
> and the receiver should be able to detect this transmission from the
> 1Mhz range, and perform a handshake with the transmitter so the
> transmitter knows the receiver has identified the chosen frequency. 
> The transmitter should then transmit the information (i.e a text file).
>
>
> For the sending a text file part, we have been able to do this using
> QPSK and GMSK with partial success (however the text file is missing
> information at the end), the main part we have not been able to
> resolve is how the USRP receiver could detect the chosen frequency,
> and then let the transmitter know it has identified this.
>
>
> Can anyone suggest some ways in which this can be done, I have broken
> it into a few stages:
>
> 1) How to get the transmitter to continuously transmit at the specific
> frequency  (i.e either 710.1, 710.3, 710.5, 710.7, 710.9 (Mhz) - what
> should be transmitted, e.g. a type of continuous code that could be
> identified by the receiver?
>
>
> 2) What is a good way to get the receiver to scan the 5 frequencies,
> and at each frequency, how could it identify that this is a
> transmission from the correct device, i.e using an access code, or a
> tag of some sort?, if it does not identify this as the required
> transmission then it will move on to the next frequency.
>
>
> 3) Once the receiver has detected the correct frequency, how can it
> inform the transmitter that it has identified this frequency is to be
> used and tell it to start transmitting the real information (the text
> file).
>
>
> I know this is probably a lot to ask, but any help on any part of it,
> or some ideas that we can start to look at would be appreciated.
>
>
> Thanks,
>
>
> Neil.
>
> 
> *From:* Discuss-gnuradio
>  on behalf
> of discuss-gnuradio-requ...@gnu.org 
> *Sent:* 20 July 2017 19:33
> *To:* ndshel...@hotmail.co.uk
> *Subject:* Welcome to the "Discuss-gnuradio" mailing list
>  
> Welcome to the Discuss-gnuradio@gnu.org mailing list!
>
> To post to this list, send your message to:
>
>   

Re: [Discuss-gnuradio] GNURadio OOT vector input/output with different size

2017-07-21 Thread Marcus Müller
Ali,

Is that really your forecast? That won't work. You'll need to implement it.
Unless you actually meant to do consume_each(noutput_items) AND
return(noutput_items), because then you shouldn't be using a general
gr::block, but gr::sync_block, which saves you the hassle of
implementing a forecast and of explicitly consuming items.

Best regards,
Marcus

On 07/21/2017 08:20 AM, Ali wrote:
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> #endif
>
> #include 
> #include "block_name_impl.h"
> #include "function.h"
>
> namespace gr {
>  namespace module {
>   
>block_name::sptr
>block_name::make(float parameter)
>{
>  return gnuradio::get_initial_sptr
> (new block_name_impl(parameter));
>}
>
>/*
> * The private constructor
> */
>
> *int myints[] = {4000,4000,4000,4000,4000,4000,4000,4000};*
> *const std::vector inputs (myints,
> myints+sizeof(myints)/sizeof(float));*
> *int myints2[] = {4000,4000,4,4};*
> *const std::vector outputs (myints2,
> myints2+sizeof(myints2)/sizeof(float));*
>
>  block_name_impl::block_name_impl(float parameter)
>   : gr::block("block_name",
> *gr::io_signature::makev(8,8,inputs),*
> *gr::io_signature::makev(4,4,outputs)),*
> parameter2(parameter)
>  {}
>
>/*
> * Our virtual constructor
> */
>block_name::~block_name_impl()
>{
>}
>
>void
>block_name_impl::forecast(int noutput_items, gr_vector_int
> _items_required)
>{
>  /* <+forecast+> e.g. ninput_items_required[0] = noutput_items */
>}
>
>int
>block_name_impl::general_work (int noutput_items,
> gr_vector_int _items,
> gr_vector_const_void_star _items,
> gr_vector_void_star _items)
>
>{
> * const float *in1 = (const float *) input_items[0];*
> * const float *in2 = (const float *) input_items[1];*
> * const float *in3 = (const float *) input_items[2];*
> * const float *in4 = (const float *) input_items[3];*
> * const float *in5 = (const float *) input_items[4];*
> * const float *in6 = (const float *) input_items[5];*
> * const float *in7 = (const float *) input_items[6];*
> * const float *in8 = (const float *) input_items[7];*
> * float *out1 = (float *) output_items[0];*
> * float *out2 = (float *) output_items[1];*
> * float *out3 = (float *) output_items[2];*
> * float *out4 = (float *) output_items[3];*
>
>  // Do <+signal processing+>
>  // Tell runtime system how many input items we consumed on
>  // each input stream.
>
> *function(in1,in2,in3,in4,in5,in6,in7,in8,parameter2,out1,out2,out3,out4);*
>
> consume_each(noutput_items);
> return noutput_items;
>  } 
>   }
> }
>   
>
> The "function line" may be inside a for, I am not sure. I am not sure
> of the bold lines also. What is your overall comments?
>
>
>
>
>
> 2017-07-21 8:52 GMT+03:00 Ali <03do...@gmail.com
> >:
>
> Hi,
>
> Patrick's code does not work since I think I am using c++98. I
> dont know how to enable c++11. Anyway for c++98 I wrote the
> followings(I found on the internet):
>
> -->
> int myints[] = {4000,4000,4000,4000,4000,4000,4000,4000};
> const std::vector inputs (myints,
> myints+sizeof(myints)/sizeof(float));
> int myints2[] = {4000,4000,4,4};
> const std::vector outputs (myints2,
> myints2+sizeof(myints2)/sizeof(float));
> -->
> makev(8,8,inputs) and makev(4,4,outputs)
>
> It is compiled after "sudo make" command.
> But when I wrote "gr_modtool makexml function", I got the
> following error(... means I skipped writing these lines).
>
> ...
> Making GRC bindings for lib/function_impl.cc...
> tbi
> Error: Can't parse input signature.
> tbi
> Error: Can't parse output signature.
> ...
>  if iosig[inout]['max_ports'] == '-1':
> Key error: 'in'
>
> I will post my whole code later.
>
>
>
>
>
>
>
>
>
>
> 2017-07-21 1:14 GMT+03:00 Patrick Sathyanathan  >:
>
> Try this instead:
>
>
> const std::vector
> inputs{4000,4000,4000,4000,4000,4000,4000,4000};
>
> and make sure you compile with c++11 enabled.
>
> --Patrick
>
> 
> 
> *From:* Discuss-gnuradio
>  > on behalf of Ali
> <03do...@gmail.com >
> *Sent:* Thursday, July 20, 2017 12:13 AM
> *To:* discuss-gnuradio@gnu.org 
> *Subject:* Re: [Discuss-gnuradio] GNURadio OOT vector
> input/output with different size
>  
> Hi,
>
> I dont have any background about C++. So I could not generate
> the std::vector with the desired content and could not
> fınd 

[Discuss-gnuradio] [GSoC 17] DAB: Updates of the week

2017-07-21 Thread Moritz Luca Schmid

Hi,

here 
 
is my blog post for this week.


I finished the audio encoders MPEG-1 Layer II and MPEG 4 HE-AAC for DAB 
and DAB+, respectively.


For those who can't wait to listen to a DAB+ live stream, I uploaded a 
python script that enables a DAB+ audio stream live reception (For now, 
you have to adjust the address of your service manually - creating a 
user friendly app is my task for the next 4 weeks).



Best

Luca

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


Re: [Discuss-gnuradio] GNURadio OOT vector input/output with different size

2017-07-21 Thread Ali
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include "block_name_impl.h"
#include "function.h"

namespace gr {
 namespace module {

   block_name::sptr
   block_name::make(float parameter)
   {
 return gnuradio::get_initial_sptr
(new block_name_impl(parameter));
   }

   /*
* The private constructor
*/

*int myints[] = {4000,4000,4000,4000,4000,4000,4000,4000};*
*const std::vector inputs (myints,
myints+sizeof(myints)/sizeof(float));*
*int myints2[] = {4000,4000,4,4};*
*const std::vector outputs (myints2,
myints2+sizeof(myints2)/sizeof(float));*

 block_name_impl::block_name_impl(float parameter)
  : gr::block("block_name",
* gr::io_signature::makev(8,8,inputs),*
* gr::io_signature::makev(4,4,outputs)),*
parameter2(parameter)
 {}

   /*
* Our virtual constructor
*/
   block_name::~block_name_impl()
   {
   }

   void
   block_name_impl::forecast(int noutput_items, gr_vector_int
_items_required)
   {
 /* <+forecast+> e.g. ninput_items_required[0] = noutput_items */
   }

   int
   block_name_impl::general_work (int noutput_items,
gr_vector_int _items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)

   {
* const float *in1 = (const float *) input_items[0];*
* const float *in2 = (const float *) input_items[1];*
* const float *in3 = (const float *) input_items[2];*
* const float *in4 = (const float *) input_items[3];*
* const float *in5 = (const float *) input_items[4];*
* const float *in6 = (const float *) input_items[5];*
* const float *in7 = (const float *) input_items[6];*
* const float *in8 = (const float *) input_items[7];*
* float *out1 = (float *) output_items[0];*
* float *out2 = (float *) output_items[1];*
* float *out3 = (float *) output_items[2];*
* float *out4 = (float *) output_items[3];*

 // Do <+signal processing+>
 // Tell runtime system how many input items we consumed on
 // each input stream.

* function(in1,in2,in3,in4,in5,in6,in7,in8,parameter2,out1,out2,out3,out4);*

consume_each(noutput_items);
return noutput_items;
 }
  }
}


The "function line" may be inside a for, I am not sure. I am not sure of
the bold lines also. What is your overall comments?





2017-07-21 8:52 GMT+03:00 Ali <03do...@gmail.com>:

> Hi,
>
> Patrick's code does not work since I think I am using c++98. I dont know
> how to enable c++11. Anyway for c++98 I wrote the followings(I found on the
> internet):
>
> -->
> int myints[] = {4000,4000,4000,4000,4000,4000,4000,4000};
> const std::vector inputs (myints, myints+sizeof(myints)/sizeof(
> float));
> int myints2[] = {4000,4000,4,4};
> const std::vector outputs (myints2, myints2+sizeof(myints2)/
> sizeof(float));
> -->
> makev(8,8,inputs) and makev(4,4,outputs)
>
> It is compiled after "sudo make" command.
> But when I wrote "gr_modtool makexml function", I got the following
> error(... means I skipped writing these lines).
>
> ...
> Making GRC bindings for lib/function_impl.cc...
> tbi
> Error: Can't parse input signature.
> tbi
> Error: Can't parse output signature.
> ...
>  if iosig[inout]['max_ports'] == '-1':
> Key error: 'in'
>
> I will post my whole code later.
>
>
>
>
>
>
>
>
>
>
> 2017-07-21 1:14 GMT+03:00 Patrick Sathyanathan :
>
>> Try this instead:
>>
>>
>> const std::vector inputs{4000,4000,4000,4000,4000,4000,4000,4000};
>>
>> and make sure you compile with c++11 enabled.
>>
>> --Patrick
>>
>> --
>> *From:* Discuss-gnuradio > hotmail@gnu.org> on behalf of Ali <03do...@gmail.com>
>> *Sent:* Thursday, July 20, 2017 12:13 AM
>> *To:* discuss-gnuradio@gnu.org
>> *Subject:* Re: [Discuss-gnuradio] GNURadio OOT vector input/output with
>> different size
>>
>> Hi,
>>
>> I dont have any background about C++. So I could not generate the
>> std::vector with the desired content and could not fınd anything on
>> the internet.
>>
>> const std::vector inputs[] = {4000,4000,4000,4000,4000,40
>> 00,4000,4000};
>>
>> does not work. I am getting the following error:
>>
>> "conversion from 'int' to non-scalar type 'std::vector' requested"
>>
>> Best,
>> Ali
>>
>>
>>
>>
>> 2017-07-18 11:51 GMT+03:00 Marcus Müller :
>>
>>> Hi Ali,
>>>
>>> I think this should also work, shouldn't it?
>>>
>>> no, that's why I explained what you need to do (use makev).
>>>
>>> Does this part need to be changed since I am working with the vectors?
>>>
>>> No, not really. The vectors are still only consecutive numbers in
>>> memory.
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 18.07.2017 07:51, Ali wrote:
>>>
>>> Hi,
>>>
>>> 1- Actually I am using the followings
>>>
>>> make(8,8,1000*sizeof(float))
>>> make3(4,4,1000*sizeof(float),1000*sizeof(float),4*sizeof(float))
>>>
>>> I think this should also work, shouldn't it?
>>>
>>> 2- Under the general work function I am using the followings:
>>>
>>>