[Discuss-gnuradio] Gear for sale

[n]

Hi guys,

I have the following gear, all guaranteed to be working, if anyone is 
interested, reach me at n...@mod.net.  My name is Jon.


USRP2 (SBX or WBX wideband dboard).  Power supply=yes, Fan working=yes, 
working=yes.
USRPN210 (SBX or WBX windband dboard).  Power supply=yes, Fan 
working=yes, working unit=yes.

MIMO cable for the two above units.
USRP B100 (FLEX900 dboard) Power supply=yes, Fan=yes, Working unit=yes.
USRP B200 USB3.0 SuperSpeed (white early-adopter PCB).  Working 
unit=yes.


BladeRF x115 + GPIO board.

I've also got a RamseyTest STE-3000 Faraday Cage but I'm not interested 
in parting with it.


All my classic USRPs have working dboards in them, working fans, working 
power supplies.

=) =)

So for the USRP2 with a SBX/WBX (I'm thinking about $1600, since the 
SBX/WBX is $450 or so, and the main was ~$2000+)


For the USRP N210 It'll be higher than that, since it's newer and a 
better unit, probably $1959.00. This includes either the SBX or WBX... 
same as above does too.  The first to order picks the card they want.


The MIMO cable can be thrown in for the cost I paid for it recently.

The B100 is a cheap way to run an OpenBTS base station, and it works 
well... $300.


The B200 - $500.

BladeRF x115 - $580 ($650 new)

GPIO board for BladeRF x115 - $40 ($50 new)

All of these are guaranteed to work, I can record a video of them 
working with a msnbc.com's homepage in the video for date proof.


Jonathan

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

Re: [Discuss-gnuradio] time tags for transition time using USRPs

[Martin Braun]

USRP sinks already support tagged streams, so you're halfway there
already. Adding a 'tx_time' tag onto the first sample of the burst will
let you transmit when you like. Note that you might want to pad your
burst with zeros (at the beginning and end) to flush the signal
processing lines.

Cheers,
M

On 04/22/2016 02:29 AM, Henning Bredenberg wrote:
> Hi all,
> 
> In the attached picture a flow graph is shown where i use the "random"
> pdu generator for a fixed sized pdu (1200 bytes here). The
> pdu_to_tagged_stream block makes it accessible for a simple BPSK
> modulation to send it over a coax cable to another USRP B200. A time
> sink shows what the transmitter transmits and what the receiver should
> receive ideally.
> By inserting some different delays, e.g. a uniformly distributed (0 to
> 80 ms in the disabled block here), i want to emulate a communication
> system. My questions are:
> 
> 1. How can a realize a burst transition that transmit the fixed sized
> burst, i.d. the pdu, in a 20 ms slot whereas the last 60ms no transition
> occurs before a new pdu is generated by the message_strobe block? By now
> it is a continuous transition no matter what i change.
> 
> 2. I want to store the time from generating the pdu till my second USRP
> receives it. Tagging the time should be an option to realize that. Since
> a have no clue: How can i realize that using time tags? The simplest
> case is - without any delays - that the pdu is generated and transmitted
> in a 20ms slot plus the processing time which should be small compared
> to the 20 ms.
> 
> I am thankful for any kind of help. Thanks and have a nice weekend,
> Henning
> 
> 
> ___
> 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] OFDM Packets and Frames into Tagged Stream Block?

[Martin Braun]

A quick hack would be to throw down a block that renames certain tags.
You'd have to write that block, but it would consist of a memcpy() for
the data and a conditional tag copying.

M

On 04/25/2016 10:20 PM, Jingyi Sun wrote:
> Hello experts,
> 
> I have a question regarding using both OFDM packets and frames as inputs
> into the same tagged stream blocks.
> 
> In particular, I would like to input data from inside an OFDM
> transmitter and data from inside an OFDM receiver into the same tagged
> stream block. I would like to process the data while they are symbols
> before the IFFT in the transmitter, and after the FFT in the receiver,
> as shown in the attached flow graph. When we run the flow graph with
> this additional block, data transmission stops due to a run-time error. 
> 
> We believe that the problem is because we are trying to input tagged
> streams with different length tag keys: the tagged stream from the OFDM
> transmitter has length_tag_key = packet_len, while the tagged stream
> from the OFDM receiver has length_tag_key = frame_len. When we use
> inputs of the same length_tag_key, we find that there is no run time error. 
> 
> My question: is there someway that we can process the receiver data and
> the transmitter data in the same block? For example, can I "break down"
> the frames into packets so that we can avoid the mismatching
> length_tag_key error? 
> 
> Thanks a bunch!
> Jenny & Team
> 
> 
> ​


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

