Re: [Discuss-gnuradio] TVRX2+USRP (serial 500) 'invalid EEPROM contents' problem
Thanks for your reply Josh, So the instructions are: (1) Use the script OR (2) - run git clone http://gnuradio.org/git/gnuradio.git;;, - Follow the Gnuradio build guide: http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide, - check the dependencies and make sure that gr-uhd is enabled in the Gnuradio source tree. I'm positive I did (1) on one of our systems and (2) on another one. To the letter. Neither of them work. I believe the libusrp1-gnuradio driver was installed along with the gr-uhd one. Is there a way to figure out which library is being used by UHD? Is there a way to specifically tell UHD which source and sink blocks should be used? Thank you, Dmitry Shatskiy. You're not understanding. If you use the classic API, rather than UHD, you won't be able to correctly deal with a TVRX2, since that card is supported *ONLY* with the UHD API. Many of the example programs, such as usrp_usb_benchmark.py, use the so-called classic API. They haven't been updated. It doesn't matter how up-to-date your UHD installation is, the classic APIed programs have no knowledge at all of UHD or any of the post-UHD hardware that's out there. If you want to check gross functionality of your TVRX2 card, you can use uhd_fft.py to grab an FFT spectrum off the card, and make sure that it's working. If you want to produce your own flow-graphs, you'll have to use the UHD source within GRC. The classic USRP1 source won't work with the TVRX2 card, because that card was released *after* the classic API was deprecated and no longer being updated. If you have an up-to-date Ubuntu system, then the 'build-gnuradio' script should take care of installing and building everything you need to make UHD-api stuff just work. Including within gnuradio-companion, uhd_fft.py, etc. But none of the classic API examples will work with TVRX2, or indeed many of the other post-UHD cards out there. Since you're a new user, you have no massive reams of code that need to maintain compatibility with the old ways, so start learning and using UHD. *** Thanks for your reply Marcus and thank you for all the work you guys do to keep this project going. As far as I've understood the problem is that old codes use so to say old sets of instructions disregarding changes in the hardware. What is the best way to start learning UHD? So far trying to run uhd_fft.py I'm getting an error (there's more to that, it's just some last few lines): * File /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py, line 1856, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs) RuntimeError: LookupError: KeyError: No devices found for - Device Address: addr: 192.168.10.2* Thanks, Dmitry Shatskiy.* * ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_sub_ff.cc
Hi everyone, I saw the file gr_sub_ff.cc Does anyone have an idea what this block does? Also, if anyone know where I can find documentations explaining different gnu-blocks in more detail (than the source code only), that would be highly appreciated. Thanks a lot Have a great day, B ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with new uhd images
hi everybody yesterday i burnt the latest uhd images (003-002-003) for n210. after that when i run usrp_uhd_probe, i received the massage FPGA build of the device is incompatible with the host code build. i reinstalled the older version, i was able to run and see n210. why the latest uhd images don't work or what is the procedure to install the latest uhd images correctly. thank you ahmad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FW: LFRX Board as Audio analyzer
Hi, I am trying to do some audio analyzing with the usrp and lfrx board which claims to be dc-to 30mhz. However it seems that the frequency response form dc to let say 100hz is not flat (lacks) I have set the USRP source on 0Hz.. Is this just a fact or am I doing something wrong. Jasper Kanbier Unix Beheer BVS ICT Shared Service Centre Universiteit Leiden +31 71 527 6894 j.w.kanb...@issc.leidenuniv.nl OLE Object: Picture (Metafile) ISSC Universiteit Leiden Niels Bohrweg 1 2333 CA Leiden www.issc.leidenuniv.nl blocked::http://www.issc.leidenuniv.nl/ Helpdesk +31 71 527 helpd...@issc.leidenuniv.nl ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting additional data from N210 to the PC
Hello, Thanks for your suggestion. I tried to replace the second DSP Core by a simple counter so that i should receive something on the second channel. Then instatiated a UHD source block in GRC, added a second channel (Num Channels = 2) to the UHD Source block and configured it the same way as the other channel. Then I tried to run the graph but it keeps telling me that the configuration of the the second channel is wrong (e.g: uhd_usrp_source_0.set_center_freq(1000, 1) leads to vector::_M_range_check ... Maybe I'm just using wrong parameters for the second channel?) By the way: I'm using a WBX board to get the I/Q Samples. Are there maybe any other parameters for the USRP board necessary (subdev specs?) to get this additional samples? Thank you, Eral On 05/09/2011 09:55, Josh Blum wrote: You may want to replace the second DSP in the top level verilog with your own module. On the host side, just configure the uhd source block for two channels. On 09/04/2011 11:18 PM, Eral Tuerkyilmaz wrote: Hi, I want to change my USRP N210 - FPGA config to calculate a correlation sum and transmit this sum synchronously with the I/Q sample pairs to the PC (e.g to get this samples from an extra channel on the UHD block). What would be the easiest way to transmit these additional data to the samples and where are changes necessary (firmware, fpga-config)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with new uhd images
On 13/09/11 05:01 AM, ahmad wrote: hi everybody yesterday i burnt the latest uhd images (003-002-003) for n210. after that when i run usrp_uhd_probe, i received the massage FPGA build of the device is incompatible with the host code build. i reinstalled the older version, i was able to run and see n210. why the latest uhd images don't work or what is the procedure to install the latest uhd images correctly. thank you ahmad _ If you update the hardware fpga/firmware images, you also have to update the host-side. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about using new block in GNURadio
Hi Tom:
Thanks for your reply. Can you tell me how to fix it? May be I looked at
my code too much, I do not know where to change.
inter
From: trondeau1...@gmail.com
Date: Mon, 12 Sep 2011 22:42:39 -0400
Subject: Re: [Discuss-gnuradio] a question about using new block in GNURadio
To: tianxia...@hotmail.com
CC: discuss-gnuradio@gnu.org
2011/9/12 intermilan tianxia...@hotmail.com
Hi all:
I wrote a new block and add it into the GnuRadio. The function of this
block is to synchronize the spread signal,
which means this block used local PN sequence to correlate the input signal.
And I set the threshold, if the correlation value is
larger than the threshold, that means I finish the synchronous part. Then use
the local PN sequence to XOR the synchronized
signal, so we will get the de-spread signal.
But there is a problem I can not figure out the reason. I test this block
in GRC. This block can works well in short time. Then
sometimes the value of the output of this block would become 0. And I do not
know the reason of this situation. I put my code
of the block in this e-mail.
I hope someone can help me to find out where is the problem of my code.
Thank you in advance.
Just a very quick read-through, but it looks like you are advancing i too much.
You're going to walk it out of bounds of the input buffer.
Tom
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include pn_correlator1_ff.h
#include gr_io_signature.h
#include vector
#include iostream
#include fstream
/*
* Create a new instance of pn_correlator_cc and return
* a boost shared_ptr. This is effectively the public constructor.
*/
pn_correlator_ff_sptr
pn_make_correlator_ff (int degree, int mask, int seed)
{
return pn_correlator_ff_sptr (new pn_correlator1_ff (degree, mask, seed));
}
/*
* Specify constraints on number of input and output streams.
* This info is used to construct the input and output signatures
* (2nd 3rd args to gr_block's constructor). The input and
* output signatures are used by the runtime system to
* check that a valid number and type of inputs and outputs
* are connected to this block. In this case, we accept
* only 1 input and 1 output.
*/
static const int MIN_IN = 1;// mininum number of input streams
static const int MAX_IN = 1;// maximum number of input streams
static const int MIN_OUT = 1;// minimum number of output streams
static const int MAX_OUT = 1;// maximum number of output streams
/*
* The private constructor
*/
pn_correlator_ff::pn_correlator_ff (int degree, int mask, int seed)
: gr_block(correlator_ff,
gr_make_io_signature (MIN_IN, MAX_IN, sizeof (float)),
gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (float)))
{
d_len = (unsigned int)((1ULL degree)-1);
d = degree;
if (mask == 0)
mask = gri_glfsr::glfsr_mask(degree);
d_reference = new gri_glfsr(mask, seed);
for (int i = 0; i d_len; i++)// initialize to last value in sequence
d_pn = 2.0*d_reference-next_bit()-1.0;
}
void
pn_correlator_ff::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
int input_required = noutput_items + d*d_len ;
unsigned ninputs = ninput_items_required.size();
for (unsigned int i = 0; i ninputs; i++) {
ninput_items_required[i] = input_required;
}
}
/*
* Our virtual destructor.
*/
pn_correlator_ff::~pn_correlator_ff()
{
delete d_reference;
}
int
pn_correlator_ff::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
int a=0;
int i=0;
float sum =0;
while(anoutput_items)
{
while(sum0.8)
{
sum =0;
for (int j = 0; j d_len; j++) {
if (j != 0)// retard PN generator one
sample per period
d_pn = 2.0*d_reference-next_bit()-1.0; // no conditionals
sum+= (2*(in[i])-1) * d_pn;
i++;
}
sum = abs(sum/d_len); //calculate the correlate value
}
d_pn = d_reference-next_bit();
if(d_pn == in[i]) // use local PN sequence to XOR the synchronized signal
out[a]=0;
else
out[a]=1;
i++;
a++;
}
consume_each (noutput_items);
return noutput_items;
}
___
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] gr_sub_ff.cc
On Tue, Sep 13, 2011 at 4:22 AM, bjoe...@ee.ethz.ch wrote: Hi everyone, I saw the file gr_sub_ff.cc Does anyone have an idea what this block does? It subtracts streams from each other. Say there are three sources (src0, src1, src2) that are gr.sig_source_f(...): self.connect(src1, (sub,0)) self.connect(src1, (sub,1)) self.connect(src1, (sub,2)) The output of sub would be: src0 - src1 - src2 You can also use this block to invert a singe stream. If you just had self.connect(src1, (sub,0)), the output would be -src1. Also, if anyone know where I can find documentations explaining different gnu-blocks in more detail (than the source code only), that would be highly appreciated. Thanks a lot Have a great day, B The in-source documentation generates Doxygen documents that can be found here: http://gnuradio.org/doc/doxygen/index.html This really is one of the best ways to handle documentation of each block, since the documentation is coupled with the blocks themselves and can be updated with any changes to the source. We do need some help to better document more blocks and more details in others. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about using new block in GNURadio
2011/9/13 intermilan tianxia...@hotmail.com
Hi Tom:
Thanks for your reply. Can you tell me how to fix it? May be I
looked at my code too much, I do not know where to change.
inter
Sorry, this is something you're really going to have to work out yourself. I
find it sometimes helps to draw a picture of the buffers as the work
function iterates over it to see what's happening to the pointers.
Just remember, if i is the index to the input buffer in, then in[i] is
only valid for 0 = i = ninput_items[0] (or noutput_items if you are using
a gr_sync_block). If you need to look beyond the current input buffer, use
set_history(nhist), and so the constraint becomes 0 = i = (ninput_items[0]
+ nhist).
Tom
--
From: trondeau1...@gmail.com
Date: Mon, 12 Sep 2011 22:42:39 -0400
Subject: Re: [Discuss-gnuradio] a question about using new block in
GNURadio
To: tianxia...@hotmail.com
CC: discuss-gnuradio@gnu.org
2011/9/12 intermilan tianxia...@hotmail.com
Hi all:
I wrote a new block and add it into the GnuRadio. The function of this
block is to synchronize the spread signal,
which means this block used local PN sequence to correlate the input
signal. And I set the threshold, if the correlation value is
larger than the threshold, that means I finish the synchronous part. Then
use the local PN sequence to XOR the synchronized
signal, so we will get the de-spread signal.
But there is a problem I can not figure out the reason. I test this
block in GRC. This block can works well in short time. Then
sometimes the value of the output of this block would become 0. And I do
not know the reason of this situation. I put my code
of the block in this e-mail.
I hope someone can help me to find out where is the problem of my code.
Thank you in advance.
Just a very quick read-through, but it looks like you are advancing i too
much. You're going to walk it out of bounds of the input buffer.
Tom
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include pn_correlator1_ff.h
#include gr_io_signature.h
#include vector
#include iostream
#include fstream
/*
* Create a new instance of pn_correlator_cc and return
* a boost shared_ptr. This is effectively the public constructor.
*/
pn_correlator_ff_sptr
pn_make_correlator_ff (int degree, int mask, int seed)
{
return pn_correlator_ff_sptr (new pn_correlator1_ff (degree, mask,
seed));
}
/*
* Specify constraints on number of input and output streams.
* This info is used to construct the input and output signatures
* (2nd 3rd args to gr_block's constructor). The input and
* output signatures are used by the runtime system to
* check that a valid number and type of inputs and outputs
* are connected to this block. In this case, we accept
* only 1 input and 1 output.
*/
static const int MIN_IN = 1;// mininum number of input streams
static const int MAX_IN = 1;// maximum number of input streams
static const int MIN_OUT = 1;// minimum number of output streams
static const int MAX_OUT = 1;// maximum number of output streams
/*
* The private constructor
*/
pn_correlator_ff::pn_correlator_ff (int degree, int mask, int seed)
: gr_block(correlator_ff,
gr_make_io_signature (MIN_IN, MAX_IN, sizeof (float)),
gr_make_io_signature (MIN_OUT, MAX_OUT, sizeof (float)))
{
d_len = (unsigned int)((1ULL degree)-1);
d = degree;
if (mask == 0)
mask = gri_glfsr::glfsr_mask(degree);
d_reference = new gri_glfsr(mask, seed);
for (int i = 0; i d_len; i++)// initialize to last value in
sequence
d_pn = 2.0*d_reference-next_bit()-1.0;
}
void
pn_correlator_ff::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
int input_required = noutput_items + d*d_len ;
unsigned ninputs = ninput_items_required.size();
for (unsigned int i = 0; i ninputs; i++) {
ninput_items_required[i] = input_required;
}
}
/*
* Our virtual destructor.
*/
pn_correlator_ff::~pn_correlator_ff()
{
delete d_reference;
}
int
pn_correlator_ff::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const float *in = (const float *) input_items[0];
float *out = (float *) output_items[0];
int a=0;
int i=0;
float sum =0;
while(anoutput_items)
{
while(sum0.8)
{
sum =0;
for (int j = 0; j d_len; j++) {
if (j != 0)// retard PN generator one
sample per period
d_pn = 2.0*d_reference-next_bit()-1.0; // no conditionals
sum+= (2*(in[i])-1) * d_pn;
i++;
}
sum = abs(sum/d_len); //calculate the correlate value
}
d_pn = d_reference-next_bit();
Re: [Discuss-gnuradio] How to reconfigure automatically the channel used to received data in USRPs
Hi Nick,
I just wanted tell you that I solved my problem using interprocess
communication, thank you for your advice!
Regards
Lebowski80 wrote:
Ok, thank you for your advice, I will try with interprocess communication.
Regards
Nick Foster-4 wrote:
Short answer: You cannot open a new USRP instance to reconfigure an
already-running USRP instance. You must reconfigure the existing
instance.
The best advice I can give is that only one flowgraph can be operational
per
USRP device. In your setup, USRP#1 will run a single flowgraph with a
source
and/or sink, USRP#2 will run a single flowgraph with a source and/or
sink,
and USRP#3 will run a single flowgraph with a source and/or sink. If you
wish to change the parameters of USRP#2 while it is running, rather than
try
to open a new USRP device in your benchmark_rxr.py flowgraph, use any of
the
standard interprocess communication methods to talk to your
already-running
USRP#2 script and reconfigure it as necessary.
--n
On Wed, Sep 7, 2011 at 9:31 AM, Lebowski80 ale.rasche...@gmail.com
wrote:
Hello Nick,
What do you mean? Actually I'm running RX and TX in two different
flowgraphs
on USRP1, the first one in usrp_spectrum_sense.py to look for a free
channel
(so the RX). In this script I also run benchmark_tx.py by the command p
=
Popen('python benchmark_tx.py', shell = True), then my second
flowgrapgh
(the TX).
My problem is that on USRP2 I want to reconfigure the RX channel by
python
(RX channel = 2484 MHz in the script benchmark_rx.py and RX channel =
channel received by USRP1 in the script benchamrk_rxr.py run by
benchmark_rx.py with the command p = Popen('python benchmark_rxr.py',
shell
= True)).
So I'm wondering if there exists the possibility to reconfigure the
parameters of a script in the same USRP (i.e. RX frequency channel)
while
it
is running and if this is not possible what do people mean with USRP
reconfigurability?
I really need an answer to understand the potentiality of my hardware,
thanks a lot!
Regards
Nick Foster-4 wrote:
On Wed, Sep 7, 2011 at 3:27 AM, Lebowski80 ale.rasche...@gmail.com
wrote:
Hello everyone,
Before to explain my problem I give some technical information about
my
hardaware. I'm using USRPs v1 and the boards integrated are XCVR2450
Transceivers.
I'm using the script usrp_spectrum_sense.py in a USRP (called USRP1)
to
make
sensing in the ISM band, after a few seconds it sends to another USRP
(Called USRP2) a free sensed channel on the central frequency 2484
MHz.
USRP2 listens to the channel 2484 MHz through the script
benchmark_rx.py
and
it can properly receive the free ISM channel sent by USRP1. Then, I
want
to
use the USRP2 to receive data from another USRP (called USRP3) that
uses
the
script benchmark_tx.py.
In the script benchmark_rx.py (used by USRP2) that listens to channel
2484
MHz I want to run another script that I called benchmark_rxr.py that
waits
for data sent by USRP3 to be received in the free ISM channel sent by
USRP1.
Relevant line of the code in the script benchmark_rx.py is attached
below:
p = Popen('python benchmark_rxr.py', shell = True)
While this is the error that I get:
usrp_open_interface:usb_claim_interface: failed interface 2
could not claim interface 2: Device or resource busy
usrp_basic_rx: can't open rx interface
Traceback (most recent call last):
File benchmark_rxr.py, line 153, in module
main()
File benchmark_rxr.py, line 138, in main
tb = my_top_block(demods[options.modulation],
mods[options.modulation],
rx_callback, options)
File benchmark_rxr.py, line 46, in __init__
self.rxpath = usrp_receive_path.usrp_receive_path(demodulator,
rx_callback, options)
File
/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py,
line 65, in __init__
self._setup_usrp_source(options)
File
/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py,
line 78, in _setup_usrp_source
self.u = usrp_options.create_usrp_source(options)
File
/usr/local/lib/python2.6/dist-packages/gnuradio/usrp_options.py,
line 88, in create_usrp_source
gain=options.rx_gain,
File
/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py,
line 138, in __init__
_generic_usrp_base.__init__(self, **kwargs)
File
/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py,
line 63, in __init__
except: raise Exception, 'Failed to automatically setup a usrp
device.'
Exception: Failed to automatically setup a usrp device.
I read different post with this problem such as Full duplex and half
duplex
does not work and help: cannot send after transport endpoint
shutdown
but
I could not solve the problem yet. I need to close the reception in
2484
MHz
channel for a new reception in another channel in USRP2. The only way
to
do
that
Re: [Discuss-gnuradio] FW: LFRX Board as Audio analyzer
You need to turn off DC offset correction. DC offset correction results in a narrow spectral hole around DC. Matt On Tue, Sep 13, 2011 at 4:13 AM, Kanbier, J.W. j.w.kanb...@issc.leidenuniv.nl wrote: ** Hi, I am trying to do some audio analyzing with the usrp and lfrx board which claims to be dc-to 30mhz. However it seems that the frequency response form dc to let say 100hz is not flat (lacks) I have set the USRP source on 0Hz.. Is this just a fact or am I doing something wrong. *Jasper Kanbier *Unix Beheer BVS *ICT Shared Service Centre* Universiteit Leiden +31 71 527 6894 ***j.w.kanb...@issc.leidenuniv.nl*** j.w.kanb...@issc.leidenuniv.nl** OLE Object: Picture (Metafile) *** * *ISSC Universiteit Leiden *Niels Bohrweg 1 2333 CA Leiden *www.issc.leidenuniv.nl* *Helpdesk* +31 71 527 *helpd...@issc.leidenuniv.nl* helpd...@issc.leidenuniv.nl ___ 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] Simulink with N210
Has anyone here used the USRP N210 with Simulink? MathWorks officially supports it, as of last month. I am wondering how mature the combination is, and what the implications are in using Simulink instead of gnuradio. http://www.mathworks.com/discovery/sdr/usrp.html Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulink with N210
On 09/13/2011 11:13 AM, mipro...@gmail.com wrote: Has anyone here used the USRP N210 with Simulink? MathWorks officially supports it, as of last month. I am wondering how mature the combination is, and what the implications are in using Simulink instead of gnuradio. http://www.mathworks.com/discovery/sdr/usrp.html Hey, So yes, mathworks has a USRP driver. But this is the gnuradio mailing list, I hope to keep the discussion about gnuradio and free software. We have a usrp-users mailing list just for this: http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Help-and-Support Thanks, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] floats over UDP into GRC?
Hi all, I would like to stream floating point numbers from another application into GRC; currently sending them over UDP as char arrays, which I was hoping to convert back into floats in GRC. Seems like kind of a basic thing, but I can't get my head around how this is possible. Any pointers / advice would be greatly appreciated… Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] floats over UDP into GRC?
On 09/13/2011 07:05 PM, Mark Cetilia wrote: Hi all, I would like to stream floating point numbers from another application into GRC; currently sending them over UDP as char arrays, which I was hoping to convert back into floats in GRC. Seems like kind of a basic thing, but I can't get my head around how this is possible. Any pointers / advice would be greatly appreciated… Cheers, Mark How are you producing the UDP stream? ARe you saying that in your producer you don't know how to pack complex-floats into a UDP buffer, or something else? The UDP source in GRC is perfectly happy to unpack complex-floats (or floats, or whatever) from a UDP-based stream. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] floats over UDP into GRC?
Marcus , Sorry to hijack the post , why is the telescope on 1420 MHz ? I saw this on your website Sent from my iPhone Andrew Rich On 14/09/2011, at 9:21, Marcus D. Leech mle...@ripnet.com wrote: On 09/13/2011 07:05 PM, Mark Cetilia wrote: Hi all, I would like to stream floating point numbers from another application into GRC; currently sending them over UDP as char arrays, which I was hoping to convert back into floats in GRC. Seems like kind of a basic thing, but I can't get my head around how this is possible. Any pointers / advice would be greatly appreciated… Cheers, Mark How are you producing the UDP stream? ARe you saying that in your producer you don't know how to pack complex-floats into a UDP buffer, or something else? The UDP source in GRC is perfectly happy to unpack complex-floats (or floats, or whatever) from a UDP-based stream. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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] floats over UDP into GRC?
I'm producing the stream in C++ (using openFrameworks) and sending the data as char arrays, and have confirmed that this is indeed all that is being sent (e.g. 1.25)… I think what I'm missing is how to unpack them from the char arrays in GRC, tried various conversions, (Packed to Unpacked, Char to Float, etc.) but am just not getting my head around how GRC would handle this… Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Sep 13, 2011, at 7:21 PM, Marcus D. Leech wrote: On 09/13/2011 07:05 PM, Mark Cetilia wrote: Hi all, I would like to stream floating point numbers from another application into GRC; currently sending them over UDP as char arrays, which I was hoping to convert back into floats in GRC. Seems like kind of a basic thing, but I can't get my head around how this is possible. Any pointers / advice would be greatly appreciated… Cheers, Mark How are you producing the UDP stream? ARe you saying that in your producer you don't know how to pack complex-floats into a UDP buffer, or something else? The UDP source in GRC is perfectly happy to unpack complex-floats (or floats, or whatever) from a UDP-based stream. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ 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] floats over UDP into GRC?
I'm producing the stream in C++ (using openFrameworks) and sending the data as char arrays, and have confirmed that this is indeed all that is being sent (e.g. 1.25)… So, you're sending them in ASCII? As ASCII strings? GRC/gnuradio has no method for dealing with that. The UDP block assumes native machine-binary format for data coming in over UDP. Doing it in ASCII (Or Unicode, or whatever) strings will be hugely inefficient, both in terms of bandwidth required-- it takes many more bytes to represent a floating-point number in ASCII, than in the native binary format, and converting from strings back into the native binary format is also quite expensive. Since UDP is entirely binary transparent, there's no reason to send them as ascii strings. The only thing you have to watch out for is if the raw floating-point format between your two machines is different. But between x86-family machines, it's all the same. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting additional data from N210 to the PC
On 09/13/2011 07:48 AM, Eral Tuerkyilmaz wrote: Hello, Thanks for your suggestion. I tried to replace the second DSP Core by a simple counter so that i should receive something on the second channel. Then instatiated a UHD source block in GRC, added a second channel (Num Channels = 2) to the UHD Source block and configured it the same way as the other channel. Then I tried to run the graph but it keeps telling me that the configuration of the the second channel is wrong (e.g: uhd_usrp_source_0.set_center_freq(1000, 1) leads to vector::_M_range_check ... Maybe I'm just using wrong parameters for the second channel?) Yea, it needs a subdev spec to map the wbx frontend to DSP0 and DSP1, try A:0 A:0 for the string representation. -josh By the way: I'm using a WBX board to get the I/Q Samples. Are there maybe any other parameters for the USRP board necessary (subdev specs?) to get this additional samples? Thank you, Eral On 05/09/2011 09:55, Josh Blum wrote: You may want to replace the second DSP in the top level verilog with your own module. On the host side, just configure the uhd source block for two channels. On 09/04/2011 11:18 PM, Eral Tuerkyilmaz wrote: Hi, I want to change my USRP N210 - FPGA config to calculate a correlation sum and transmit this sum synchronously with the I/Q sample pairs to the PC (e.g to get this samples from an extra channel on the UHD block). What would be the easiest way to transmit these additional data to the samples and where are changes necessary (firmware, fpga-config)? ___ 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] the problem with the uhd_fft.py modified
Hi,everyone I 'd like to watch the OFDM constellation,so I modified the uhd_fft.py, I added some code as follows: demod = blks2.ofdm_demod(options) stream = gr.vector_to_stream(8,200) self.connect(self.u, (demod.ofdm_recv,0),stream,self.scope) self.connect((demod.ofdm_recv,1),gr.null_sink(1)) when modified the code, the graph stopped after running one or two seconds, it looks like not receive any data. Could you tell me where is wrong? I appreciate any help, thanks in advance. BR guojun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
