Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

[W3AXL Patrick]

Hi Kyeong

 

This is running a GRC file inside of GNURadio Companion. Something is
indeed broken.

 

I simply ran the Win64 installer for GNURadio from the Windows builds site
linked by the GNURadio wiki. I recall last year I had this same issue on my
Windows system and gave up using GRC on Windows because of it. It’s a pain
to load up my linux box every time I want to use GNURadio though.

 

Thanks for the input

 

Patrick

 

From: Kyeong Su Shin  
Sent: Monday, June 24, 2019 9:52 PM
To: W3AXL Patrick ; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

 

Hello Patrick:

 

Are you running a GNU Radio Python code? Or, are you running a GRC file
using GNU Radio Companion?

 

If you are running a Python code generated from GNU Radio Companion, you
should be running that code using "GNU Radio Command Prompt" (which comes
with correct library PATH variables). 

 

If you are running a GRC file using GNU Radio Companion, then I guess
something is broken..

 

Also, please note that the GNU Radio Windows distribution comes with its
own Python interpreter (which you can use by using GNU Radio Command
Prompt", and does not touch or use the Python interpreter on your system.

 

Regards,

Kyeong Su Shin

 

  _  

보낸 사람: W3AXL Patrick mailto:patr...@w3axl.com> >
대신 Discuss-gnuradio mailto:discuss-gnuradio-
bounces+ksshin=postech.ac...@gnu.org> >
보낸 날짜: 2019년 6월 25일 화요일 오전 10:50:11
받는 사람: discuss-gnuradio@gnu.org  
제목: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR 

 

Hi all on the list,

 

I’ve been tearing my hair out trying to solve an issue I’m having with a
clean install of GNURadio using the Windows builds.

 

When trying to run a simple flowgraph, with an RTL-SDR source connected to
a frequency sink, I receive the following traceback:

 

Traceback (most recent call last):

  File "C:\Users\Patrick\Documents\top_block.py", line 29, in 

import osmosdr

  File "C:\Program Files\GNURadio-3.7\lib\site-
packages\osmosdr\__init__.py", line 26, in 

from osmosdr_swig import *

  File "C:\Program Files\GNURadio-3.7\lib\site-
packages\osmosdr\osmosdr_swig.py", line 17, in 

_osmosdr_swig = swig_import_helper()

  File "C:\Program Files\GNURadio-3.7\lib\site-
packages\osmosdr\osmosdr_swig.py", line 16, in swig_import_helper

return importlib.import_module('_osmosdr_swig')

  File "C:\Program Files\GNURadio-3.7\gr-
python27\lib\importlib\__init__.py", line 37, in import_module

__import__(name)

ImportError: No module named _osmosdr_swig

 

I think this is a problem with my PATH, or with the installation of
GNURadio, but I can’t figure out how to fix it. There is almost no info on
anyone else having errors like this with GRC so I’m stumped.

 

Additionally, on this clean install of GNURadio, I receive over a hundred
of errors similar to this one during startup of GRC:

 

Warning: Block with key "xxx" already exists.

Ignoring: C:\Program Files\GNURadio-
3.7\share\gnuradio\grc\blocks\xxx.xml

 

I feel as if these two issues might be related in some way.

 

I would appreciate any help. My system is running Win10 and I have the
latest Python 2.7 installed.

 

Thanks to all,

 

Patrick

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

Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

[Kyeong Su Shin]

Hello Patrick:


Are you running a GNU Radio Python code? Or, are you running a GRC file using 
GNU Radio Companion?


If you are running a Python code generated from GNU Radio Companion, you should 
be running that code using "GNU Radio Command Prompt" (which comes with correct 
library PATH variables).


If you are running a GRC file using GNU Radio Companion, then I guess something 
is broken..


Also, please note that the GNU Radio Windows distribution comes with its own 
Python interpreter (which you can use by using GNU Radio Command Prompt", and 
does not touch or use the Python interpreter on your system.


Regards,

Kyeong Su Shin



보낸 사람: W3AXL Patrick  대신 Discuss-gnuradio 

보낸 날짜: 2019년 6월 25일 화요일 오전 10:50:11
받는 사람: discuss-gnuradio@gnu.org
제목: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR


Hi all on the list,



I’ve been tearing my hair out trying to solve an issue I’m having with a clean 
install of GNURadio using the Windows builds.



When trying to run a simple flowgraph, with an RTL-SDR source connected to a 
frequency sink, I receive the following traceback:



Traceback (most recent call last):

  File "C:\Users\Patrick\Documents\top_block.py", line 29, in 

import osmosdr

  File "C:\Program Files\GNURadio-3.7\lib\site-packages\osmosdr\__init__.py", 
line 26, in 

from osmosdr_swig import *

  File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 17, in 


_osmosdr_swig = swig_import_helper()

  File "C:\Program 
Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 16, in 
swig_import_helper

return importlib.import_module('_osmosdr_swig')

  File "C:\Program Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", 
line 37, in import_module

__import__(name)

ImportError: No module named _osmosdr_swig



I think this is a problem with my PATH, or with the installation of GNURadio, 
but I can’t figure out how to fix it. There is almost no info on anyone else 
having errors like this with GRC so I’m stumped.



Additionally, on this clean install of GNURadio, I receive over a hundred of 
errors similar to this one during startup of GRC:



Warning: Block with key "xxx" already exists.

Ignoring: C:\Program 
Files\GNURadio-3.7\share\gnuradio\grc\blocks\xxx.xml



I feel as if these two issues might be related in some way.



I would appreciate any help. My system is running Win10 and I have the latest 
Python 2.7 installed.



Thanks to all,



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

[Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

[W3AXL Patrick]

Hi all on the list,

 

I've been tearing my hair out trying to solve an issue I'm having with a
clean install of GNURadio using the Windows builds.

 

When trying to run a simple flowgraph, with an RTL-SDR source connected to a
frequency sink, I receive the following traceback:

 

Traceback (most recent call last):

  File "C:\Users\Patrick\Documents\top_block.py", line 29, in 

import osmosdr

  File "C:\Program
Files\GNURadio-3.7\lib\site-packages\osmosdr\__init__.py", line 26, in


from osmosdr_swig import *

  File "C:\Program
Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 17, in


_osmosdr_swig = swig_import_helper()

  File "C:\Program
Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 16, in
swig_import_helper

return importlib.import_module('_osmosdr_swig')

  File "C:\Program
Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 37, in
import_module

__import__(name)

ImportError: No module named _osmosdr_swig

 

I think this is a problem with my PATH, or with the installation of
GNURadio, but I can't figure out how to fix it. There is almost no info on
anyone else having errors like this with GRC so I'm stumped.

 

Additionally, on this clean install of GNURadio, I receive over a hundred of
errors similar to this one during startup of GRC:

 

Warning: Block with key "xxx" already exists.

Ignoring: C:\Program
Files\GNURadio-3.7\share\gnuradio\grc\blocks\xxx.xml

 

I feel as if these two issues might be related in some way.

 

I would appreciate any help. My system is running Win10 and I have the
latest Python 2.7 installed.

 

Thanks to all,

 

Patrick

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

[Discuss-gnuradio] [GSoC19] Block header parsing tool: Blog update

[Arpit Gupta]

Hello everyone,
I have updated the blog  for the Week
4 updates and the tasks for week 5. Here
 is the link to the updated
Github project.

Week 4 updates:
- Parse the I/O signature from the header implementation file.
- Write python unit-tests for the core blocktool API.
- Modify the CLI to use 'file_path' as an argument only.
- Parse the default values for the arguments of make function.
- Write a JSON generator.

Tasks for Week 5:
- Parse the I/O signature from the header implementation file.
- Implement a YAML generator to create YAML files from the parsed output
data.
- Modify the tool to parse the complete directory of the header files with
'directory_path' as the input.

Link to the parser branch  in
the forked repository.

Thanks,
Arpit Gupta
Indian Institute of Technology Roorkee
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC19] Weekly report of Verilog simulation phase 1 week 4

[Bowen Hu]

Hi all,
​
You can find my weekly report 
here(https://b0wen-hu.github.io/2019/06/23/GSoC-weekly-report-P1W4/).​

​
The following content is the abstract  of report, please find the full report 
at the link above.​
​​
## Progress this week
I planned to work on the parse function this week, but this week's two major 
exams took me more time than I expected. I did not finish it.

Fortunately, I got good suggestions on the mailing list from Sébastien this 
week, where he suggested that it could be done by forcing the the port names 
and using a defined interface like AXI4 stream, and I agree with him.

## Plan next week
Glance over AXI4 stream protocol, and implement this interface. The parse 
function was delayed until later.

## Issue(s)
The parse function was delayed until I found a better solution.
​
Best regards,​
Bowen​

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

[Discuss-gnuradio] Router (or IP decapsulation)in GNU Radio?

[mehtap özkan]

Dear All,
 I have recorded a RF Signal for reverse engineering. I found it is a BPSK
modulated  HDLC/ Frame Relay data.
The recovered data itself  is IP encapsulated, exactly as explained in:
 https://www.tutorialspoint.com/ipv4/ipv4_packet_structure.htm

The data itself is UDP.
 In summary the recovered data is formatted as:
IP Header+UDP Header+Payload.
The source IP and destination IP changes from frame to frame.
My networking knowledge is quite limited. What should I do to send the
packets to their intended destination IP?
 Is this function a router, which blocks should I use?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Difference in Spectrum Analysis between Wx and Qt?

[Martijn Scale]

Hi Marcus,

Thanks for your reply, I connected a File Sink and later sourced the file into 
both Qt and Wx instruments, with the same result.
I expected this to happen, as for the hardware setup I did not change a thing 
between Qt and Wx measurements, it was just a matter of switching between Qt 
and Wx in GRC and disabling the non-needed instruments.

So I just added SDRSharp into the equation, which showed an AM signal on top of 
the carrier as well, so that indicates that the Qt instruments are right.
Next, fiddled with the Amplitude of the Signal generator, when I reduced the 
amplitude with further 30 dB, the AM signal disappeared.

Although the carrier-level did not reduce a whole lot (maybe some 8 dB), I 
guess the setup was creating a lot of intermodulation distortion. That's fixed 
now.

Still it is interesting that Wx did not pickup that AM modulation... If you 
would be interested I can share the IQ-file

No more reason to stay with Wx though, I'll keep in track with the community 

Thanks, case closed, Martijn

-Original Message-
From: Müller, Marcus (CEL)  
Sent: maandag 24 juni 2019 15:05
To: discuss-gnuradio@gnu.org; theje...@hotmail.com
Subject: Re: [Discuss-gnuradio] Difference in Spectrum Analysis between Wx and 
Qt?

Hi Martijn,

Can you please use a file sink to record the signal, so that you can
verify that it's different when visualized with Qt and Wx?

Because: there might be a scaling difference between Qt and Wx GUI, but
the math should really be the same inside. I'd hence assume that
there's really a different signal causing the different pictures.

Just to pull one tooth right away: staying with WX will force you to
stay on GNU Radio release 3.7 forever, and within that, using a
component that nobody in the GNU Radio developer community knows how to
maintain. So, I'd still really recommend moving away from WX.

Best regards,
Marcus

On Mon, 2019-06-24 at 12:04 +, Martijn Scale wrote:
> I’m using GNU Radio v 3.7.11 on Windows 10, 1903 with Intel i5-3550 CPU and 
> on Linux Ubuntu 18.04, with i7-3720 CPU. Both have 16GB mem.
> Further, I have connected a HackRF One with firmware 2017.02.1. To the HackRF 
> One I have connected a Siglent SDG1025 Waveform generator, with external GPS 
> disciplined oscillator. I used a DC blocker and 30 db attenuation between de 
> generator and the HackRF One.
>  
> The waveform generator generates a sinewave of 9.76 MHz, I have setup GNU 
> Radio with a osmocom Source with 2M sps and Frequency of 10.3 MHz.
> To the osmocom Source I have connected first a QT GUI Frequency Sink.
>  
> To my surprise I see an AM modulated signal of around 70 kHz on the 9.76 Mhz 
> carrier. I have tried many things, removed the external oscillator and used 
> the internal one, tried a different waveform generator (HP33120A), but same 
> result, on both machines.
>  
> Today by coincidence I found that there is NO AM modulated signal when using 
> WX GUI and the WX GUI FFT Sink.
>  
> Anyone any thoughts on this? Qt will prevail over Wx in the future, but for 
> me this is unexpected behavior and I would like to stick to Wx.
>  
> 
> ___
> 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] Difference in Spectrum Analysis between Wx and Qt?

[CEL]

Hi Martijn,

Can you please use a file sink to record the signal, so that you can
verify that it's different when visualized with Qt and Wx?

Because: there might be a scaling difference between Qt and Wx GUI, but
the math should really be the same inside. I'd hence assume that
there's really a different signal causing the different pictures.

Just to pull one tooth right away: staying with WX will force you to
stay on GNU Radio release 3.7 forever, and within that, using a
component that nobody in the GNU Radio developer community knows how to
maintain. So, I'd still really recommend moving away from WX.

Best regards,
Marcus

On Mon, 2019-06-24 at 12:04 +, Martijn Scale wrote:
> I’m using GNU Radio v 3.7.11 on Windows 10, 1903 with Intel i5-3550 CPU and 
> on Linux Ubuntu 18.04, with i7-3720 CPU. Both have 16GB mem.
> Further, I have connected a HackRF One with firmware 2017.02.1. To the HackRF 
> One I have connected a Siglent SDG1025 Waveform generator, with external GPS 
> disciplined oscillator. I used a DC blocker and 30 db attenuation between de 
> generator and the HackRF One.
>  
> The waveform generator generates a sinewave of 9.76 MHz, I have setup GNU 
> Radio with a osmocom Source with 2M sps and Frequency of 10.3 MHz.
> To the osmocom Source I have connected first a QT GUI Frequency Sink.
>  
> To my surprise I see an AM modulated signal of around 70 kHz on the 9.76 Mhz 
> carrier. I have tried many things, removed the external oscillator and used 
> the internal one, tried a different waveform generator (HP33120A), but same 
> result, on both machines.
>  
> Today by coincidence I found that there is NO AM modulated signal when using 
> WX GUI and the WX GUI FFT Sink.
>  
> Anyone any thoughts on this? Qt will prevail over Wx in the future, but for 
> me this is unexpected behavior and I would like to stick to Wx.
>  
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] Difference in Spectrum Analysis between Wx and Qt?

[Martijn Scale]

I'm using GNU Radio v 3.7.11 on Windows 10, 1903 with Intel i5-3550 CPU and on 
Linux Ubuntu 18.04, with i7-3720 CPU. Both have 16GB mem.
Further, I have connected a HackRF One with firmware 2017.02.1. To the HackRF 
One I have connected a Siglent SDG1025 Waveform generator, with external GPS 
disciplined oscillator. I used a DC blocker and 30 db attenuation between de 
generator and the HackRF One.

The waveform generator generates a sinewave of 9.76 MHz, I have setup GNU Radio 
with a osmocom Source with 2M sps and Frequency of 10.3 MHz.
To the osmocom Source I have connected first a QT GUI Frequency Sink.

To my surprise I see an AM modulated signal of around 70 kHz on the 9.76 Mhz 
carrier. I have tried many things, removed the external oscillator and used the 
internal one, tried a different waveform generator (HP33120A), but same result, 
on both machines.

Today by coincidence I found that there is NO AM modulated signal when using WX 
GUI and the WX GUI FFT Sink.

Anyone any thoughts on this? Qt will prevail over Wx in the future, but for me 
this is unexpected behavior and I would like to stick to Wx.

[cid:image004.png@01D52A95.CBEF77E0][cid:image003.png@01D52A95.9B79C480]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Combining blocks

[CEL]

Hi Tom,

that's **exactly** what hierarchical blocks are for.

Make a new flow graph. Set the flow graph type to "Hier Block" (instead
of "Qt Gui") in the "Options" block, and __give it a good "Dd" and
"Title"__. You should probably also define a descriptive "Category
Name", e.g. "[Resamplers]" if your block is a resampler.

Add "Pad Sink"s / "Source"s for the out- and inputs of that flow graph.
Use "Parameter" blocks to define variables that get an entry field in
the block properties.

When done, hit the "generate" button. You can then use it in your main
flow graph like any other block.

Best regards,
Marcus

On Mon, 2019-06-24 at 11:52 +, tom sutherland wrote:
> I have a GNURadio Companion design that is getting large. It has many 
> sections that are repeated. Is there a way to combine a group of blocks into 
> a single block and allow you to just put down the single block and not show 
> all the sub-blocks below it? Preferably without writing everything in python.
> Thanks…Tom
>  
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] How to introduce regex in GNU Radio block?

[Bowen Hu]

Hi Sébastien,

Thank you for your reply. I am really glad to know that what I am doing is 
meaningful !!

It will be much easier if the module use defined interface. I will try to 
implement this block the way as you suggested.

On the other hand, I've ever thought about use the XML file output from 
Verilator, but this file changes with the version of Verilator according to the 
author. Then I decided to parse the port directly from the C++ source from 
Verilator. It could still be fragile, but this allows the user to do the 
minimum amount of work. I may do this work later.

Thank you again for your advice, I appreciated.

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