Re: [Discuss-gnuradio] (no subject)

[Yile Ku]

So a 'sudo ldconfig' fixed the problem.

On Tue, Apr 26, 2016 at 7:20 AM, Yile Ku  wrote:

> I am running Ubuntu 14.04 and used pybombs to build gnuradio.  Whenever I
> create a module and try and run it, I get the AttributeError shown at the
> bottom.
>
> Y-
>
>
> radio@ubuntu:~$ gr_modtool newmod tryit
> Creating out-of-tree module in ./gr-tryit... Done.
> Use 'gr_modtool add' to add a new block to this currently empty module.
> radio@ubuntu:~$ cd gr-tryit/
> radio@ubuntu:~/gr-tryit$ gr_modtool add -t noblock thisis
> GNU Radio module name identified: tryit
> Language (python/cpp): cpp
> Language: C++
> Block/code identifier: thisis
> Enter valid argument list, including default arguments:
> Add C++ QA code? [Y/n]
> Adding file 'lib/thisis.cc'...
> Adding file 'include/tryit/thisis.h'...
> Adding file 'lib/qa_thisis.cc'...
> Adding file 'lib/qa_thisis.h'...
> Editing swig/tryit_swig.i...
> Adding file 'grc/tryit_thisis.xml'...
> Editing grc/CMakeLists.txt...
> radio@ubuntu:~/gr-tryit$ ls
> apps   CMakeLists.txt  examples  include  MANIFEST.md  swig
> cmake  docsgrc   lib  python
> radio@ubuntu:~/gr-tryit$ mkdir build
> radio@ubuntu:~/gr-tryit$ cd build
> radio@ubuntu:~/gr-tryit/build$ cmake ..
> -- The CXX compiler identification is GNU 4.8.4
> -- The C compiler identification is GNU 4.8.4
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
> -- checking for module 'cppunit'
> --   found cppunit, version 1.13.1
> -- Found CPPUNIT: /usr/lib/i386-linux-gnu/libcppunit.so;dl
> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.6")
> Checking for GNU Radio Module: RUNTIME
> -- checking for module 'gnuradio-runtime'
> --   found gnuradio-runtime, version 3.7.9.2
>  * INCLUDES=/usr/local/include
>  *
> LIBS=/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so
> -- Found GNURADIO_RUNTIME:
> /usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so
> GNURADIO_RUNTIME_FOUND = TRUE
> --
> -- Checking for module SWIG
> -- Found SWIG version 2.0.11.
> -- Found SWIG: /usr/bin/swig2.0
> -- Found PythonLibs: /usr/lib/i386-linux-gnu/libpython2.7.so (found
> suitable version "2.7.6", minimum required is "2")
> -- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.6",
> minimum required is "2")
> -- Looking for sys/types.h
> -- Looking for sys/types.h - found
> -- Looking for stdint.h
> -- Looking for stdint.h - found
> -- Looking for stddef.h
> -- Looking for stddef.h - found
> -- Check size of size_t
> -- Check size of size_t - done
> -- Check size of unsigned int
> -- Check size of unsigned int - done
> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
> -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/radio/gr-tryit/build
> radio@ubuntu:~/gr-tryit/build$ vi ../lib/
> CMakeLists.txt  qa_thisis.h qa_tryit.h  thisis.cc
> qa_thisis.ccqa_tryit.cc test_tryit.cc
> radio@ubuntu:~/gr-tryit/build$ vi ../lib/thisis.cc
> radio@ubuntu:~/gr-tryit/build$ make
> Scanning dependencies of target gnuradio-tryit
> [  6%] Building CXX object lib/CMakeFiles/gnuradio-tryit.dir/thisis.cc.o
> Linking CXX shared library libgnuradio-tryit.so
> [  6%] Built target gnuradio-tryit
> Scanning dependencies of target test-tryit
> [ 12%] Building CXX object lib/CMakeFiles/test-tryit.dir/test_tryit.cc.o
> [ 18%] Building CXX object lib/CMakeFiles/test-tryit.dir/qa_tryit.cc.o
> [ 25%] Building CXX object lib/CMakeFiles/test-tryit.dir/qa_thisis.cc.o
> Linking CXX executable test-tryit
> [ 25%] Built target test-tryit
> Scanning dependencies of target _tryit_swig_doc_tag
> [ 31%] Building CXX object
> swig/CMakeFiles/_tryit_swig_doc_tag.dir/_tryit_swig_doc_tag.cpp.o
> Linking CXX executable _tryit_swig_doc_tag
> [ 31%] Built target _tryit_swig_doc_tag
> Scanning dependencies of target tryit_swig_swig_doc
> [ 37%] Generating doxygen xml for tryit_swig_doc docs
> [ 43%] Generating python docstrings for tryit_swig_doc
> [ 43%] Built target tryit_swig_swig_doc
> Scanning dependencies of target _tryit_swig_swig_tag
> [ 50%] Building CXX object
> swig/CMakeFiles/_tryit_swig_swig_tag.dir/_tryit_swig_swig_tag.cpp.o
> Linking CXX executable _tryit_swig_swig_tag
> [ 50%] Built target _tryit_swig_swig_tag
> [ 56%] Generating tryit_swig.tag
> Scanning dependencies of target tryit_swig_swig_2d0df
> [ 62%] Building CXX object
> 

