Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Gary.Simpkins]

Hi Marcus and any windows experts

Trying to get portaudio working in GNURadio (win10). can you answer 
these simple questions.


Using  gnuradio-config-info  --enabled-components, I get the following.

python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* 
portaudio;* 
windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq.


 Is the * infront of portaudio significant?  Is it a wild card? do you 
now what this means? (I know this is windows and not UNIX)


gnuradio-config-info  --userprefsdir  responds with

C:\Users\Gary\AppData\Roaming\.gnuradio

In this directory is a config.conf file.  It was empty, so I added

[audio]

audio_module = portaudio

I saved and restarted the PC, but GNUradio is not using portaudio. So it 
looks like it is not being used.


Regards

Gary



On 04/05/2019 14:39, Müller, Marcus (CEL) wrote:

Hey Gary,
please keep things on the list! Good news:
That's the exact opposite of what I wanted to convey! *Use* GNU Radio's
existing portaudio interface; chances are that your GNU Radio
installation supports that (which is why I asked how you've installed
it).
https://www.gnuradio.org/doc/doxygen/page_audio.html tells us how to do
that:
you just need to find your GNU Radio configuration (for me as Unix user
it's in ~/.gnuradio/config.conf, but yours is probably somewhere else;
running `gnuradio-config-info --userprefsdir` should give you an idea
where to look). Add, if not already in there, the following:

[audio]
audio_module = portaudio

Done! That tells GNU Radio to not just try the first best guess of what
audio system you want to use (that being windows API under windows),
but to specifically use portaudio – and that should have the features
you're looking for.

Still, the windows source not working as it should is a pain. We should
fix that.

Best regards,
Marcus

On Sat, 2019-05-04 at 08:05 +0100, gary.simpk...@gdscs.co.uk wrote:

Many thanks for the explanation. Looks like I can go no further. I do
not have the skills to develope the audio source.

Gary

Sent from my Huawei Mobile


 Original Message 
Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs
(Stereo) in
windows
From: "M黮ler, Marcus (CEL)"
To: discuss-gnuradio@gnu.org,gary.simpk...@gdscs.co.uk
CC:



Hi Gary!


I have double checked and all the windows audio devices I have
used
for the audio source are 2 channels.

I never doubted that – all I wanted to point out that the I think
it
was Windows that told the GNU Radio windows audio source it saw
only
one channel, and consequently the windows audio source only enabled
one
output port.

I was wrong, it turns out! When you look at gr-
audio/liob/windows/windows_source.cc, you'll find the number of
output
streams of the block to be hardcoded to be between 1 and 1, so...
1:


windows_source::windows_source(int sampling_freq,
const std::string
device_name)
: sync_block("audio_windows_source",
io_signature::make(0, 0, 0),
io_signature::make(1, 1,
sizeof(float))),

The last line does that.
So, that's a um, underdeveloped feature in the windows audio
source.


They work fine with WSJT-X, or MAP65.

The stereo channels I wish to use are the I and Q outputs from

my

SDRPLay Duo using virtual cables

(I have tried the speaker outputs from the PC with GNURadio audio
source
and get the same problem)

Does the audio source work with two channels on linux?

Yes, (haven't tried today, but it /used/ to work), but it sadly
shares
nearly no code with the windows audio source. That's due to fact
that
Linux' ALSA and Windows' sound API and OS X's Core Audio are pretty
different.

I do have an idea, though, which *might* be a solution to your
problem,
but: untested; don't expect wonders.

Has your GNU Radio build portaudio enabled? As said, it's not
tested,
but unlike the windows audio source, the portaudio source at least
from
the state of the source code (far as I can tell) enables as many
maximum output streams as your card has.

I am using the latest version of GNURadio 3.7.13.4 on a 64bit win

10

PC.


Built from source, or where did you happen across it?


I am really stuck here. Nothing I try allows the second output to

be

enabled.


Sorry to hear that! We'll try to get you unstuck :)

Best regards,
Marcus


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

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Marcus Müller]

