Re: Resending: reconfigure flowgrpah through messaging

[Achilleas Anastasopoulos]

Thanks Nick!

I tried the "selector" idea with a message block and it works fine.

Achilleas

On Wed, Mar 27, 2024 at 2:50 PM Nick Foster  wrote:

> Achilleas,
>
> Sure, this is possible. Through Python all things are possible, to
> paraphrase. =)
>
> The message could be, but doesn't have to be, a Gnuradio PMT message
> passed via the message passing interface. It is probably easier for your
> sending block to simply set a semaphore or condition variable shared by the
> toplevel flowgraph and passed into the sending block at construction. The
> semaphore is monitored by the toplevel main loop and triggers a
> reconfiguration when set.
>
> You could also use the "Message to Variable" block to set a variable
> created in the toplevel flowgraph, and then monitor that variable's value
> in the toplevel main loop to trigger reconfiguration.
>
> The important thing to remember about the above two approaches is that
> thread safety requires that you do the reconfiguration in the thread
> context of the toplevel main loop. You cannot trigger a reconfiguration via
> a callback as each block runs in its own thread.
>
> You could also try using the "Selector" block to control dataflow through
> a static flowgraph without reconfiguring. A pair of such selectors can be
> used much the same as filterbank switches in hardware. The selection change
> can be triggered via the same "Message to Variable" block.
>
> There are probably more elegant options as well. These are just the ones
> that came to mind immediately.
>
> Hope this helps,
> Nick
>
> On Wed, Mar 27, 2024 at 9:44 AM Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi all,
>>
>> I sent an email earlier but didn't get any response, so I am restating
>> the problem in the hope that I will elicit some feedback.
>>
>> I would like to be able to reconfigure a flowgraph when a message is
>> received by a block.
>> Is there a mechanism to do that?
>>
>>
>> Here is why I want to do it:
>> I am building a system which uses a lot of resources for initial
>> acquisition (think eg, of a FH system that tries to acquire the FH pattern,
>> which I have implemented by a massively parallel filter bank).
>> Once this is done, I want to "turn off" this part of the RX.
>> I was thinking that a block will send an appropriate message once
>> acquisition is achieved and this will trigger the reconfiguration of a
>> flowgraph.
>>
>> thanks
>> Achilleas
>>
>>
>>
>>
>>
>>

Resending: reconfigure flowgrpah through messaging

[Achilleas Anastasopoulos]

Hi all,

I sent an email earlier but didn't get any response, so I am restating the
problem in the hope that I will elicit some feedback.

I would like to be able to reconfigure a flowgraph when a message is
received by a block.
Is there a mechanism to do that?


Here is why I want to do it:
I am building a system which uses a lot of resources for initial
acquisition (think eg, of a FH system that tries to acquire the FH pattern,
which I have implemented by a massively parallel filter bank).
Once this is done, I want to "turn off" this part of the RX.
I was thinking that a block will send an appropriate message once
acquisition is achieved and this will trigger the reconfiguration of a
flowgraph.

thanks
Achilleas

message used to reconfigure flowgraph

[Achilleas Anastasopoulos]

Hi all,

I have a flowgraph that is reconfigured using a QTgui chooser.
Essentially I generated a simple grc file with all the appropriate blocks
and then edited the python file to change the "set" function of the chooser
to something like:

def set_onoff(self, onoff):
if self.onoff==1 and onoff==0:
self.onoff = onoff
self._onoff_callback(self.onoff)
self.lock()
print('ON-->OFF')
self.disconnect(self.blocks_throttle2_1,
self.interp_fir_filter_xxx_0)
self.disconnect(self.interp_fir_filter_xxx_0,
self.qtgui_freq_sink_x_0)
self.connect(self.blocks_throttle2_1, self.qtgui_freq_sink_x_0)
self.unlock()
elif self.onoff==0 and onoff==1:
self.onoff = onoff
self._onoff_callback(self.onoff)
self.lock()
print('OFF-->ON')
self.disconnect(self.blocks_throttle2_1,
self.qtgui_freq_sink_x_0)
self.connect(self.blocks_throttle2_1,
self.interp_fir_filter_xxx_0)
self.connect(self.interp_fir_filter_xxx_0,
self.qtgui_freq_sink_x_0)
self.unlock()


this seems to be working fine.

Now I want to accomplish something similar with an embedded python block
that receives a message and makes this change in the flowgraph.
The message handler function of this block should do the reconfiguration.
However, the message handling function does not have access to the
flowgraph...

Is there a way this can be done?

thanks
Achilleas

Re: GNURADIO installation on windows using conda fails

[Achilleas Anastasopoulos]

\pixbufloader-bmp.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-gif.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-gif.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-icns.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-icns.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-ico.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-ico.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-pnm.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-pnm.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-qtif.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-qtif.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-tga.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-tga.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-tiff.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-tiff.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-xbm.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-xbm.dll':
The specified procedure could not be found.
g_module_open() failed for
C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-xpm.dll:
'C:\Users\anastas\AppData\Local\miniforge3\envs\gnuradio38\Library\lib\gdk-pixbuf-2.0\2.10.0\loaders\pixbufloader-xpm.dll':
The specified procedure could not be found.

done

(gnuradio38) C:\Users\anastas>
===


On Mon, Mar 4, 2024 at 4:26 PM Achilleas Anastasopoulos 
wrote:

> Hi everyone,
>
> I followed the instructions here:
> https://wiki.gnuradio.org/index.php?title=CondaInstall
> to install gnuradio on a windows machine.
>
> after installing with:
> conda install gnuradio=3.10.9
>
> I try to run gnuradio-companion from the command window
> and get the following error:
>
> -
> ** (process:22428): WARNING **: 16:15:20.577: Failed to load shared
> library 'gdk_pixbuf-2.0-0.dll' referenced by the typelib:
> 'gdk_pixbuf-2.0-0.dll': The specified procedure could not be found.
> While trying to display an error message, another error occurred
>
> The original error message follows.
> AssertionError
>
> Failed to initialize GTK. If you are running over ssh, did you enable X
> forwarding and start ssh with -X?
>
> ()
>
> (gnuradio310) C:\Users\anastas>
> --
> I checked that I had gdk_pixbuff and indeed I have it:
> --
> (gnuradio310) C:\Users\anastas>conda install gdk-pixbuf
> Channels:
>  - conda-forge
> Platform: win-64
> Collecting package metadata (repodata.json): done
> Solving environment: done
>
> # All requested packages already installed.
>
>
> (gnuradio310) C:\Users\anastas>
> --
>
>
>
>
> Can someone point me to the correct direction on how to resolve this.
>
> thanks
> Achilleas
>
>

GNURADIO installation on windows using conda fails

[Achilleas Anastasopoulos]

Hi everyone,

I followed the instructions here:
https://wiki.gnuradio.org/index.php?title=CondaInstall
to install gnuradio on a windows machine.

after installing with:
conda install gnuradio=3.10.9

I try to run gnuradio-companion from the command window
and get the following error:

-
** (process:22428): WARNING **: 16:15:20.577: Failed to load shared library
'gdk_pixbuf-2.0-0.dll' referenced by the typelib: 'gdk_pixbuf-2.0-0.dll':
The specified procedure could not be found.
While trying to display an error message, another error occurred

The original error message follows.
AssertionError

Failed to initialize GTK. If you are running over ssh, did you enable X
forwarding and start ssh with -X?

()

(gnuradio310) C:\Users\anastas>
--
I checked that I had gdk_pixbuff and indeed I have it:
--
(gnuradio310) C:\Users\anastas>conda install gdk-pixbuf
Channels:
 - conda-forge
Platform: win-64
Collecting package metadata (repodata.json): done
Solving environment: done

# All requested packages already installed.


(gnuradio310) C:\Users\anastas>
--




Can someone point me to the correct direction on how to resolve this.

thanks
Achilleas

Re: GNURADIO10 and hierarchical blocks

[Achilleas Anastasopoulos]

please disregard the email.

I answered my question here:

https://wiki.gnuradio.org/index.php/Hier_Blocks_and_Parameters


"For GNU Radio v3.10, the files will be created in the directory where the
*.grc* file is saved. Please create the *.grc_gnuradio* directory and copy
the *.py* and *.yml* files there:"


thanks
Achilleas

On Wed, Feb 21, 2024 at 11:25 AM Achilleas Anastasopoulos 
wrote:

> Hi all,
>
> I recently upgraded from 3.8 to 3.10 and tested a hierarchical block.
> I compiled it and it generated a py file in the same directory as the grc
> file.
>
> My understanding from 3.8 was that it puts the py code and an yml file in
> my .grc_gnuradio folder
> so it is available to grab it in my flowgraphs.
>
> However this is not the case now.
>
> Am I missing something here?
>
> thanks
> Achilleas
>

GNURADIO10 and hierarchical blocks

[Achilleas Anastasopoulos]

Hi all,

I recently upgraded from 3.8 to 3.10 and tested a hierarchical block.
I compiled it and it generated a py file in the same directory as the grc
file.

My understanding from 3.8 was that it puts the py code and an yml file in
my .grc_gnuradio folder
so it is available to grab it in my flowgraphs.

However this is not the case now.

Am I missing something here?

thanks
Achilleas

Re: anyone had luck with RTL-SDR on Windows GNURADIO installation?

[Achilleas Anastasopoulos]

Thank you all for your suggestions.
Here is an update:

I installed SDR# and the RTL-SDR is recognized from the SDRSharp
application.
HOWEVER, the installed GNURADIO does not recognize the dongle, even after
installing the rtl-sdr drivers manually.

Anyone who may have made this work with the specific binary installation
please let me know.

thanks again,
Achilleas


On Thu, Nov 3, 2022 at 11:53 AM JEREMY CLARK  wrote:

> Try installing SDR# first and running the install-rtlsdr bat file, that
> will install all the windows drivers. Then see if it is recognized in GNU
> Radio.
>
> BR/JC
>
> https://airspy.com/download/
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows
>
>
>
> *From: *Achilleas Anastasopoulos 
> *Sent: *November 3, 2022 10:25 AM
> *To: *Discuss-gnuradio@gnu.org 
> *Subject: *anyone had luck with RTL-SDR on Windows GNURADIO installation?
>
>
>
> Hi all,
>
>
>
> I was testing GNURADIO 3.8 Windows binary installation
>
> from  Geof Nieboer's installer hosted at gcndevelopment.com
> <http://www.gcndevelopment.com/gnuradio/index.htm>
>
> http://www.gcndevelopment.com/gnuradio/index.htm
>
>
>
> Everything seems to be working fine.
>
> However I have no luck when I connect my RTL-SDR dongle.
>
> The device is not recognised.
>
>
>
> Anyone has similar experience or some suggestion?
>
>
>
> thanks
>
> Achilleas
>
>
>

anyone had luck with RTL-SDR on Windows GNURADIO installation?

[Achilleas Anastasopoulos]

Hi all,

I was testing GNURADIO 3.8 Windows binary installation
from  Geof Nieboer's installer hosted at gcndevelopment.com

http://www.gcndevelopment.com/gnuradio/index.htm

Everything seems to be working fine.
However I have no luck when I connect my RTL-SDR dongle.
The device is not recognised.

Anyone has similar experience or some suggestion?

thanks
Achilleas

Re: Gnuradio: SineWave generator python block choppy audio out

[Achilleas Anastasopoulos]

Hi all,

I do not think that the proposed algorithm by Marcus is the correct way to
implement this block,
because it assumes that the frequency has remained the same throughout the
life of the block!
The correct way is to keep a state variable (say, "self.phase") that is
initialized to 0 and  records the accumulated state (modulo 2 pi) up to the
last call of work.
Then in one call of work you should just generate the sin wave as suggested:

f_rel = 2 * np.pi * self.frequency / self.sample_rate
number = len(output_items[0])
phases = (f_rel * np.arange(0,number)+self.phase ) % (2*np.pi)
output_items[0][:] = self.amplitude*np.sin(phases)
self.phase=phases[-1]+ f_rel

best
Achilleas

embedded python blocks inside hierarchical blocks

[Achilleas Anastasopoulos]

Hi all,

I noticed the following discrepancy between how 3.7 and 3.8 treat the above
blocks:

When I generated a hierarchical block in 3.7 with an embedded python block
in it, the generated code of the embedded python blocks (epy files) were
copied to the .grc_gnuradio directory.

In 3.8 the generated epy files still reside in the directory of the
original hierarchical block and are not copied to the .grc_gnuradio
directory.
As a result, when executing a flowgraph that contains the hierarchical
block I get the error:
--
Executing: /usr/bin/python3 -u
/n/girard/x/anastas/GNURADIO_LAB/projects/csma-arq/arq-fixed/TX/TX_ARQ.py

Traceback (most recent call last):
  File
"/n/girard/x/anastas/GNURADIO_LAB/projects/csma-arq/arq-fixed/TX/TX_ARQ.py",
line 27, in 
from PHY_RX import PHY_RX  # grc-generated hier_block
  File "/n/girard/x/anastas/.grc_gnuradio/PHY_RX.py", line 24, in 
import epy_check_packet
ModuleNotFoundError: No module named 'epy_check_packet'


I have to manually copy all the epy files to .grc_gnuradio every time I
make changes to the embedded python blocks.

Is this an inadvertent mistake in 3.8 or the expected behavior?

thanks
Achilleas

QT tab widget does not work on maint-3.8 (ubuntu 20.04)

[Achilleas Anastasopoulos]

I just tested a simple QT tab widget with two tabs and it does not run on
maint-3.8
Attached please see the example giving the following error (at the end of
the email)
Can someone verify this is indeed the case?

thanks
Achilleas


File "/n/girard/x/anastas/GNURADIO_LAB/test_tabs.py", line 169, in main
tb = top_block_cls()
  File "/n/girard/x/anastas/GNURADIO_LAB/test_tabs.py", line 128, in
__init__
self.mytab_layout_0.addWidget(self._qtgui_time_sink_x_0_win)
  File "/usr/local/lib/python3/dist-packages/gnuradio/gr/hier_block2.py",
line 93, in __getattr__
return getattr(self._impl, name)
AttributeError: 'top_block_sptr' object has no attribute 'mytab_layout_0'

>>> Done (return code -11)


test_tabs.grc
Description: Binary data

usrp sink burst transmission

[Achilleas Anastasopoulos]

Hi all,

I am reading from here:

https://wiki.gnuradio.org/index.php/USRP_Sink

how to do burt transmission with the usrp_sink.
My questions have to do with the second option:


Using tagged streams (See Tagged Stream Blocks
). To use this
capability, you must specify which string the usrp_sink block should be
looking for to denote the length of the next PDU to be transmitted. Set the
"tsb_tag_name" parameter in the usrp_sink to whatever string your radio
application uses to denote your PDU length. A commonly used string for this
purpose is simply "tx_pkt_len". If using Tagged Streams for timed bursts,
you must include your "tx_pkt_len" tag and a "tx_time" tag on the first
sample of a tx burst. If your first "tx_pkt_len" tag has an offset of 0,
and your packet length is 1000 items, your next "tx_pkt_len" and "tx_time"
tags must appear with an offset of 1000. TX bursts should not overlap, and
there should not be gaps in samples between bursts.


Q1: why do we need two tags to make this happen? I would think that
"tx_pkt_len" tag would be sufficient: when a tag like this is found by the
usrp sink then it waits for that many samples to come in and then it
transmits them in burst mode. Then it waits for the next such tag and so on.
What is the meaning/use of the second tag  "tx_time"?

Q2: Does the "tx_time" tag have to be exactly that name (as opposed to the
"tx_pkt_len" tag which can be user defined?)

Q3: The text above is talking about PDU's but my understanding is that a
PDU is a special type of a PMT, while the USRP sink input has to be a
tagged stream, not a PMT/PDU. Should the input be a PDU (to a message
port?) or should it be a tagged stream?

thanks
Achilleas

Re: QT chooser and QT range do not cooperate with each other

[Achilleas Anastasopoulos]

Hi Christophe,

No errors on the console. There seems to be nothing coming out of the last
selector block.

I have tested it with 3.7 (Windows and Ubuntu)
and with 3.8 (Windows).
I will test it with 3.9 (beta Windows version) and let you know.

best
Achilleas



On Wed, Apr 14, 2021 at 12:16 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> Yes it worked at least under GR 3.9
>
> Did you get any error message?
> On 14/04/2021 18:06, Achilleas Anastasopoulos wrote:
>
> Christophe,
>
> thank you for the two suggestions. The second one (using selectors) is
> preferable for me.
> Unfortunately the grc flowgraph you provided does not work for me at all:
> it does not produce any samples at the output.
> I had to remove the first selector for it to work (see attached).
>
> I don't know if this is another bug, but can you confirm that the grc
> flowgraph you sent me (with two selectors) worked for you?
>
> best
> Achilleas
>
> On Mon, Apr 12, 2021 at 4:41 PM Christophe Seguinot <
> christophe.segui...@orange.fr> wrote:
>
>> I would have implement this differently:
>>
>>- First solution combine To filters taps in one filter such as
>>   - final_taps=rrc_taps*(pulse-1)+rect*pulse
>>   - with pulse =0 or 1 (obtainde with a QT GUI Chooser)
>>   - BUT filters must have the same number of coefficients
>>- 2nd: use QT Gui selector as in this flowgraph. (it can be extended
>>to multiple filters easily)
>>
>> Regards, Christophe
>>
>> P.S. my flowgraph is for GR 3.8 /3.9
>> On 12/04/2021 19:10, Achilleas Anastasopoulos wrote:
>>
>> Hi all,
>>
>> I have a flowgraph with QT chooser choosing between rect pulse and rrc
>> pulse.
>> I also have a QT range where I want to control the rolloff factor of the
>> rrc pulse when chosen.
>> However, in the flowgrpah it seems that once the rrc is chosen I cannot
>> change its roloff factor dynamically from the QT range.
>>
>> I have tried it in both 3.7 and 3.8 and I get the same result.
>> Is this a bug?
>> Is there a more appropriate way of achieving this result?
>>
>> thanks
>> Achilleas
>>
>>

