Re: [Discuss-gnuradio] Transmission using Aux cable

[Marcus Müller]

Hi Haaris,

with "aux cable", you're referring to an audio transmission?
> The point is that the symbols are always recovered correctly, but the
> dynamic amount of junk recovered before the constellation locks itself
> makes the pack 8 bits block work differently. (this is what I think is
> happening)
Exactly! Since there's no way for the receiver to know when the
transmitter started transmitting, it decodes stuff before there's
actually anything to decode.

In essence, you need some kind of preamble or so to tell your receiver
when to start – side effect of having something like that would be that
you could correct some things (the two sound cards don't share the same
oscillator, which leads to a symbol rate offset, and a center frequency
offset).

I'm not quite sure about the right approach here; we used to have
"correlate access code", which you can just tell to look for a specific
streams of 0s and 1s, and throw away stuff before, I think. But also, we
deprecated that, because it had some fundamental architectural
drawbacks; don't know what I should really recommend in this scenario.

Could you maybe export your flow graph (if you made it in GRC;
File->Screen Capture) and share it with us?

Best regartds,
Marcus
On 05.05.2016 03:09, Haaris wrote:
> Hello all,
>
> I am trying to transmit data using aux cable from one laptop to another.
> The modulation scheme I am using the PSK mod block is DQPSK.
> The problem is that while recovering data I have to set a specific
> value of delay to recover the original data back.
> Sometimes no delay is needed, while at times some constant value is
> needed.
> The point is that the symbols are always recovered correctly, but the
> dynamic amount of junk recovered before the constellation locks itself
> makes the pack 8 bits block work differently. (this is what I think is
> happening)
> Is there a workaround or a simple way to fix this problem e.g dynamic
> delay of some type?
> Any help will be appreciated.
>
>
>
> ___
> 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] Introducing the New GNU Radio Website

[Ravi Sharan]

Hi,

The website looks great with more orange everywhere :D. Here are few
things which I think may improve the site's usability:

* The welcome image slides out of the viewing region on smaller screens

* "Learn more" buttons occupy more space below the items in "Learn
about GNU Radio" section

* The "Latest news" and "Upcoming events" can be converged into a
single section with a separate box like area for each section. Smaller
icons can be used for each item in the section and each item in the
list can direct to a page with more detailed
info about the it.

* Foldable "Past Events" section on the Events page ?

* Date information on pages that direct from the News Page (eg: on
release information pages, etc.)

Cheers,
Ravi Sharan

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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[Marcus Müller]

Hi Khalid,

all PPS inputs are 50-Ohm-terminated; you can s

And, as Marcus Leech said, 2.52V should probably be OK – If you go to
the datasheet that he linked to, p.8, you'll see that for the used Vcc
of 3.3V, the rising edge threshold voltage is less then 1.16V; which
means that over the 1.2K/2K voltage divider (R590 / R592) a total
voltage of a little less than 3/2 * 1.16V  = 1.74V must exist. Your
2.52V is higher than that. You should be fine, though not by a huge amount.