Hi Gary,

The "* " is good; when you take that full output of gnuradio-config…,
and replace the ";" with line breaks, you get a nice list with indented
subentries. In this case, the list entry of interest would be

gr-audio
* portaudio
* windows

Nothing to do with windows vs UNIX, it's just the way we output things
(for historical reasons). I think it wasn't originally meant to be all
on one line (I don't actually know), but you can't change a
"diagnostic" program's output to look better later on – there might be
someone else's software depending on it being one line (welcome to the
hell of popular software!). 

> I saved and restarted the PC, but GNUradio is not using portaudio. So
> it 

Huh! Interesting, to say the least. Can you check whether `gnuradio-
config-info --prefs` actually shows the correct value (as put by you
there)?

Best regards,
Marcus

On Sun, 2019-05-05 at 10:39 +0100, Gary.Simpkins wrote:
> Hi Marcus and any windows experts
> 
> Trying to get portaudio working in GNURadio (win10). can you answer 
> these simple questions.
> 
> Using  gnuradio-config-info  --enabled-components, I get the
> following.
> 
> python-support;testing-support;volk;doxygen;sphinx;gnuradio-
> runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-
> filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* 
> portaudio;* 
> windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-
> utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq.
> 
>   Is the * infront of portaudio significant?  Is it a wild card? do
> you 
> now what this means? (I know this is windows and not UNIX)
> 
> gnuradio-config-info  --userprefsdir  responds with
> 
> C:\Users\Gary\AppData\Roaming\.gnuradio
> 
> In this directory is a config.conf file.  It was empty, so I added
> 
> [audio]
> 
> audio_module = portaudio
> 
> I saved and restarted the PC, but GNUradio is not using portaudio. So
> it 
> looks like it is not being used.
> 
> Regards
> 
> Gary
> 
> 
> 
> On 04/05/2019 14:39, Müller, Marcus (CEL) wrote:
> > Hey Gary,
> > please keep things on the list! Good news:
> > That's the exact opposite of what I wanted to convey! *Use* GNU
> > Radio's
> > existing portaudio interface; chances are that your GNU Radio
> > installation supports that (which is why I asked how you've
> > installed
> > it).
> > https://www.gnuradio.org/doc/doxygen/page_audio.html tells us how
> > to do
> > that:
> > you just need to find your GNU Radio configuration (for me as Unix
> > user
> > it's in ~/.gnuradio/config.conf, but yours is probably somewhere
> > else;
> > running `gnuradio-config-info --userprefsdir` should give you an
> > idea
> > where to look). Add, if not already in there, the following:
> > 
> > [audio]
> > audio_module = portaudio
> > 
> > Done! That tells GNU Radio to not just try the first best guess of
> > what
> > audio system you want to use (that being windows API under
> > windows),
> > but to specifically use portaudio – and that should have the
> > features
> > you're looking for.
> > 
> > Still, the windows source not working as it should is a pain. We
> > should
> > fix that.
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-04 at 08:05 +0100, gary.simpk...@gdscs.co.uk wrote:
> > > Many thanks for the explanation. Looks like I can go no further.
> > > I do
> > > not have the skills to develope the audio source.
> > > 
> > > Gary
> > > 
> > > Sent from my Huawei Mobile
> > > 
> > > 
> > >  Original Message 
> > > Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs
> > > (Stereo) in
> > > windows
> > > From: "M黮ler, Marcus (CEL)"
> > > To: discuss-gnuradio@gnu.org,gary.simpk...@gdscs.co.uk
> > > CC:
> > > 
> > > 
> > > > Hi Gary!
> > > > 
> > > > > I have double checked and all the windows audio devices I
> > > > > have
> > > > > used
> > > > > for the audio source are 2 channels.
> > > > I never doubted that – all I wanted to point out that the I
> > > > think
> > > > it
> > > > was Windows that told the GNU Radio windows audio source it saw
> > > > only
> > > > one channel, and consequently the windows audio source only
> > > > enabled
> > > > one
> > > > output port.
> > > > 
> > > > I was wrong, it turns out! When you look at gr-
> > > > audio/liob/windows/windows_source.cc, you'll find the number of
> > > > output
> > > > streams of the block to be hardcoded to be between 1 and 1,
> > > > so...
> > > > 1:
> > > > 
> > > > 
> > > > windows_source::windows_source(int sampling_freq,
> > > > const std::string
> > > > device_name)
> > > > : sync_block("audio_windows_source",
> > > > io_signature::make(0, 0, 0),
> > > > io_signature::make(1, 1,
> > > > sizeof(float))),
> > > > 
> > > > The last line does that.
> > > > So, that's a um, underdeveloped feature in the windows audio
> > > > source.
> > > > 
> > > > > They work fine with WSJT-X, or MAP65.
> > > > > 
> > > > > The stereo channels I wish to use are the I and Q outputs
> > > > > from
> > > > my
> > > > > SD

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Gary.Simpkins]

