[Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()
Hello all, I've been trying to use the set_start_time() method of usrp_source to start my USRP N210 streaming data at a known time. The USRP has the GPSDO fitted and the time is set automatically from this, so I can specify an absolute time for when I want streaming to begin. I've done this successfully using UHD in C++ programs, but I couldn't get it to work in GNURadio. For the record, I'm using GNURadio 3.6.1 and UHD 3.4.2. The problem seemed to be that despite calling set_start_time(), streaming didn't start when it should, yet if I specified a start time in the past, the program failed with an error as I'd expect, so the start time seemed to be interpreted correctly. Having studied gr_uhd_usrp_source.cc, I realised that the problem is that the timeout for the first call to the recv() function in UHD is very short so that if my start time is many seconds in the future, the call times out and the block is done. My question is: is this the intended behaviour and if so, how do I avoid my flowgraph stopping before it's even started, so to speak? I could delay starting the flowgraph until the time is sufficiently close to the wanted start of streaming, but that sounds a bit risky. I have made a small patch to gr_uhd_usrp_source.cc to automatically set an initial receive timeout based on the device time when the streaming command is issued and the wanted streaming start time. Being new to GNURadio, I'm not sure if this is the right way to solve the problem but I'm happy to share the patch if anyone thinks it might be useful. I would welcome any comments and suggestions on this. Thanks, Andrew. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] descrambling radio waves
Hi I am researching methods/algorithms to perform descrambling of scrambled radio waves as part of a research project. - I was hoping to find out if anyone here knows about or has resources where GNU radio is being used for doing such things. If yes, what algorithms are possibly used to scramble the content ? Do the algorithms depend on the hardware or since this is SDR it doesn't matter ? - i have used GNU radio successfully to receive FM waves and listen to music. however, while trying to transmit I am not having much success and have not found much documentation on that. Does anyone successfully transmit using GNU radio or are they using separate software ? - can we transmit and receive at the same time in the same application using the same hardware ? Thanks Vikas -- http://www.vikaskumar.org/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] descrambling radio waves
Hi Vikas, If the signal is crypted then it was not ment for you unless you have a KEY to "unlock". In CCSDS (digital reception) frame header there is a bit telling you if data is/not crypted. It also contains the key number that you have to use to descramble it. GNU Radio does not support hacking, it is up to you if you want to do/try and embarres yourself Be honest and forget that (stuped) idea, Patrik - Original Message - From: "Vikas N Kumar" To: Sent: Tuesday, June 19, 2012 16:47 Subject: [Discuss-gnuradio] descrambling radio waves Hi I am researching methods/algorithms to perform descrambling of scrambled radio waves as part of a research project. - I was hoping to find out if anyone here knows about or has resources where GNU radio is being used for doing such things. If yes, what algorithms are possibly used to scramble the content ? Do the algorithms depend on the hardware or since this is SDR it doesn't matter ? - i have used GNU radio successfully to receive FM waves and listen to music. however, while trying to transmit I am not having much success and have not found much documentation on that. Does anyone successfully transmit using GNU radio or are they using separate software ? - can we transmit and receive at the same time in the same application using the same hardware ? Thanks Vikas -- http://www.vikaskumar.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] descrambling radio waves
On Tue, Jun 19, 2012 at 10:01 AM, Patrik Tast wrote: > If the signal is crypted then it was not ment for you unless you have a KEY > to "unlock". > In CCSDS (digital reception) frame header there is a bit telling you if data > is/not crypted. It also contains the key number that you have to use to > descramble it. Thanks. How is the "KEY" exchange done ? Descrambling doesn't necessarily mean hacking for malicious purposes, it can also mean learning existing systems to design better/more efficient ones for the future. Thanks for your opinion. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] descrambling radio waves
Sample CCSDS frames that were crypted (not ment for my eyes) http://www.poes-weather.com/~aptdecoder/martin/Meteosat9--LRIT/2011-11-17-meteosat9--cadu.txt P - Original Message - From: "Patrik Tast" To: "Vikas N Kumar" ; Sent: Tuesday, June 19, 2012 17:01 Subject: Re: [Discuss-gnuradio] descrambling radio waves Hi Vikas, If the signal is crypted then it was not ment for you unless you have a KEY to "unlock". In CCSDS (digital reception) frame header there is a bit telling you if data is/not crypted. It also contains the key number that you have to use to descramble it. GNU Radio does not support hacking, it is up to you if you want to do/try and embarres yourself Be honest and forget that (stuped) idea, Patrik - Original Message - From: "Vikas N Kumar" To: Sent: Tuesday, June 19, 2012 16:47 Subject: [Discuss-gnuradio] descrambling radio waves Hi I am researching methods/algorithms to perform descrambling of scrambled radio waves as part of a research project. - I was hoping to find out if anyone here knows about or has resources where GNU radio is being used for doing such things. If yes, what algorithms are possibly used to scramble the content ? Do the algorithms depend on the hardware or since this is SDR it doesn't matter ? - i have used GNU radio successfully to receive FM waves and listen to music. however, while trying to transmit I am not having much success and have not found much documentation on that. Does anyone successfully transmit using GNU radio or are they using separate software ? - can we transmit and receive at the same time in the same application using the same hardware ? Thanks Vikas -- http://www.vikaskumar.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py destination host unreachable
It works! Thanks. On Mon, Jun 18, 2012 at 5:53 PM, Alex Zhang wrote: > Weixian, > > Here is a temp solution, not sure it works or not: > > In the csma_mac.main_loop() of your tunnel.py, add a > time_sleep(fixed_delay) right after the payload is read from the OS. You > can set fixed_delay as 0.01 to 0.1 and test the result. > > And also, please set the CSMA threshold carefully to avoid > possible collision. > > Alex > > On Mon, Jun 18, 2012 at 10:10 AM, Weixian Zhou wrote: > >> The following is the messages of the transmitter after I ping. The >> packages of len(payload)=42 failed CRC check, but other packages succeed. >> *URx: ok = True len(payload) = 101* >> *Tx: len(payload) = 90* >> *Tx: len(payload) = 54* >> *UTx: len(payload) = 220* >> *UTx: len(payload) = 326* >> *URx: ok = False len(payload) = 326* >> *Tx: len(payload) = 81* >> *UTx: len(payload) = 326* >> *UTx: len(payload) = 326* >> *UTx: len(payload) = 302* >> *URx: ok = False len(payload) = 302* >> *Tx: len(payload) = 78* >> *UTx: len(payload) = 220* >> *URx: ok = False len(payload) = 220* >> *Tx: len(payload) = 81* >> *UTx: len(payload) = 302* >> *URx: ok = False len(payload) = 302* >> *Tx: len(payload) = 70* >> *UTx: len(payload) = 110* >> *UTx: len(payload) = 240* >> *URx: ok = False len(payload) = 240* >> *Tx: len(payload) = 404* >> *Tx: len(payload) = 201* >> *UTx: len(payload) = 101* >> *UTx: len(payload) = 404* >> *Tx: len(payload) = 201* >> *Tx: len(payload) = 54* >> *UTx: len(payload) = 404* >> *Tx: len(payload) = 201* >> *Tx: len(payload) = 114* >> *UTx: len(payload) = 380* >> *Tx: len(payload) = 189* >> *Rx: ok = False len(payload) = 380* >> *UTx: len(payload) = 240* >> *UTx: len(payload) = 101* >> *UTx: len(payload) = 318* >> *UTx: len(payload) = 81* >> *UTx: len(payload) = 380* >> *Tx: len(payload) = 189* >> *Rx: ok = False len(payload) = 380* >> *URx: ok = False len(payload) = 189* >> *Tx: len(payload) = 302* >> *UTx: len(payload) = 90* >> *UTx: len(payload) = 350* >> *UTx: len(payload) = 101* >> *UTx: len(payload) = 380* >> *Tx: len(payload) = 189* >> *Rx: ok = False len(payload) = 380* >> *UTx: len(payload) = 70* >> *UTx: len(payload) = 81* >> *UTx: len(payload) = 101* >> *UTx: len(payload) = 70* >> *UTx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *URx: ok = True len(payload) = 81* >> *Tx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *URx: ok = True len(payload) = 101* >> *Tx: len(payload) = 42* >> *UTx: len(payload) = 81* >> *UTx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 101* >> *UTx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *UTx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 42* >> *URx: ok = False len(payload) = 42* >> *Tx: len(payload) = 81* >> *UTx: len(payload) = 101* >> *URx: ok = True len(payload) = 81* >> *Rx: ok = True len(payload) = 101* >> >> >> On Mon, Jun 18, 2012 at 11:01 AM, Weixian Zhou wrote: >> >>> Hi Alex, >>> After tried many times I found that the transmitter actually received >>> packages of len(payload)=42 from the receiver, but the the packages failed >>> CRC check (ok=false). I think some parameters need to be tuned, maybe >>> bitrate? >>> >>> On Mon, Jun 18, 2012 at 10:21 AM, Weixian Zhou wrote: >>> Hi Alex, I tried it. The problem is the same. The transmitter only showed tx message of len(payload) = 42, and the receiver showed both tx/rx messages of len(payload) = 42. On Fri, Jun 15, 2012 at 6:43 PM, Alex Zhang wrote: > Weixian, > > Could you please try the ping command like this (if you are working on > linux): > > *sudo ping 192.168.200.2 -i 0.01* > > -i 0.01 means the time interval between pings is 0.01 second. And tell > me what happened. > You can try different time intervals. > > > On Fri, Jun 15, 2012 at 5:37 PM, Alex Zhang > wrote: > >> I did the test by myself, and the most of the time ARP queries >> failed I met this problem when I do the OFDM link test, but that is >> because the physical layer is not robust. But for this narrow band (GMSK) >> modulation, I am not sure what the problem is. >> >> May Josh knows... :) >> >> >> On Fri, Jun 15, 2012 at 3:05 PM, Alex Zhang
Re: [Discuss-gnuradio] descrambling radio waves
Most likely it is a 64bit PIN Seed that your key will contain. If you do not know it then data was not ment for "your eyes". Descrambling doesn't necessarily mean hacking for malicious purposes, it can also mean learning existing systems to design better/more efficient ones for the future. If you don't know the key then you are in the wrong group. All the best, Patrik - Original Message - From: "Vikas N Kumar" To: "Patrik Tast" Cc: Sent: Tuesday, June 19, 2012 17:21 Subject: Re: [Discuss-gnuradio] descrambling radio waves On Tue, Jun 19, 2012 at 10:01 AM, Patrik Tast wrote: If the signal is crypted then it was not ment for you unless you have a KEY to "unlock". In CCSDS (digital reception) frame header there is a bit telling you if data is/not crypted. It also contains the key number that you have to use to descramble it. Thanks. How is the "KEY" exchange done ? Descrambling doesn't necessarily mean hacking for malicious purposes, it can also mean learning existing systems to design better/more efficient ones for the future. Thanks for your opinion. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()
Andrew,
There is a better way. If you look in gr_uhd_usrp_sink.cc, it's expecting
to see tags indicating start of burst ("tx_sob") and end of burst
("tx_eob") as well as a transmit time ("tx_time"). To issue a start of
burst, for instance, use:
add_item_tag(0, //stream ID
nitems_written(0)+i, //absolute sample number to tag
pmt::pmt_string_to_symbol("tx_eob"), //tag name
pmt::pmt_from_bool(1), //set this true to indicate start of burst
d_me//block src id
);
Similar syntax applies for marking the end of burst (use tx_eob instead).
To use the tx_time tag, use a pmt::pmt_from_tuple where the bool is above.
The tuple is (uint64_t, double) where the integer value is seconds and the
double value is fractional seconds.
The block source ID d_me above is really just a convenience identifier and
one way to put it together is:
std::stringstream id;
id << name() << unique_id();
d_me = pmt::pmt_string_to_symbol(id.str());
It does sound a little complicated but it works well in practice. Feel free
to keep asking questions. The best reference is gr_uhd_usrp_sink.cc, and
you'll probably want to look at gruel/src/include/gruel/pmt.h.
--n
On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior wrote:
> Hello all,
>
> I've been trying to use the set_start_time() method of usrp_source to
> start my USRP N210 streaming data at a known time. The USRP has the GPSDO
> fitted and the time is set automatically from this, so I can specify an
> absolute time for when I want streaming to begin. I've done this
> successfully using UHD in C++ programs, but I couldn't get it to work in
> GNURadio. For the record, I'm using GNURadio 3.6.1 and UHD 3.4.2.
>
> The problem seemed to be that despite calling set_start_time(), streaming
> didn't start when it should, yet if I specified a start time in the past,
> the program failed with an error as I'd expect, so the start time seemed to
> be interpreted correctly.
>
> Having studied gr_uhd_usrp_source.cc, I realised that the problem is that
> the timeout for the first call to the recv() function in UHD is very short
> so that if my start time is many seconds in the future, the call times out
> and the block is done.
>
> My question is: is this the intended behaviour and if so, how do I avoid
> my flowgraph stopping before it's even started, so to speak? I could delay
> starting the flowgraph until the time is sufficiently close to the wanted
> start of streaming, but that sounds a bit risky.
>
> I have made a small patch to gr_uhd_usrp_source.cc to automatically set an
> initial receive timeout based on the device time when the streaming command
> is issued and the wanted streaming start time. Being new to GNURadio, I'm
> not sure if this is the right way to solve the problem but I'm happy to
> share the patch if anyone thinks it might be useful.
>
> I would welcome any comments and suggestions on this.
>
> Thanks,
>
> Andrew.
>
> __**_
> 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] Announcing the LiveUSB SDR Environment
Matt, That's AWESOME!!! Thanks for sharing! Definitely, getting a few ASAP!!! - Jose Miguel On Mon, Jun 18, 2012 at 1:54 PM, Matt Ettus wrote: > Ettus Research has released the LiveUSB SDR Environment - a 16 GB > bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10, > UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated > documentation. The SDR Environment enables users to get up and running > with the USRP product family quickly and easily, and lets users > familiarize themselves with the included software before installing it > on their own. Additionally, the portability of the LiveUSB file > system can be used to deploy standard configurations in classrooms, > R&D labs, or other USRP installations. > > Features: > * Ubuntu 11.10, 64-bit > * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS > * Documentation Included on Drive > * 16 GB > * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback > capability > * USB 2.0 Fallback > * Persistent File system - save files, configurations, and other > customizations > * Portability - take your projects with you and boot on any PC > > The LiveUSB includes the most recent release of UHD, GNU Radio, and > OpenBTS. UHD is compatible with all USRP devices, and allows > applications to be easily ported across different USRP models. The > UHD installation includes documentation and examples. GNU Radio is an > easy-to-use, open-source, DSP toolbox that comes with GNU Radio > Companion, a graphical development tool. OpenBTS is an open-source > GSM air-interface implementation, which can be used with the USRP > product family to assemble a fully functional cellular base station. > > The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio > from the Ettus Research 'apt' repositories. This allows users to > update the software without manually downloading, building, and > installing the source code. > > This drive is compatible with USB 2.0 ports, but the system will take > longer to boot, load programs, and respond to user interaction. > > Now, developing with the USRP product family is as easy as plugging in > the LiveUSB SDR Environment and booting up! > > > Matt Ettus > > ___ > 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] descrambling radio waves
On Tue, Jun 19, 2012 at 09:47:49AM -0400, Vikas N Kumar wrote: > - I was hoping to find out if anyone here knows about or has resources > where GNU radio is being used for doing such things. If yes, what > algorithms are possibly used to scramble the content ? Do the > algorithms depend on the hardware or since this is SDR it doesn't > matter ? That's a bit unspecific. > - i have used GNU radio successfully to receive FM waves and listen to > music. however, while trying to transmit I am not having much success > and have not found much documentation on that. Does anyone > successfully transmit using GNU radio or are they using separate > software ? Transmission is fine, works just as good as receiving. We couldn't transmit data between USRPs otherwise. > - can we transmit and receive at the same time in the same application > using the same hardware ? This question has a *lot* of caveats. I'll assume you know what you're doing (and what you can realistically expect), and then the answer is yes, GNU Radio can do that. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpFgvRj8AzDb.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()
I thought the "set_start_time" method simply keeps UHD from instantly
streaming, and then does this "tx_sob" and "tx_time" tagging for you on the
first sample. Sure, it can be done somewhere in the flowgraph using GNU Radio
tags, but doesn't this achieve the same end goal with less complexity for the
user? I.e., if the user simply wants to start continuous streaming sometime in
the future, "set_start_time" should do the trick.
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Nick Foster
Sent: Tuesday, June 19, 2012 10:50 AM
To: Andrew Senior
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Timeout problem using
usrp_source.set_start_time()
Andrew,
There is a better way. If you look in gr_uhd_usrp_sink.cc, it's expecting to
see tags indicating start of burst ("tx_sob") and end of burst ("tx_eob") as
well as a transmit time ("tx_time"). To issue a start of burst, for instance,
use:
add_item_tag(0, //stream ID
nitems_written(0)+i, //absolute sample
number to tag
pmt::pmt_string_to_symbol("tx_eob"), //tag
name
pmt::pmt_from_bool(1), //set this true to
indicate start of burst
d_me//block src id
);
Similar syntax applies for marking the end of burst (use tx_eob instead). To
use the tx_time tag, use a pmt::pmt_from_tuple where the bool is above. The
tuple is (uint64_t, double) where the integer value is seconds and the double
value is fractional seconds.
The block source ID d_me above is really just a convenience identifier and one
way to put it together is:
std::stringstream id;
id << name() << unique_id();
d_me = pmt::pmt_string_to_symbol(id.str());
It does sound a little complicated but it works well in practice. Feel free to
keep asking questions. The best reference is gr_uhd_usrp_sink.cc, and you'll
probably want to look at gruel/src/include/gruel/pmt.h.
--n
On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior
mailto:a.sen...@lancaster.ac.uk>> wrote:
Hello all,
I've been trying to use the set_start_time() method of usrp_source to start my
USRP N210 streaming data at a known time. The USRP has the GPSDO fitted and the
time is set automatically from this, so I can specify an absolute time for when
I want streaming to begin. I've done this successfully using UHD in C++
programs, but I couldn't get it to work in GNURadio. For the record, I'm using
GNURadio 3.6.1 and UHD 3.4.2.
The problem seemed to be that despite calling set_start_time(), streaming
didn't start when it should, yet if I specified a start time in the past, the
program failed with an error as I'd expect, so the start time seemed to be
interpreted correctly.
Having studied gr_uhd_usrp_source.cc, I realised that the problem is that the
timeout for the first call to the recv() function in UHD is very short so that
if my start time is many seconds in the future, the call times out and the
block is done.
My question is: is this the intended behaviour and if so, how do I avoid my
flowgraph stopping before it's even started, so to speak? I could delay
starting the flowgraph until the time is sufficiently close to the wanted start
of streaming, but that sounds a bit risky.
I have made a small patch to gr_uhd_usrp_source.cc to automatically set an
initial receive timeout based on the device time when the streaming command is
issued and the wanted streaming start time. Being new to GNURadio, I'm not sure
if this is the right way to solve the problem but I'm happy to share the patch
if anyone thinks it might be useful.
I would welcome any comments and suggestions on this.
Thanks,
Andrew.
___
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] Timeout problem using usrp_source.set_start_time()
Hi Nick,
thanks for replying. I'm a bit confused though: it's receiving data from
the USRP with gr_uhd_usrp_source that's giving me trouble, not sending
it with gr_uhd_usrp_sink.
Looking again at gr_uhd_usrp_source.cc I see that tags are added
indicating the time of the received samples. I guess this would allow me
to figure out where I am in the stream if it's started at some random
time, but this is conceptually quite different to actually starting the
stream at a defined time. Am I missing something else here?
Regards,
Andrew.
On 19/06/12 15:49, Nick Foster wrote:
Andrew,
There is a better way. If you look in gr_uhd_usrp_sink.cc, it's
expecting to see tags indicating start of burst ("tx_sob") and end of
burst ("tx_eob") as well as a transmit time ("tx_time"). To issue a
start of burst, for instance, use:
add_item_tag(0, //stream ID
nitems_written(0)+i, //absolute sample number to tag
pmt::pmt_string_to_symbol("tx_eob"), //tag name
pmt::pmt_from_bool(1), //set this true to indicate start of burst
d_me //block src id
);
Similar syntax applies for marking the end of burst (use tx_eob
instead). To use the tx_time tag, use a pmt::pmt_from_tuple where the
bool is above. The tuple is (uint64_t, double) where the integer value
is seconds and the double value is fractional seconds.
The block source ID d_me above is really just a convenience identifier
and one way to put it together is:
std::stringstream id;
id << name() << unique_id();
d_me = pmt::pmt_string_to_symbol(id.str());
It does sound a little complicated but it works well in practice. Feel
free to keep asking questions. The best reference is
gr_uhd_usrp_sink.cc, and you'll probably want to look at
gruel/src/include/gruel/pmt.h.
--n
On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior mailto:a.sen...@lancaster.ac.uk>> wrote:
Hello all,
I've been trying to use the set_start_time() method of usrp_source
to start my USRP N210 streaming data at a known time. The USRP has
the GPSDO fitted and the time is set automatically from this, so I
can specify an absolute time for when I want streaming to begin.
I've done this successfully using UHD in C++ programs, but I
couldn't get it to work in GNURadio. For the record, I'm using
GNURadio 3.6.1 and UHD 3.4.2.
The problem seemed to be that despite calling set_start_time(),
streaming didn't start when it should, yet if I specified a start
time in the past, the program failed with an error as I'd expect, so
the start time seemed to be interpreted correctly.
Having studied gr_uhd_usrp_source.cc, I realised that the problem is
that the timeout for the first call to the recv() function in UHD is
very short so that if my start time is many seconds in the future,
the call times out and the block is done.
My question is: is this the intended behaviour and if so, how do I
avoid my flowgraph stopping before it's even started, so to speak? I
could delay starting the flowgraph until the time is sufficiently
close to the wanted start of streaming, but that sounds a bit risky.
I have made a small patch to gr_uhd_usrp_source.cc to automatically
set an initial receive timeout based on the device time when the
streaming command is issued and the wanted streaming start time.
Being new to GNURadio, I'm not sure if this is the right way to
solve the problem but I'm happy to share the patch if anyone thinks
it might be useful.
I would welcome any comments and suggestions on this.
Thanks,
Andrew.
_
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] descrambling radio waves
On Tue, Jun 19, 2012 at 11:13 AM, Martin Braun (CEL) wrote: >> - can we transmit and receive at the same time in the same application >> using the same hardware ? > > This question has a *lot* of caveats. I'll assume you know what you're > doing (and what you can realistically expect), and then the answer is > yes, GNU Radio can do that. > I agree my question is unclear. I want to know if one can write a single program using gnuradio-companion that can perform both transmission and reception using the same hardware, or if such program already exists. So instead of having a full fledged HAM radio equipment with a transceiver etc, I want to experiment with GNU Radio and cheaper hardware. I only have used RTL2838U chip based dongles and have no transmission hardware yet. I have to purchase it and am evaluating which one to pick that can perform maximum tasks. USRP is expensive for my budget right now. thanks. > MB > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- http://www.vikaskumar.org/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()
Oh, for receiving you should use UHD stream commands. I've never done anything
with this myself, but I think "set_command_time" in uhd_usrp_sink will help you.
http://files.ettus.com/uhd_docs/manual/html/sync.html#align-cordics-in-the-dsp
http://gnuradio.org/doc/doxygen/classuhd__usrp__source.html#a59558860e816995c0cbbc43a44523ab7
Sean
-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Andrew Senior
Sent: Tuesday, June 19, 2012 11:38 AM
To: Nick Foster
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Timeout problem using
usrp_source.set_start_time()
Hi Nick,
thanks for replying. I'm a bit confused though: it's receiving data from the
USRP with gr_uhd_usrp_source that's giving me trouble, not sending it with
gr_uhd_usrp_sink.
Looking again at gr_uhd_usrp_source.cc I see that tags are added indicating the
time of the received samples. I guess this would allow me to figure out where I
am in the stream if it's started at some random time, but this is conceptually
quite different to actually starting the stream at a defined time. Am I missing
something else here?
Regards,
Andrew.
On 19/06/12 15:49, Nick Foster wrote:
> Andrew,
>
> There is a better way. If you look in gr_uhd_usrp_sink.cc, it's
> expecting to see tags indicating start of burst ("tx_sob") and end of
> burst ("tx_eob") as well as a transmit time ("tx_time"). To issue a
> start of burst, for instance, use:
>
> add_item_tag(0, //stream ID
> nitems_written(0)+i, //absolute sample number to tag
> pmt::pmt_string_to_symbol("tx_eob"), //tag name pmt::pmt_from_bool(1),
> //set this true to indicate start of burst d_me //block src id );
>
> Similar syntax applies for marking the end of burst (use tx_eob
> instead). To use the tx_time tag, use a pmt::pmt_from_tuple where the
> bool is above. The tuple is (uint64_t, double) where the integer value
> is seconds and the double value is fractional seconds.
>
> The block source ID d_me above is really just a convenience identifier
> and one way to put it together is:
>
> std::stringstream id;
> id << name() << unique_id();
> d_me = pmt::pmt_string_to_symbol(id.str());
>
> It does sound a little complicated but it works well in practice. Feel
> free to keep asking questions. The best reference is
> gr_uhd_usrp_sink.cc, and you'll probably want to look at
> gruel/src/include/gruel/pmt.h.
>
> --n
>
> On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior
> mailto:a.sen...@lancaster.ac.uk>> wrote:
>
> Hello all,
>
> I've been trying to use the set_start_time() method of usrp_source
> to start my USRP N210 streaming data at a known time. The USRP has
> the GPSDO fitted and the time is set automatically from this, so I
> can specify an absolute time for when I want streaming to begin.
> I've done this successfully using UHD in C++ programs, but I
> couldn't get it to work in GNURadio. For the record, I'm using
> GNURadio 3.6.1 and UHD 3.4.2.
>
> The problem seemed to be that despite calling set_start_time(),
> streaming didn't start when it should, yet if I specified a start
> time in the past, the program failed with an error as I'd expect, so
> the start time seemed to be interpreted correctly.
>
> Having studied gr_uhd_usrp_source.cc, I realised that the problem is
> that the timeout for the first call to the recv() function in UHD is
> very short so that if my start time is many seconds in the future,
> the call times out and the block is done.
>
> My question is: is this the intended behaviour and if so, how do I
> avoid my flowgraph stopping before it's even started, so to speak? I
> could delay starting the flowgraph until the time is sufficiently
> close to the wanted start of streaming, but that sounds a bit risky.
>
> I have made a small patch to gr_uhd_usrp_source.cc to automatically
> set an initial receive timeout based on the device time when the
> streaming command is issued and the wanted streaming start time.
> Being new to GNURadio, I'm not sure if this is the right way to
> solve the problem but I'm happy to share the patch if anyone thinks
> it might be useful.
>
> I would welcome any comments and suggestions on this.
>
> Thanks,
>
> Andrew.
>
> _
> 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/listi
Re: [Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()
Hey, I'm losing my mind, apparently. Sorry about the confusion. I was
recently hacking on timed TX and my brain apparently read source as sink.
The easiest way to get around it is to schedule your receive thread to
start sometime less than 1 second before your set_start_time() call
expires. This will keep recv() from timing out.
--n
On Tue, Jun 19, 2012 at 8:37 AM, Andrew Senior wrote:
> Hi Nick,
>
> thanks for replying. I'm a bit confused though: it's receiving data from
> the USRP with gr_uhd_usrp_source that's giving me trouble, not sending it
> with gr_uhd_usrp_sink.
>
> Looking again at gr_uhd_usrp_source.cc I see that tags are added
> indicating the time of the received samples. I guess this would allow me to
> figure out where I am in the stream if it's started at some random time,
> but this is conceptually quite different to actually starting the stream at
> a defined time. Am I missing something else here?
>
> Regards,
>
> Andrew.
>
>
> On 19/06/12 15:49, Nick Foster wrote:
>
>> Andrew,
>>
>> There is a better way. If you look in gr_uhd_usrp_sink.cc, it's
>> expecting to see tags indicating start of burst ("tx_sob") and end of
>> burst ("tx_eob") as well as a transmit time ("tx_time"). To issue a
>> start of burst, for instance, use:
>>
>> add_item_tag(0, //stream ID
>> nitems_written(0)+i, //absolute sample number to tag
>> pmt::pmt_string_to_symbol("tx_**eob"), //tag name
>> pmt::pmt_from_bool(1), //set this true to indicate start of burst
>> d_me //block src id
>> );
>>
>> Similar syntax applies for marking the end of burst (use tx_eob
>> instead). To use the tx_time tag, use a pmt::pmt_from_tuple where the
>> bool is above. The tuple is (uint64_t, double) where the integer value
>> is seconds and the double value is fractional seconds.
>>
>> The block source ID d_me above is really just a convenience identifier
>> and one way to put it together is:
>>
>> std::stringstream id;
>> id << name() << unique_id();
>> d_me = pmt::pmt_string_to_symbol(id.**str());
>>
>> It does sound a little complicated but it works well in practice. Feel
>> free to keep asking questions. The best reference is
>> gr_uhd_usrp_sink.cc, and you'll probably want to look at
>> gruel/src/include/gruel/pmt.h.
>>
>> --n
>>
>> On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior > > wrote:
>>
>>Hello all,
>>
>>I've been trying to use the set_start_time() method of usrp_source
>>to start my USRP N210 streaming data at a known time. The USRP has
>>the GPSDO fitted and the time is set automatically from this, so I
>>can specify an absolute time for when I want streaming to begin.
>>I've done this successfully using UHD in C++ programs, but I
>>couldn't get it to work in GNURadio. For the record, I'm using
>>GNURadio 3.6.1 and UHD 3.4.2.
>>
>>The problem seemed to be that despite calling set_start_time(),
>>streaming didn't start when it should, yet if I specified a start
>>time in the past, the program failed with an error as I'd expect, so
>>the start time seemed to be interpreted correctly.
>>
>>Having studied gr_uhd_usrp_source.cc, I realised that the problem is
>>that the timeout for the first call to the recv() function in UHD is
>>very short so that if my start time is many seconds in the future,
>>the call times out and the block is done.
>>
>>My question is: is this the intended behaviour and if so, how do I
>>avoid my flowgraph stopping before it's even started, so to speak? I
>>could delay starting the flowgraph until the time is sufficiently
>>close to the wanted start of streaming, but that sounds a bit risky.
>>
>>I have made a small patch to gr_uhd_usrp_source.cc to automatically
>>set an initial receive timeout based on the device time when the
>>streaming command is issued and the wanted streaming start time.
>>Being new to GNURadio, I'm not sure if this is the right way to
>>solve the problem but I'm happy to share the patch if anyone thinks
>>it might be useful.
>>
>>I would welcome any comments and suggestions on this.
>>
>>Thanks,
>>
>>Andrew.
>>
>>__**___
>>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] build-gnuradio script with RedHat Enterprise Linux 6
I am trying to use the build-gnuradio script on a RedHat Enterprise Linux 6 machine and I can not download certain packages. Those packages being wxPython-devel, pygsl, qwtplot3d-qt4-devel, and Orc. I have enabled the optional package stream at the RHN so that is how I was able to narrow it down these four. I made an attempt to download those four rpms but it seems that they require too many prerequisites that I have to keep on downloading, execute, and discover I need more prerequisite packages for those prerequisite packages. Is there a better way to install GNU Radio on RedHat? I would use a different distro but I really need RedHat for other projects and RedHat is the only Linux OS that is allowed on my organization's network. Thanks for your help. -Jon Fox ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timeout problem using usrp_source.set_start_time()
Hi Nick,
thanks for your help, I'll give that a try.
Regards,
Andrew.
On 19 Jun 2012, at 18:15, Nick Foster wrote:
> Hey, I'm losing my mind, apparently. Sorry about the confusion. I was
> recently hacking on timed TX and my brain apparently read source as sink.
>
> The easiest way to get around it is to schedule your receive thread to start
> sometime less than 1 second before your set_start_time() call expires. This
> will keep recv() from timing out.
>
> --n
>
> On Tue, Jun 19, 2012 at 8:37 AM, Andrew Senior
> wrote:
> Hi Nick,
>
> thanks for replying. I'm a bit confused though: it's receiving data from the
> USRP with gr_uhd_usrp_source that's giving me trouble, not sending it with
> gr_uhd_usrp_sink.
>
> Looking again at gr_uhd_usrp_source.cc I see that tags are added indicating
> the time of the received samples. I guess this would allow me to figure out
> where I am in the stream if it's started at some random time, but this is
> conceptually quite different to actually starting the stream at a defined
> time. Am I missing something else here?
>
> Regards,
>
> Andrew.
>
>
> On 19/06/12 15:49, Nick Foster wrote:
> Andrew,
>
> There is a better way. If you look in gr_uhd_usrp_sink.cc, it's
> expecting to see tags indicating start of burst ("tx_sob") and end of
> burst ("tx_eob") as well as a transmit time ("tx_time"). To issue a
> start of burst, for instance, use:
>
> add_item_tag(0, //stream ID
> nitems_written(0)+i, //absolute sample number to tag
> pmt::pmt_string_to_symbol("tx_eob"), //tag name
> pmt::pmt_from_bool(1), //set this true to indicate start of burst
> d_me //block src id
> );
>
> Similar syntax applies for marking the end of burst (use tx_eob
> instead). To use the tx_time tag, use a pmt::pmt_from_tuple where the
> bool is above. The tuple is (uint64_t, double) where the integer value
> is seconds and the double value is fractional seconds.
>
> The block source ID d_me above is really just a convenience identifier
> and one way to put it together is:
>
> std::stringstream id;
> id << name() << unique_id();
> d_me = pmt::pmt_string_to_symbol(id.str());
>
> It does sound a little complicated but it works well in practice. Feel
> free to keep asking questions. The best reference is
> gr_uhd_usrp_sink.cc, and you'll probably want to look at
> gruel/src/include/gruel/pmt.h.
>
> --n
>
> On Tue, Jun 19, 2012 at 6:08 AM, Andrew Senior > wrote:
>
>Hello all,
>
>I've been trying to use the set_start_time() method of usrp_source
>to start my USRP N210 streaming data at a known time. The USRP has
>the GPSDO fitted and the time is set automatically from this, so I
>can specify an absolute time for when I want streaming to begin.
>I've done this successfully using UHD in C++ programs, but I
>couldn't get it to work in GNURadio. For the record, I'm using
>GNURadio 3.6.1 and UHD 3.4.2.
>
>The problem seemed to be that despite calling set_start_time(),
>streaming didn't start when it should, yet if I specified a start
>time in the past, the program failed with an error as I'd expect, so
>the start time seemed to be interpreted correctly.
>
>Having studied gr_uhd_usrp_source.cc, I realised that the problem is
>that the timeout for the first call to the recv() function in UHD is
>very short so that if my start time is many seconds in the future,
>the call times out and the block is done.
>
>My question is: is this the intended behaviour and if so, how do I
>avoid my flowgraph stopping before it's even started, so to speak? I
>could delay starting the flowgraph until the time is sufficiently
>close to the wanted start of streaming, but that sounds a bit risky.
>
>I have made a small patch to gr_uhd_usrp_source.cc to automatically
>set an initial receive timeout based on the device time when the
>streaming command is issued and the wanted streaming start time.
>Being new to GNURadio, I'm not sure if this is the right way to
>solve the problem but I'm happy to share the patch if anyone thinks
>it might be useful.
>
>I would welcome any comments and suggestions on this.
>
>Thanks,
>
>Andrew.
>
>_
>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] tunnel.py doesn't work on expected frequency
I am using two USRP N210s (daughter boards are XCVR2450) and the supported frequency in theory ranged in 2.4GHz ~ 2.5GHz. I have done experiment to test the working freq using benchmark_tx/benchmark_rx, the working freq is 2.41G, 2,42G, 243G, 2.44G, 2.46G, 2.47G, 2.48G, 2.49G, 2.50G, 2.51G, 2.52G. But when I tested tunnel.py, the working freq is only 2.50 G and 2.51G. Why doesn't tunnel.py work on the same frequencies as benchmark_tx/benchmark_rx? -- Regards, Weixian Zhou ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py doesn't work on expected frequency
On 06/19/2012 02:30 PM, Weixian Zhou wrote: > I am using two USRP N210s (daughter boards are XCVR2450) and the supported > frequency in theory ranged in 2.4GHz ~ 2.5GHz. I have done experiment to > test the working freq using benchmark_tx/benchmark_rx, the working freq is > 2.41G, 2,42G, 243G, 2.44G, 2.46G, 2.47G, 2.48G, 2.49G, 2.50G, 2.51G, 2.52G. > But when I tested tunnel.py, the working freq is only 2.50 G and 2.51G. Why > doesn't tunnel.py work on the same frequencies as benchmark_tx/benchmark_rx? > > I believe there was a bug that was fixed if you see this thread: http://www.ruby-forum.com/topic/4402826 What version of UHD are you running? If you update to latest master/maint you will get this fix. I think it is worth trying. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Complex square wave source
This is probably a Tom question, but I'm of course open to suggestions from anyone. This is a restatement of Mario Ruz's question on 6/8 after additional conversation on the IRC channel. I think it didn't get much response due to the way it was phrased. I'm not much of a DSP fundamentals guy, so take this with a grain of salt. Currently, the complex square source outputs a 90-degree-delayed square wave on the imaginary output, rather than an actual analytic square wave, which can be approximated by passing a float square source through a Hilbert filter. The imaginary component in that case is (2/pi)*ln(tan(t/2)); when used with complex input I believe the imaginary part of the result will actually be the real square wave component, since it's a Hilbert transform and so it's reciprocal. The same general comment applies to the sawtooth and triangle wave sources although their analytic representations are different. So, I don't actually care what the square wave source emits if there's a reason for it, but was there a reason it was implemented as a delayed square wave rather than the analytic representation? Is there actually a use for complex square/saw/triangle wave sources? Am I just causing trouble and it's way too late to be changing the behavior of this block? --n ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Complex square wave source
> So, I don't actually care what the square wave source emits if there's a > reason for it, but was there a reason it was implemented as a delayed > square wave rather than the analytic representation? Is there actually a > use for complex square/saw/triangle wave sources? Am I just causing trouble > and it's way too late to be changing the behavior of this block? > Some total nOOb added the triangle, square, sawtooth waveforms to signal source. There was a spot to fill in the complex versions of these waveforms, so it just kind of got filled in... doesnt mean much. My only regret was not making ramp function cross 0. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rational resampler question
Hi, I'm trying to convert a flowgraph from grc to c++. In grc there is a rational resampler block and a rational resampler base block. I could not find a c++ version of the rational resampler block. Does a c++ version exist? I don't much about either but I tried to use the rational resampler base block in both the grc flow graph and my c++ code and I could not get it to work in either. What's the difference between the two? Stephen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Read daughterboard eeprom from python
Dear everyone: Is there a method that I can read daughterboard eeprom from python? Or is there anyway that I can know what stored in the daughterboard eeprom in a visible way? Best regards___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-announce] Announcing the LiveUSB SDR Environment
Hi Matt, Would like to know if there is an iso image file which we can write to CD/USB. Thanks & Regds, Sudhir. On Tue, Jun 19, 2012 at 2:27 AM, Matt Ettus wrote: > Ettus Research has released the LiveUSB SDR Environment - a 16 GB > bootable USB 3.0 drive, which comes pre-installed with Ubuntu 11.10, > UHD (USRP Hardware Driver), GNU Radio, OpenBTS, and associated > documentation. The SDR Environment enables users to get up and running > with the USRP product family quickly and easily, and lets users > familiarize themselves with the included software before installing it > on their own. Additionally, the portability of the LiveUSB file > system can be used to deploy standard configurations in classrooms, > R&D labs, or other USRP installations. > > https://www.ettus.com/product/details/LiveUSB > > Features: > * Ubuntu 11.10, 64-bit > * Pre-installed Software: USRP Hardware Driver (UHD), GNU Radio, OpenBTS > * Documentation Included on Drive > * 16 GB > * USB 3.0 Read/Write Speeds - fast boot times and RF record/playback > capability > * USB 2.0 Fallback > * Persistent File system - save files, configurations, and other > customizations > * Portability - take your projects with you and boot on any PC > > The LiveUSB includes the most recent release of UHD, GNU Radio, and > OpenBTS. UHD is compatible with all USRP devices, and allows > applications to be easily ported across different USRP models. The > UHD installation includes documentation and examples. GNU Radio is an > easy-to-use, open-source, DSP toolbox that comes with GNU Radio > Companion, a graphical development tool. OpenBTS is an open-source > GSM air-interface implementation, which can be used with the USRP > product family to assemble a fully functional cellular base station. > > The LiveUSB Ubuntu OS is pre-configured to install UHD and GNU Radio > from the Ettus Research 'apt' repositories. This allows users to > update the software without manually downloading, building, and > installing the source code. > > This drive is compatible with USB 2.0 ports, but the system will take > longer to boot, load programs, and respond to user interaction. > > Now, developing with the USRP product family is as easy as plugging in > the LiveUSB SDR Environment and booting up! > > You can buy a USB 3 Flash Drive with the environment on it here: > >https://www.ettus.com/product/details/LiveUSB > > Matt Ettus > > ___ > USRP-announce mailing list > usrp-annou...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-announce_lists.ettus.com > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic question about filters
Hi, You can look into "Multirate Signal Processing" by Fedrick Harris for more details regarding CIC filter, decimators,etc.. Thanks sencen Message: 10 Date: Tue, 19 Jun 2012 09:46:43 +0800 (CST) From: signalswdm To: GNURadio Subject: [Discuss-gnuradio] Basic question about filter Message-ID: <5178d5c1.7b3.138026b9bba.coremail.signals...@yeah.net> Content-Type: text/plain; charset="gbk" Hello everyone: You see in theory there should be a low-pass filter after ADC for eliminating the image. Also after DDC there should also be a filter. But in USRP there are not such things. So do the cic filter and half band filter implement that function besides decimation? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rational resampler question
The rational resampler is part of BLKS2 which is python only. I'm currently working on porting blks2 over to C++ so the API will not be python only, but there is a lot of python code it is built on that needs to be converted first so it could be a bit. You could just do it yourself, all the rational resampler block does is make it easier for you, http://www.dspguru.com/dsp/faqs/multirate/resampling , this is a good starting point if you need, or you could look at the code for the rational resampler and follow it. Also the resampler base block, I believe is used by the python block and cannot be used by itself. On Tue, Jun 19, 2012 at 11:01 PM, Stephen wrote: > > Hi, > > I'm trying to convert a flowgraph from grc to c++. In grc there is a > rational resampler block and a rational resampler base block. I could > not find a c++ version of the rational resampler block. Does a c++ > version exist? I don't much about either but I tried to use the rational > resampler base block in both the grc flow graph and my c++ code and I > could not get it to work in either. What's the difference between the two? > > Stephen > > ___ > 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] Read daughterboard eeprom from python
On 06/19/2012 08:05 PM, signalswdm wrote: > Dear everyone: > Is there a method that I can read daughterboard eeprom from python? Or is > there anyway that I can know what stored in the daughterboard eeprom in a > visible way? > > Best regards > > I believe the following call will yield the information you seek: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n133 -josh > > ___ > 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