Best regards,
Marcus
On 05.05.2016 14:28, khalid.el-darymli wrote:
> Hi,
>
> I will appreciate it if someone could please answer my question.
>
> The PPS signal output from the FireFly 1-A GPS is designed to drive a
> high impedance load (not 50 ohms). Without 50 ohm terminator, my scope
> placed at the output of our PPS fan-out reads 3.68 V (as shown in the
> attachment). With 50 ohm terminator, my scope reads 2.52 V.
>
> Now our fan-out circuit is designed to be a high input impedance and a
> 50 ohm output impedance. What is the input impedance for the PPS
> receiver on the N200 unit?
>
> I understand that the PSS input for N200 is recommended to be in the
> range [3.3 V, 5 V],
> http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
>
> Maybe due to impedance mismatch, the actual input PPS voltage taken
> from our fan-out to the N200 unit exceeds the 5V thus causing
> stability issues inside the N200 unit. I am just guessing because
> using the same set-up, same code, everything worked before just fine.
> The only major change we made was in our fan-out unit.
>
> Khalid
>  
>
> On Tue, May 3, 2016 at 5:20 PM,  > wrote:
>
> What you're going to need to do is provide the *simplest*
> flow-graph that demonstrates the issue, rather than requiring the
> community to debug your entire end-to-end setup.
>
> Also a diagram of your setup showing the RF and 1PPS and 10MHz paths.
>
>  
>
>  
>
>  
>
> On 2016-05-03 15:39, khalid.el-darymli wrote:
>
>> Thanks again Marcus. I really appreciate your help.
>>
>> I am setting Ref Clock / PPS to external, etc. I get the syncing
>> to work properly around a year ago. Since then, we made various
>> changes and I think one or more change may be causing the issue.
>> Among the changes are: buy N200 units with a new revision (could
>> that be a problem when syncing?), upgrading GNU Radio / UHD,
>> enabling Rs 232  echoing in the GPSDO, etc.
>>
>> Similar to my last year tests (I entirely unplugged the RS 232
>> cable), and now it is not detected as an Internal GPSDO. However,
>> I am still having issue syncing the two motherboards.
>>
>> Attached are two figures for the phase drift between Rx1 vs. Rx2,
>> and Rx1 vs. Rx3. This was generated through splitting the Tx and
>> looping it back to the Rx's. Signal processing was done properly
>> (for dechirping, downsamplng, etc). My application is LFMCW
>> radar, so each 490 samples in the attachment represents one
>> sweep, and sweeping was done continuously.
>>  
>> angle(Rx1./Rx2) looks great. As to angle(Rx1./Rx3), I would
>> expect a linear phase offset between different motherboards.
>> However, as .shown in the attachment, Rx1 vs. Rx3 has weird phase
>> spikes. I think this shows that, for some reason, the Tx is not
>> properly synced with the second motherboard. Any ideas on what
>> might be causing this issue?
>>
>> I am using Starttech Ethernet Adapter (ST1000SPEX4). The problem
>> I have with this card is that it won't turn AUTONEG off, it is
>> always on. Could this cause the problem?
>>
>> I tried this on two different Ubuntu machines, with similar
>> results as shown in the attachment.
>>
>> For the first machine,
>>
>> UBUNTU 14.04 LTS
>> linux; GNU C++ version 4.8.2; Boost_105400;
>> UHD_003.008.002-80-ge28d7844
>>
>> For the second machine,
>> UBUNTU 14.04 LTS
>> linux; GNU C++ version 4.8.2; Boost_105400;
>> UHD_003.008.000-46-g5b706d29
>>
>>
>> I'll highly appreciate any suggestions to solve this problem.
>>
>> Thank you.
>>
>> Best wishes,
>> khalid
>>
>>
>>
>>  
>>
>>
>>
>> On Tue, May 3, 2016 at 1:45 PM, > > wrote:
>>
>> The only way the USRP knows that there's a GPSDO present is
>> if the serial data from the GSPDO is validated.  If it
>> doesn't see that data, it concludes that there's no
>> (internal) GPSDO present.
>>
>> There is no concept of "external GPSDO" -- only that
>> *something* is providing 10MHz and 1PPS externally.  The N2xx
>> has no idea what that might be.
>>
>> You should set both 1PPS and 10MHz clock to "external" in
>> your flow-graph. The only time "GPSDO" is used is when you
>> have a properly-installed internally-mounted, GPSDO unit.
>>
>>  
>>
>>  
>>
>>   

Re: [Discuss-gnuradio] Transmission using Aux cable

[Marcus Müller]

Ah!
I'll take the freedom of mentioning your StackOverflow question here:
http://stackoverflow.com/questions/37042209/receiving-data-using-aux-cable-on-gnu-radio
Because it contains an image of your receiver.

Best regards,
Marcus

On 05.05.2016 15:05, Marcus Müller wrote:
> Hi Haaris,
>
> with "aux cable", you're referring to an audio transmission?
>> The point is that the symbols are always recovered correctly, but the
>> dynamic amount of junk recovered before the constellation locks
>> itself makes the pack 8 bits block work differently. (this is what I
>> think is happening)
> Exactly! Since there's no way for the receiver to know when the
> transmitter started transmitting, it decodes stuff before there's
> actually anything to decode.
>
> In essence, you need some kind of preamble or so to tell your receiver
> when to start – side effect of having something like that would be
> that you could correct some things (the two sound cards don't share
> the same oscillator, which leads to a symbol rate offset, and a center
> frequency offset).
>
> I'm not quite sure about the right approach here; we used to have
> "correlate access code", which you can just tell to look for a
> specific streams of 0s and 1s, and throw away stuff before, I think.
> But also, we deprecated that, because it had some fundamental
> architectural drawbacks; don't know what I should really recommend in
> this scenario.
>
> Could you maybe export your flow graph (if you made it in GRC;
> File->Screen Capture) and share it with us?
>
> Best regartds,
> Marcus
> On 05.05.2016 03:09, Haaris wrote:
>> Hello all,
>>
>> I am trying to transmit data using aux cable from one laptop to another.
>> The modulation scheme I am using the PSK mod block is DQPSK.
>> The problem is that while recovering data I have to set a specific
>> value of delay to recover the original data back.
>> Sometimes no delay is needed, while at times some constant value is
>> needed.
>> The point is that the symbols are always recovered correctly, but the
>> dynamic amount of junk recovered before the constellation locks
>> itself makes the pack 8 bits block work differently. (this is what I
>> think is happening)
>> Is there a workaround or a simple way to fix this problem e.g dynamic
>> delay of some type?
>> Any help will be appreciated.
>>
>>
>>
>> ___
>> 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] Introducing the New GNU Radio Website