Re: QT chooser and QT range do not cooperate with each other

[Achilleas Anastasopoulos]

Christophe,

thank you for the two suggestions. The second one (using selectors) is
preferable for me.
Unfortunately the grc flowgraph you provided does not work for me at all:
it does not produce any samples at the output.
I had to remove the first selector for it to work (see attached).

I don't know if this is another bug, but can you confirm that the grc
flowgraph you sent me (with two selectors) worked for you?

best
Achilleas

On Mon, Apr 12, 2021 at 4:41 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> I would have implement this differently:
>
>- First solution combine To filters taps in one filter such as
>   - final_taps=rrc_taps*(pulse-1)+rect*pulse
>   - with pulse =0 or 1 (obtainde with a QT GUI Chooser)
>   - BUT filters must have the same number of coefficients
>- 2nd: use QT Gui selector as in this flowgraph. (it can be extended
>to multiple filters easily)
>
> Regards, Christophe
>
> P.S. my flowgraph is for GR 3.8 /3.9
> On 12/04/2021 19:10, Achilleas Anastasopoulos wrote:
>
> Hi all,
>
> I have a flowgraph with QT chooser choosing between rect pulse and rrc
> pulse.
> I also have a QT range where I want to control the rolloff factor of the
> rrc pulse when chosen.
> However, in the flowgrpah it seems that once the rrc is chosen I cannot
> change its roloff factor dynamically from the QT range.
>
> I have tried it in both 3.7 and 3.8 and I get the same result.
> Is this a bug?
> Is there a more appropriate way of achieving this result?
>
> thanks
> Achilleas
>
>


test_chooser_3.grc
Description: Binary data

message_strobe_random Poisson ==> Exponential

[Achilleas Anastasopoulos]

Hi all,

I was playing around with the message_strobe_random block and saw that it
has an option that the random delay is Poisson distributed.
When choosing this option the block does not behave as expected.

I believe the intention of the author was to have an "exponential"
distribution
in place of the Poisson distribution:

A Poisson distribution counts the number of arrivals in a given time
interval.The exponential distribution refers to the corresponding
interarrival time.
The two are intimately related, but refer to different things.

The block uses these distributions to calculate the delay before generating
a message so it clearly refers to the latter than the former.
I suppose the only change should be that the corresponding boost library is
used:

https://www.boost.org/doc/libs/1_54_0/libs/math/doc/html/math_toolkit/dist_ref/dists/exp_dist.html

instead of

https://www.boost.org/doc/libs/1_64_0/boost/random/poisson_distribution.hpp


best,
Achilleas

QT chooser and QT range do not cooperate with each other

[Achilleas Anastasopoulos]

Hi all,

I have a flowgraph with QT chooser choosing between rect pulse and rrc
pulse.
I also have a QT range where I want to control the rolloff factor of the
rrc pulse when chosen.
However, in the flowgrpah it seems that once the rrc is chosen I cannot
change its roloff factor dynamically from the QT range.

I have tried it in both 3.7 and 3.8 and I get the same result.
Is this a bug?
Is there a more appropriate way of achieving this result?

thanks
Achilleas


test_chooser.grc
Description: Binary data

Windows build request

[Achilleas Anastasopoulos]

Hi all,

It seems that the Windows10 builds for 3.7.15 on
http://www.gcndevelopment.com/gnuradio/downloads.htm
are not the most recent ones that appear in the 3.7.15 maintenance branch.

Specifically, corr_estimator is different in the Windows vs the Linux
version.

I would be wonderful if the team at GCNDEVELOPMENT updates this part.

thank you in advance,
Achilleas

Re: Problems with Viterbi decoding

[Achilleas Anastasopoulos]

There may be some additional things to consider when using gr-trellis:

The fsm class does not understand bits. It understands input symbols and
output symbols.
Your fsm has binary input symbols and quaternary output symbols.
So the encoder gets L input bits and produces L quaternary symbols (if you
are wondering why, please read the gr-trellis documentation to see the
design philosophy).
For the VA to work you have to provide L (noisy) quaternary symbols at the
input.

I attach a modified version of the tcm.grc example (in the
gr.trellis/examples/grc/tcm.grc)
that shows that the VA works perfectly (0 BER) with your encoder.


test_tcm1.grc
Description: Binary data

Re: Problems with Viterbi decoding

[Achilleas Anastasopoulos]

My understanding is that the constructor takes first k=1 and then n=2 as a
parameter
for an (n,k) code, so it should be:
trellis.fsm(1,2,[0b11001,0b10111])

Achilleas

//##
//# Automatically generate the FSM from the generator matrix
//# of a (n,k) binary convolutional code
//##
fsm::fsm(int k, int n, const std::vector& G)

Re: Embedded Python basic_block input buffer lengths

[Achilleas Anastasopoulos]

Hi Jeff,

Thanks for the pointers!

I did not realize that I could only process the minimum length of the two
input buffers.
Dumb mistake on my part...
I just changed that and everything works fine.

BTW, just to confirm:

Is the minimum of the length of all input buffers to be trusted, even if it
is larger than the number from forecast?
ie, if forecast says inputs have to be 10 times the required outputs,
and len(output_items[0])=100
and len(input_items[0])=1010, and len(input_items[0])=1005
can I trust the contents of the input buffers 0:1004 ?

thanks again,
Achilleas

Re: Embedded Python basic_block input buffer lengths

[Achilleas Anastasopoulos]

Hi Jeff,

I can confirm that the same behavior happens in 3.8

I attach the 3.8 graph

Achilleas


test_input_buffers_38.grc
Description: Binary data

Embedded Python basic_block input buffer lengths

[Achilleas Anastasopoulos]

HI all,

I am trying to debug a grc flowgraph containing an Embedded Python
BASIC_BLOCK.
The python block has two inputs and one output.
The block makes sure (through FORECAST()) that both inputs have the SAME
sample requirements.
Also, the block ALWAYS uses CONSUME_EACH() so that both input buffers are
cleared by the same amount of samples.

I observe the following behavior:

During normal operation (high SNR) the lengths of the two input buffers are
the same.
However, after some tinkering (I decrease the SNR using a QT Range and then
increase it again) the two input buffers have different lengths!

Is this even possible?
Can the scheduler do that?

I first suspected that the peak detector which is present in the flowgraph
and feeds the first input of the python block is chewing up samples when it
does not find a peak so my two streams become unsynchronized. However I
verified that the peak detector is a sync_block so this is impossible
either...

Do you have any idea as to why this is happening?

I attach the grc code (this is tested in 3.7 and 3.8).

thanks in advance for any help,
Achilleas


test_input_buffers.grc
Description: Binary data

Correlation Estimator corr_est_cc "threshold" meaning

[Achilleas Anastasopoulos]

Hi all,

I have been playing a bit with the "corr_est_cc" block and I was banging my
head to understand the meaning of the parameter "threshold".
In all examples it seems to be a number VERY close to 1.
The documentation is cryptic:
" Threshold of correlator, relative to a 100% correlation (1.0). Default is
0.9."

Upon inspection of the code it is clear that there is a mixup between the
quantities "threshold" and "1-probability of false alarm".

The code defines

d_pfa = -logf(1.0f-threshold);

which is clearly not the intended use: the pfa cannot be the log of
something!
In fact, what is meant is that

===> THRESHOLD = -logf(PFA);

The smaller the PFA the larger the threshold should be.
This explains why we need to put a number close to 1 as "threshold" (which
is actually 1-PFA).
Further down the code it shows how THRESHOLD is meant to be used:

float detection = 0;
for(int i = 0; i < noutput_items; i++) {
detection += d_corr_mag[i];
 }
 detection /= static_cast(noutput_items);
 detection *= d_pfa;   <

Clearly, the average magnitude is evaluated and then it is multiplied by
"d_pfa"
which is meaningless, unless (as mentioned above) you interpret this as

detection *= THRESHOLD;

To summarize:
---
What is shown as "pfa" in the code is actually a THRESHOLD
What is shown as "threshold" in the code is actually 1-PFA.
The user actually inputs 1-PFA (erroneously named "threshold").

I hope this will help anyone having similar issues understanding how this
block works.

best
Achilleas

Re: Adding a set_sensitivity() function to VCO_C block

[Achilleas Anastasopoulos]

So editing the vco_c.h file :

...
static sptr make(double sampling_rate, double sensitivity, double
amplitude);

//! Sets the sensitivity.
virtual void set_sensitivity(double sensitivity) =0;



did the job!

thanks again,
Achilleas

Adding a set_sensitivity() function to VCO_C block

[Achilleas Anastasopoulos]

Hi all,

I am working with GNURADIO 3.7 and realized that the VCO blocks do not have
functionality to change the sensitivity parameter during operation.
I wanted to use them for generating FSK signals.
I realized I can do that equivalently with the Frequency Mod block, so this
is fine.

However I decided to add the set_sensitivity functionality to the VCO_c
block.
So I did the following:

1) edited the vco_c_impl.h file


public:
  vco_c_impl(double sampling_rate, double sensitivity, double
amplitude);
  ~vco_c_impl();
  void set_sensitivity(double sensitivity);
.

2) I edited the  vco_c_impl.cc file:

vco_c_impl::~vco_c_impl()
{
}

void
vco_c_impl::set_sensitivity(double sensitivity)
{
  d_sensitivity = sensitivity;
  d_k = d_sensitivity / d_sampling_rate;
}



3) I edited the blocks_vco_c.xml file:

...
blocks.vco_c($samp_rate, $sensitivity, $amplitude)
set_sensitivity($sensitivity)
...


4) After remaking/reinstalling gnuradio I do the following test in python:

>>> from gnuradio import blocks
>>> x=blocks.vco_c(1,2,3)
>>> x.set_sensitivity(4)
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'vco_c_sptr' object has no attribute 'set_sensitivity'

5) In addition when I use the block in GRC and try to change the
sensitivity I get similar errors.

So I know that somehow the python bindings are not generated.
I feel I have forgotten to edit some file before compilation, but do not
remember which one has to be changed (it has been some time since I last
did development work on the gnuradio code).

What am I missing?

thanks
Achilleas

Re: IQ and complex signals tutorial

[Achilleas Anastasopoulos]

Hi Crostophe,

thank you for this wonderful tutorial.


You may want to use the more standard terms:

"pre-envelope" m_+(t) = m(t) + j \hat{m}(t)
(ie, the signal you currently denote as \tilde{m}(t))

"complex-envelope", \tilde{m}(t)
(for the signal you currently denote as m^{bb}(t) )

thank you again for your efforts,
Achilleas

Hiw to install binaries for GNURADIO 3.7 using MacPorts for MAC

[Achilleas Anastasopoulos]

Hi all,

this email is intended primarily for Michael Dickens who maintains GNURADIO
for MAC, but if anyone else knows feel free to chime in.

I am teaching a class where some of the students have MAC and want to
install a version of GNURADIO/GRC locally.
The class is using GNURADIO 3.7 in the Lab computers so I want them to
install the same version.
How is this done on MacPorts?

At this point I am trying to go over the instructions here:
https://wiki.gnuradio.org/index.php/MacInstall
that suggest this:

>  sudo port install gnuradio

but I guess this will install the latest version.

thanks a lot,
Achilleas

Re: bug report

[Achilleas Anastasopoulos]

Hi Ali,

the block "chunks to symbols" is a simple look-up table and actually this
would have been a better name for it.

Given an array A of size NxD,
you give it an index i \in{ 0,1,...,N-1}
and it gives you back the elements of the array in the i-th position, ie,
A[i,0:D-1].

Which part is related to endianess?

best
Achilleas

Re: Correlation Estimator block threshold settings in Absolute/Dynamic mode

[Achilleas Anastasopoulos]

There is definitely a weird logic with this block.
Let me explain:

Suppose your training sequence is c(t) with energy E=sum_t |c(t)|^2.
The training c(.) is exactly what the parameter "symbols" is in the
correlate block.
Suppose your signal is some scaled version of the training sequence eg,
y(t) = a c(t).
You would expect that the block correlates the incoming signal y(t) with
the given training c(t) and declares a peak when the correlation is above a
certain threshold, A.
ie, something like  sum^t y(s) c^*(s)  > A <==> a sum^t |c(s)|^2 > A <==>
sum^t |c(s)|^2 > A/a
Now since the full correlation, sum_s |c(s)|^2  equals E, you would expect
that the quantity A/a should scale with E (ie, it should be a fraction of
E), ie, A/a = fraction E <==> A = a fraction E.

This means that if one wants to build a correlator that works with an
arbitrary scaling "a" (suppose a genie gave you that at the Rx), the only
thing you should have to do is to
put as the parameter "threshold" in the block the quantity "a fraction".
This would make the whole system transparent: no matter what the scaling
is, your estimator would work exactly the same.

HOWEVER, as it turns out the "correct" scaling that works for this block is
to set  "threshold= a^2 fraction".
This is really weird and I do not see any intuition behind that type of
scaling...

Please see attached minimal working example and notice the squaring of
scaling inside the block that makes it transparent to scaling the input
signal.
However if you change this to anything else, the system breaks down (in the
sense that its behavior changes with scaling the input signal).

best
Achilleas


test.grc
Description: Binary data

is there a set_output_multiple() in pyhton blocks?

[Achilleas Anastasopoulos]

Hi all,

I was writing an embedded python (general) block in 3.8 and wanted to
use set_output_multiple as I have done in C++ in the past.
It seems that this method does not exist.
I just wanted to verify this.
Is there a way to set the output multiple in a general block in python?

thanks
Achilleas

Re: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

[Achilleas Anastasopoulos]

Awesome, thanks!

Achilleas

On Wed, Nov 13, 2019 at 12:58 PM Morman, Joshua 
wrote:

>
> Achilleas,
>
>
> I have added 3.7 Releases to a separate PPA to host the latest 3.7 release
> (currently 3.7.13.5)
>
> sudo add-apt-repository ppa:gnuradio/gnuradio-releases-3.7
> sudo apt-get update
>
>
> Please let me know if you run into any issues with this.
>
>
> Thanks,
>
> Josh
>
> --
> *From:* Achilleas Anastasopoulos 
> *Sent:* Thursday, November 7, 2019 1:18 PM
> *To:* Morman, Joshua
> *Subject:* [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available
>
> Yes, so I was wondering if 3.7.13.4 can be made available for 18.04 as
> well.
> I am used to installing everything from scratch but my experience is that
> this
> is a substantial hurdle for students and also some of my colleagues who
> just want to try it...
>
> best
> Achilleas
>
> > Apt comes up with 3.7.11 for both Ubuntu 16.04 and 18.04, and 3.7.13.4
> for 19.04
>
>

Re: [Discuss-gnuradio] cannot find block tree panel in grc

[Achilleas Anastasopoulos]

Have you fixed this issue?
I got the same thing in Ubuntu 18.04 since yesterday and cannot figure out
what happened...

Achilleas

Fwd: GNU Radio PPA packages for Ubuntu Available

[Achilleas Anastasopoulos]

Yes, so I was wondering if 3.7.13.4 can be made available for 18.04 as well.
I am used to installing everything from scratch but my experience is that
this
is a substantial hurdle for students and also some of my colleagues who
just want to try it...

Thanks again for all your efforts.

best
Achilleas

> Apt comes up with 3.7.11 for both Ubuntu 16.04 and 18.04, and 3.7.13.4
for 19.04

Re: [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available

[Achilleas Anastasopoulos]

That would be great as many people out there are not yet comfortable
switching to 3.8 ...

best
Achilleas

On Wed, Nov 6, 2019 at 11:33 AM Morman, Joshua 
wrote:

> Not currently - but I can pull it together either as a separate PPA, or in
> the same Releases PPA
>
> Josh
>
> ------
> *From:* Achilleas Anastasopoulos 
> *Sent:* Wednesday, November 6, 2019 11:06 AM
> *To:* Morman, Joshua; Discuss-gnuradio@gnu.org
> *Subject:* [EXTERNAL] Re: GNU Radio PPA packages for Ubuntu Available
>
> Great work!
>
> So is there a package for the latest pre-8.0 version, say 3.7.14 or
> 3.7.maintenance?
>
> thanks
> Achilleas
>

Re: GNU Radio PPA packages for Ubuntu Available

[Achilleas Anastasopoulos]

Great work!

So is there a package for the latest pre-8.0 version, say 3.7.14 or
3.7.maintenance?

thanks
Achilleas

Re: [Discuss-gnuradio] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Achilleas Anastasopoulos]

Understood. Thanks!
So here is the actual output of cmake (in my previous email I also included
the file CMakeOutput.log in case it provides more info):

thanks again for all the help,
Achilleas

--

anastas@raulubuntu:~/workarea-gnuradio/build_maint37$ cmake ../gnuradio/
-- Build type not specified: defaulting to release.
-- Build type set to Release.
-- Extracting version information from git describe...
CMake Deprecation Warning at CMakeLists.txt:73 (cmake_policy):
 The OLD behavior for policy CMP0026 will be removed from a future version
 of CMake.

 The cmake-policies(7) manual explains that the OLD behaviors of all
 policies are deprecated and that a policy should be set to OLD only under
 specific short-term circumstances.  Projects should be ported to the NEW
 behavior and not rely on setting a policy to OLD.


CMake Error at CMakeLists.txt:182 (include):
 include could not find load file:

   CMakeOverloads


-- Compiler Version: cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 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.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -std=gnu99
-fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized
CMake Error at CMakeLists.txt:265 (include):
 include could not find load file:

   GrPlatform


-- ADDING PERF COUNTERS
-- Building Static Libraries: OFF
CMake Error: File /home/anastas/workarea-gnuradio/gnuradio/cmake/
cmake_uninstall.cmake.in does not
exist.
CMake Error at CMakeLists.txt:337 (configure_file):
 configure_file Problem configuring file


-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   regex
--   thread
--   chrono
--   atomic
CMake Error at CMakeLists.txt:365 (include):
 include could not find load file:

   GrComponent


CMake Error at CMakeLists.txt:366 (GR_REGISTER_COMPONENT):
 Unknown CMake command "GR_REGISTER_COMPONENT".


-- Configuring incomplete, errors occurred!
See also
"/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeOutput.log".
See also
"/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeError.log".

On Tue, Oct 1, 2019 at 3:35 PM Michael Dickens 
wrote:

> What I mean is you listed the CMakeError.log file. During cmake
> configuration, it looks for how to do threading; some fail before cmake
> finds one that works. Cmake documents these errors in this file, and these
> errors are not abnormal ... they are just part of cmake doing its job.
>
> That said, cmake's normal output printouts and other logging are only as
> good as it is programmed to do. GR does a pretty good job of showing what's
> going on so that one can figure out the issues & then how to resolve them.
> GR OOTs vary a lot in this regard.
>
> On Tue, Oct 1, 2019 at 3:25 PM Achilleas Anastasopoulos 
> wrote:
>
>> Hi Michael,
>>
>> not sure what you mean by "these errors are normal?"
>> I thought that gnuradio development at the 3.7 branch is beyond "normal
>> errors" status...
>>
>> In any case, I also attach the CMakeOutput.log file in case this is more
>> useful:
>>
>> Thanks again,
>> Achilleas
>>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Achilleas Anastasopoulos]

Hi Michael,

not sure what you mean by "these errors are normal?"
I thought that gnuradio development at the 3.7 branch is beyond "normal
errors" status...

In any case, I also attach the CMakeOutput.log file in case this is more
useful:

Thanks again,
Achilleas





On Tue, Oct 1, 2019 at 3:08 PM Michael Dickens 
wrote:

> Those errors are normal. Guessing there's info in the cmake output that's
> more useful. - MLD
>
> On Tue, Oct 1, 2019 at 3:03 PM Achilleas Anastasopoulos 
> wrote:
>
>> Hi all,
>>
>> I have the following issue trying a fresh installation on a VM-Ubuntu
>> 18.04.
>> After installing the dependencies etc from here:
>> https://wiki.gnuradio.org/index.php/UbuntuInstall
>>
>> and after checking out the maint_3.7 branch the cmake fails with the
>> following CMakeError.log file.
>>
>> Something tell me I am missing something obvious, but don't know what...
>> This is the first time I see something like this.
>>
>> Any help is appreciated.
>>
>> best
>> Achilleas
>>
>>
>>
>>
>> ---
>>
>> Determining if the pthread_create exist failed with the following output:
>> Change Dir:
>> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp
>>
>> Run Build Command:"/usr/bin/make" "cmTC_a2fc5/fast"
>> /usr/bin/make -f CMakeFiles/cmTC_a2fc5.dir/build.make
>> CMakeFiles/cmTC_a2fc5.dir/build
>> make[1]: Entering directory
>> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
>> Building C object CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o
>> /usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized-o CMakeFi
>> les/cmTC_a2fc5.dir/CheckSymbolExists.c.o   -c
>> /home/anastas/workarea-gnuradio/build_maint37/CMakeF
>> iles/CMakeTmp/CheckSymbolExists.c
>> Linking C executable cmTC_a2fc5
>> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a2fc5.dir/link.txt
>> --verbose=1
>> /usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized -rdynamic
>> CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o  -o cmTC_a2fc5
>> CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o: In function `main':
>> CheckSymbolExists.c:(.text+0x1b): undefined reference to `pthread_create'
>> collect2: error: ld returned 1 exit status
>> CMakeFiles/cmTC_a2fc5.dir/build.make:97: recipe for target 'cmTC_a2fc5'
>> failed
>> make[1]: *** [cmTC_a2fc5] Error 1
>> make[1]: Leaving directory
>> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
>> Makefile:126: recipe for target 'cmTC_a2fc5/fast' failed
>> make: *** [cmTC_a2fc5/fast] Error 2
>>
>> File
>> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
>>
>> /* */
>> #include 
>>
>> int main(int argc, char** argv)
>> {
>>  (void)argv;
>> #ifndef pthread_create
>>  return ((int*)(_create))[argc];
>> #else
>>  (void)argc;
>>  return 0;
>> #endif
>> }
>>
>> Determining if the function pthread_create exists in the pthreads failed
>> with the following output
>> :
>> Change Dir:
>> /home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp
>>
>> Run Build Command:"/usr/bin/make" "cmTC_cfcc3/fast"
>> /usr/bin/make -f CMakeFiles/cmTC_cfcc3.dir/build.make
>> CMakeFiles/cmTC_cfcc3.dir/build
>> make[1]: Entering directory
>> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
>> Building C object CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o
>> /usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized -DCHECK_FUNCT
>> ION_EXISTS=pthread_create   -o
>> CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o   -c /usr/share/c
>> make-3.10/Modules/CheckFunctionExists.c
>> Linking C executable cmTC_cfcc3
>> /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_cfcc3.dir/link.txt
>> --verbose=1
>> /usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
>> -Wno-uninitialized -DCHECK_FUNCTI
>> ON_EXISTS=pthread_create-rdynamic
>> CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o  -o cmTC_c
>> fcc3 -lpthreads
>> /usr/bin/ld: cannot find -lpthreads
>> collect2: error: ld returned 1 exit status
>> CMakeFiles/cmTC_cfcc3.dir/build.make:97: recipe for target 'cmTC_cfcc3'
>> failed
>> make[1]: *** [cmTC_cfcc3] Error 1
>> make[1]: Leaving directory
>> '/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMake

[Discuss-gnuradio] cmake fails when installing maint_3.7 branch on VM-Ubuntu 18.04

[Achilleas Anastasopoulos]

Hi all,

I have the following issue trying a fresh installation on a VM-Ubuntu 18.04.
After installing the dependencies etc from here:
https://wiki.gnuradio.org/index.php/UbuntuInstall

and after checking out the maint_3.7 branch the cmake fails with the
following CMakeError.log file.

Something tell me I am missing something obvious, but don't know what...
This is the first time I see something like this.

Any help is appreciated.

best
Achilleas




---

Determining if the pthread_create exist failed with the following output:
Change Dir:
/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_a2fc5/fast"
/usr/bin/make -f CMakeFiles/cmTC_a2fc5.dir/build.make
CMakeFiles/cmTC_a2fc5.dir/build
make[1]: Entering directory
'/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o
/usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized-o CMakeFi
les/cmTC_a2fc5.dir/CheckSymbolExists.c.o   -c
/home/anastas/workarea-gnuradio/build_maint37/CMakeF
iles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTC_a2fc5
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_a2fc5.dir/link.txt
--verbose=1
/usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized -rdynamic
CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o  -o cmTC_a2fc5
CMakeFiles/cmTC_a2fc5.dir/CheckSymbolExists.c.o: In function `main':
CheckSymbolExists.c:(.text+0x1b): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_a2fc5.dir/build.make:97: recipe for target 'cmTC_a2fc5'
failed
make[1]: *** [cmTC_a2fc5] Error 1
make[1]: Leaving directory
'/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_a2fc5/fast' failed
make: *** [cmTC_a2fc5/fast] Error 2

File
/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp/CheckSymbolExists.c:

/* */
#include 

int main(int argc, char** argv)
{
 (void)argv;
#ifndef pthread_create
 return ((int*)(_create))[argc];
#else
 (void)argc;
 return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed
with the following output
:
Change Dir:
/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_cfcc3/fast"
/usr/bin/make -f CMakeFiles/cmTC_cfcc3.dir/build.make
CMakeFiles/cmTC_cfcc3.dir/build
make[1]: Entering directory
'/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o
/usr/bin/cc   -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized -DCHECK_FUNCT
ION_EXISTS=pthread_create   -o
CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o   -c /usr/share/c
make-3.10/Modules/CheckFunctionExists.c
Linking C executable cmTC_cfcc3
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_cfcc3.dir/link.txt
--verbose=1
/usr/bin/cc  -std=gnu99 -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized -DCHECK_FUNCTI
ON_EXISTS=pthread_create-rdynamic
CMakeFiles/cmTC_cfcc3.dir/CheckFunctionExists.c.o  -o cmTC_c
fcc3 -lpthreads
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
CMakeFiles/cmTC_cfcc3.dir/build.make:97: recipe for target 'cmTC_cfcc3'
failed
make[1]: *** [cmTC_cfcc3] Error 1
make[1]: Leaving directory
'/home/anastas/workarea-gnuradio/build_maint37/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_cfcc3/fast' failed
make: *** [cmTC_cfcc3/fast] Error 2


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

[Discuss-gnuradio] OFDM with continuous pilots but bursty data

[Achilleas Anastasopoulos]

Hi Alex,

you may want to take a look at the OOT module gr-cdma (
https://github.com/anastas/gr-cdma).
This system implements a two-channel system with one of the orthogonal
channels being continuously transmitting pilots,
while the other carries data (in a synchronous/asynchronous way).
The Rx is always listening to the pilot channel and is continuously
adjusting frequency/timing.

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

Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example

[Achilleas Anastasopoulos]

Thanks Andy.

Indeed the "symbol_sync" block is very robust and recovers immediately.
Everything seems to be working now.


Achilleas





On Wed, Jul 10, 2019 at 9:45 AM Andy Walls 
wrote:

> Hi Achilleas:
>
> > From: Achilleas Anastasopoulos
> > Date: Wed, 10 Jul 2019 08:45:03 -0400
> > Hi Ernest,
> >
> > Although this explains why the system breaks when the noise becomes
> > large (~10dB) and so the overall signal amplitude increases beyond
> > (~1), it cannot explain why the system does not recover AFTER
> > all amplitudes are set back to normal values (~1) and noise back to
> > -30dB ...
> >
> > It was my impression that the polyphase sync block will completely
> > reset once it sees a tag from the correlate and sync block, but this
> > does not seem to be the actual behavior...
>
> It does not, unfortunately.
>
> The nominal symbol clock period, which is stored in the integral branch
> of the loop filter internal to the pfb_clock_sync block, is not reset
> upon receipt of a "time_est" tag.
>
> If processing the noise pulled the nominal clock symbol period estimate
> way off from the actual symbol clock period, the pfb_clock_sync block
> could take a long time to recover depending on the damping factor and
> loop bandwidth you provided.  The pfb_clock_sync block (errantly)
> defaults to extremely overdamped, BTW.
>
> The new symbol_sync block does reset it's nominal symbol clock period
> estimate on receipt of a "time_est" (or "clock_est") tag, but can be
> configured to act like the pfb_clock_sync block in other respects.
>
> Regards,
> Andy
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example

[Achilleas Anastasopoulos]

Hi Ernest,

Although this explains why the system breaks when the noise becomes large
(~10dB) and so the overall signal amplitude increases beyond (~1), it
cannot explain why the system does not recover AFTER
all amplitudes are set back to normal values (~1) and noise back to -30dB
...

It was my impression that the polyphase sync block will completely reset
once it sees a tag from the correlate and sync block, but this does not
seem to be the actual behavior...

Achilleas




On Wed, Jul 10, 2019 at 12:16 AM Ernest Fardin  wrote:

> Hi,
>
> I think this behaviour may be due to the level into the Polyphase Clock
> Sync block. The block expects a signal amplitude of 1 as explained in [1].
>
> An AGC between the Correlate and Sync and the Polyphase Clock Sync blocks
> might do the trick.
>
> Cheers
>
> Ernest
>
> [1] https://destevez.net/2017/08/agc-for-gr-satellites/
>
>
> On Wed, Jul 10, 2019 at 6:22 AM Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi all,
>>
>> I am not very successful in running the uhd_corr_and_sync_tx/rx.grc
>> example in the gr-digital examples directory (3.7.13.5) using usrps.
>>
>> In an effort to debug it, i merged the two graphs and eliminated the uhd
>> sink/sources (see attached) and so I am running a simulation without the
>> usrps. I also eliminated the FLL block as I do not have any frequency error
>> and not even any noise.
>>
>> The behavior I see is as follows:
>>
>> The transmission seems fine (a nice rrc spectrum followed by silence
>> periodically on and off).
>> On the reception side the blocks seem to be working fine producing
>> appropriate tags (one every 20Ksamples as expected) which means that the
>> "correlate_and_sync" block works as expected.
>>
>> When I plot the output of the "polyphase_clock_sync" I expect to see
>> three clear points:  +/- A and 0. Indeed this is what I see at first.
>>
>> Now I do the following: I increase the noise for a while to a large
>> number (~10dB) and then I take it back almost to 0 (-20dB). From that point
>> on, although the "correlate_and_sync" block works as expected (I see the
>> tag offsets back to normal) the picture does not contain three clear points
>> but is blurred indicating that the "polyphase_clock_sync" does not work
>> appropriately and I can never recover from this.
>>
>> I was hopping that since the "correlate_and_sync" block recovers and adds
>> the appropriate tags to the stream, the downstream block can recover as
>> well. However the behavior is not as robust as I expected.
>>
>> Can someone shed some light into this.
>>
>> thanks
>> Achilleas
>> ___
>> 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] debugging uhd_corr_and_sync example

[Achilleas Anastasopoulos]

Hi all,

I am not very successful in running the uhd_corr_and_sync_tx/rx.grc example
in the gr-digital examples directory (3.7.13.5) using usrps.

In an effort to debug it, i merged the two graphs and eliminated the uhd
sink/sources (see attached) and so I am running a simulation without the
usrps. I also eliminated the FLL block as I do not have any frequency error
and not even any noise.

The behavior I see is as follows:

The transmission seems fine (a nice rrc spectrum followed by silence
periodically on and off).
On the reception side the blocks seem to be working fine producing
appropriate tags (one every 20Ksamples as expected) which means that the
"correlate_and_sync" block works as expected.

When I plot the output of the "polyphase_clock_sync" I expect to see three
clear points:  +/- A and 0. Indeed this is what I see at first.

Now I do the following: I increase the noise for a while to a large number
(~10dB) and then I take it back almost to 0 (-20dB). From that point on,
although the "correlate_and_sync" block works as expected (I see the tag
offsets back to normal) the picture does not contain three clear points but
is blurred indicating that the "polyphase_clock_sync" does not work
appropriately and I can never recover from this.

I was hopping that since the "correlate_and_sync" block recovers and adds
the appropriate tags to the stream, the downstream block can recover as
well. However the behavior is not as robust as I expected.

Can someone shed some light into this.

thanks
Achilleas


uhd_corr_and_sync_tx_rx.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] fractional resampler weird behavior?

[Achilleas Anastasopoulos]

Hi all,

I have a 1KHz complex exponential sampled at 10Ksps going through a
fractional resampler with resampling ratio = 10
I display the output on a frequency sink (with sampling rate set to
100Ksps).
I expect to see a 1 KHz tone.
Instead I see only a DC component (see attached grc file)

When I repeat the experiment with the RATIONAL resampler with interpolation
10 and decimation 1 I get the expected result.

Can someone verify this behavior and if yes, am I missing something or is
this a bug?
(gnuradio 3.7.13.5)

thanks
Achilleas


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

[Discuss-gnuradio] UHD:USRP source FE options: recent experience and 2 questions

[Achilleas Anastasopoulos]

Hi all,

I have recently run an old experiment that used to work fine:

One UHD:USRP Tx is sending a constant tone at 1GHz
One UHD:USRP Rx is receiving at 1GHz and displays in X-Y mode.

Observations:
1) When the 2 USRPs have default (internal) clock I see a circle (due to
frequency instability).
2) When they have external clock (eg either from octoclock, or one feeds
the other in a master/slave configuration) I see a nice dot (off center)
that is pretty stable thus showing that the Tx/Rx are time/frequency
synchronized.

When I run this experiment recently
(with GNURADIO 3.7.13.5 and UHD 3.14.0.0)
 I got observation 1) but NOT 2).
In fact any time I connected an external clock and did 2) the Rx didn't
seem to receive anything.

After several hours of agony (thinking I have burnt the REF IN port) I
realized what the culprit was:
The switch in the UHD:USRP source block in the FE Correction tab was
"Enable DC offset correction: True"

Once I turned off the DC offset correction everything worked as before.
In retrospect I realize that this is the intended behavior, since the USRP
is receiving a DC signal and tries to eliminate it.
Clearly one way to avoid this is to receive at 1GHz+df and then correct for
df in software.
I am writing this note in case someone else comes up with a similar
situation and wonders what is going on...

Another issue I saw is that no matter what the switch is for the IQ
imbalance correction (True/False) I always get a warning when I run the
program:

[WARNING] [MULTI_USRP] Setting IQ imbalance compensation is not possible on
this device.

Q1) Is this a bug or a feature?

Finally one last question (probably off topic since it is USRP related):

Q2) Is it OK to connect the REF OUT of one USRP to the REF IN of another?
The REF OUT says 3.3V and the REF IN says +15dBm MAX.
I used to do that all the time without burning anything but now I am
skeptical...

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

[Discuss-gnuradio] question on sample rate and ethernet rate

[Achilleas Anastasopoulos]

Hi all,

I am trying to figure out what I am doing/thinking wrong in the following
example:

I have a simple flowgraph with a complex source sending samples to USRP.
The sample rate is fs=200e6/32=6.25 Msps which is the parameter that I set
in the USRP.

I assume that this parameter will result in fs x 8 =  50 MBytes/sec
transmission
over the ethernet (2 complex samples and float32 (4 bytes) each. This is
the format that I have set in USRP).

However, when I observe the transmission rate on the system monitor (Ubuntu
Linux) it reports a sustained rate of exactly half of it, ie, 25 MBytes/sec.

I cannot figure out what I am doing wrong and I get this factor of 2
mismatch.
All the above is run in an ubuntu box with gnuradio maint-3.7 installed and
uhd 3.14.0

thanks in advance for any explanation,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Symbol to chip Mapping

[Achilleas Anastasopoulos]

Not quite:

You set the "dimension" of the c2s block to 32.
No need to set any variable to 16...

Then you have to input to the c2s block an array of size 16 by 32 (or
simply 16x32=512).

Take a look at some examples of how c2s block is used in gr-trellis.

Achilleas



On Mon, Mar 11, 2019 at 11:58 PM Tellrell White  wrote:

> Okay. Let me make sure i’m clear on this.
>
> My flow graph looks like the following :
>
> Random source -> packed to unpacked -> chunks to symbols
>
> The source and packed to unpacked are set to byte and the packed to
> unpacked is outputting 4 bits per chunks so am I setting the dimension of
> the “chunks to symbols” block to 16 (0-15) and inputting 1024 values, 0’s
> and 1’s, (32 values for each dimension) to complete the mapping?
>
> Thanks for the assistance.
>
> Tellrell
>
> Sent from my iPhone
>
> > On Mar 11, 2019, at 8:28 AM, Achilleas Anastasopoulos 
> wrote:
> >
> > Yes this can be done with chunks-to-symbols.
> > This is essentially a 16 x 32 lookup table:
> >
> > turn your 4 bits into a byte which indices a lookup table with 32
> dimensions
> > (set the "dimension" variable to 32 in chunks-to-symbols).
> >
> > Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Symbol to chip Mapping

[Achilleas Anastasopoulos]

Yes this can be done with chunks-to-symbols.
This is essentially a 16 x 32 lookup table:

turn your 4 bits into a byte which indices a lookup table with 32 dimensions
(set the "dimension" variable to 32 in chunks-to-symbols).

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

Re: [Discuss-gnuradio] Different uhd behavior with two cloned computers

[Achilleas Anastasopoulos]

Problem solved!

The IT people had done an apt-get dist-upgrade
that upgraded the libraries to 13.1.
After recompiling gnuradio with the new libraries and burning new fpga
images in the X300 everything worked fine.

thanks for the help,
Achilleas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Different uhd behavior with two cloned computers

[Achilleas Anastasopoulos]

OK, this is getting too confusing for me:

FIRST (original) computer
address@hidden:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.0.1-release

SECOND (cloned) computer
address@hidden:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.1.0-release

clearly two different libraries are used (thanks for pointing this out).
how is that even possible?

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

[Discuss-gnuradio] Different uhd behavior with two cloned computers

[Achilleas Anastasopoulos]

Hi all,

I have successfully installed from source gnuradio on an ubuntu 10.4.

We are in the process of creating a communications lab with 10 hosts and 10
X300
and we thought the easiest way is to clone the original computer so that we
don't have to reinstall all the software.

However, when I tried to the same command on the 2nd computer I get a
different result:

FIRST (original) computer

anastas@AA-1:~$ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
UHD_3.13.0.1-release
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [GPS] No GPSDO found
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1310 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1314 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
  _
 /
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:22:60:05
|   |   mac-addr1: 00:80:2f:22:60:06
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 311D131
|   |   FW Version: 6.0
|   |   FPGA Version: 35.1
|   |   FPGA git hash: 1107862
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: UBX-160 v2 (0x007e)
|   |   |   Serial: 315EA0D
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: UBX RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   RX Dboard: B
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: Unknown (0x) - 0
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: B
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: UBX-160 v2 (0x007d)
|   |   |   Serial: 315EA0D
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: UBX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9146
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX Dboard: B
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: Unknown (0x) - 0
|   |   |   |   Antennas:
|   |   |   |   Sensors:
|   |   |   |   Freq range: 0.000 to 0.000 MHz
|   |   |   |   Gain Elements: None
|   |   |   |   Bandwidth range: 

Re: [Discuss-gnuradio] issues with building 3.7.13.4 with thrift support on Ubuntu 18.04

[Achilleas Anastasopoulos]

Thanks!

I have succesfully built thrift 0.10.0 and the entire installation of
gnuradio went smoothly on Ubuntu 18.04.

One think that was missing from the wiki:
I needed to install an additional package "pygraphviz"
which on ubuntu repos was  "python-pygraphviz"
for the gr-perfomance-monitor application to run.

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

[Discuss-gnuradio] issues with building 3.7.13.4 with thrift support on Ubuntu 18.04

[Achilleas Anastasopoulos]

Hi all,

I have installed thrift 0.12.0 following the instructions in
https://wiki.gnuradio.org/index.php/ControlPort

I tried to build from source v3.7.13.4

cmake seems to work well producing:

--
-- Configuring gr-ctrlport support...
--   Dependency Boost_FOUND = 1
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Enabling gr-ctrlport support.
--   Override with -DENABLE_GR_CTRLPORT=ON/OFF
-- Looking for C++ include sys/resource.h
-- Looking for C++ include sys/resource.h - found
-- Loading build date Sun, 13 Jan 2019 00:41:52 into constants...
-- Loading version 3.7.13.4 into constants...
-- Checking for module 'thrift'
--   Found thrift, version 0.12.0
--
-- Python checking for Thrift
-- Python checking for Thrift - found
-- Found THRIFT: /usr/local/lib/libthrift.so
-- Found and enabling Thrift backend to ControlPort
-- Running thrift to build C++ bindings
-- Looking for C++ include windows.h
-- Looking for C++ include windows.h - not found
-- TRY_SHM_VMCIRCBUF set to ON.
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
suitable version "2.7.15rc1", minimum required is "2")
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE
-- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success
-

and finally:

--
-- ##
-- # Gnuradio enabled components
-- ##
--   * python-support
--   * testing-support
--   * volk
--   * doxygen
--   * sphinx
--   * gnuradio-runtime
--   * gr-ctrlport
--   * * thrift
--   * gr-blocks
--   * gnuradio-companion
--   * gr-fec
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-dtv
--   * gr-atsc
--   * gr-audio
--   * * alsa
--   * * oss
--   * gr-comedi
--   * 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
--
-- ##
-- # Gnuradio disabled components
-- ##
--
-- Using install prefix: /usr/local
-- Building for version: 3.7.13.4 / 3.7.13.4
-- Configuring done
-- Generating done

-












However, make errors out with:

[ 26%] Building CXX object
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/controlport/thrift/rpcserver_thrift.cc.o

In file included from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/lib/controlport/rpcserver_selector.cc:24:0:
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:57:15:
warning: ‘template class std::auto_ptr’ is deprecated
[-Wdeprecated-declarations]
   static std::auto_ptr boot;
   ^~~~
In file included from /usr/include/c++/7/memory:80:0,
 from /usr/include/boost/config/no_tr1/memory.hpp:21,
 from /usr/include/boost/smart_ptr/shared_ptr.hpp:23,
 from /usr/include/boost/shared_ptr.hpp:17,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/pmt/pmt.h:28,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/messages/msg_accepter.h:26,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/rpccallbackregister_base.h:26,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_base.h:26,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_aggregator.h:28,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/rpcserver_booter_aggregator.h:28,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/lib/controlport/rpcserver_selector.cc:23:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template class auto_ptr;
^~~~
In file included from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/lib/controlport/rpcserver_selector.cc:24:0:
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/gnuradio/rpcmanager.h:58:15:
warning: ‘template class std::auto_ptr’ is deprecated
[-Wdeprecated-declarations]
   static std::auto_ptr aggregator;
   ^~~~
In file included from /usr/include/c++/7/memory:80:0,
 from /usr/include/boost/config/no_tr1/memory.hpp:21,
 from /usr/include/boost/smart_ptr/shared_ptr.hpp:23,
 from /usr/include/boost/shared_ptr.hpp:17,
 from
/home/anastas/workarea-gnuradio/gnuradio/gnuradio-runtime/include/pmt/pmt.h:28,
 from

Re: [Discuss-gnuradio] problems with installation on ubuntu 18.04.1

[Achilleas Anastasopoulos]

I resolved all the issues with 3.7.13.4

Achilleas

On Fri, Jan 11, 2019 at 3:37 PM Achilleas Anastasopoulos 
wrote:

> Hi Martin,
>
> I resolved all the issues with 3.7.13.4
>
> Achilleas
>
> On Fri, Jan 11, 2019 at 2:07 PM Martin Braun 
> wrote:
>
>> Is there more info in the build output further up?
>>
>> On Thu, Jan 10, 2019 at 4:48 PM Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Hi all,
>>>
>>> I needed to install gnuradio from source on an ubuntu 18.04.1 machine.
>>> I followed the directions in
>>>
>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>>>
>>> I installed the dependencies and then cloned gnuradio
>>>
>>> I checked out v3.7.10
>>>
>>> git checkout 3.7.10git
>>>
>>> and performed the standard
>>>
>>> cmake
>>>
>>> make
>>>
>>> Unfortunately make stops around 50% with an error when linking
>>> libgnuradio-blocks-3.7.10git.so
>>>
>>> ---
>>> [ 53%] Linking CXX shared library libgnuradio-blocks-3.7.10git.so
>>> [ 53%] Built target gnuradio-blocks
>>> Makefile:162: recipe for target 'all' failed
>>> make: *** [all] Error 2
>>>
>>> I am also attaching the output of cmake
>>>
>>> Any clues as to what maybe wrong?
>>>
>>> thanks
>>>
>>> Achilleas
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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] problems with installation on ubuntu 18.04.1

[Achilleas Anastasopoulos]

Hi all,

I needed to install gnuradio from source on an ubuntu 18.04.1 machine.
I followed the directions in
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux

I installed the dependencies and then cloned gnuradio

I checked out v3.7.10

git checkout 3.7.10git

and performed the standard

cmake

make

Unfortunately make stops around 50% with an error when linking
libgnuradio-blocks-3.7.10git.so

---
[ 53%] Linking CXX shared library libgnuradio-blocks-3.7.10git.so
[ 53%] Built target gnuradio-blocks
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

I am also attaching the output of cmake

Any clues as to what maybe wrong?

thanks

Achilleas


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

[Discuss-gnuradio] two versions of uhd installed?

[Achilleas Anastasopoulos]

Hi all and happy new year,

It is not clear to me if this question is a usrp or gnuradio related so I
send it to both lists. Apologies for the duplication.


I have installed a clean version of gnuradio to an ubuntu box
from repos with apt-get.

I then installed from the ettus site the uhd files using:
"Using binaries provided by Ettus Research":

sudo add-apt-repository ppa:ettusresearch/uhd
sudo apt-get update
sudo apt-get install libuhd-dev libuhd003 uhd-host

After trying to communicate with my newly bought X310
I got some error messages about incompatibility of FPGA images that
I fixed with appropriate downloading/burning the new images to FPGA.

Now commands like uhd_find_devices and uhd_usrp_probe work perfectly, eg,

anastas@AA-1:~$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.1-release
--
-- UHD Device 0
--
Device Address:
serial: 311D131
addr: 192.168.10.2
fpga: HG
name:
product: X310
type: x300

telling me that I am using UHD_3.13.0.1-release

PROBLEM: however when I run a simple uhd example (eg, uhd_const_wave.py)
I get the following error:

anastas@AA-1:/tmp$ ./uhd_const_wave.py
Warning: failed to XInitThreads()
linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown

-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
Traceback (most recent call last):
  File "./uhd_const_wave.py", line 203, in 
main()
  File "./uhd_const_wave.py", line 191, in main
tb = top_block_cls(samp_rate=options.samp_rate, freq=options.freq,
gain=options.gain, address=options.address)
  File "./uhd_const_wave.py", line 98, in __init__
channels=range(1),
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
  File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3012, in make
return _uhd_swig.usrp_sink_make(*args)
RuntimeError: RuntimeError: Expected FPGA compatibility number 33, but got 35:
The FPGA image on your device is not compatible with this host code build.
Download the appropriate FPGA images for this version of UHD.
Please run:

 "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

Then burn a new image to the on-board flash storage of your
USRP X3xx device using the image loader utility. Use this command:

"/usr/bin/uhd_image_loader" --args="type=x300,addr=192.168.10.2"

For more information, refer to the UHD manual:

 http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash

--

So it seems that it is using a different uhd library
(UHD_003.010.003.000-0-unknown) than the one I installed from ettus...

How can I fix this?

Thanks

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

Re: [Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

Hi Mathew,

the random source outputs bytes with numbers 0 or 1 (NOT 2).
This single bit information is "packed" into a byte that is the input to
the QAM modulator.
The QAM modulator internally breaks up these bytes and uses every 4 bits to
signal the 16QAM constellation.

best,
Achilleas



On Tue, Nov 20, 2018 at 3:03 PM Matthew J. Brandsema 
wrote:

> Hello,
>
> When I switched AC coupling off, it just went blank.
>
> So instead, I saved the waveforms to a file and plotted the result in
> Matlab.  See attached for plots.  The blue curve are the data before
> modulating, and the red x's are the data after demodulating.  They are
> lined up!
>
> Thanks so much for the help in getting this working!!!  I noticed the
> random numbers are only 0, 1 and 2.  How the heck does this work for 16
> QAM?  How does it encode 3 numbers to 16 symbols?
>
> My next step is to transmit and receive using two Ettus radios next.  I
> got them to transmit and receive but I can't seem to find a delay that will
> make them sync up like I did with the file you sent.
>
> I saved their IQ waveforms to see how out of sync they are by doing a
> correlation and the correlation peak seem to be changing between data
> collects. Does anyone have any idea of what might be happening? (Sorry to
> add another question, I have been trying all day to get this working).
> --
> *From:* Achilleas Anastasopoulos [anas...@umich.edu]
> *Sent:* Tuesday, November 20, 2018 1:25 PM
> *To:* Matthew J. Brandsema; Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Packet Decoder Breaking when adding
> noise
>
> Can you switch off the AC-coupling, and check the scope plot again.
> Also, maybe useful to have markers instead of just lines.
>
> The two streams should be perfectly synchronized (for low noise) and as
> noise gets higher
> some of the demodulated bits are in error. This is perfectly OK.
>
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

Can you switch off the AC-coupling, and check the scope plot again.
Also, maybe useful to have markers instead of just lines.

The two streams should be perfectly synchronized (for low noise) and as
noise gets higher
some of the demodulated bits are in error. This is perfectly OK.

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

Re: [Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

There is something really disturbing with your plots:

The values have to be either 0 or 1 (recall they are the
transmitted/demodulated bits).
Yet, you have values in the range 0.6-0.8...

Are you sure the plots correspond to the flowgraph you posted?

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

Re: [Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

It is important that you have a time scope where you compare the initial
bit stream with the output of the demodulator.
These are NOT synchronized.
Unless you do that you cannot get any meaningful measurement of the BER!

You can substitute the Qt blocks with WX blocks. This is easy.

Achilleas


On Tue, Nov 20, 2018 at 7:36 AM Matthew J. Brandsema 
wrote:

> Hello,
>
> I don't have QT gui so I had to convert to WX blocks (how do I install
> QT?). I cannot get the BER to change appreciably, no matter what delay I
> set.  The best I can get it to is only about -1 dB.  I will keep playing
> with it.
> --
> *From:* Achilleas Anastasopoulos [anas...@umich.edu]
> *Sent:* Monday, November 19, 2018 5:37 PM
> *To:* Matthew J. Brandsema; Discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Packet Decoder Breaking when adding
> noise
>
> I attach a simple grc file that works for me.
>
> Using the delay10/delay sliders try to align the input/output bit stream.
> (in this example this happens at delay=12, but it may be different for
> you...)
>
> Then play with the noise variance; you will see the BER changing slowly as
> you go around values = -6,-5,-4
>
> let me know if this works for you,
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

I attach a simple grc file that works for me.

Using the delay10/delay sliders try to align the input/output bit stream.
(in this example this happens at delay=12, but it may be different for
you...)

Then play with the noise variance; you will see the BER changing slowly as
you go around values = -6,-5,-4

let me know if this works for you,
Achilleas


test_QAM.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

...neither do you want the extended FEC encoder/decoder.

Just send random symbols through the QAM modulator, add noise and
demodulate with the QAM demodulator.

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

[Discuss-gnuradio] Packet Decoder Breaking when adding noise

[Achilleas Anastasopoulos]

There is no reason to have packet encoder/decoder in your system if you
only want to measure BER for QAM.

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

Re: [Discuss-gnuradio] signal cancellation example using GRC and USRP B210

[Achilleas Anastasopoulos]

even without any frequency error, why do you expect that

exp[j(w t + phi1)] - exp[j(w t + phi2)]

is zero?

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

Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2

[Achilleas Anastasopoulos]

Hi Anshul,

regarding frequency correction (although I do not know the details of DVB)
my understanding is that there is a repeated training sequence, let's say
it is repeated N times.
If this is true, then the output of the MF (matched to one of the training
chunk) will give N peaks, each of which will be something like
r_k = exp(j 2 pi df T k) + noise
where T is the duration of each training chunk.
If you post-process this signal as
y_k = r_k r_{k-1}^*  ~=   exp(j 2 pi df T) + noise
which can be used for frequency estimation of df.

Achilleas




On Thu, Mar 22, 2018 at 12:49 PM, Anshul Thakur  wrote:

> Hi Marcus,
>
> So I did an implementation using a similar logic as in gr-cdma (courtesy 
> Achilleas)
> after smoothening the input. Once the correlation rose above a threshold, I
> essentially started taking 1K point FFTs and correlated the power
> distribution with the Carrier Distribution Sequence as specified in the
> standard [1].  By doing this, I am able to find the peak position and
> likewise, a more refined window of where the P1 symbol would be starting.
>
> Now, for the frequency offset correction part, I am confused as to what it
> should be. The standard says:
>
> *The argument of the 'correlator' outputs contains information about the
> fine frequency offset, but also the unknown*
> *arbitrary phase (with respect to the transmitter) of the down-shifter
> oscillator. By multiplying the two correlator pulsesas shown, the effect of
> the unknown arbitrary phase is cancelled. The argument of the final output
> pulse can be shownto be proportional to the 'fine' component of the
> frequency offset.*
>
> Mathematically, if each of my correlations in either branches had a
> constant frequency offset of 'theta', then multiplying the two would have
> given me (2*theta) while the random phase fluctuations are expected to have
> cancelled. In that case, should I be dividing the argument by 2 to get to
> my frequency offset?
>
> Also, should I take the argument of the index at which peak was detected
> as my frequency-offset, or should it be an average of something? Actually,
> I've tried using the phase value at the peak directly, but it does not lead
> to a meaningful P1 pre-signaling signal after DBPSK demodulation [2].
>
> [1] DVBT2 Implementation Guidelines, Section 10.2.2.6 P1 Validation
> [2] DVBT2 Standard ETSI EN 302 755 V1.4.1, Section 9.8.2.2
>
> Warm regards,
> Anshul Thakur
>
> On 15 March 2018 at 22:29, Anshul Thakur 
> wrote:
>
>> Hi Marcus,
>>
>> Thank you for your inputs.
>>
>> On 13 March 2018 at 22:22, Müller, Marcus (CEL)  wrote:
>>
>>> Hi Anshul,
>>>
>>> do you normalize your correlation by the received signal power in that
>>> same window?
>>>
>>
>> No. I wasn't normalizing the correlations. I'm using the image attached
>> as reference design.
>> I guess I got a little excited to see the peaks in Matlab that I did not
>> even consider the energy of the signal as a possible normalization
>> denominator.  :D
>>
>>
>> ​
>>
>>
>>> How's your frequency correction doing? If you don't have frequency
>>> detection at that point, your signal might get decorrelated.
>>>
>>
>> The preamble detection step itself is supposed to find a coarse
>> frequency-offset which must be
>> further refined by correlation with the Carrier-Distribution-Sequence(cds)
>> in the next step. So, no, currently, there is no frequency correction as
>> per se.
>>
>>
>>>
>>> You can solve both by employing a fixed delay correlation of your
>>> receive signal; IIRC, P1 is roughly split into three parts: A middle
>>> part that repeats in the front and at the end of the symbol. Let's say
>>> that repeated part in the front is N samples long. Take these N,
>>> correlate with the N that follow, divide by the power of these samples.
>>>
>>
>> Correct. I was not dividing by the power. I did that and the slopes have
>> become more smooth except occasional blips over a single sample.
>> I am correcting for these occasional blips by comparing my current value
>> with the running average a small previous window (5 samples currently), the
>> reasoning being -
>> If the signal is rising fairly consistently, the current value will be
>> greater than the average of what came in the short term past.
>> By doing so, I am able to get a coarse window of prospective sample
>> ranges where the signal might be starting.
>>
>> I will now try to filter them further by correlating with the CDS and
>> revert back if I run into more trouble. Many thanks!
>>
>>
>>>
>>> You'll not only get a value that should be independent from absolute
>>> receive signal strength (as long as fading is not faster than ¼ of the
>>> P1 length), and as a bonus, the correlation coefficient's phase allows
>>> for a relatively robust frequency offset estimate. You can use that
>>> estimate to correct your receive signal and get a better detection
>>> result :)
>>
>> Best regards,
>>> Marcus

Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2

[Achilleas Anastasopoulos]

Hi  Anshul,

take a look at how acquisition is done on the gr-cdma OOT module

https://github.com/anastas/gr-cdma

It is using a MF followed by a peak finder to generate flags for
the beginning of the frame which is them processed downstream.


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

Re: [Discuss-gnuradio] Audio sink + windows binaries

[Achilleas Anastasopoulos]

Great Geof,

thanks for the feedback!

The wav file was downloaded from the internet and the data file was
generated by the simple matlab script that is also present in the
Dropbox directory I provided: essentially it opens the wav file, reads the
samples, extracts only one of the two channels and saves the data in
float32 format.

Just to clarify: both files (data and wav) are played perfectly OK on my
Linux Box, so the issue is not with wav vs data but with Linux vs Windows.

thanks again,
Achilleas









On Wed, Oct 25, 2017 at 5:28 PM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> Achilleas,
>
> I have duplicated the problem with the same setup, playing the .data file
> w/ the file source, and also playing the wav file with the wav file source
> produces similar distorted results.
>
> However, I don't have a quick solution to return.  I'll need to keep
> looking.
>
> Can you describe how you created the .data file and .wav files?
>
> Geof
>
> On Wed, Oct 25, 2017 at 4:22 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi Marcus,
>>
>> thanks for offering to help.
>>
>> As i say in my email the audio file sounds with a different speed than
>> the original!
>>
>> I have added a new file in the Dropbox link that I sent last time,
>> "experiment.m4a"
>> If you play it you'll hear the two different sounds: one from my standard
>> wav player and the other from within grc.
>>
>> thanks again,
>> Achilleas
>>
>> ___
>> 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] Audio sink + windows binaries

[Achilleas Anastasopoulos]

Hi Marcus,

thanks for offering to help.

As i say in my email the audio file sounds with a different speed than the
original!

I have added a new file in the Dropbox link that I sent last time,
"experiment.m4a"
If you play it you'll hear the two different sounds: one from my standard
wav player and the other from within grc.

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

[Discuss-gnuradio] Audio sink + windows binaries

[Achilleas Anastasopoulos]

Hi all,

I have a problem using audio sink on windows 10 using the installation of
the latest binaries from here:

http://www.gcndevelopment.com/gnuradio/index.htm


The audio is simply not playing what is SUPPOSED to play.
If anyone wants to give me some feedback on what may be wrong please
take a look at this folder with some examples:

https://www.dropbox.com/sh/f6tyc87tpu7plwv/AACvWZIPqedxNIGAZWgfG2c_a?dl=0

1) try to play the wav files with your favorite wav player
2) try to play the corresponding data files with the grc script

They sound differently (almost double the rate + some clicking noise).

I would really appreciate some feedback because I am going crazy with
this...

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

Re: [Discuss-gnuradio] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Achilleas Anastasopoulos]

Hi all,

apologies for not replying earlier.

So it has been quite some time since i last dealt with this problem but my
recollection is that this project is far from being able to implement a
practical CPM scheme exactly because it is not robust even to a phase
(forget about frequency) change.
It is a purely coherent system and my purpose was to illustrate how the
gr-trellis framework can be used for optimal demodulation of CPM; not to
provide a ready-to-use block.

For anyone who wants to take it to the next level, you have to incorporate
some kind of phase detection. Possibly a packetized transmission with each
packet containing a training sequence that gives initial phase estimation
followed by either (a) a decision feedback PLL (with tentative decisions
from the VA) or (b) a per-survivor processing (PSP) architecture where a
PLL is attached to each state of the trellis and is updated accordingly.
The next step (in terms of complexity) would be to implement epoch
estimation...

Both of these require modifications to the basic VA algorithms so this can
be a nice more general project: how to modify the basic VA blocks in
gr-trellis to provide tentative decisions that can be used by any type of
decision-feedback estimator.

I may give this project to a student over the summer if there is interest
for it...

best,
Achilleas













On Fri, Apr 7, 2017 at 9:49 AM, Andy Walls <a...@silverblocksystems.net>
wrote:

> So I did some thinking about how to synchronize to the 2*pi*f0*t phase
> term.
>
> After checking the papers again and the particular GMSK example in
> test_cpm.py, that phase term cycles over 4 symbol periods, so it
> definitely adds phase ambiguity.  Resetting it at every symbol is
> definitely the wrong thing to do.
>
> So I plugged in some real numbers from AIS to see what f0 actually was:
>
> Rb = 1/T = 9600 bits/sec
> h = 1/2 = f_dev / (Rb/2)  => f_dev = 2400 Hz
>
> so the AIS GMSK signaling freqs are +/-2400 Hz.
>
> From Achilleas' paper, the expression for f0 is:
>
> M = 2
> f0 = -h(M-1)/(2T) = -9600/4 = -2400 Hz
>
> So f0 is really the lower signaling frequency, at least for the
> specific case of binary MSK.  (Achilleas, maybe you can comment on what
> f0 is in the general case?)
>
> I'm thinking that if I can pick off the phase of the lower signaling
> frequency during the AIS preamble (where I know there are always spots
> of -2400 Hz when a symbol repeats ), I can properly initialize the
> phase of the the frequency shift by f0.
>
> That seems kind of hokey to me, so I'm open to better ideas.  I'd also
> like to hear if anyone thinks what I suggested will work or not.
>
> I was trying to contemplate how the t in 2*pi*f0*t could be
> incorporated into the FSM state, since this phase term appears to be
> part of the phase memory of the system, though not part of the
> modulation memory.  I couldn't see an obvious way to do that.
>
> Regards,
> Andy
>
>
> On Thu, 2017-04-06 at 15:36 -0400, Andy Walls wrote:
> > On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > > sure, feel free to look into the gr-trellis documentation and
> > > provide
> > > some feedback.
> > > If you have further questions please let us know.
> > >
> > > best,
> > > Achilleas
> >
> > Hi Achilleas:
> >
> > My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver,
> > using
> > the Viterbi algorithm for optimal demodulation of the CPM symbols.
> >
> > In examining gr-trellis/examples/python/test_cpm.py, I see that
> > everything is perfectly synchronized, for the purposes of
> > demonstration. (The addition of a 0.0 to the end of the 99% energy
> > orthonormal basis vectors for the matched filter correlators, to have
> > the taps completely fall into the initial all-0 history of the fir
> > filter blocks, was a nice trick BTW).
> >
> > In my design concept for a receiver, I believe I have worked out
> > carrier frequency offset correction, phase offset correction, symbol
> > timing recovery at either 4 or 5 samples per symbol, and injecting
> > samples to properly realign the symbols entering the decimating
> > matched
> > filter correlators when a new burst is received.
> >
> > What I can't quite figure out is how to properly synchronize the
> > correction of f0T carrier frequency shift introduced by the CPM
> > decomposition, without unintentionally adding an arbitrary phase
> > shift
> > to the symbol's signal in the CPM decomposition.
> >
> > Do I restart the complex exponential frequency shift sequence with a
> > phase of 0 at the start of each symbol?  I think that works for Q=4.
> > But what about f

Re: [Discuss-gnuradio] gr-trellis test_cpm.py question

[Achilleas Anastasopoulos]

Here is what needs to be done (simple).

N is the dimensionality of the signal space (found earlier in the code).
Now we need to set up a filter bank to project the incoming signal to all
its dimensions. These filters are held on the MF[] array.
Now (due to laziness) i didn't write a for loop that instantiates N filter
blocks, but I just instantiated them manually for the case of N=2 in

filter_fir_filter_xxx_0_0 = filter.fir_filter_ccc(Q, MF[0].conjugate())
filter_fir_filter_xxx_0_0_0 = filter.fir_filter_ccc(Q, MF[1].conjugate())

So what needs to be done is (through a for loop) instantiate these N filter
blocks
and appropriately modify the code (in the "connections" part) to make the
right
connections to and from these blocks.

best,
Achilleas


On Sun, Apr 2, 2017 at 6:58 PM, Andy Walls 
wrote:

> Hi Achilleas:
>
> In the test_cpm.py example under gr-trellis, there is a comment:
>
> "# only works for N=2, do it manually for N>2..."
> https://github.com/gnuradio/gnuradio/blob/master/gr-
> trellis/examples/python/test_cpm.py#L108
>
> Could you, or anyone else, elaborate on what need to be done manually for
> N>2?
>
> Thanks,
> Andy
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-cdma doxygen build

[Achilleas Anastasopoulos]

Hi Murray,

although I am the author of gr-cdma I do not know how to help you with
this. I am using doxygen etc as a user, not a developer, so I wouldn't even
know where to start.
For what it's worth, I have developed and tested this module on  Fedora 21.

Hope someone else in the list can help on this one.

If you have any questions on the technical side of things please let me
know.

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

Re: [Discuss-gnuradio] GSL_FOUND both TRUE and FALSE

[Achilleas Anastasopoulos]

Hi all,

thank you for your input.

Some clarifications:

I was indeed cmaking the latest version from git

"Building for version: v3.7.10.1-237-g81e7af7b / 3.7.11git"

and was working from scratch with a clean built.

I attach here the whole output of cmake.

thanks for the help ,
Achilleas


















On Tue, Feb 21, 2017 at 6:01 PM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> Hi all,
>
> after a long time update from source on a Fedora 23 I came across the
> following problem when cmaking:
>
> -- Configuring gr-fec support...
> --   Dependency ENABLE_VOLK = ON
> --   Dependency Boost_FOUND = 1
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Dependency GSL_FOUND = TRUE <
> --   Enabling gr-fec support.
> --   Override with -DENABLE_GR_FEC=ON/OFF
> -- Checking for module 'fftw3f >= 3.0'
> --   Found fftw3f , version 3.3.4
> -- Found FFTW3F: /lib64/libfftw3f.so
>
> but then
>
> -- Configuring gr-dtv support...
> --   Dependency Boost_FOUND = 1
> --   Dependency GSL_FOUND = FALSE  <
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_ANALOG = ON
> --   Dependency ENABLE_GR_FILTER = ON
> --   Dependency ENABLE_GR_FEC = ON
> --   Disabling gr-dtv support.
> --   Override with -DENABLE_GR_DTV=ON/OFF
> -- Could NOT find GSL (missing:  GSL_INCLUDE_DIRS GSL_LIBRARY_DIRS)
> --
> -- Configuring gr-atsc support...
> --   Dependency Boost_FOUND = 1
> --   Dependency GSL_FOUND = FALSE   <
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_FFT = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Dependency ENABLE_GR_FEC = ON
> --   Dependency ENABLE_GR_FILTER = ON
> --   Dependency ENABLE_GR_ANALOG = ON
> --   Disabling gr-atsc support.
> --   Override with -DENABLE_GR_ATSC=ON/OFF
>
> --
> -- Configuring gr-wavelet support...
> --   Dependency Boost_FOUND = 1
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Dependency ENABLE_GR_ANALOG = ON
> --   Dependency GSL_FOUND = FALSE  <
> --   Disabling gr-wavelet support.
> --   Override with -DENABLE_GR_WAVELET=ON/OFF
> --
>
> and so the packages
>
> --   * gr-dtv
> --   * gr-atsc
> --   * gr-wavelet
>
> are not being built.
>
> BTW: I have gsl and gsl-devel installed (version 1.16-17)
>
> Can anyone give me a hint as to what may be wrong here?
>
> thanks
> Achilleas
>
>
-- The CXX compiler identification is GNU 5.3.1
-- The C compiler identification is GNU 5.3.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Build type set to Release.
-- Found Git: /usr/bin/git  
-- Extracting version information from git describe...
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_WARN_SIGN_COMPARE
-- Performing Test HAVE_WARN_SIGN_COMPARE - Success
-- Performing Test HAVE_WARN_ALL
-- Performing Test HAVE_WARN_ALL - Success
-- Performing Test HAVE_WARN_NO_UNINITIALIZED
-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
-- Compiler Version: cc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Copyright (C) 2015 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.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -std=c++98 -fvisibility=hidden -Wsign-compare 
-Wall -Wno-uninitialized
-- ADDING PERF COUNTERS
-- Building Static Libraries: OFF
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   regex
--   thread
-- Found PythonLibs: /usr/lib64/libpython2.7.so (found suitable version 
"2.7.11", minimum required is "2") 
-- 
-- Checking for module SWIG
-- Found SWIG version 3.0.7.
-- Found SWIG: /usr/bin/swig  
-- 
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
-- 
-- Configuring python-support support...
--   Dependency PYTHONLI

[Discuss-gnuradio] GSL_FOUND both TRUE and FALSE

[Achilleas Anastasopoulos]

Hi all,

after a long time update from source on a Fedora 23 I came across the
following problem when cmaking:

-- Configuring gr-fec support...
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Dependency GSL_FOUND = TRUE <
--   Enabling gr-fec support.
--   Override with -DENABLE_GR_FEC=ON/OFF
-- Checking for module 'fftw3f >= 3.0'
--   Found fftw3f , version 3.3.4
-- Found FFTW3F: /lib64/libfftw3f.so

but then

-- Configuring gr-dtv support...
--   Dependency Boost_FOUND = 1
--   Dependency GSL_FOUND = FALSE  <
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_ANALOG = ON
--   Dependency ENABLE_GR_FILTER = ON
--   Dependency ENABLE_GR_FEC = ON
--   Disabling gr-dtv support.
--   Override with -DENABLE_GR_DTV=ON/OFF
-- Could NOT find GSL (missing:  GSL_INCLUDE_DIRS GSL_LIBRARY_DIRS)
--
-- Configuring gr-atsc support...
--   Dependency Boost_FOUND = 1
--   Dependency GSL_FOUND = FALSE   <
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_FFT = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Dependency ENABLE_GR_FEC = ON
--   Dependency ENABLE_GR_FILTER = ON
--   Dependency ENABLE_GR_ANALOG = ON
--   Disabling gr-atsc support.
--   Override with -DENABLE_GR_ATSC=ON/OFF

--
-- Configuring gr-wavelet support...
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Dependency ENABLE_GR_ANALOG = ON
--   Dependency GSL_FOUND = FALSE  <
--   Disabling gr-wavelet support.
--   Override with -DENABLE_GR_WAVELET=ON/OFF
--

and so the packages

--   * gr-dtv
--   * gr-atsc
--   * gr-wavelet

are not being built.

BTW: I have gsl and gsl-devel installed (version 1.16-17)

Can anyone give me a hint as to what may be wrong here?

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

Re: [Discuss-gnuradio] Building simulation of basic turbo code

[Achilleas Anastasopoulos]

Adrian,

your scattered questions indicate you have a long way to go before you can
do anything useful with gnuradio on your own.

I suggest you "study" these examples carefully: you'll discover that many
people have put a lot of time and love into this and have provided
documentation to answer most if not all your questions.
Try to read the documentation of gr-trellis explaining how you can build
any arbitrary fsm.
Then read the documentation and code for the siso modules.
Then read the documentation and code for sccc/pccc etc.
As the folder name suggests these are only EXAMPLES but this is also open
source so all the code is there for you to read/change.

If the documentation does not answer your questions then please post a
specific question on the list. Even better, provide your own grc draft
design so people can comment on something concrete.
I am willing to help you with gr-trellis if you decide to take it seriously.

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

Re: [Discuss-gnuradio] Building simulation of basic turbo code

[Achilleas Anastasopoulos]

Hi Adrian,

in gr-trellis/examples/grc

there are two examples of a sccc and a pccc

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

Re: [Discuss-gnuradio] problems with windows binaries and audio

[Achilleas Anastasopoulos]

I think I figured out what is going on:

The audio block DOES NOT BLOCK no matter what the value of the "OK to
block" setting is.

The reason that the 440 Hz tone was heard perfectly was that although
samples were dropped by the audio device, the remaining samples where
enough to reconstruct a nice tone.

This unfortunately does not work with other audio signals.

The solution of putting a throttle unfortunately does not work well: it
produces a very choppy sound on-off all the time.


Geof: thanks for all the help. I guess I will have to wait for version
3.7.10.2.

Could you please confirm that indeed in this version the audio block DOES
NOT BLOCK regardless of the setting.

thanks again,
Achilleas



On Mon, Nov 7, 2016 at 3:24 PM, Achilleas Anastasopoulos <anas...@umich.edu>
wrote:

> Hi Geof,
>
> apologies if the email was not clear: I guess for me getting some sound
> was not considered good enough :-)
>
>
> The audio sink IS BLOCKING (OK to block is indeed set to YES)
> and as I mentioned in the last email, a nice 440Hz tone generated by a
> signal source is PERFECTLY audible.
>
> As I mentioned earlier, I am starting to believe that the "wav file
> source" is not working properly.
>
> Can anyone confirm a working configuration with:
>
> Wav File Source --> Audio Sink
>
> Thanks
> Achilleas
>
>
> On Mon, Nov 7, 2016 at 2:49 PM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> OK, so you are getting *some* sound.  Your first email seemed to indicate
>> nothing at all was happening.
>>
>> In that case, please add a throttle block to your flowgraph, set to the
>> audio sample rate you desire.
>>
>> The audio sink is being overwhelmed with data from the file source and is
>> not blocking.
>> When 3.7.10.2 is released the windows audio sink will block when "OK to
>> block" is set to true.
>>
>> Geof
>>
>>
>> On Mon, Nov 7, 2016 at 1:25 PM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> oopps I meant "a nice 440 Hz" cosine can be heard nicely.
>>>
>>> Achilleas
>>>
>>> On Mon, Nov 7, 2016 at 11:57 AM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
>>>> I also would like to report that a nice 440KHz cosine can be heard
>>>> perfectly OK with the default audio sink.
>>>>
>>>> So now I have my doubts about the wav file source block instead of the
>>>> audio sink block
>>>>
>>>> Any ideas?
>>>>
>>>> thanks
>>>> Achilleas
>>>>
>>>> On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <
>>>> anas...@umich.edu> wrote:
>>>>
>>>>> Hi Geof,
>>>>>
>>>>> thank you for your suggestions.
>>>>>
>>>>>
>>>>> Here is some more information from my Windows 7 running gnuradio
>>>>> binaries 3.7.10.1
>>>>>
>>>>> 1)
>>>>> When I use a simple wav file source with audio sink and without
>>>>> setting the "Device Name" entry I get the following output:
>>>>>
>>>>> INFO: Audio sink arch: windows
>>>>> gr::pagesize: no info; setting pagesize = 4096
>>>>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>>>>
>>>>> I can hear the sound but it is not coming out at the right speed/etc
>>>>> regardless of what sample rate I choose.
>>>>>
>>>>> So I tried the second method that Geof suggested: entering explicitly
>>>>> the device ID and/or the string representing the device's name.
>>>>>
>>>>> 2)
>>>>> Following Geof's advice I went to the "Device Manager" and the
>>>>> "Sounds, video and game controllers" section and I see a device "High
>>>>> Definition Audio Device". I clink on the "Details" tab and under the
>>>>> Property "device description" i see "High Definition Audio Device", so 
>>>>> this
>>>>> is what I put as the string under the "Device Name" property of the audio
>>>>> sink.
>>>>>
>>>>> The output then is:
>>>>>
>>>>> INFO: Audio sink arch: windows
>>>>> INFO: Warning: waveOut device 'High Definition Audio Device' was not
>>>>> found, defaulting to WAVE_MAPPER
>>>>> gr:

Re: [Discuss-gnuradio] problems with windows binaries and audio

[Achilleas Anastasopoulos]

Hi Geof,

apologies if the email was not clear: I guess for me getting some sound was
not considered good enough :-)


The audio sink IS BLOCKING (OK to block is indeed set to YES)
and as I mentioned in the last email, a nice 440Hz tone generated by a
signal source is PERFECTLY audible.

As I mentioned earlier, I am starting to believe that the "wav file source"
is not working properly.

Can anyone confirm a working configuration with:

Wav File Source --> Audio Sink

Thanks
Achilleas


On Mon, Nov 7, 2016 at 2:49 PM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> OK, so you are getting *some* sound.  Your first email seemed to indicate
> nothing at all was happening.
>
> In that case, please add a throttle block to your flowgraph, set to the
> audio sample rate you desire.
>
> The audio sink is being overwhelmed with data from the file source and is
> not blocking.
> When 3.7.10.2 is released the windows audio sink will block when "OK to
> block" is set to true.
>
> Geof
>
>
> On Mon, Nov 7, 2016 at 1:25 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> oopps I meant "a nice 440 Hz" cosine can be heard nicely.
>>
>> Achilleas
>>
>> On Mon, Nov 7, 2016 at 11:57 AM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> I also would like to report that a nice 440KHz cosine can be heard
>>> perfectly OK with the default audio sink.
>>>
>>> So now I have my doubts about the wav file source block instead of the
>>> audio sink block
>>>
>>> Any ideas?
>>>
>>> thanks
>>> Achilleas
>>>
>>> On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
>>>> Hi Geof,
>>>>
>>>> thank you for your suggestions.
>>>>
>>>>
>>>> Here is some more information from my Windows 7 running gnuradio
>>>> binaries 3.7.10.1
>>>>
>>>> 1)
>>>> When I use a simple wav file source with audio sink and without setting
>>>> the "Device Name" entry I get the following output:
>>>>
>>>> INFO: Audio sink arch: windows
>>>> gr::pagesize: no info; setting pagesize = 4096
>>>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>>>
>>>> I can hear the sound but it is not coming out at the right speed/etc
>>>> regardless of what sample rate I choose.
>>>>
>>>> So I tried the second method that Geof suggested: entering explicitly
>>>> the device ID and/or the string representing the device's name.
>>>>
>>>> 2)
>>>> Following Geof's advice I went to the "Device Manager" and the "Sounds,
>>>> video and game controllers" section and I see a device "High Definition
>>>> Audio Device". I clink on the "Details" tab and under the Property "device
>>>> description" i see "High Definition Audio Device", so this is what I put as
>>>> the string under the "Device Name" property of the audio sink.
>>>>
>>>> The output then is:
>>>>
>>>> INFO: Audio sink arch: windows
>>>> INFO: Warning: waveOut device 'High Definition Audio Device' was not
>>>> found, defaulting to WAVE_MAPPER
>>>> gr::pagesize: no info; setting pagesize = 4096
>>>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>>> aOaOaOaOaOaOaOaOaOa
>>>> aOaOaOaOaOaOaOaOaOaO
>>>>
>>>> And the sound is the same as above.
>>>>
>>>> So my question is the following:
>>>>
>>>> How exactly can I find in the control panel the name of my audio device?
>>>> Clearly the one I used ("High Definition Audio Device") was not found...
>>>>
>>>> Can it be that the problem is with the "wav file source" block and not
>>>> with the audio sink block?
>>>>
>>>> Thanks
>>>> Achilleas
>>>>
>>>>
>>>> On Sun, Nov 6, 2016 at 5:12 PM, Geof Nieboer <gnieb...@corpcomm.net>
>>>> wrote:
>>>>
>>>>> The audio device in the windows audio sink can be used one of two ways,
>>>>>
>>>>> First is to use a number which is the device ID of the audio device,
>>>>> the second is to enter a string representing the device's name.
>>>>>
>>>

Re: [Discuss-gnuradio] problems with windows binaries and audio

[Achilleas Anastasopoulos]

oopps I meant "a nice 440 Hz" cosine can be heard nicely.

Achilleas

On Mon, Nov 7, 2016 at 11:57 AM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> I also would like to report that a nice 440KHz cosine can be heard
> perfectly OK with the default audio sink.
>
> So now I have my doubts about the wav file source block instead of the
> audio sink block
>
> Any ideas?
>
> thanks
> Achilleas
>
> On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi Geof,
>>
>> thank you for your suggestions.
>>
>>
>> Here is some more information from my Windows 7 running gnuradio binaries
>> 3.7.10.1
>>
>> 1)
>> When I use a simple wav file source with audio sink and without setting
>> the "Device Name" entry I get the following output:
>>
>> INFO: Audio sink arch: windows
>> gr::pagesize: no info; setting pagesize = 4096
>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>
>> I can hear the sound but it is not coming out at the right speed/etc
>> regardless of what sample rate I choose.
>>
>> So I tried the second method that Geof suggested: entering explicitly the
>> device ID and/or the string representing the device's name.
>>
>> 2)
>> Following Geof's advice I went to the "Device Manager" and the "Sounds,
>> video and game controllers" section and I see a device "High Definition
>> Audio Device". I clink on the "Details" tab and under the Property "device
>> description" i see "High Definition Audio Device", so this is what I put as
>> the string under the "Device Name" property of the audio sink.
>>
>> The output then is:
>>
>> INFO: Audio sink arch: windows
>> INFO: Warning: waveOut device 'High Definition Audio Device' was not
>> found, defaulting to WAVE_MAPPER
>> gr::pagesize: no info; setting pagesize = 4096
>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>> aOaOaOaOaOaOaOaOaOa
>> aOaOaOaOaOaOaOaOaOaO
>>
>> And the sound is the same as above.
>>
>> So my question is the following:
>>
>> How exactly can I find in the control panel the name of my audio device?
>> Clearly the one I used ("High Definition Audio Device") was not found...
>>
>> Can it be that the problem is with the "wav file source" block and not
>> with the audio sink block?
>>
>> Thanks
>> Achilleas
>>
>>
>> On Sun, Nov 6, 2016 at 5:12 PM, Geof Nieboer <gnieb...@corpcomm.net>
>> wrote:
>>
>>> The audio device in the windows audio sink can be used one of two ways,
>>>
>>> First is to use a number which is the device ID of the audio device, the
>>> second is to enter a string representing the device's name.
>>>
>>> Realize, however, that there is no way to interactively iterate through
>>> the list of available devices, so you'll have to figure out the ID's/names
>>> yourself through the control panel.  It will give a warning in the output
>>> log if what you entered is not found so you can least use trial and error.
>>> If it can't find the device you entered, or you don't put an entry in, it
>>> will use the WAVE_MAPPER device.
>>>
>>> Geof
>>>
>>>
>>> On Sun, Nov 6, 2016 at 5:15 AM, Tarquin Roode <tarquin.ro...@gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>>
>>>>
>>>> Mine works, I am using 3.7.9.2
>>>>
>>>> So not a problem with the inary, it worked on Both Win 7 and Win 10
>>>>
>>>>
>>>>
>>>> I am not a home a he moment so don’t have  ss to my PC, bt I just
>>>> plopped the Audio Sink down and it worked
>>>>
>>>>
>>>>
>>>> Ood luck
>>>>
>>>> arqun
>>>>
>>>>
>>>>
>>>> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+tarquin.roode
>>>> =gmail@gnu.org] *On Behalf Of *Achilleas Anastasopoulos
>>>> *Sent:* Saturday, 05 November 2016 2:46 AM
>>>> *To:* Discuss-gnuradio@gnu.org
>>>> *Subject:* [Discuss-gnuradio] problems with windows binaries and audio
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I have installed the windows binaries from GCNDevelopment
>>>>
>>>> http://www.gcndevelopment.com/gnuradio/
>>>>
>>>>
>>>>
>>>> A simple test with a wav file and an audio sink does not seem to work.
>>>>
>>>> I have changed the config file to use audio - windows but still this is
>>>> not working.
>>>>
>>>> (same grc file works fine on Linux).
>>>>
>>>> I have tried this on both Windows 7 and 10 with no success.
>>>>
>>>>
>>>>
>>>> Can someone report if they had success with audio on Windows with these
>>>> binaries?
>>>>
>>>>
>>>>
>>>> Any ideas as to what else I can try?
>>>>
>>>>
>>>>
>>>> thanks
>>>>
>>>> Achilleas
>>>>
>>>> ___
>>>> 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] problems with windows binaries and audio

[Achilleas Anastasopoulos]

I also would like to report that a nice 440KHz cosine can be heard
perfectly OK with the default audio sink.

So now I have my doubts about the wav file source block instead of the
audio sink block

Any ideas?

thanks
Achilleas

On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> Hi Geof,
>
> thank you for your suggestions.
>
>
> Here is some more information from my Windows 7 running gnuradio binaries
> 3.7.10.1
>
> 1)
> When I use a simple wav file source with audio sink and without setting
> the "Device Name" entry I get the following output:
>
> INFO: Audio sink arch: windows
> gr::pagesize: no info; setting pagesize = 4096
> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>
> I can hear the sound but it is not coming out at the right speed/etc
> regardless of what sample rate I choose.
>
> So I tried the second method that Geof suggested: entering explicitly the
> device ID and/or the string representing the device's name.
>
> 2)
> Following Geof's advice I went to the "Device Manager" and the "Sounds,
> video and game controllers" section and I see a device "High Definition
> Audio Device". I clink on the "Details" tab and under the Property "device
> description" i see "High Definition Audio Device", so this is what I put as
> the string under the "Device Name" property of the audio sink.
>
> The output then is:
>
> INFO: Audio sink arch: windows
> INFO: Warning: waveOut device 'High Definition Audio Device' was not
> found, defaulting to WAVE_MAPPER
> gr::pagesize: no info; setting pagesize = 4096
> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
> aOaOaOaOaOaOaOaOaOa
> aOaOaOaOaOaOaOaOaOaO
>
> And the sound is the same as above.
>
> So my question is the following:
>
> How exactly can I find in the control panel the name of my audio device?
> Clearly the one I used ("High Definition Audio Device") was not found...
>
> Can it be that the problem is with the "wav file source" block and not
> with the audio sink block?
>
> Thanks
> Achilleas
>
>
> On Sun, Nov 6, 2016 at 5:12 PM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> The audio device in the windows audio sink can be used one of two ways,
>>
>> First is to use a number which is the device ID of the audio device, the
>> second is to enter a string representing the device's name.
>>
>> Realize, however, that there is no way to interactively iterate through
>> the list of available devices, so you'll have to figure out the ID's/names
>> yourself through the control panel.  It will give a warning in the output
>> log if what you entered is not found so you can least use trial and error.
>> If it can't find the device you entered, or you don't put an entry in, it
>> will use the WAVE_MAPPER device.
>>
>> Geof
>>
>>
>> On Sun, Nov 6, 2016 at 5:15 AM, Tarquin Roode <tarquin.ro...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>>
>>>
>>> Mine works, I am using 3.7.9.2
>>>
>>> So not a problem with the inary, it worked on Both Win 7 and Win 10
>>>
>>>
>>>
>>> I am not a home a he moment so don’t have  ss to my PC, bt I just
>>> plopped the Audio Sink down and it worked
>>>
>>>
>>>
>>> Ood luck
>>>
>>> arqun
>>>
>>>
>>>
>>> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+tarquin.roode=
>>> gmail@gnu.org] *On Behalf Of *Achilleas Anastasopoulos
>>> *Sent:* Saturday, 05 November 2016 2:46 AM
>>> *To:* Discuss-gnuradio@gnu.org
>>> *Subject:* [Discuss-gnuradio] problems with windows binaries and audio
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have installed the windows binaries from GCNDevelopment
>>>
>>> http://www.gcndevelopment.com/gnuradio/
>>>
>>>
>>>
>>> A simple test with a wav file and an audio sink does not seem to work.
>>>
>>> I have changed the config file to use audio - windows but still this is
>>> not working.
>>>
>>> (same grc file works fine on Linux).
>>>
>>> I have tried this on both Windows 7 and 10 with no success.
>>>
>>>
>>>
>>> Can someone report if they had success with audio on Windows with these
>>> binaries?
>>>
>>>
>>>
>>> Any ideas as to what else I can try?
>>>
>>>
>>>
>>> thanks
>>>
>>> Achilleas
>>>
>>> ___
>>> 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] problems with windows binaries and audio

[Achilleas Anastasopoulos]

Hi Geof,

thank you for your suggestions.


Here is some more information from my Windows 7 running gnuradio binaries
3.7.10.1

1)
When I use a simple wav file source with audio sink and without setting the
"Device Name" entry I get the following output:

INFO: Audio sink arch: windows
gr::pagesize: no info; setting pagesize = 4096
aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO

I can hear the sound but it is not coming out at the right speed/etc
regardless of what sample rate I choose.

So I tried the second method that Geof suggested: entering explicitly the
device ID and/or the string representing the device's name.

2)
Following Geof's advice I went to the "Device Manager" and the "Sounds,
video and game controllers" section and I see a device "High Definition
Audio Device". I clink on the "Details" tab and under the Property "device
description" i see "High Definition Audio Device", so this is what I put as
the string under the "Device Name" property of the audio sink.

The output then is:

INFO: Audio sink arch: windows
INFO: Warning: waveOut device 'High Definition Audio Device' was not found,
defaulting to WAVE_MAPPER
gr::pagesize: no info; setting pagesize = 4096
aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
aOaOaOaOaOaOaOaOaOa
aOaOaOaOaOaOaOaOaOaO

And the sound is the same as above.

So my question is the following:

How exactly can I find in the control panel the name of my audio device?
Clearly the one I used ("High Definition Audio Device") was not found...

Can it be that the problem is with the "wav file source" block and not with
the audio sink block?

Thanks
Achilleas


On Sun, Nov 6, 2016 at 5:12 PM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> The audio device in the windows audio sink can be used one of two ways,
>
> First is to use a number which is the device ID of the audio device, the
> second is to enter a string representing the device's name.
>
> Realize, however, that there is no way to interactively iterate through
> the list of available devices, so you'll have to figure out the ID's/names
> yourself through the control panel.  It will give a warning in the output
> log if what you entered is not found so you can least use trial and error.
> If it can't find the device you entered, or you don't put an entry in, it
> will use the WAVE_MAPPER device.
>
> Geof
>
>
> On Sun, Nov 6, 2016 at 5:15 AM, Tarquin Roode <tarquin.ro...@gmail.com>
> wrote:
>
>> Hi
>>
>>
>>
>> Mine works, I am using 3.7.9.2
>>
>> So not a problem with the inary, it worked on Both Win 7 and Win 10
>>
>>
>>
>> I am not a home a he moment so don’t have  ss to my PC, bt I just plopped
>> the Audio Sink down and it worked
>>
>>
>>
>> Ood luck
>>
>> arqun
>>
>>
>>
>> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+tarquin.roode=
>> gmail@gnu.org] *On Behalf Of *Achilleas Anastasopoulos
>> *Sent:* Saturday, 05 November 2016 2:46 AM
>> *To:* Discuss-gnuradio@gnu.org
>> *Subject:* [Discuss-gnuradio] problems with windows binaries and audio
>>
>>
>>
>> Hi,
>>
>>
>>
>> I have installed the windows binaries from GCNDevelopment
>>
>> http://www.gcndevelopment.com/gnuradio/
>>
>>
>>
>> A simple test with a wav file and an audio sink does not seem to work.
>>
>> I have changed the config file to use audio - windows but still this is
>> not working.
>>
>> (same grc file works fine on Linux).
>>
>> I have tried this on both Windows 7 and 10 with no success.
>>
>>
>>
>> Can someone report if they had success with audio on Windows with these
>> binaries?
>>
>>
>>
>> Any ideas as to what else I can try?
>>
>>
>>
>> thanks
>>
>> Achilleas
>>
>> ___
>> 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] problems with windows binaries and audio

[Achilleas Anastasopoulos]

Thanks Geof,

How exactly can I do what you are suggesting in GRC?
The only available controls on the audio sink is the bit rate and an entry
called "audio device".
What exactly should I enter in this entry?

thanks again,
Achilleas

On Sat, Nov 5, 2016 at 4:05 PM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> Achilleas,
>
> There are several others who had had success, so there must be something
> unique in your setup .  Do you have more then one audio device installed?
> If you do perhaps it is being routed to the wrong audio device.  The
> default is the windows wave mapper which normally should send it to your
> default audio device.  You can try specifying the audio device in the block
> settings.
>
> The audio -source- is not yet implemented but it will be in 3.7.10.2 when
> released
>
> Geof
>
>
> On Friday, November 4, 2016, Achilleas Anastasopoulos <anas...@umich.edu>
> wrote:
>
>> Hi,
>>
>> I have installed the windows binaries from GCNDevelopment
>> http://www.gcndevelopment.com/gnuradio/
>>
>> A simple test with a wav file and an audio sink does not seem to work.
>> I have changed the config file to use audio - windows but still this is
>> not working.
>> (same grc file works fine on Linux).
>> I have tried this on both Windows 7 and 10 with no success.
>>
>> Can someone report if they had success with audio on Windows with these
>> binaries?
>>
>> Any ideas as to what else I can try?
>>
>> thanks
>> Achilleas
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] problems with windows binaries and audio

[Achilleas Anastasopoulos]

Hi,

I have installed the windows binaries from GCNDevelopment
http://www.gcndevelopment.com/gnuradio/

A simple test with a wav file and an audio sink does not seem to work.
I have changed the config file to use audio - windows but still this is not
working.
(same grc file works fine on Linux).
I have tried this on both Windows 7 and 10 with no success.

Can someone report if they had success with audio on Windows with these
binaries?

Any ideas as to what else I can try?

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

Re: [Discuss-gnuradio] gr-cdma

[Achilleas Anastasopoulos]

Hi Elisabeta,

could you please post some more info:

what os are you working with
what is your gnuradio prefix
post the entire cdma_parameters.py file
also is this the latest version of gr-cdma from github?

thanks
Achilleas







On Sun, Jul 17, 2016 at 4:26 AM, Elisabetta . <elisabettascia...@hotmail.it>
wrote:

> Dear Achilleas Anastasopoulos,
>
> I have read your discussion with Frank Pinto and I think I have a similar
> problem. When I open a python session and do
>
>
> >>> from cdma import cdma_parameters
>
> It tells me:
>
> CDMA PARAMETERS : for adaptive coded modulation
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34,
> in 
> import cdma_parameters
>   File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py",
> line 110, in 
> local_header_obj =
> cdma.packet_header2(bits_per_header,length_tag_name,num_tag_name,
> header_mod.bits_per_symbol(),tcm_type_selector_default, "tcm_type")
> *AttributeError: 'module' object has no attribute 'packet_header2*'
>
>
> How can I fix the problem?
>
> I am using GNU Radio 3.7.5
>
> Thank you.
>
> Elisabetta Sciacca
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Good CDMA codes

[Achilleas Anastasopoulos]

BTW, take a look at gr-cdma.

https://github.com/anastas/gr-cdma

It is fully customizable so you can define a system with N=20 chips per
symbol
and provide your own such sequences.

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

Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior

[Achilleas Anastasopoulos]

Olivier,

the link you gave us does not work.
It says:

"
*That file isn’t here anymore *
Someone might’ve deleted the file or disabled the link
"

Achilleas

PS: I attach here a simple simulation grc file for you to "play" with.
If you are not clear about it there is no point going on with more
complicated designs.
I believe your "polyphase filter" does not work properly...

Once you have a working design on simulation you can move to USRPs...



On Fri, Jun 10, 2016 at 9:05 AM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> Olivier,
>
> can you point EXACTLY at the reference (page no, etc so we don't have to
> search)
> where it requires an RRC after the CPFSK and an RRC at the input of the
> receiver.
>
> Achilleas
>
> On Thu, Jun 9, 2016 at 3:04 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Why are you using the RRC filters?
>>
>> I hope you are realizing that filtering a CPFSK signal is not the same as
>> filtering its instantaneous frequency (which is a PAM signal with
>> rectangular pulses).
>> As a result, the next question is why in your poly-phase filter you are
>> using RRC filter taps?
>>
>> Achilleas
>>
>
>


test_cpfsk.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior

[Achilleas Anastasopoulos]

Olivier,

can you point EXACTLY at the reference (page no, etc so we don't have to
search)
where it requires an RRC after the CPFSK and an RRC at the input of the
receiver.

Achilleas

On Thu, Jun 9, 2016 at 3:04 PM, Achilleas Anastasopoulos <anas...@umich.edu>
wrote:

> Why are you using the RRC filters?
>
> I hope you are realizing that filtering a CPFSK signal is not the same as
> filtering its instantaneous frequency (which is a PAM signal with
> rectangular pulses).
> As a result, the next question is why in your poly-phase filter you are
> using RRC filter taps?
>
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior

[Achilleas Anastasopoulos]

Marcus,

any PAM signal with symbol rate R can be transmitted using bandwidth R/2

(essentially a sinc pulse; this is the case when you put 0 as the
roll-off factor of an RRC).

I thought your comment was not specifically for CPFSK,

but general transmission schemes thus my clarification.

If it is specific for CPFSK then kindly disregard the above.

Achilleas


> So, I will need you to *explain* how you can transport 1.somethingMb/s
> through a 625kHz wide channel if every time you use that channel to
> transmit a symbol, only one bit can get sent. How do these numbers add
> up for you? You've got a serious problem with your pulse shaping, there.


On Thu, Jun 9, 2016 at 3:04 PM, Achilleas Anastasopoulos <anas...@umich.edu>
wrote:

> Why are you using the RRC filters?
>
> I hope you are realizing that filtering a CPFSK signal is not the same as
> filtering its instantaneous frequency (which is a PAM signal with
> rectangular pulses).
> As a result, the next question is why in your poly-phase filter you are
> using RRC filter taps?
>
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CPFSK mod/demod + strange behavior

[Achilleas Anastasopoulos]

Why are you using the RRC filters?

I hope you are realizing that filtering a CPFSK signal is not the same as
filtering its instantaneous frequency (which is a PAM signal with
rectangular pulses).
As a result, the next question is why in your poly-phase filter you are
using RRC filter taps?

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

Re: [Discuss-gnuradio] grc probe broken after commit c85984f105106ff0a7e3b387d680e0f2f5884d55

[Achilleas Anastasopoulos]

I think I found out what is going wrong with this:

After the above commit, the compiled python files places the
"probe" definition blocks AFTER the definiotion of the thread.

See attached pythoon script:

In line 219 we have the definition:

-
def _freq_acq_est_probe():
while True:
val = self.blocks_probe_freq.level()
try:
self.set_freq_acq_est(val)
except AttributeError:
pass
time.sleep(1.0 / (10))
_freq_acq_est_thread = threading.Thread(target=_freq_acq_est_probe)
_freq_acq_est_thread.daemon = True
_freq_acq_est_thread.start()
self._fmaxt_static_text = forms.static_text(
parent=self.GetWin(),
value=self.fmaxt,
callback=self.set_fmaxt,
label="f_max (Hz)",
converter=forms.float_converter(),
)
--

while the probe block is defined only AFTER in line 263

---
self.blocks_probe_freq = blocks.probe_signal_f()



The situation is not the same before that commit...
I suppose this is a bug.

best
Achilleas





On Sun, May 15, 2016 at 11:49 PM, Achilleas Anastasopoulos <
anas...@umich.edu> wrote:

> Some of my grc apps in gr-cdma using probe blocks in grc are broken after
> the above commit.
> Not sure what the problem might be but when apps start they give the
> following error:
>
>
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
> self.run()
>   File "/usr/lib64/python2.7/threading.py", line 764, in run
> self.__target(*self.__args, **self.__kwargs)
>   File "/home/anastas/Dropbox/gr-cdma/apps/cdma_txrx.py", line 221, in
> _freq_acq_est_probe
> val = self.blocks_probe_freq.level()
>   File
> "/usr/local/lib64/python2.7/site-packages/gnuradio/gr/hier_block2.py", line
> 92, in __getattr__
> return getattr(self._impl, name)
> AttributeError: 'top_block_sptr' object has no attribute
> 'blocks_probe_freq'
>
>
> The commit log says:
>
> -
> commit c85984f105106ff0a7e3b387d680e0f2f5884d55
> Author: Sebastian Koslowski <koslow...@kit.edu>
> Date:   Wed Apr 27 14:19:04 2016 +0200
>
> grc: fix callback evaluation
> --
>
> but I am not a grc expert to understand what went wrong.
>
> Please let me know if you need more info about the erros.
>
> thanks
> Achilleas
>
>
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: cdma_txrx
# Author: Achilleas Anastasopoulos, Zhe Feng
# Generated: Mon May 16 11:53:42 2016
##

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"

import os
import sys
sys.path.append(os.environ.get('GRC_HIER_PATH', os.path.expanduser('~/.grc_gnuradio')))

from cdma_rx_hier import cdma_rx_hier  # grc-generated hier_block
from cdma_tx_hier import cdma_tx_hier  # grc-generated hier_block
from gnuradio import blocks
from gnuradio import channels
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.digital.utils import tagged_streams
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.wxgui import forms
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import cdma
import cdma.cdma_parameters as cp
import numpy ; numpy.random.seed(666)
import threading
import time
import wx


class cdma_txrx(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="cdma_txrx")

##
# Variables
##
self.N0est = N0est = 1.0
self.Esest = Esest = 1e-1
self.EsN0dB_est = EsN0dB_est = 10*numpy.log10( cp.epsilon+ abs(Esest)/ (abs(N0est)+cp.epsilon) ) 
self.symbol_rate = symbol_rate = 100e3
self.DataEsN0dBthreshold = DataEsN0dBthreshold = 10
self.DataEsN0dB_est = DataEsN0dB_est = EsN0dB_est + 10*numpy.log10( 1.0-cp.training_percent/100.0 ) 
self.samp_rate = samp_rate = symbol_rate*cp.chips_per_symbol
self.onoff_manual = onoff_manual = 1
self.onoff_auto = onoff_auto = 0 if DataEsN0dB_est>DataEsN0dBthreshold else 1
 

[Discuss-gnuradio] grc probe broken after commit c85984f105106ff0a7e3b387d680e0f2f5884d55

[Achilleas Anastasopoulos]

Some of my grc apps in gr-cdma using probe blocks in grc are broken after
the above commit.
Not sure what the problem might be but when apps start they give the
following error:


Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
self.run()
  File "/usr/lib64/python2.7/threading.py", line 764, in run
self.__target(*self.__args, **self.__kwargs)
  File "/home/anastas/Dropbox/gr-cdma/apps/cdma_txrx.py", line 221, in
_freq_acq_est_probe
val = self.blocks_probe_freq.level()
  File
"/usr/local/lib64/python2.7/site-packages/gnuradio/gr/hier_block2.py", line
92, in __getattr__
return getattr(self._impl, name)
AttributeError: 'top_block_sptr' object has no attribute 'blocks_probe_freq'


The commit log says:

-
commit c85984f105106ff0a7e3b387d680e0f2f5884d55
Author: Sebastian Koslowski 
Date:   Wed Apr 27 14:19:04 2016 +0200

grc: fix callback evaluation
--

but I am not a grc expert to understand what went wrong.

Please let me know if you need more info about the erros.

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

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Achilleas Anastasopoulos]

Geof,

out of curiosity:

In your setting do you see the errors produced in cases 2 and 3 (but the
program keeps running) or is it that you do not see these errors at all?

thanks
Achilleas

2) A simple flowgraph with noise, throttle, filter, fft display runs
perfectly with WX.
The following info is displayed:

Generating: 'C:\\Users\\anastas\\Dropbox\\gnuradio_examples\\top_block.py'

Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\anas
tas\Dropbox\gnuradio_examples\top_block.py

Using Volk machine: ssse3
fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdom: No such
file or
 directory
C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67:
GtkWarning: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate (text,
len,
NULL)' failed
  self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
¶: Invalid argument
gr::pagesize: no info; setting pagesize = 4096
¶: Invalid argument

>>> Done
--



On Wed, May 4, 2016 at 12:21 AM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> The initial GRC errors are known and for now occur on all the builds.
>
> The QT/GTK error is interesting.  Unfortunately, I'm still building blind
> for these older systems, in a month I'll have good direct access.  I will
> try to work it regardless.
>
> Thanks for the feedback!
>
>
>
>
> On Wed, May 4, 2016 at 4:24 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> I had partial success with these binaries:
>>
>> 1) GRC starts with the following warnings which I am not sure if they are
>> important:
>>
>> ---
>> setting gnuradio environment
>>
>> ** (python.exe:2060): WARNING **: Trying to register gtype
>> 'GMountMountFlags' as
>>  enum when in fact it is of type 'GFlags'
>>
>> ** (python.exe:2060): WARNING **: Trying to register gtype
>> 'GDriveStartFlags' as
>>  enum when in fact it is of type 'GFlags'
>>
>> ** (python.exe:2060): WARNING **: Trying to register gtype
>> 'GSocketMsgFlags' as
>> enum when in fact it is of type 'GFlags'
>> gnuradio-companion.py:122: GtkWarning: Could not find the icon
>> 'gnuradio-grc'. T
>> he 'hicolor' theme
>> was not found either, perhaps you need to install it.
>> You can get a copy from:
>> http://icon-theme.freedesktop.org/releases
>>   gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc',
>> 256, 0))
>>
>> <<< Welcome to GNU Radio Companion 3.7.9.2 >>>
>>
>> Preferences file: C:\Users\anastas/.gnuradio/grc.conf
>> Block paths:
>> C:\Users\anastas\.grc_gnuradio (C:\Users\anastas/.grc_gnuradio)
>> C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks
>> (C:\Program File
>> s\GNURadio-3.7\bin\..\share\gnuradio\grc\blocks)
>> ---
>>
>>
>> 2) A simple flowgraph with noise, throttle, filter, fft display runs
>> perfectly with WX.
>> The following info is displayed:
>> 
>> Generating: 'C:\\Users\\anastas\\Dropbox\\gnuradio_examples\\top_block.py'
>>
>> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
>> C:\Users\anas
>> tas\Dropbox\gnuradio_examples\top_block.py
>>
>> Using Volk machine: ssse3
>> fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdom: No such
>> file or
>>  directory
>> C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67:
>> GtkWarning: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate
>> (text, len,
>> NULL)' failed
>>   self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
>> ¶: Invalid argument
>> gr::pagesize: no info; setting pagesize = 4096
>> ¶: Invalid argument
>>
>> >>> Done
>> --
>>
>>
>> 3) However the QT version of the above simple flowgraph does not run; it
>> returns the error:
>> --
>> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
>> C:\Users\anas
>> tas\Dropbox\gnuradio_examples\top_block.py
>>
>> Using Volk machine: ssse3
>> fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdomC:\Program
>> Files\
>> GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67:
>> GtkWarning: gtk_t
>> ext_buffer_emit_insert: assertion 'g_utf8_validate (text, len, NULL)'
>> failed
>>   self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
>> : No su

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Achilleas Anastasopoulos]

I had partial success with these binaries:

1) GRC starts with the following warnings which I am not sure if they are
important:

---
setting gnuradio environment

** (python.exe:2060): WARNING **: Trying to register gtype
'GMountMountFlags' as
 enum when in fact it is of type 'GFlags'

** (python.exe:2060): WARNING **: Trying to register gtype
'GDriveStartFlags' as
 enum when in fact it is of type 'GFlags'

** (python.exe:2060): WARNING **: Trying to register gtype
'GSocketMsgFlags' as
enum when in fact it is of type 'GFlags'
gnuradio-companion.py:122: GtkWarning: Could not find the icon
'gnuradio-grc'. T
he 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
  gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc',
256, 0))

<<< Welcome to GNU Radio Companion 3.7.9.2 >>>

Preferences file: C:\Users\anastas/.gnuradio/grc.conf
Block paths:
C:\Users\anastas\.grc_gnuradio (C:\Users\anastas/.grc_gnuradio)
C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks (C:\Program
File
s\GNURadio-3.7\bin\..\share\gnuradio\grc\blocks)
---


2) A simple flowgraph with noise, throttle, filter, fft display runs
perfectly with WX.
The following info is displayed:

Generating: 'C:\\Users\\anastas\\Dropbox\\gnuradio_examples\\top_block.py'

Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\anas
tas\Dropbox\gnuradio_examples\top_block.py

Using Volk machine: ssse3
fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdom: No such
file or
 directory
C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67:
GtkWarning: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate (text,
len,
NULL)' failed
  self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
¶: Invalid argument
gr::pagesize: no info; setting pagesize = 4096
¶: Invalid argument

>>> Done
--


3) However the QT version of the above simple flowgraph does not run; it
returns the error:
--
Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\anas
tas\Dropbox\gnuradio_examples\top_block.py

Using Volk machine: ssse3
fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdomC:\Program
Files\
GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67: GtkWarning:
gtk_t
ext_buffer_emit_insert: assertion 'g_utf8_validate (text, len, NULL)' failed
  self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
: No such file or directory

>>> Done
-

thanks
Achilleas




On Tue, May 3, 2016 at 5:05 PM, Geof Nieboer  wrote:

> All,
>
> An updated set of windows binaries and build scripts have been posted.
> Quick summary:
> 1- Added gqrx to package
> 2- Patched 2 x issues which would cause the generic version to crash on
> non-AVX systems (one in volk, one in FFTW)
> 3- Added gr-newmod to package
>
> Plus a number of improvements to make the scripts more robust.
>
> Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
> Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>
> A couple gqrx known bugs:
> 1- Toolbar icons do not appear (our Qt5 issue)
> 2- Switching a USRP to another modulation will cause a crash (upstream UHD)
> 3- Switching between a RTL-SDR device and a USRP device will cause a crash
> (upstream gqrx)
>
> Cheers,
>
> Geof
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Geof,

thanks for the suggestions.

I get the same problem even when i run volk_profile.exe
which means that the problem is pretty basic...

Anyway after searching around on the web i see that everyone suggests a
different thing so most probably no one knows what the real issue is...

I am giving up on that for now...

thank you,
Achilleas



On Mon, Apr 18, 2016 at 12:46 PM, Geof Nieboer <gnieb...@corpcomm.net>
wrote:

> No that should be it.  I just doublechecked on my plain vanilla Win7 VM
> that it worked and that VM has nothing installed but SP1 and security
> updates.
>
> OK... let's try this... go to the GR python prompt and try to import
> different gnuradio libraries and see if maybe we can find a pattern?  I.E.
> from gnuradio import fft
> from gnuradio import audio
> from gnuradio import wxgui
> {keep going}
>
>
>
> On Mon, Apr 18, 2016 at 6:45 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Geof,
>>
>> thanks again for your help.
>> Indeed I am running SP1.
>>
>> Here is what I have on my computer at this point:
>> I have a bunch of applications (seen in the control
>> panel/Programs/Programs and Features)
>> named:
>>
>> Microsoft Visual C++ 2005 Redistributable (x64)
>> Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022
>> Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161
>> Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
>> Microsoft Visual Studio 2010 Tools for Office Runtime (x64)
>>
>> I just downloaded and installed the following
>>
>> Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026
>> Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.23026
>>
>>
>> but i get the same error.
>> Is there anything else that is required?
>>
>> thanks
>> Achilleas
>>
>>
>>
>>
>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Geof,

thanks again for your help.
Indeed I am running SP1.

Here is what I have on my computer at this point:
I have a bunch of applications (seen in the control panel/Programs/Programs
and Features)
named:

Microsoft Visual C++ 2005 Redistributable (x64)
Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022
Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161
Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219
Microsoft Visual Studio 2010 Tools for Office Runtime (x64)

I just downloaded and installed the following

Microsoft Visual C++ 2015 Redistributable (x64) - 14.0.23026
Microsoft Visual C++ 2015 Redistributable (x86) - 14.0.23026


but i get the same error.
Is there anything else that is required?

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

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

I have resolved one out of two issues.
The problem with IESHIMS.DLL is resolved (it is in the internet explorer
directory and all i needed was to add this to the path).

Still don't know how to resolve the DCOMP.DLL issue.

thanks again
Achilleas

On Mon, Apr 18, 2016 at 8:35 AM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> Geof,
>
> thanks for your help.
> There are two dll's missing as reported by the program.
> Those are:
>
> DCOMP.DLL
> IESHIMS.DLL
>
> any help on how to move forward is appreciated,
>
> thanks again
> Achilleas
>
>
>
>
>
> On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> Achilleas,
>>
>> To troubleshoot that problem:
>> 1- download a program called "Dependency Walker",  (www.
>> *dependencywalker*.com/)
>> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
>> default settings.  It will give a dialog saying something wasn't found,
>> that's normal.
>> 3- Go to Options->Configure Module Search Order
>> 4- On the bottom right of the window, go to "Browse" and
>> select C:\Program Files\GNURadio-3.7\bin and click "Add Directory", then
>> say "Yes"
>> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>>
>> Now on the top left you will see huge tree of all the dependencies...
>> something in there is missing.  IGNORE the entries that look like
>> "API_MS_WIN...", those are fine to be missing.
>>
>> Please tell me what you are missing.
>>
>> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime
>> that is missing.  If the missing entries are "UCRTBASE.DLL",
>> "MSVCP140.DLL", and VCRUNTIME140.DLL", that is the problem.  That's a
>> download from Microsoft here:
>> https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>
>> Geof
>>
>>
>> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Some more information about the problem I have running the installed
>>> version.
>>>
>>> In the GNYRADIO command prompt shell I run python and then
>>> >> from gnuradio import filter
>>>
>>>
>>> and I get the following:
>>>
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
>>> .py", line 32, in 
>>> from filter_swig import *
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 28, in 
>>> _filter_swig = swig_import_helper()
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 24, in swig_import_helper
>>> _mod = imp.load_module('_filter_swig', fp, pathname, description)
>>> ImportError: DLL load failed with error code -1073741795
>>>
>>> =
>>>
>>> Any help is welcome,
>>>
>>> thanks
>>> Achilleas
>>>
>>>
>>> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
>>>> I installed the binary files
>>>> gnuradio_3.7.9.2_win64.msi
>>>> on a Win-8 machine succefullyon the default directory.
>>>>
>>>> After running gnuradio-companion file from the Gnuradio 3.7
>>>> start menu folder I see a command window opening with message
>>>> "setting gnuradio environment",
>>>> then a couple of warnings of the sort:
>>>>
>>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>>> 'GMountMountFlags' as
>>>>  enum when in fact it is of type 'GFlags'
>>>>
>>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>>> 'GDriveStartFlags' as
>>>>  enum when in fact it is of type 'GFlags'
>>>>
>>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>>> 'GSocketMsgFlags' as
>>>> enum when in fact it is of type 'GFlags'
>>>>
>>>>
>>>> and then the "standard" gnuradio window appears with the import-error
>>>> warning
>>>>
>>>>
>>>> 
>>>> Cannot import gnuradio.
>>>>
>>>> Is the python path environment variable set correctly?
>>>> All OS: PYTHONPATH
>>>>
>>>> Is the library path environment variable set correctly?
>>>> Linux: LD_LIBRARY_PATH
>>>> Windows: PATH
>>>> MacOSX: DYLD_LIBRARY_PATH
>>>>
>>>>
>>>> (DLL load failed with error code -1073741795)
>>>> ---
>>>>
>>>>
>>>> any thoughts as to what is going wrong?
>>>>
>>>> thanks
>>>> Achilleas
>>>>
>>>
>>>
>>> ___
>>> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Also a correction:

I am running Windows 7 (not 8 as I erroneously reported)

thanks again
Achilleas

On Mon, Apr 18, 2016 at 8:35 AM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> Geof,
>
> thanks for your help.
> There are two dll's missing as reported by the program.
> Those are:
>
> DCOMP.DLL
> IESHIMS.DLL
>
> any help on how to move forward is appreciated,
>
> thanks again
> Achilleas
>
>
>
>
>
> On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> Achilleas,
>>
>> To troubleshoot that problem:
>> 1- download a program called "Dependency Walker",  (www.
>> *dependencywalker*.com/)
>> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
>> default settings.  It will give a dialog saying something wasn't found,
>> that's normal.
>> 3- Go to Options->Configure Module Search Order
>> 4- On the bottom right of the window, go to "Browse" and
>> select C:\Program Files\GNURadio-3.7\bin and click "Add Directory", then
>> say "Yes"
>> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>>
>> Now on the top left you will see huge tree of all the dependencies...
>> something in there is missing.  IGNORE the entries that look like
>> "API_MS_WIN...", those are fine to be missing.
>>
>> Please tell me what you are missing.
>>
>> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime
>> that is missing.  If the missing entries are "UCRTBASE.DLL",
>> "MSVCP140.DLL", and VCRUNTIME140.DLL", that is the problem.  That's a
>> download from Microsoft here:
>> https://www.microsoft.com/en-us/download/details.aspx?id=48145
>>
>> Geof
>>
>>
>> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Some more information about the problem I have running the installed
>>> version.
>>>
>>> In the GNYRADIO command prompt shell I run python and then
>>> >> from gnuradio import filter
>>>
>>>
>>> and I get the following:
>>>
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
>>> .py", line 32, in 
>>> from filter_swig import *
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 28, in 
>>> _filter_swig = swig_import_helper()
>>>   File "C:\Program
>>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>>> wig.py", line 24, in swig_import_helper
>>> _mod = imp.load_module('_filter_swig', fp, pathname, description)
>>> ImportError: DLL load failed with error code -1073741795
>>>
>>> =
>>>
>>> Any help is welcome,
>>>
>>> thanks
>>> Achilleas
>>>
>>>
>>> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
>>>> I installed the binary files
>>>> gnuradio_3.7.9.2_win64.msi
>>>> on a Win-8 machine succefullyon the default directory.
>>>>
>>>> After running gnuradio-companion file from the Gnuradio 3.7
>>>> start menu folder I see a command window opening with message
>>>> "setting gnuradio environment",
>>>> then a couple of warnings of the sort:
>>>>
>>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>>> 'GMountMountFlags' as
>>>>  enum when in fact it is of type 'GFlags'
>>>>
>>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>>> 'GDriveStartFlags' as
>>>>  enum when in fact it is of type 'GFlags'
>>>>
>>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>>> 'GSocketMsgFlags' as
>>>> enum when in fact it is of type 'GFlags'
>>>>
>>>>
>>>> and then the "standard" gnuradio window appears with the import-error
>>>> warning
>>>>
>>>>
>>>> 
>>>> Cannot import gnuradio.
>>>>
>>>> Is the python path environment variable set correctly?
>>>> All OS: PYTHONPATH
>>>>
>>>> Is the library path environment variable set correctly?
>>>> Linux: LD_LIBRARY_PATH
>>>> Windows: PATH
>>>> MacOSX: DYLD_LIBRARY_PATH
>>>>
>>>>
>>>> (DLL load failed with error code -1073741795)
>>>> ---
>>>>
>>>>
>>>> any thoughts as to what is going wrong?
>>>>
>>>> thanks
>>>> Achilleas
>>>>
>>>
>>>
>>> ___
>>> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Geof,

thanks for your help.
There are two dll's missing as reported by the program.
Those are:

DCOMP.DLL
IESHIMS.DLL

any help on how to move forward is appreciated,

thanks again
Achilleas





On Mon, Apr 18, 2016 at 12:17 AM, Geof Nieboer <gnieb...@corpcomm.net>
wrote:

> Achilleas,
>
> To troubleshoot that problem:
> 1- download a program called "Dependency Walker",  (www.*dependencywalker*
> .com/)
> 2- Then with that, open the _filter_swig.pyd file located at C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter if you used the
> default settings.  It will give a dialog saying something wasn't found,
> that's normal.
> 3- Go to Options->Configure Module Search Order
> 4- On the bottom right of the window, go to "Browse" and select C:\Program
> Files\GNURadio-3.7\bin and click "Add Directory", then say "Yes"
> 5- Repeat that for C:\Program Files\GNURadio-3.7\gr-python27/DLLs
>
> Now on the top left you will see huge tree of all the dependencies...
> something in there is missing.  IGNORE the entries that look like
> "API_MS_WIN...", those are fine to be missing.
>
> Please tell me what you are missing.
>
> I suspect since you are running Windows 8, it's the MSVC 14.0 runtime that
> is missing.  If the missing entries are "UCRTBASE.DLL", "MSVCP140.DLL", and
> VCRUNTIME140.DLL", that is the problem.  That's a download from Microsoft
> here: https://www.microsoft.com/en-us/download/details.aspx?id=48145
>
> Geof
>
>
> On Mon, Apr 18, 2016 at 3:16 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Some more information about the problem I have running the installed
>> version.
>>
>> In the GNYRADIO command prompt shell I run python and then
>> >> from gnuradio import filter
>>
>>
>> and I get the following:
>>
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
>> .py", line 32, in 
>> from filter_swig import *
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>> wig.py", line 28, in 
>> _filter_swig = swig_import_helper()
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
>> wig.py", line 24, in swig_import_helper
>> _mod = imp.load_module('_filter_swig', fp, pathname, description)
>> ImportError: DLL load failed with error code -1073741795
>>
>> =
>>
>> Any help is welcome,
>>
>> thanks
>> Achilleas
>>
>>
>> On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> I installed the binary files
>>> gnuradio_3.7.9.2_win64.msi
>>> on a Win-8 machine succefullyon the default directory.
>>>
>>> After running gnuradio-companion file from the Gnuradio 3.7
>>> start menu folder I see a command window opening with message
>>> "setting gnuradio environment",
>>> then a couple of warnings of the sort:
>>>
>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>> 'GMountMountFlags' as
>>>  enum when in fact it is of type 'GFlags'
>>>
>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>> 'GDriveStartFlags' as
>>>  enum when in fact it is of type 'GFlags'
>>>
>>> ** (python.exe:5392): WARNING **: Trying to register gtype
>>> 'GSocketMsgFlags' as
>>> enum when in fact it is of type 'GFlags'
>>>
>>>
>>> and then the "standard" gnuradio window appears with the import-error
>>> warning
>>>
>>>
>>> 
>>> Cannot import gnuradio.
>>>
>>> Is the python path environment variable set correctly?
>>> All OS: PYTHONPATH
>>>
>>> Is the library path environment variable set correctly?
>>> Linux: LD_LIBRARY_PATH
>>> Windows: PATH
>>> MacOSX: DYLD_LIBRARY_PATH
>>>
>>>
>>> (DLL load failed with error code -1073741795)
>>> ---
>>>
>>>
>>> any thoughts as to what is going wrong?
>>>
>>> thanks
>>> Achilleas
>>>
>>
>>
>> ___
>> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

Some more information about the problem I have running the installed
version.

In the GNYRADIO command prompt shell I run python and then
>> from gnuradio import filter


and I get the following:

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\__init__
.py", line 32, in 
from filter_swig import *
  File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
wig.py", line 28, in 
_filter_swig = swig_import_helper()
  File "C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\filter\filter_s
wig.py", line 24, in swig_import_helper
_mod = imp.load_module('_filter_swig', fp, pathname, description)
ImportError: DLL load failed with error code -1073741795

=

Any help is welcome,

thanks
Achilleas


On Sun, Apr 17, 2016 at 2:07 PM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> I installed the binary files
> gnuradio_3.7.9.2_win64.msi
> on a Win-8 machine succefullyon the default directory.
>
> After running gnuradio-companion file from the Gnuradio 3.7
> start menu folder I see a command window opening with message
> "setting gnuradio environment",
> then a couple of warnings of the sort:
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GMountMountFlags' as
>  enum when in fact it is of type 'GFlags'
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as
>  enum when in fact it is of type 'GFlags'
>
> ** (python.exe:5392): WARNING **: Trying to register gtype
> 'GSocketMsgFlags' as
> enum when in fact it is of type 'GFlags'
>
>
> and then the "standard" gnuradio window appears with the import-error
> warning
>
>
> 
> Cannot import gnuradio.
>
> Is the python path environment variable set correctly?
> All OS: PYTHONPATH
>
> Is the library path environment variable set correctly?
> Linux: LD_LIBRARY_PATH
> Windows: PATH
> MacOSX: DYLD_LIBRARY_PATH
>
>
> (DLL load failed with error code -1073741795)
> ---
>
>
> any thoughts as to what is going wrong?
>
> thanks
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Achilleas Anastasopoulos]

I installed the binary files
gnuradio_3.7.9.2_win64.msi
on a Win-8 machine succefullyon the default directory.

After running gnuradio-companion file from the Gnuradio 3.7
start menu folder I see a command window opening with message
"setting gnuradio environment",
then a couple of warnings of the sort:

** (python.exe:5392): WARNING **: Trying to register gtype
'GMountMountFlags' as
 enum when in fact it is of type 'GFlags'

** (python.exe:5392): WARNING **: Trying to register gtype
'GDriveStartFlags' as
 enum when in fact it is of type 'GFlags'

** (python.exe:5392): WARNING **: Trying to register gtype
'GSocketMsgFlags' as
enum when in fact it is of type 'GFlags'


and then the "standard" gnuradio window appears with the import-error
warning



Cannot import gnuradio.

Is the python path environment variable set correctly?
All OS: PYTHONPATH

Is the library path environment variable set correctly?
Linux: LD_LIBRARY_PATH
Windows: PATH
MacOSX: DYLD_LIBRARY_PATH


(DLL load failed with error code -1073741795)
---


any thoughts as to what is going wrong?

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