Re: [Discuss-gnuradio] Update: RTL2832 re-written (better GRC block, librtl2832++) & works with OP25 digital radio!

[Alexandru Csete]

Balint,

Thanks for your work on this. Yesterday I have been playing with my EzTV
666 and today I tried a Dexatek dongle using your latest code with FC2580
tuner support.

If I try to run a simple src->fft flowgraph (attached) right after plugging
the dongle in I get a bunch of errors, see atached fc2580-1.txt file. I
tried to capture a file using the latest rtl-sdr code from the osmocom
repository using the same frequency and sample and it worked. After that I
can try the grc flowgraph using your source block again and it will work
(see attached fc2580-2.txt). So it seems there is something wrong with the
tuner initialization. I didn't have time to look into what the problem
could be.

Alex

On Thu, Apr 5, 2012 at 1:55 PM, Balint Seeber  wrote:

> Hi folks,
>
> ** **
>
> Firstly, thank you to those who have tested the initial release and have
> been in touch with feedback – I really appreciate it.
>
> ** **
>
> I would like to share the completely re-written RTL2832 code in 
> gr-baz,
> which should now support all devices I can find with an E4000, FC0013 and
> now FC0012 tuner (if there are any missing, you can simply set the custom
> VID/PID in the GRC RTL2832 Source block, or add just one line to an array
> in rtl2832.cc). This will be ported to the Windows plugin soon.
>
> ** **
>
> The RTL2832 Source block code itself is much tidier, and makes use of
> (what I submit for your consideration/experimentation as) ‘librtl2832++’ –
> this is a completely re-designed GNU Radio-independent C++ (OO) interface
> to the hardware. The idea is to make it really easy to talk to the dongles.
> If you want to use it for something else, just copy out the ‘rtl2832-*’
> files! You will find the main ‘demod’ class, and the ‘tuner’s, all with (I
> hope) a simple API.
>
> ** **
>
> The updated GRC Source block also exposes lots of new settings too
> (including bandwidth, buffer settings, FIR coefficients, …).
>
> ** **
>
> Moreover, just to ensure that I hadn’t led people down the garden path
> (since, let’s face it, it’s 8 bits, XO drifts like crazy, and wasn’t
> designed for general-purpose SDR), I hooked it up to 
> OP25(the open source P25 digital radio decoder) – 
> and happily it works!
> 
>
> ** **
>
> Check out the RTL2832+OP25+DES-OFB demonstration/RTL2832 update video:
> http://www.youtube.com/watch?v=wShOLgW2tmI
>
> ** **
>
> In the process I also created two new GRC blocks (now in gr-baz, also in
> the video):
>
> ** **
>
> **1.   **‘OP25 Decoder’ (float baseband in, audio out with optional
> parameter for setting DES-OFB decryption key – this requires a patch with
> decryption support that I will release soon)
>
> 
>
> **2.   **‘Message Callback’ sink whose input port accepts messages,
> and calls the relevant GRC-generated code to update a GRC variable (i.e.
> you can have various blocks that output messages into a message queue, and
> these will be picked up by this block and trigger a particular variable in
> your flowgraph to by updated automatically – e.g. you can change a tuning
> offset if a block detects a frequency error creeping in, and/or you can
> have GUI elements – text boxes/sliders/etc – controlled by arbitrary blocks
> if their value needs to be updated by a feedback mechanism)
>
> ** **
>
> Please note: RTL2832’s Source block now has Relative Gain *enabled* by
> default, so valid gain values are in the range [0,1]. This means you don’t
> need to remember the absolute gain range for whichever tuner you have!
>
> ** **
>
> Also, there is a known issue that may occur while tuning. If you change
> the frequency too rapidly, a USB error may occur and require reconnection
> of the dongle (this has only ever happened to me though when there are
> sample rate mismatches in a flowgraph). Enforcing coarse-grained locking in
> the source block code does not solve this. The only obvious fix to me at
> this stage is rate-limiting tuning requests (I’m guessing perhaps the
> device wasn’t designed to expect rapid re-tuning). Implementing async
> libusb control transfers would also be nice!
>
> ** **
>
> Finally, I have found that on my Linux box, streaming performance isn’t as
> great as on Windows. By ‘performance’ I mean occasional degradation in the
> baseband signal (i.e. signal ‘jumps’, after AM or FM demod of a constant
> tone, you would hear a ‘click’ discontinuity). I hope that’s not a result
> of an undiscovered bug, but  I’ve been largely able to avoid these
> discontinuities by selecting a modest sample rate (e.g. 1 Msps), increasing
> the transfer read length (you can do this easily in the GRC block) to e.g.
> 256K (though this will increase delay in reflection of freq/gain changes in
> output signal due to longer buffer), and enabling real-time scheduling
> (this requires root).
>
> ** **
>
> If you get run-time complaints about it not finding certain libraries