[Ben Hilburn]

Hi Ravi -

Thanks for passing along your ideas! These are great.

We don't currently have an identified "Web Master", and really need someone
knowledgeable about web development to get involved and help us maintain &
continue improving the site. If you have further suggestions, especially as
you are working on your GSoC project over the coming months, please send
them my way.

Cheers,
Ben

On Thu, May 5, 2016 at 9:48 AM, Ravi Sharan <
bhagavathula.ravisha...@gmail.com> wrote:

> Hi,
>
> The website looks great with more orange everywhere :D. Here are few
> things which I think may improve the site's usability:
>
> * The welcome image slides out of the viewing region on smaller screens
>
> * "Learn more" buttons occupy more space below the items in "Learn
> about GNU Radio" section
>
> * The "Latest news" and "Upcoming events" can be converged into a
> single section with a separate box like area for each section. Smaller
> icons can be used for each item in the section and each item in the
> list can direct to a page with more detailed
> info about the it.
>
> * Foldable "Past Events" section on the Events page ?
>
> * Date information on pages that direct from the News Page (eg: on
> release information pages, etc.)
>
> Cheers,
> Ravi Sharan
>
> ___
> 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] Run Gnu Radio after installation

[Shahnaz Shirazi]

Hi all,

Last night I installed Gnu radio through Pybombs without any error.
I can see all folder being build correctly and have all the required
library.
But some how when I try to run Gnu radio getting error


sudo apt-get install gnuradioThe program 'gnuradio-companion' is currently
not installed. You can install it by typing:shahnaz@ubuntu:~$
gnuradio-companion

as suggested in GitHub I created another folder to install the gnu radio
other than install in on usr/local.

I added below line to my bashrc but no success :

export PYTHONPATH=$PYTHONPATH:/home/shahnaz/Work/lib/python2.7/dist-packages

Do I need another Path set up for Pybombs ?
not sure what I'm missing but after I run the command

pybombs [-p myprefix] install gnuradio

I didn't get any error and at the end it confirmed successful installation.

Thanks in advance.

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

Re: [Discuss-gnuradio] Transmission using Aux cable

[Haaris]

Hi Marcus,

Thanks a lot for the reply.
The screen shot of the flow graph is present below.

http://pasteboard.co/HzDBxB6.png

One more thing is that where in ubuntu is file_sink.cc or the C++ files of
blocks present?
I searched the whole computer for '.cc' and found no .cc gnu radio block
file.
I think I can easily change the C++ code to solve this problem.
Please don't recommend adding a new block, because I have tried that 2 or 3
times and it just does not work.
There are different errors everytime I try to add a new block, sometimes
gnu radio just doesn't pick it up etc.
Moreover there is also not much time left now, before my demo.

Thanks once again for your time.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC] Passive radar support for gr-radar - Introduction

[Anton Debner]

Hello everybody!

My name is Anton Debner and I’m an Information Technology student from Aalto 
University, Finland.

I’m currently polishing my bachelor’s thesis about passive radars and I will be 
implementing the passive radar support for gr-radar during this summer. The 
code will be hosted in [1] and I will be keeping a weekly blog in [2]. My first 
blog post about the project milestones will be coming soon.

I’m very excited about joining this community as a part of this project, I’m 
sure I’ll like it here!

Best regards,
Anton

[1] https://github.com/kit-cel/gr-radar
[2] https://grradar.wordpress.com/


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

[Discuss-gnuradio] gr_modtool and swig

[Laur Joost]

Hi all!

I've run into problems with swig in a project generated by gr_modtool.

When I run
ctest -V -R tle_cc
the test fails with import error:

2: Traceback (most recent call last):
2:   File "/home/ec/Thesis/blocks/gr-doppler/python/qa_doppler_tle_cc.py",
line 25, in 
2: import doppler_swig as doppler
2:   File "/home/ec/Thesis/blocks/gr-doppler/build/swig/doppler_swig.py",
line 28, in 
2: _doppler_swig = swig_import_helper()
2:   File "/home/ec/Thesis/blocks/gr-doppler/build/swig/doppler_swig.py",
line 24, in swig_import_helper
2: _mod = imp.load_module('_doppler_swig', fp, pathname, description)
2: ImportError:
/home/ec/Thesis/blocks/gr-doppler/build/lib/libgnuradio-doppler.so:
undefined symbol: _ZTIN2gr7doppler14doppler_tle_ccE
1/1 Test #2: qa_doppler_tle_cc ***Failed1.83 sec

Objdump has this to say:

ec@GR:~/Thesis/blocks/gr-doppler/build$ objdump -tT
lib/libgnuradio-doppler.so | grep _ZTIN2gr7doppler14doppler_tle_ccE
 *UND* 
 _ZTIN2gr7doppler14doppler_tle_ccE
  D  *UND* 
 _ZTIN2gr7doppler14doppler_tle_ccE

doppler_tle_cc.h is the public header, with doppler_tle_cc_impl.cc/.h being
the implementation header and source. The code compiles.

The test worked before. I refactored the parameters and added setters and
getters, and initialized some variables, but can't pinpoint which of these
broke it.

I know this is not a lot to go on, but perhaps someone has seen something
like this before and can chime in on where to look?

All the best
Laur Joost
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_modtool and swig

[Martin Braun]

Have you nuked the build dir and tried from scratch? These kind of
problems always seem to be SWIG-artifact related.

M

On 05/05/2016 01:01 PM, Laur Joost wrote:
> Hi all!
> 
> I've run into problems with swig in a project generated by gr_modtool.
> 
> When I run
> ctest -V -R tle_cc
> the test fails with import error:
> 
> 2: Traceback (most recent call last):
> 2:   File
> "/home/ec/Thesis/blocks/gr-doppler/python/qa_doppler_tle_cc.py", line
> 25, in 
> 2: import doppler_swig as doppler
> 2:   File
> "/home/ec/Thesis/blocks/gr-doppler/build/swig/doppler_swig.py", line 28,
> in 
> 2: _doppler_swig = swig_import_helper()
> 2:   File
> "/home/ec/Thesis/blocks/gr-doppler/build/swig/doppler_swig.py", line 24,
> in swig_import_helper
> 2: _mod = imp.load_module('_doppler_swig', fp, pathname, description)
> 2: ImportError:
> /home/ec/Thesis/blocks/gr-doppler/build/lib/libgnuradio-doppler.so:
> undefined symbol: _ZTIN2gr7doppler14doppler_tle_ccE
> 1/1 Test #2: qa_doppler_tle_cc ***Failed1.83 sec
> 
> Objdump has this to say: 
> 
> ec@GR:~/Thesis/blocks/gr-doppler/build$ objdump -tT
> lib/libgnuradio-doppler.so | grep _ZTIN2gr7doppler14doppler_tle_ccE
>  *UND*
>  _ZTIN2gr7doppler14doppler_tle_ccE
>   D  *UND*
>  _ZTIN2gr7doppler14doppler_tle_ccE
> 
> doppler_tle_cc.h is the public header, with doppler_tle_cc_impl.cc/.h
>  being the implementation header and
> source. The code compiles.
> 
> The test worked before. I refactored the parameters and added setters
> and getters, and initialized some variables, but can't pinpoint which of
> these broke it.
> 
> I know this is not a lot to go on, but perhaps someone has seen
> something like this before and can chime in on where to look?
> 
> All the best
> Laur Joost
> 
> 
> 
> ___
> 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] [GSoC] Passive radar support for gr-radar - Introduction

[Markus Heller]

Hi Anton,

please check the presentation of Martin PA1SDR:
https://www.youtube.com/watch?v=hulDwYB7-JI

vy73
markus
dl8rds