[Discuss-gnuradio] (no subject)

[Yile Ku]

I am running Ubuntu 14.04 and used pybombs to build gnuradio.  Whenever I
create a module and try and run it, I get the AttributeError shown at the
bottom.

Y-


radio@ubuntu:~$ gr_modtool newmod tryit
Creating out-of-tree module in ./gr-tryit... Done.
Use 'gr_modtool add' to add a new block to this currently empty module.
radio@ubuntu:~$ cd gr-tryit/
radio@ubuntu:~/gr-tryit$ gr_modtool add -t noblock thisis
GNU Radio module name identified: tryit
Language (python/cpp): cpp
Language: C++
Block/code identifier: thisis
Enter valid argument list, including default arguments:
Add C++ QA code? [Y/n]
Adding file 'lib/thisis.cc'...
Adding file 'include/tryit/thisis.h'...
Adding file 'lib/qa_thisis.cc'...
Adding file 'lib/qa_thisis.h'...
Editing swig/tryit_swig.i...
Adding file 'grc/tryit_thisis.xml'...
Editing grc/CMakeLists.txt...
radio@ubuntu:~/gr-tryit$ ls
apps   CMakeLists.txt  examples  include  MANIFEST.md  swig
cmake  docsgrc   lib  python
radio@ubuntu:~/gr-tryit$ mkdir build
radio@ubuntu:~/gr-tryit$ cd build
radio@ubuntu:~/gr-tryit/build$ cmake ..
-- The CXX compiler identification is GNU 4.8.4
-- The C compiler identification is GNU 4.8.4
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'cppunit'
--   found cppunit, version 1.13.1
-- Found CPPUNIT: /usr/lib/i386-linux-gnu/libcppunit.so;dl
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.6")
Checking for GNU Radio Module: RUNTIME
-- checking for module 'gnuradio-runtime'
--   found gnuradio-runtime, version 3.7.9.2
 * INCLUDES=/usr/local/include
 *
LIBS=/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so
-- Found GNURADIO_RUNTIME:
/usr/local/lib/libgnuradio-runtime.so;/usr/local/lib/libgnuradio-pmt.so
GNURADIO_RUNTIME_FOUND = TRUE
-- 
-- Checking for module SWIG
-- Found SWIG version 2.0.11.
-- Found SWIG: /usr/bin/swig2.0
-- Found PythonLibs: /usr/lib/i386-linux-gnu/libpython2.7.so (found
suitable version "2.7.6", minimum required is "2")
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.6",
minimum required is "2")
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of size_t
-- Check size of size_t - done
-- Check size of unsigned int
-- Check size of unsigned int - done
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/radio/gr-tryit/build
radio@ubuntu:~/gr-tryit/build$ vi ../lib/
CMakeLists.txt  qa_thisis.h qa_tryit.h  thisis.cc
qa_thisis.ccqa_tryit.cc test_tryit.cc
radio@ubuntu:~/gr-tryit/build$ vi ../lib/thisis.cc
radio@ubuntu:~/gr-tryit/build$ make
Scanning dependencies of target gnuradio-tryit
[  6%] Building CXX object lib/CMakeFiles/gnuradio-tryit.dir/thisis.cc.o
Linking CXX shared library libgnuradio-tryit.so
[  6%] Built target gnuradio-tryit
Scanning dependencies of target test-tryit
[ 12%] Building CXX object lib/CMakeFiles/test-tryit.dir/test_tryit.cc.o
[ 18%] Building CXX object lib/CMakeFiles/test-tryit.dir/qa_tryit.cc.o
[ 25%] Building CXX object lib/CMakeFiles/test-tryit.dir/qa_thisis.cc.o
Linking CXX executable test-tryit
[ 25%] Built target test-tryit
Scanning dependencies of target _tryit_swig_doc_tag
[ 31%] Building CXX object
swig/CMakeFiles/_tryit_swig_doc_tag.dir/_tryit_swig_doc_tag.cpp.o
Linking CXX executable _tryit_swig_doc_tag
[ 31%] Built target _tryit_swig_doc_tag
Scanning dependencies of target tryit_swig_swig_doc
[ 37%] Generating doxygen xml for tryit_swig_doc docs
[ 43%] Generating python docstrings for tryit_swig_doc
[ 43%] Built target tryit_swig_swig_doc
Scanning dependencies of target _tryit_swig_swig_tag
[ 50%] Building CXX object
swig/CMakeFiles/_tryit_swig_swig_tag.dir/_tryit_swig_swig_tag.cpp.o
Linking CXX executable _tryit_swig_swig_tag
[ 50%] Built target _tryit_swig_swig_tag
[ 56%] Generating tryit_swig.tag
Scanning dependencies of target tryit_swig_swig_2d0df
[ 62%] Building CXX object
swig/CMakeFiles/tryit_swig_swig_2d0df.dir/tryit_swig_swig_2d0df.cpp.o
Linking CXX executable tryit_swig_swig_2d0df
Swig source
[ 62%] Built target tryit_swig_swig_2d0df
Scanning dependencies of target _tryit_swig
[ 68%] Building CXX object
swig/CMakeFiles/_tryit_swig.dir/tryit_swigPYTHON_wrap.cxx.o
Linking CXX shared module _tryit_swig.so
[ 

Re: [Discuss-gnuradio] Higher Accuracy Metadata Header

[Paul Garver]

Hi Michael,

I’d be interested in your timing results once you fix the issue. We’ve done 
something similar in [1] at 25MSPS with a mean difference between B200s of 
around a sample (~40ns). I presume the B200 minis are on different computers 
due to the sample rate. Another issue could be in how you are calculating the 
time delay. We transmit pulses on the PPS and use a tool in gr-analysis 
(gr_fileman) [2] to chunk up the files from multiple B200s based on the time 
tags in the metadata header. Then, you can just to cross-correlation, take the 
magnitude of the DFT, pick the peak, and interpolate (or upsample). That’s what 
we do, anyways. I would be very much interested to hear your results.

PWG


[1] 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-March/018979.html
 

[2] https://github.com/garverp/gr-analysis 


> 
> From: Michael Skaggs >
> Subject: Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?
> Date: April 25, 2016 at 10:09:16 AM EDT
> To: Marcus Müller >
> Cc: discuss-gnuradio@gnu.org 
> 
> 
> Hey Marcus,
> 
> In GRC, I have a USRP Source block with "Sync" set to "Unknown PPS" and 
> "Timing Source" set to "External". I assumed the device would be setting time 
> based on the external PPS using these parameters. The synchronize(S0) LED 
> goes solid (after about half a second of recording, maybe less) and the other 
> LED (S1) is blinking with the PPS.
> 
> Thanks,
> Michael
> 
> On Fri, Apr 22, 2016 at 11:56 AM, Marcus Müller  > wrote:
> Are you sure you're setting the device time correctly? 2.5ms offset is 
> definitely much much worse than what to devices that should have the same 
> device time should exhibit. So:
> How are you setting the device time?
> 
> Best regards,
> Marcus
> 
> 
> On 04/21/2016 08:59 PM, Michael Skaggs wrote:
>> Aha! You were correct. I was parsing the header incorrectly. However, even 
>> after parsing, and the more accurate values (now accurate to 10e-6), it 
>> appears the recorded RF data sets are still are offset from each other by an 
>> amount of nearly 2.5e-3 seconds. Any idea why this would be? It's strange, 
>> especially considering that the are synchronized to the same PPS, and I 
>> think the time is with reference to the pulse.
>> 
>> Michael
>> 
>> On Thu, Apr 21, 2016 at 11:57 AM, Marcus D. Leech > > wrote:
>> On 04/21/2016 11:41 AM, Michael Skaggs wrote:
>> I'm trying to time/sample synchronize RF recordings with two B200minis. I am 
>> using the detached Metadata File Sink in GRC. Both recordings are at 30MSps 
>> and both B200mini boards are synchronized to the same 1PPS signal.
>> 
>> My issue is this, when I extract the data from the Metadata header file, the 
>> "rx_time" value is only accurate to 10e-4 seconds (0.0001s). Which, with a 
>> recording at 30MSps, this will only give me a sample alignment accuracy to 
>> 10e-4(s)*30(MS/s) = 30,000 samples.
>> 
>> If I'm attempting to align the two recordings by samples or time, this is 
>> not nearly accurate enough. Is there a way that I can get more accuracy out 
>> of my metadata header or a way that I can synchronize the recordings of 
>> these B200minis?
>> 
>> Thanks,
>> Michael
>> 
>> The precision of the timestamps from UHD should have a precision of whatever 
>> the master-clock is on the device--how are you interpreting
>>   the rx_time tag?  It's two parts--a uint64 with the full-seconds portion, 
>> and a double-precision float for the fractional part.
>> 
>> 
>> 
>> ___
>> 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 
> 
> 
> 
> 
> 
> 
> From: Marcus Müller  >
> Subject: Re: [Discuss-gnuradio] Higher Accuracy Metadata Header?
> Date: April 25, 2016 at 10:31:24 AM EDT
> To: Michael Skaggs >
> Cc: discuss-gnuradio@gnu.org 

[Discuss-gnuradio] OS X Tutorial Problem fixed

[jim Schimpf]

Hi,
Thanks to  Michael Dickens >. The tutorial problem in OS X I was having 
is fixed.  Deleting the tutorial build directory, and then starting over using 
cmake -DCMAKE_INSTALL_PREFIX=/opt/local ../ for the cmake line in the tutorial 
was the cure. This re-targeted the "make install" to /opt/local which is the 
“port” OS X install location for gnuradio. Starting gnuradio-companion then had 
the tutorial block added just like it’s supposed to.

Thank you for the help.

—jim schimpf

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

Re: [Discuss-gnuradio] Unexpected wifi_loopback.grc output

[Gupta, Arjan]

Thank you! I appreciate it.

From: Bastian Bloessl 
Sent: Monday, April 25, 2016 10:56 PM
To: Gupta, Arjan; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unexpected wifi_loopback.grc output

Hi,

On 04/26/2016 03:44 AM, Gupta, Arjan wrote:
> Here is the output the output for the flow graph:
>
> http://pastebin.com/JrfKwEB7

Looks fine.

>
>
> When I generate the flow graph for wifi_loopback.grc, it gives me the
> output:
>
> -
>
> Generating: '/home/student/bastibl/gr-ieee802-11/examples/wifi_loopback.py'
>  >>> Warning: This flow graph may not have flow control: no audio or RF
> hardware blocks found. Add a Misc->Throttle block to your flow graph to
> avoid CPU congestion.
>
> -
>
>
> Is it supposed to be this way or am I doing something wrong? Any help
> would be really appreciated.
>

That's OK. It just tells you that if you had only streams in your flow
graph and no clock that throttles it down then the flow graph would run
at maximum speed occupying all CPU cores.

In the loopback example there is, however, a message strobe that inputs
frames only from time to time and, therefore, takes care not to burn
your CPU.

Best,
Bastian

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