Hi Marcus.

Nothing in --prefs at all.

Regards

Gary

On 05/05/2019 11:30, Marcus Müller wrote:

Hi Gary,

The "* " is good; when you take that full output of gnuradio-config…,
and replace the ";" with line breaks, you get a nice list with indented
subentries. In this case, the list entry of interest would be

gr-audio
* portaudio
* windows

Nothing to do with windows vs UNIX, it's just the way we output things
(for historical reasons). I think it wasn't originally meant to be all
on one line (I don't actually know), but you can't change a
"diagnostic" program's output to look better later on – there might be
someone else's software depending on it being one line (welcome to the
hell of popular software!).


I saved and restarted the PC, but GNUradio is not using portaudio. So
it

Huh! Interesting, to say the least. Can you check whether `gnuradio-
config-info --prefs` actually shows the correct value (as put by you
there)?

Best regards,
Marcus

On Sun, 2019-05-05 at 10:39 +0100, Gary.Simpkins wrote:

Hi Marcus and any windows experts

Trying to get portaudio working in GNURadio (win10). can you answer
these simple questions.

Using  gnuradio-config-info  --enabled-components, I get the
following.

python-support;testing-support;volk;doxygen;sphinx;gnuradio-
runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-
filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
portaudio;*
windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-
utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq.

   Is the * infront of portaudio significant?  Is it a wild card? do
you
now what this means? (I know this is windows and not UNIX)

gnuradio-config-info  --userprefsdir  responds with

C:\Users\Gary\AppData\Roaming\.gnuradio

In this directory is a config.conf file.  It was empty, so I added

[audio]

audio_module = portaudio

I saved and restarted the PC, but GNUradio is not using portaudio. So
it
looks like it is not being used.

Regards

Gary



On 04/05/2019 14:39, Müller, Marcus (CEL) wrote:

Hey Gary,
please keep things on the list! Good news:
That's the exact opposite of what I wanted to convey! *Use* GNU
Radio's
existing portaudio interface; chances are that your GNU Radio
installation supports that (which is why I asked how you've
installed
it).
https://www.gnuradio.org/doc/doxygen/page_audio.html tells us how
to do
that:
you just need to find your GNU Radio configuration (for me as Unix
user
it's in ~/.gnuradio/config.conf, but yours is probably somewhere
else;
running `gnuradio-config-info --userprefsdir` should give you an
idea
where to look). Add, if not already in there, the following:

[audio]
audio_module = portaudio

Done! That tells GNU Radio to not just try the first best guess of
what
audio system you want to use (that being windows API under
windows),
but to specifically use portaudio – and that should have the
features
you're looking for.

Still, the windows source not working as it should is a pain. We
should
fix that.

Best regards,
Marcus

On Sat, 2019-05-04 at 08:05 +0100, gary.simpk...@gdscs.co.uk wrote:

Many thanks for the explanation. Looks like I can go no further.
I do
not have the skills to develope the audio source.

Gary

Sent from my Huawei Mobile


 Original Message 
Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs
(Stereo) in
windows
From: "M黮ler, Marcus (CEL)"
To: discuss-gnuradio@gnu.org,gary.simpk...@gdscs.co.uk
CC:



Hi Gary!


I have double checked and all the windows audio devices I
have
used
for the audio source are 2 channels.

I never doubted that – all I wanted to point out that the I
think
it
was Windows that told the GNU Radio windows audio source it saw
only
one channel, and consequently the windows audio source only
enabled
one
output port.

I was wrong, it turns out! When you look at gr-
audio/liob/windows/windows_source.cc, you'll find the number of
output
streams of the block to be hardcoded to be between 1 and 1,
so...
1:


windows_source::windows_source(int sampling_freq,
const std::string
device_name)
: sync_block("audio_windows_source",
io_signature::make(0, 0, 0),
io_signature::make(1, 1,
sizeof(float))),

The last line does that.
So, that's a um, underdeveloped feature in the windows audio
source.


They work fine with WSJT-X, or MAP65.

The stereo channels I wish to use are the I and Q outputs
from

my

SDRPLay Duo using virtual cables

(I have tried the speaker outputs from the PC with GNURadio
audio
source
and get the same problem)

Does the audio source work with two channels on linux?

Yes, (haven't tried today, but it /used/ to work), but it sadly
shares
nearly no code with the windows audio source. That's due to
fact
that
Linux' ALSA and Windows' sound API and OS X's Core Audio are
pretty
different.

I do have an idea, though, which *might* be a solution to your
problem,
but: untested; don't expect wonders.

Has your GNU Radio build portaudio enabled? As said, it's not
tested,
but un

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Gary.Simpkins]

Hi Marcus

--prefsdir returns

Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d

I dont have a drive Z:

This confuses simple folk like me.  Willing to learn though.

Regards

Gary

On 05/05/2019 11:30, Marcus Müller wrote:

Hi Gary,

The "* " is good; when you take that full output of gnuradio-config…,
and replace the ";" with line breaks, you get a nice list with indented
subentries. In this case, the list entry of interest would be

gr-audio
* portaudio
* windows

Nothing to do with windows vs UNIX, it's just the way we output things
(for historical reasons). I think it wasn't originally meant to be all
on one line (I don't actually know), but you can't change a
"diagnostic" program's output to look better later on – there might be
someone else's software depending on it being one line (welcome to the
hell of popular software!).


I saved and restarted the PC, but GNUradio is not using portaudio. So
it

Huh! Interesting, to say the least. Can you check whether `gnuradio-
config-info --prefs` actually shows the correct value (as put by you
there)?

Best regards,
Marcus

On Sun, 2019-05-05 at 10:39 +0100, Gary.Simpkins wrote:

Hi Marcus and any windows experts

Trying to get portaudio working in GNURadio (win10). can you answer
these simple questions.

Using  gnuradio-config-info  --enabled-components, I get the
following.

python-support;testing-support;volk;doxygen;sphinx;gnuradio-
runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-
filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
portaudio;*
windows;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-
utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq.

   Is the * infront of portaudio significant?  Is it a wild card? do
you
now what this means? (I know this is windows and not UNIX)

gnuradio-config-info  --userprefsdir  responds with

C:\Users\Gary\AppData\Roaming\.gnuradio

In this directory is a config.conf file.  It was empty, so I added

[audio]

audio_module = portaudio

I saved and restarted the PC, but GNUradio is not using portaudio. So
it
looks like it is not being used.

Regards

Gary



On 04/05/2019 14:39, Müller, Marcus (CEL) wrote:

Hey Gary,
please keep things on the list! Good news:
That's the exact opposite of what I wanted to convey! *Use* GNU
Radio's
existing portaudio interface; chances are that your GNU Radio
installation supports that (which is why I asked how you've
installed
it).
https://www.gnuradio.org/doc/doxygen/page_audio.html tells us how
to do
that:
you just need to find your GNU Radio configuration (for me as Unix
user
it's in ~/.gnuradio/config.conf, but yours is probably somewhere
else;
running `gnuradio-config-info --userprefsdir` should give you an
idea
where to look). Add, if not already in there, the following:

[audio]
audio_module = portaudio

Done! That tells GNU Radio to not just try the first best guess of
what
audio system you want to use (that being windows API under
windows),
but to specifically use portaudio – and that should have the
features
you're looking for.

Still, the windows source not working as it should is a pain. We
should
fix that.

Best regards,
Marcus

On Sat, 2019-05-04 at 08:05 +0100, gary.simpk...@gdscs.co.uk wrote:

Many thanks for the explanation. Looks like I can go no further.
I do
not have the skills to develope the audio source.

Gary

Sent from my Huawei Mobile


 Original Message 
Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs
(Stereo) in
windows
From: "M黮ler, Marcus (CEL)"
To: discuss-gnuradio@gnu.org,gary.simpk...@gdscs.co.uk
CC:



Hi Gary!


I have double checked and all the windows audio devices I
have
used
for the audio source are 2 channels.

I never doubted that – all I wanted to point out that the I
think
it
was Windows that told the GNU Radio windows audio source it saw
only
one channel, and consequently the windows audio source only
enabled
one
output port.

I was wrong, it turns out! When you look at gr-
audio/liob/windows/windows_source.cc, you'll find the number of
output
streams of the block to be hardcoded to be between 1 and 1,
so...
1:


windows_source::windows_source(int sampling_freq,
const std::string
device_name)
: sync_block("audio_windows_source",
io_signature::make(0, 0, 0),
io_signature::make(1, 1,
sizeof(float))),

The last line does that.
So, that's a um, underdeveloped feature in the windows audio
source.


They work fine with WSJT-X, or MAP65.

The stereo channels I wish to use are the I and Q outputs
from

my

SDRPLay Duo using virtual cables

(I have tried the speaker outputs from the PC with GNURadio
audio
source
and get the same problem)

Does the audio source work with two channels on linux?

Yes, (haven't tried today, but it /used/ to work), but it sadly
shares
nearly no code with the windows audio source. That's due to
fact
that
Linux' ALSA and Windows' sound API and OS X's Core Audio are
pretty
different.

I do have an idea, though, which *might* be a sol

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Marcus Müller]

Hi Gary,

> This confuses simple folk like me.

this confuses simple folks such as me, too!

That --prefsdir output is most defintely bogus. I can speculate what
happened there, however:

> Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d

That --prefsdir value is part of the source code that gets compiled
into the tool/the GNU Radio libraries. Normally, you wouldn't do that,
"hardwiring" a directory path into a library, but write it in a
configuration file or something.

However, in this case, that's the place we start looking into to find
the configuration files. So, that's the one thing that actually need to
hardwire.

So, there's a text string "Z:\gr-build\src-
stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is
probably a remnant of the machine that your GNU Radio got built on
(again, how did you install that?).
Sadly, the "\" gets interpreted by the compiler to be "escape symbol",
so that you can have things like "\n" for newline in strings. Luckily,
none of the first letters of directory names combined with "\" give a
valid escape sequence, so the compiler just silently drops the "\" and
this is the string you end up with.

I'll admit it: that's funky, and I didn't know that happened. We'll
most definitely will have to rewrite something to make this work under
windows (which uses backslashes for directory separation, unlike
unixoids, which use forward slashes).

So, why does --userprefsdir work, but --prefsdir not? 

Well, --userprefsdir is built from environment variables at runtime, so
it's correct, not mangled by a compiler.

I hear you say, that's fine and all, and now? 

Welll! I thought it strange that, although your userprefsdir seems
correct, GNU Radio didn't read the configuration file you modified. So,
down the rabbit hole it goes. Here's our culprit, in prefs.cc:

  std::vector
  prefs::_sys_prefs_filenames()
  {
std::vector fnames;

fs::path dir = prefsdir();
if(!fs::is_directory(dir))
  return fnames; // 10 emails
thread that started with a sound card problem:

The solution should be simple.

There's a way of overriding the hardwired prefsdir! We don't even have
to set it to the *right* directory, just any path that is actually a
directory. The way to do that would be setting an environment variable
"GR_PREFIX" that leads to the right place.

So, I don't actually know where these things get installed to on
Windows, or on your individual machine, but: Can you look for a
directory "conf.d" in a path ending in etc\gnuradio\conf.d?

Let's say it's C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d .

then, you'd have to do something like

set GR_PREFIX=C:\Programs\gnuradio\dragonsbehere
gnuradio-config-info --prefsdir

If that now prints
C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d, we're almost
there. Try, from the same command window, 

gnuradio-config-info --prefs

Does that work?
If it does, there's a way to permanently set environment variables
under windows, but I've forgotten it. I can look it up, if you want.

Best regards,
Marcus

On Sun, 2019-05-05 at 13:55 +0100, Gary.Simpkins wrote:
> Hi Marcus
> 
> --prefsdir returns
> 
> Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
> 
> I dont have a drive Z:
> 
> This confuses simple folk like me.  Willing to learn though.
> 
> Regards
> 
> Gary
> 
> On 05/05/2019 11:30, Marcus Müller wrote:
> > Hi Gary,
> > 
> > The "* " is good; when you take that full output of gnuradio-
> > config…,
> > and replace the ";" with line breaks, you get a nice list with
> > indented
> > subentries. In this case, the list entry of interest would be
> > 
> > gr-audio
> > * portaudio
> > * windows
> > 
> > Nothing to do with windows vs UNIX, it's just the way we output
> > things
> > (for historical reasons). I think it wasn't originally meant to be
> > all
> > on one line (I don't actually know), but you can't change a
> > "diagnostic" program's output to look better later on – there might
> > be
> > someone else's software depending on it being one line (welcome to
> > the
> > hell of popular software!).
> > 
> > > I saved and restarted the PC, but GNUradio is not using
> > > portaudio. So
> > > it
> > Huh! Interesting, to say the least. Can you check whether
> > `gnuradio-

Re: [Discuss-gnuradio] Data loss during transmission (OFDM .bmp file)

[Marcus Müller]

Well, noise happens, and synchronization isn't instantaneous. Things
that aren't detected can't be received, and bit errors that the FEC
can't correct are bit errors in the received data.

That's the beauty and the curse of wireless communications.

Best regards,
Marcus

On Sat, 2019-05-04 at 20:26 -0400, Simran Kaur wrote:
> Hello All,
> We are trying to transmit a .bmp file using USRP Tx/Rx. However, I am
> getting bogus header data at the receiving end. I tried transmitting
> a text file also which clips my starting text and also it inserts
> some invalid/unknown characters. We are losing some of the bytes for
> e.g, the transmitted file size is of 426316 bytes, but receiving file
> size is of 4,264,224 bytes.
> Can somebody explain what we are doing wrong here. I have attached my
> Tx and Rx .grc and snapshots for the reference.
> 
> Best,
> Simran Kaur
> ___
> 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] Data loss during transmission (OFDM .bmp file)

[Kevin McQuiggin]

Read, read read!  Simple questions often lead to very complex answers.

You might start your studies with "The Scientist & Engineer's Guide to Digital 
Signal Processing” by S. Smith.

Kevin

> On May 5, 2019, at 9:46 AM, Marcus Müller  wrote:
> 
> Well, noise happens, and synchronization isn't instantaneous. Things
> that aren't detected can't be received, and bit errors that the FEC
> can't correct are bit errors in the received data.
> 
> That's the beauty and the curse of wireless communications.
> 
> Best regards,
> Marcus
> 
> On Sat, 2019-05-04 at 20:26 -0400, Simran Kaur wrote:
>> Hello All,
>> We are trying to transmit a .bmp file using USRP Tx/Rx. However, I am
>> getting bogus header data at the receiving end. I tried transmitting
>> a text file also which clips my starting text and also it inserts
>> some invalid/unknown characters. We are losing some of the bytes for
>> e.g, the transmitted file size is of 426316 bytes, but receiving file
>> size is of 4,264,224 bytes.
>> Can somebody explain what we are doing wrong here. I have attached my
>> Tx and Rx .grc and snapshots for the reference.
>> 
>> Best,
>> Simran Kaur
>> ___
>> 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



signature.asc
Description: Message signed with OpenPGP
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Gary.Simpkins]

Hi Marcus  Fed up with me yet !!

OK we make some progress. My conf.d directory is 
F:\GNURadio-3.7\etc\gnuradio\conf.d.


I have set this as the prefix

gnuradio-config.info --prefix shows F:\GNURadio-3.7\etc\gnuradio\conf.d

gnuradio-config.info --prefsdir shows F:\GNURadio-3.7\etc\gnuradio\conf.d

looking good   hey.

gnuradio-config.info --prefs shows yep 
nought


FYI and anyone who would like to know

To set a variable in windows 10.

Left click on windows icon (Lower left of screen). Then press "e".

select edit system variables,  Select Enviroment Variables

Select new variable.  Enter vaible name and variable.

It works I just tried it and the GR_PREFIX variable is there as gets 
output with gnuradio-config-infi --prefix and prefsdir



I instaled gnuradio_3.7.13.4_win64 (2).msi 



from 
http://www.gcndevelopment.com/gnuradio/downloads/installers/v1.5.0/gnuradio_3.7.13.4_win64.msi


Regards

Gary


On 05/05/2019 17:43, Marcus Müller wrote:

Hi Gary,


This confuses simple folk like me.

this confuses simple folks such as me, too!

That --prefsdir output is most defintely bogus. I can speculate what
happened there, however:


Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d

That --prefsdir value is part of the source code that gets compiled
into the tool/the GNU Radio libraries. Normally, you wouldn't do that,
"hardwiring" a directory path into a library, but write it in a
configuration file or something.

However, in this case, that's the place we start looking into to find
the configuration files. So, that's the one thing that actually need to
hardwire.

So, there's a text string "Z:\gr-build\src-
stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is
probably a remnant of the machine that your GNU Radio got built on
(again, how did you install that?).
Sadly, the "\" gets interpreted by the compiler to be "escape symbol",
so that you can have things like "\n" for newline in strings. Luckily,
none of the first letters of directory names combined with "\" give a
valid escape sequence, so the compiler just silently drops the "\" and
this is the string you end up with.

I'll admit it: that's funky, and I didn't know that happened. We'll
most definitely will have to rewrite something to make this work under
windows (which uses backslashes for directory separation, unlike
unixoids, which use forward slashes).

So, why does --userprefsdir work, but --prefsdir not?

Well, --userprefsdir is built from environment variables at runtime, so
it's correct, not mangled by a compiler.

I hear you say, that's fine and all, and now?

Welll! I thought it strange that, although your userprefsdir seems
correct, GNU Radio didn't read the configuration file you modified. So,
down the rabbit hole it goes. Here's our culprit, in prefs.cc:

   std::vector
   prefs::_sys_prefs_filenames()
   {
 std::vector fnames;

 fs::path dir = prefsdir();
 if(!fs::is_directory(dir))
   return fnames; // 10 emails
thread that started with a sound card problem:

The solution should be simple.

There's a way of overriding the hardwired prefsdir! We don't even have
to set it to the *right* directory, just any path that is actually a
directory. The way to do that would be setting an environment variable
"GR_PREFIX" that leads to the right place.

So, I don't actually know where these things get installed to on
Windows, or on your individual machine, but: Can you look for a
directory "conf.d" in a path ending in etc\gnuradio\conf.d?

Let's say it's C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d .

then, you'd have to do something like

set GR_PREFIX=C:\Programs\gnuradio\dragonsbehere
gnuradio-config-info --prefsdir

If that now prints
C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d, we're almost
there. Try, from the same command window,

gnuradio-config-info --prefs

Does that work?
If it does, there's a way to permanently set environment variables
under windows, but I've forgotten it. I can look it up, if you want.

Best regards,
Marcus

On Sun, 2019-05-05 at 13:55 +0100, Gary.Simpkins wrote:

Hi Marcus

--prefsdir returns

Z:g

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Gary.Simpkins]

Hi Marcus.

FYI    I also tried changing the gr-audio.conf file in the conf.d in the 
directory to to portaudio, but even that did not change the audio source 
to portaudio. AG


Gary

On 05/05/2019 17:43, Marcus Müller wrote:

Hi Gary,


This confuses simple folk like me.

this confuses simple folks such as me, too!

That --prefsdir output is most defintely bogus. I can speculate what
happened there, however:


Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d

That --prefsdir value is part of the source code that gets compiled
into the tool/the GNU Radio libraries. Normally, you wouldn't do that,
"hardwiring" a directory path into a library, but write it in a
configuration file or something.

However, in this case, that's the place we start looking into to find
the configuration files. So, that's the one thing that actually need to
hardwire.

So, there's a text string "Z:\gr-build\src-
stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is
probably a remnant of the machine that your GNU Radio got built on
(again, how did you install that?).
Sadly, the "\" gets interpreted by the compiler to be "escape symbol",
so that you can have things like "\n" for newline in strings. Luckily,
none of the first letters of directory names combined with "\" give a
valid escape sequence, so the compiler just silently drops the "\" and
this is the string you end up with.

I'll admit it: that's funky, and I didn't know that happened. We'll
most definitely will have to rewrite something to make this work under
windows (which uses backslashes for directory separation, unlike
unixoids, which use forward slashes).

So, why does --userprefsdir work, but --prefsdir not?

Well, --userprefsdir is built from environment variables at runtime, so
it's correct, not mangled by a compiler.

I hear you say, that's fine and all, and now?

Welll! I thought it strange that, although your userprefsdir seems
correct, GNU Radio didn't read the configuration file you modified. So,
down the rabbit hole it goes. Here's our culprit, in prefs.cc:

   std::vector
   prefs::_sys_prefs_filenames()
   {
 std::vector fnames;

 fs::path dir = prefsdir();
 if(!fs::is_directory(dir))
   return fnames; // 10 emails
thread that started with a sound card problem:

The solution should be simple.

There's a way of overriding the hardwired prefsdir! We don't even have
to set it to the *right* directory, just any path that is actually a
directory. The way to do that would be setting an environment variable
"GR_PREFIX" that leads to the right place.

So, I don't actually know where these things get installed to on
Windows, or on your individual machine, but: Can you look for a
directory "conf.d" in a path ending in etc\gnuradio\conf.d?

Let's say it's C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d .

then, you'd have to do something like

set GR_PREFIX=C:\Programs\gnuradio\dragonsbehere
gnuradio-config-info --prefsdir

If that now prints
C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d, we're almost
there. Try, from the same command window,

gnuradio-config-info --prefs

Does that work?
If it does, there's a way to permanently set environment variables
under windows, but I've forgotten it. I can look it up, if you want.

Best regards,
Marcus

On Sun, 2019-05-05 at 13:55 +0100, Gary.Simpkins wrote:

Hi Marcus

--prefsdir returns

Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d

I dont have a drive Z:

This confuses simple folk like me.  Willing to learn though.

Regards

Gary

On 05/05/2019 11:30, Marcus Müller wrote:

Hi Gary,

The "* " is good; when you take that full output of gnuradio-
config…,
and replace the ";" with line breaks, you get a nice list with
indented
subentries. In this case, the list entry of interest would be

gr-audio
* portaudio
* windows

Nothing to do with windows vs UNIX, it's just the way we output
things
(for historical reasons). I think it wasn't originally meant to be
all
on one line (I don't actually know), but you can't change a
"diagnostic" program's output to look better later on – there might
be
someone else's software depending on it being one line (welcome to
the
hell of popular software!).


I saved and restarted the PC, but GNUradio