Am Donnerstag, den 05.05.2016, 22:28 +0300 schrieb Anton Debner:
> Hello everybody!
> 
>  
> 
> My name is Anton Debner and I’m an Information Technology student from
> Aalto University, Finland.
> 
>  
> 
> I’m currently polishing my bachelor’s thesis about passive radars and
> I will be implementing the passive radar support for gr-radar during
> this summer. The code will be hosted in [1] and I will be keeping a
> weekly blog in [2]. My first blog post about the project milestones
> will be coming soon.
> 
>  
> 
> I’m very excited about joining this community as a part of this
> project, I’m sure I’ll like it here!
> 
>  
> 
> Best regards,
> 
> Anton
> 
>  
> 
> [1] https://github.com/kit-cel/gr-radar
> 
> [2] https://grradar.wordpress.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

[Discuss-gnuradio] Portaudio Audio Source in Windows

[Tony Richardson]

I'm using the pre-built Win64 binary of GNURadio listed on the gnuradio.org
site.  The portaudio library was included as part of the Win64 build, but I
can't seem to figure out how to use it instead of the default windows
audio.  (I want an audio source and the windows audio source does not
work.)  I've tried putting "audio_module = portaudio" (and "audio_module =
audio_portaudio") in the config.conf file, but when I run a simple
flowgraph that includes an audio source and sink, I see:

INFO: Audio source arch: windows
INFO: Audio sink arch: windows

in the console and there is no sound.  I assume the lines above are telling
me that the windows audio devices are being used and not the desired
portaudio devices.  I have tried leaving the device name in the audio
source blank as well as trying "0" and "hw:0,0", but still see the messages
above.  Can someone tell me how to configure audio for portaudio or is it
just not supported?

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

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Marcus Müller]

Sorry, not currently running any Windows VM, but in the spirit of giving
you the info you need as fast as possible:

Quick lecture of the audio sink/source factory tells me that under
windows, by default the windows audio architecture is used.
So to use portaudio instead, you need to have a GNU Radio config file
(under unixoids, that's ~/.gnuradio/config.conf), and add

[audio]
audio_module= portaudio


Best regards,
Marcus

On 05.05.2016 22:59, Tony Richardson wrote:
> I'm using the pre-built Win64 binary of GNURadio listed on the
> gnuradio.org  site.  The portaudio library was
> included as part of the Win64 build, but I can't seem to figure out
> how to use it instead of the default windows audio.  (I want an audio
> source and the windows audio source does not work.)  I've tried
> putting "audio_module = portaudio" (and "audio_module =
> audio_portaudio") in the config.conf file, but when I run a simple
> flowgraph that includes an audio source and sink, I see:
>
> INFO: Audio source arch: windows
> INFO: Audio sink arch: windows
>
> in the console and there is no sound.  I assume the lines above are
> telling me that the windows audio devices are being used and not the
> desired portaudio devices.  I have tried leaving the device name in
> the audio source blank as well as trying "0" and "hw:0,0", but still
> see the messages above.  Can someone tell me how to configure audio
> for portaudio or is it just not supported?
>
> Tony Richardson
>
>
> ___
> 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] Linux install script for Xubuntu 16

[Camera Parts]

Is there a version for Ubuntu 16?

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

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Tony Richardson]

Thanks, but I've tried that (setting "audio_module = portaudio").  It
doesn't appear to have the desired effect.

Tony

On Thu, May 5, 2016 at 4:26 PM, Marcus Müller 
wrote:

> Sorry, not currently running any Windows VM, but in the spirit of giving
> you the info you need as fast as possible:
>
> Quick lecture of the audio sink/source factory tells me that under
> windows, by default the windows audio architecture is used.
> So to use portaudio instead, you need to have a GNU Radio config file
> (under unixoids, that's ~/.gnuradio/config.conf), and add
>
> [audio]
> audio_module= portaudio
>
>
> Best regards,
> Marcus
>
> On 05.05.2016 22:59, Tony Richardson wrote:
>
> I'm using the pre-built Win64 binary of GNURadio listed on the
> gnuradio.org site.  The portaudio library was included as part of the
> Win64 build, but I can't seem to figure out how to use it instead of the
> default windows audio.  (I want an audio source and the windows audio
> source does not work.)  I've tried putting "audio_module = portaudio" (and
> "audio_module = audio_portaudio") in the config.conf file, but when I run a
> simple flowgraph that includes an audio source and sink, I see:
>
> INFO: Audio source arch: windows
> INFO: Audio sink arch: windows
>
> in the console and there is no sound.  I assume the lines above are
> telling me that the windows audio devices are being used and not the
> desired portaudio devices.  I have tried leaving the device name in the
> audio source blank as well as trying "0" and "hw:0,0", but still see the
> messages above.  Can someone tell me how to configure audio for portaudio
> or is it just not supported?
>
> Tony Richardson
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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