Re: [Discuss-gnuradio] BPSK transmitter - time domain waveform

[senthil murugan]

I am sorry that i was not able to attach my flowgraph and output waveforms
with this mail though i had .If any one need, pls ping me. I will mail
those for your view.

On Thu, Apr 5, 2012 at 7:03 PM, senthil murugan wrote:

> Hi all,
>
> I have some doubt on the time domain view of bpsk signal generated in
> Gnuradio and usrp. I used psk mod block in GRC (sps =2) and created bpsk
> (baseband )waveform with vector source producing 0,1,1 continuously.
>
> When I plotted the output of psk mod block using scope sink, I seen
> waveform of  constant 1 for some samples (for 0) , inverted root-raised
> cosine waveform (for 1) and another inverted root-raised cosine waveform
> (for 1). This is repeated continuously and i understand that it because of
> transmit pulse shaping.
>
> Now, the question is when I give this signal to USRP for transmission, how
> the time-domain view of that waveform look like?  Will it look like
> sinusoid signal with 180deg phase shift as we all seen in stand.
> communication text books? I guess it will not the case. I tried
>  multiplying  the baseband waveform with signal source (complex) --
> mathematical equivalent of what happening in usrp -- and seen waveform. No
> smooth shift of 180deg.
>
> If anyone having usrp and digital oscilloscope, could you please send me
> the pic of time domain view of output of usrp?
>
> Thanks
> Senthil
>



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

Re: [Discuss-gnuradio] Debugging in gnuradio

[ikjtel]

On Thu, Apr 5, 2012 at 5:11 AM, Tom Rondeau wrote:

> You can use the following link as a guide to debugging segfaults when
> they occur:
> 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-debug-GNU-Radio-in-Python

Hi Tom

I've noticed this issue pop up a few times on the list and noticed that the 
wiki suggests starting the app
under control of GDB.  This has in the past caused me a lot of "Heisen-bugs" 
because GDB really messes
with the timing of some apps.
The true old-fashioned way was 'core' files (I learned Fortran on a machine 
with 8K of 16-bit words of core ;-).  I've put together
a writeup on using this alternative method of invoking GDB, which is at 

http://op25.osmocom.org/wiki/wiki/DebugPage

If you feel like incorporating this verbiage into the main GR wiki, I'd be 
happy to send you the raw markup...

Best Regards

Max


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

Re: [Discuss-gnuradio] Debugging in gnuradio

[Tom Rondeau]

On Fri, Apr 6, 2012 at 9:56 AM, ikjtel  wrote:
>
>
> On Thu, Apr 5, 2012 at 5:11 AM, Tom Rondeau wrote:
>
>> You can use the following link as a guide to debugging segfaults when
>> they occur:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-debug-GNU-Radio-in-Python
>
> Hi Tom
>
> I've noticed this issue pop up a few times on the list and noticed that the 
> wiki suggests starting the app
> under control of GDB.  This has in the past caused me a lot of "Heisen-bugs" 
> because GDB really messes
> with the timing of some apps.
> The true old-fashioned way was 'core' files (I learned Fortran on a machine 
> with 8K of 16-bit words of core ;-).  I've put together
> a writeup on using this alternative method of invoking GDB, which is at
>
> http://op25.osmocom.org/wiki/wiki/DebugPage
>
> If you feel like incorporating this verbiage into the main GR wiki, I'd be 
> happy to send you the raw markup...
>
> Best Regards
>
> Max

That's great, Max, thanks! I'll be stealing it for sure. Don't worry
about the markup; it's easy enough to do that kind of thing on the
Redmine Wiki.

Tom

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

Re: [Discuss-gnuradio] Multiplying 2 signals from the grc

[Nick Foster]

On Fri, Apr 6, 2012 at 2:04 AM, guelord ingala wrote:

> Hi all,
> I need to multiply 2 signals (800 MHz and 820 MHz) from external signal
> generators. I used the usrp-1 and DBSRX daughter-boards to detect the 2
> signals. I attached the grc file that I created for this application. I can
> detect signal from the output  of the usrp source.
>
> When I multiply, I expect to have 2 components (sum and difference) at 20
> MHz and 1.620 GHz. To visualize these 2 components, I need to set the
> FFT-sink to display a wide range. This means the FFT sink sample rate must
> be high i.e 3.4 G. With this value, the FFT doesn't display the plot. I
> used a Rational Resampler to match the usrp source sample rate with the FFT
> sample rate. But it's still not working.
>

It is working, but you have a misunderstanding of how the USRP and Gnuradio
work. The DBSRXs downconvert the 800 and 820MHz signals to baseband (0Hz)
and then the USRP digitizes them and brings them to Gnuradio. You are
effectively multiplying two 0Hz signals. You cannot mix RF signals in
Gnuradio, only baseband signals. In the same way, a sample rate of 3.4Gsps
does not make sense.

--n


>
> Can anyone tell me how to fix this. Your help will be appreciated.
> Dominique
> Regards.
>
>
> ___
> 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] 100 Msps N210 update

[Marc Epard]

I just updated the repository at https://github.com/mepard/N210CeVI.

* It's compatible with the latest UHD host library.
* It no longer requires a modification to the UHD host library.
* uhd_streamer uses the channel API to switch to the 2nd DSP chain for 100 Msps.
* uhd_streamer builds and works on Windows.
* The client/server feature in uhd_streamer uses TCP instead of file locks and 
FIFOs.

Enjoy.

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

[Discuss-gnuradio] edit existing blocks

[anay tuljapurkar]

Hey All,
This question might be a little stupid but what shell command would one
have to use to edit an existing c++ block , just modify it a tad bit( not
add functionality to it) but print statements in general to see the outputs
of the block.

Thanks and regards,
Anay.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] 100 Msps N210 update

[Per Zetterberg]

Great!

From: usrp-users-boun...@lists.ettus.com [usrp-users-boun...@lists.ettus.com] 
on behalf of Marc Epard [mep...@me.com]
Sent: Friday, April 06, 2012 6:21 PM
To: usrp-us...@lists.ettus.com; Discuss-gnuradio@gnu.org Group
Subject: [USRP-users] 100 Msps N210 update

I just updated the repository at https://github.com/mepard/N210CeVI.

* It's compatible with the latest UHD host library.
* It no longer requires a modification to the UHD host library.
* uhd_streamer uses the channel API to switch to the 2nd DSP chain for 100 Msps.
* uhd_streamer builds and works on Windows.
* The client/server feature in uhd_streamer uses TCP instead of file locks and 
FIFOs.

Enjoy.

-Marc


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

Re: [Discuss-gnuradio] edit existing blocks

[Marcus D. Leech]

On 04/06/2012 01:00 PM, anay tuljapurkar wrote:

Hey All,
This question might be a little stupid but what shell command 
would one have to use to edit an existing c++ block , just modify it a 
tad bit( not add functionality to it) but print statements in general 
to see the outputs of the block.


Thanks and regards,
Anay.
Linux has a plethora of text editors, and code editors:  vi, gedit, 
emacs, geany, eclipse   just to name a handful off the top of my head.


  [directed at nobody in particular, nothing personal]
But I'll point out that this isn't the right forum for learning 
very-basic software/computer skills like editing a simple text file.  We 
must
  necessarily assume that you have those basic skills.  This is, 
after-all, *software* defined radio, rather than, for example,
  social-psychology-defined radio, or 
comparative-mid-17th-century-literature-defined radio, or 
watching-football-defined radio.
  So, it shouldn't perhaps come as a big surprise that basic *software* 
development skills are rather a requirement.





--
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] help, cant find device

[sumitstop]

Is the problem solved ? Generally it happens when we accidentally try running
the usrp without connecting
cables/power.





0soon2 wrote:
> 
> My environment is:
> Fedora 16, USRP N210
> 
> I installed gnuradio and uhd by using the script.
> And I set host ip address 192.168.10.1
> So ping test was passed. But when I ran uhd_find_devieces, it prints this
> message
> No UHD Devices Found
> How can I solve this problem??
> 
> LED D and F are on
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/help%2C-cant-find-device-tp33544638p33569279.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] GR 3.5.1 & OSX

[Steven]

> Third
> downloaded the git version and after the usual steps with cmake, the
> building crashes at the 3% with the error
> 
> cc1: error: unrecognized command line option "-mpopcnt"
> make[2]: ***
> [volk/lib/CMakeFiles/volk.dir/volk_machine_sse4_a_64.c.o] Error 1
> make[1]: *** [volk/lib/CMakeFiles/volk.dir/all] Error 2
> make: *** [all] Error 2
> No idea, but using CMake is the way to go to get Volk working. Could
> be an OSX 10.7 issue; I'm still using 10.6 though I do do testing
> using an OSX 10.7 boot disk. I haven't tried this in a while, so I'll
> give it a whirl later today or tomorrow, as time allows.
> 
> Good luck! - MLD
> 
> 
> ___
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ok i'll do other "experiments" and report news.thx very much :D
> downloaded the latest git version and made a little progress in the third 
> case. I set :
> export CXX=clang++
> export CC=clang
> 
> and the cmake building worked ! ! !. Now i have to set the python path 
> correctly. GRC still doesn't run but the python interpreter import the 
> gnuradio module correctly.
> i removed the documentantion from building because it seems to stuck at a 
> certain point, and cpu(s) load is at full ! ! !
> The py27-wxpython issue still remains, i'll post a ticket on macports
> 
> Regards, Arturo

I found that specifying CXX=clang and CC=clang actually breaks the volk tests 
so it will compile but doesn't actually work when you try and run anything.  
Having them unset I'm having the same issue as Arturo at the 3% mark.

-- Performing Test have_maltivec
-- Performing Test have_maltivec - Failed
-- Performing Test have_mfpu=neon
-- Performing Test have_mfpu=neon - Failed
-- Performing Test have_mfloat-abi=softfp
-- Performing Test have_mfloat-abi=softfp - Failed
-- Performing Test have_funsafe-math-optimizations
-- Performing Test have_funsafe-math-optimizations - Failed
-- 32 overruled
-- Performing Test have_m64
-- Performing Test have_m64 - Failed
-- Performing Test have_m3dnow
-- Performing Test have_m3dnow - Failed
-- Performing Test have_msse4.2
-- Performing Test have_msse4.2 - Failed
-- Performing Test have_mpopcnt
-- Performing Test have_mpopcnt - Failed
-- Performing Test have_mmmx
-- Performing Test have_mmmx - Failed
-- Performing Test have_msse
-- Performing Test have_msse - Failed

$ head -n17 volk/CMakeFiles/CMakeError.log 
Performing C++ SOURCE FILE Test have_maltivec failed with the following output:
Change Dir: /usr/local/gnuradio/build/volk/CMakeFiles/CMakeTmp

Run Build Command:/usr/bin/make "cmTryCompileExec/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make 
CMakeFiles/cmTryCompileExec.dir/build
/opt/local/bin/cmake -E cmake_progress_report 
/usr/local/gnuradio/build/volk/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec.dir/src.cxx.o
/usr/bin/clang-Dhave_maltivec   /usr/localmaltivec -o 
CMakeFiles/cmTryCompileExec.dir/src.cxx.o -c 
/usr/local/gnuradio/build/volk/CMakeFiles/CMakeTmp/src.cxx
clang: error: no such file or directory: '/usr/localmaltivec'
make[1]: *** [CMakeFiles/cmTryCompileExec.dir/src.cxx.o] Error 1
make: *** [cmTryCompileExec/fast] Error 2

Source file was:
int main() { return 0;}
Performing C++ SOURCE FILE Test have_mfpu=neon failed with the following output:
Change Dir: /usr/local/gnuradio/build/volk/CMakeFiles/CMakeTmp





smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Benchmark_Tx Problem

[sibar002]

Hello,

I am using USRP 1 with the XCVR2450 daughterboard. I am also using Ubuntu
10.0.4 with gnuradio-3.5.1. I have tried running benchmark_tx/rx with the
following parameters:

./benchmark_tx.py -f 2.45G -A J1 --spec B:0 
./benchmark_rx.py -f 2.45G -A J1 --spec B:0

I am not consistently able to receive the packets that are sent. I sometimes
receive the initial packets, but then program begins to overflow ('O'). I
have tried connecting the USRP1s directly with attenuators, and I have also
tried using the antennas.  I have also used the uhd_fft.py program in order
to make sure that I am receiving a signal. I am able to see a peak at the
correct frequency when I am transmitting. I have also tried using the
Basic_Tx/RX and LFTX/RX daughter-board and I obtain the same result. I would
greatly appreciate any help or advise that anyone could give me. Thank you
for your time and help.

Sam

-- 
View this message in context: 
http://old.nabble.com/Benchmark_Tx-Problem-tp33645086p33645086.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] make test failures on master branch

[Justin Ford]

On Fri, Apr 6, 2012 at 10:36 AM, Justin Ford  wrote:
> On Fri, Apr 6, 2012 at 10:06 AM, Josh Blum  wrote:
>> Justin,
>>
>> Can you tell us more about your platform: OS version, compiler, boost
>> version?
>>
>> I kind of stopped reading through the XML when I got to this one:
>>
>> - Expected: std::invalid_argument
>> - Actual  : std::invalid_argument
>
> Absolutely.  I'm also concerned I have some underlying platform issue.
>
> $ cat /proc/version
> Linux version 2.6.18-274.3.1.el5
> (mockbu...@hs20-bc2-4.build.redhat.com) (gcc version 4.1.2 20080704
> (Red Hat 4.1.2-51)) #1 SMP Fri Aug 26 18:49:02 EDT 2011
>
> $ gcc --version
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Boost version is 1.41 (from EPEL).  I also upgraded the following:
> * SDCC 2.6 (no longer a dependency?)
> * SWIG 2.0.4
> * Python 2.6 (from IUS)
>  - numpy 1.6.1
>  - cheetah 2.4.4
>
> I then manually point cmake to the updated versions since they're
> installed along side the old versions built into RHEL:
> $ cmake -DPYTHON_EXECUTABLE=/usr/bin/python26
> -DBOOST_INCLUDEDIR=/usr/include/boost141
> -DBOOST_LIBRARYDIR=/usr/lib64/boost141
> -DSWIG_EXECUTABLE=/usr/share/swig/2.0.4/bin/swig ../
>
> Are there other important platform specifics that I haven't mentioned?
>
> Justin

Just noticed I had dropped the mailing list off my replies...


  

  qa_gr_io_signature::t1
  Error
  uncaught exception of type std::invalid_argument
- gr_io_signature(1)



  qa_gr_flowgraph::t2_connect_invalid_src_port_neg
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
57
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : negative port number -1 is invalid



  qa_gr_flowgraph::t3_connect_src_port_exceeds
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
67
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : port number 1 exceeds max of 0



  qa_gr_flowgraph::t4_connect_invalid_dst_port_neg
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
77
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : negative port number -1 is invalid



  qa_gr_flowgraph::t5_connect_dst_port_exceeds
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
87
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : port number 1 exceeds max of 0



  qa_gr_flowgraph::t6_connect_dst_in_use
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
99
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : destination already in use by edge null_source(14):0->null_sink(16):0



  qa_gr_flowgraph::t8_connect_type_mismatch
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
121
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : itemsize mismatch: nop(20):0 using 1, nop(21):0 using 4



  qa_gr_flowgraph::t10_disconnect_unconnected_block
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
144
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : cannot disconnect edge nop(24):0->nop(26):0, not found



  qa_gr_flowgraph::t11_disconnect_unconnected_port
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_gr_flowgraph.cc
155
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : cannot disconnect edge nop(27):0->nop(28):1, not found



  qa_block_tags::t0
  Assertion
  
/home/gr/source/git-2/gnuradio/gnuradio-core/src/lib/runtime/qa_block_tags.cc
71
  
  expected exception not thrown
- Expected: std::invalid_argument
- Actual  : std::invalid_argument
- What()  : gr_block_detail::n_input_items


  
  

  qa_gr_vmcircbuf::test_all


  qa_gr_io_signature::t0


  qa_gr_io_signature::t2


  qa_gr_io_signature::t3


  qa_gr_b

Re: [Discuss-gnuradio] Benchmark_Tx Problem

[Ben Hilburn]

Sam -

(O)s indicate that there are overflows occurring - your computer is not
able to keep up with the data rate, and is falling behind in processing as
new packets arrive.

Cheers,
Ben

On Fri, Apr 6, 2012 at 1:39 PM, sibar002  wrote:

>
> Hello,
>
> I am using USRP 1 with the XCVR2450 daughterboard. I am also using Ubuntu
> 10.0.4 with gnuradio-3.5.1. I have tried running benchmark_tx/rx with the
> following parameters:
>
> ./benchmark_tx.py -f 2.45G -A J1 --spec B:0
> ./benchmark_rx.py -f 2.45G -A J1 --spec B:0
>
> I am not consistently able to receive the packets that are sent. I
> sometimes
> receive the initial packets, but then program begins to overflow ('O'). I
> have tried connecting the USRP1s directly with attenuators, and I have also
> tried using the antennas.  I have also used the uhd_fft.py program in order
> to make sure that I am receiving a signal. I am able to see a peak at the
> correct frequency when I am transmitting. I have also tried using the
> Basic_Tx/RX and LFTX/RX daughter-board and I obtain the same result. I
> would
> greatly appreciate any help or advise that anyone could give me. Thank you
> for your time and help.
>
> Sam
>
> --
> View this message in context:
> http://old.nabble.com/Benchmark_Tx-Problem-tp33645086p33645086.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Benchmark_Tx Problem

[sibar002]

Hello Ben,

Thank you for your response. I tried adjusting my bitrate in order to
prevent this from happening, but I continue to have the same problem. I
forgot to mention that I am running a dual OS on my computer (Windows and
Linux). Could this be causing the overflow problem? Thank you again. I
really appreciate any help or advice.

Thanks
Sam



Ben Hilburn-3 wrote:
> 
> Sam -
> 
> (O)s indicate that there are overflows occurring - your computer is not
> able to keep up with the data rate, and is falling behind in processing as
> new packets arrive.
> 
> Cheers,
> Ben
> 
> On Fri, Apr 6, 2012 at 1:39 PM, sibar002  wrote:
> 
>>
>> Hello,
>>
>> I am using USRP 1 with the XCVR2450 daughterboard. I am also using Ubuntu
>> 10.0.4 with gnuradio-3.5.1. I have tried running benchmark_tx/rx with the
>> following parameters:
>>
>> ./benchmark_tx.py -f 2.45G -A J1 --spec B:0
>> ./benchmark_rx.py -f 2.45G -A J1 --spec B:0
>>
>> I am not consistently able to receive the packets that are sent. I
>> sometimes
>> receive the initial packets, but then program begins to overflow ('O'). I
>> have tried connecting the USRP1s directly with attenuators, and I have
>> also
>> tried using the antennas.  I have also used the uhd_fft.py program in
>> order
>> to make sure that I am receiving a signal. I am able to see a peak at the
>> correct frequency when I am transmitting. I have also tried using the
>> Basic_Tx/RX and LFTX/RX daughter-board and I obtain the same result. I
>> would
>> greatly appreciate any help or advise that anyone could give me. Thank
>> you
>> for your time and help.
>>
>> Sam
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Benchmark_Tx-Problem-tp33645086p33645086.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Benchmark_Tx-Problem-tp33645086p33646235.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Close to tagging and releasing 3.5.3, merging next branch

[John Coppens]

On Thu, 5 Apr 2012 13:51:42 -0700
Johnathan Corgan  wrote:

> At this point, the master branch of the repository is ready for
> tagging and releasing as 3.5.3, which is the last planned release of
> the 3.5.x series.  It will have a maint branch, so there is a
> possibility of a 3.5.3.x bug fix release, but no plans for a 3.5.4
> with new features.

Johnathan, I wrote a signal source block for Matlab files. It needs more
testing, and is only for .mat level 4 files. Is there interest in
adding this now, or is there a preference to leave it for 3.6?

John

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

Re: [Discuss-gnuradio] Benchmark_Tx Problem

[Marcus D. Leech]

On 04/06/2012 07:59 PM, sibar002 wrote:

Hello Ben,

Thank you for your response. I tried adjusting my bitrate in order to
prevent this from happening, but I continue to have the same problem. I
forgot to mention that I am running a dual OS on my computer (Windows and
Linux). Could this be causing the overflow problem? Thank you again. I
really appreciate any help or advice.

Thanks
Sam



Are you running your Linux partition as a VM, or you just dual-boot?

I've found that USB support through VMWare is *horrible*.



Ben Hilburn-3 wrote:

Sam -

(O)s indicate that there are overflows occurring - your computer is not
able to keep up with the data rate, and is falling behind in processing as
new packets arrive.

Cheers,
Ben

On Fri, Apr 6, 2012 at 1:39 PM, sibar002  wrote:


Hello,

I am using USRP 1 with the XCVR2450 daughterboard. I am also using Ubuntu
10.0.4 with gnuradio-3.5.1. I have tried running benchmark_tx/rx with the
following parameters:

./benchmark_tx.py -f 2.45G -A J1 --spec B:0
./benchmark_rx.py -f 2.45G -A J1 --spec B:0

I am not consistently able to receive the packets that are sent. I
sometimes
receive the initial packets, but then program begins to overflow ('O'). I
have tried connecting the USRP1s directly with attenuators, and I have
also
tried using the antennas.  I have also used the uhd_fft.py program in
order
to make sure that I am receiving a signal. I am able to see a peak at the
correct frequency when I am transmitting. I have also tried using the
Basic_Tx/RX and LFTX/RX daughter-board and I obtain the same result. I
would
greatly appreciate any help or advise that anyone could give me. Thank
you
for your time and help.

Sam

--
View this message in context:
http://old.nabble.com/Benchmark_Tx-Problem-tp33645086p33645086.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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


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





--
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] Close to tagging and releasing 3.5.3, merging next branch

[Johnathan Corgan]

On Fri, Apr 6, 2012 at 17:05, John Coppens  wrote:

> Johnathan, I wrote a signal source block for Matlab files. It needs more
> testing, and is only for .mat level 4 files. Is there interest in
> adding this now, or is there a preference to leave it for 3.6?

Let's get it into the master branch after the 3.6 merge, which should
be tomorrow sometime.  We don't expect it it take too long to clean up
master for a 3.6.0 release, so it would probably end up being part of
that.

Johnathan

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

Re: [Discuss-gnuradio] Benchmark_Tx Problem

[Tom Rondeau]

On Fri, Apr 6, 2012 at 8:10 PM, Marcus D. Leech  wrote:
> On 04/06/2012 07:59 PM, sibar002 wrote:
>>
>> Hello Ben,
>>
>> Thank you for your response. I tried adjusting my bitrate in order to
>> prevent this from happening, but I continue to have the same problem. I
>> forgot to mention that I am running a dual OS on my computer (Windows and
>> Linux). Could this be causing the overflow problem? Thank you again. I
>> really appreciate any help or advice.
>>
>> Thanks
>> Sam
>>
>>
> Are you running your Linux partition as a VM, or you just dual-boot?
>
> I've found that USB support through VMWare is *horrible*.

Sam,

Also, are you building with autotools (./configure) or cmake? I've
been seeing more reports on this then before, so I'm trying to figure
out if there's something odd going on and where.

Tom

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