[Discuss-gnuradio] [UHD] 3.9.4 Release Announcement

[Martin Braun]

All,

the 3.9.4 UHD release is tagged and available. Please find the github
tag here: https://github.com/EttusResearch/uhd/tree/release_003_009_004
Installers for Fedora and Ubuntu are available in the usual spots.
Windows installers will come early next week at the latest.

One of the reasons we are releasing this much sooner than usual is the
fact that a bug was introduced in 3.9.3, which affects full-duplex
operations. There are a few other minor issues resolved in this release,
too, and we strongly recommend upgrading to this version.
Anyone tracking maint branch will already have all the updates. We do
appreciate all feedback we got from the community!

Cheers,
Martin


PS: Changelog:

## 003.009.004
- GPIO control: Fix address mismatch for RX and full duplex.
  This fixes full-duplex mode for most devices.
- B200: Fixed auto rate selection (can now select 61.44 Msps)
- UBX: Fix member declaration order which could cause
  segfaults for debug builds
- Manual/Docs: Numerous fixes, use dot for graphs in manual
- Utils: multiple fixes for query_gpsdo_sensors, fixed floating point
  comparison
- Windows: Include registry file in installation
- Converters: Improve NEON converters


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

Re: [Discuss-gnuradio] [USRP-users] [UHD] 3.9.4 Release Announcement

[Derek Kozel]

The Windows installers are now available.

http://files.ettus.com/binaries/uhd/uhd_003.009.004-release/

On Thu, May 5, 2016 at 3:44 PM, Martin Braun via USRP-users <
usrp-us...@lists.ettus.com> wrote:

> All,
>
> the 3.9.4 UHD release is tagged and available. Please find the github
> tag here: https://github.com/EttusResearch/uhd/tree/release_003_009_004
> Installers for Fedora and Ubuntu are available in the usual spots.
> Windows installers will come early next week at the latest.
>
> One of the reasons we are releasing this much sooner than usual is the
> fact that a bug was introduced in 3.9.3, which affects full-duplex
> operations. There are a few other minor issues resolved in this release,
> too, and we strongly recommend upgrading to this version.
> Anyone tracking maint branch will already have all the updates. We do
> appreciate all feedback we got from the community!
>
> Cheers,
> Martin
>
>
> PS: Changelog:
>
> ## 003.009.004
> - GPIO control: Fix address mismatch for RX and full duplex.
>   This fixes full-duplex mode for most devices.
> - B200: Fixed auto rate selection (can now select 61.44 Msps)
> - UBX: Fix member declaration order which could cause
>   segfaults for debug builds
> - Manual/Docs: Numerous fixes, use dot for graphs in manual
> - Utils: multiple fixes for query_gpsdo_sensors, fixed floating point
>   comparison
> - Windows: Include registry file in installation
> - Converters: Improve NEON converters
>
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with Pybomb new release

[Shahnaz Shirazi]

Hi,

Last night ( 6:00pm 5/4/2016) I cloned to pybomb and installed GNU Radio
without any issue.

Today morning follows same step to install it  on my new VM image but no
success and keep getting below error after install gnu radio command.

Please set GLIB_CFLAGS and GLIB_LIBS to the correct values or pass
--with-internal-glib to configure to use the bundled copy

I found there was an update on pybomb Github 20 hrs ago.
Can some one help to put back the change to earlier version?
Also meanwhile wanted to know how I can clone to yesterday pybomb
repository as there are multiple file updated and I want to clone to what
exactly I did yesterday.


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

Re: [Discuss-gnuradio] Problem with Pybomb new release

[Shahnaz Shirazi]

just found the command :

git checkout @{1.days.ago}


On Thu, May 5, 2016 at 8:00 PM, Shahnaz Shirazi 
wrote:

> Hi,
>
> Last night ( 6:00pm 5/4/2016) I cloned to pybomb and installed GNU Radio
> without any issue.
>
> Today morning follows same step to install it  on my new VM image but no
> success and keep getting below error after install gnu radio command.
>
> Please set GLIB_CFLAGS and GLIB_LIBS to the correct values or pass
> --with-internal-glib to configure to use the bundled copy
>
> I found there was an update on pybomb Github 20 hrs ago.
> Can some one help to put back the change to earlier version?
> Also meanwhile wanted to know how I can clone to yesterday pybomb
> repository as there are multiple file updated and I want to clone to what
> exactly I did yesterday.
>
>
> Thanks,
> Shahnaz
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio