Re: USRP LO stabilization time ?

[Sylvain Munaut]

I played with fast hopping a while ago and it works very well and you
get lock times of less than 1 msec easily.

This is a B210 just quickly switching between  100M (FM), 816M (LTE),
940M (GSM), 1817M (LTE), 2115M (3G), 2450M (Wifi/Bluetooth)

http://i.imgur.com/FwzVgMx.jpg

You can get an idea of the switch time by looking at the duration of
the GSM FCCH signal ( which is ~ 4.6 ms long )

The hardware can only store 8 profiles internally but you can upload /
download profiles via SPI while another profile is running and so my
plan was to use the FPGA to upload next profile and switch to it at
times interval.

The client for that project disappeared and so I never continued to
actually implement it ...

Cheers,

 Sylvain

Re: Conversion of .dat file to a readable data using GNU octave

[Kyeong Su Shin]

Hello Akinyele:

It really depends on what you are saving, and how you are saving the data (.dat 
is a generic suffix for data binary files, and does not really tell much about 
the actual format).

If you are saving complex I-Q numbers using a "File Sink", and if the metadata 
feature is turned off, then see: 
https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
 , and https://github.com/gnuradio/gnuradio/tree/master/gr-utils/octave .

If that is not the case, please provide us more details about your "sink".

Regards,
Kyeong Su Shin

보낸 사람: AKINYELE ITAMAKINDE  대신 Discuss-gnuradio 

보낸 날짜: 2020년 4월 15일 수요일 오후 11:26
받는 사람: discuss-gnuradio@gnu.org 
제목: Conversion of .dat file to a readable data using GNU octave

I am working on channel sounding using USRP and GNU radio platforms. I am 
experiencing difficulty in converting the .dat file of sink file at receiver of 
flow graph into readable data using GNU octave. Can somebody help me to achieve 
this? Thanks

Re: USRP LO stabilization time ?

[Andrej Rode]

Hi,

a while a ago I looked into fast-hopping using a (possibly modified) 
B210.
Basically UHD is issuing a reconfiguration of the AD9361 for each tune 
which will not only
wait for the LO to settle, but also will due DC-offset and IQ balance 
calibration in the AD9361.

For fast hopping there is a special mode in the AD9361 manual where you 
can basically save the settings after
calibration either in a special set of registers (limited space) or 
supply them on the fly so no calibration is
carried out. Using this it would be possible to possibly to sub-ms 
tuning. (I don't recall the details)
In the end I did not implement this but it would be definitely feasible 
(would require a bit of work).
Maybe someone else has some more details on this (I think there is 
something in the archives on this).

Cheers
Andrej
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Conversion of .dat file to a readable data using GNU octave

[AKINYELE ITAMAKINDE]

I am working on channel sounding using USRP and GNU radio platforms. I am
experiencing difficulty in converting the .dat file of sink file at
receiver of flow graph into readable data using GNU octave. Can somebody
help me to achieve this? Thanks

Message stuck in the OFDM TX chain

[Anthony B.]

Hi all,

I am currently experimenting an OFDM transmission/reception using message
passing and two USRP B200.
The TX/RX flowgraphs (each USRP handling one)  are based on the examples
provided in GNU Radio :

https://github.com/gnuradio/gnuradio/tree/master/gr-digital/examples/ofdm

I added at the beginning of the TX chain and at the end of the RX chains
custom blocks to handle messages, based on the Chat Application example
here :

https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics#5.3.3_Example:_Chat_Application

So far I have been able to transmit and receive messages correctly.
My main issue is that while sending messages through the OFDM Tx chain, I
am only able to actually send every second message.
I am checking that with the TX LED, which corresponds with the good
reception on the RX side. So there is one message that stays stuck in the
OFDM TX chain.
While figuring out this issue, I changed the device args according to
transport notes for the USB link :

https://files.ettus.com/manual/page_transport.html

I observed that if I set send_frame_size to a value less than 152 bytes, I
am able to send messages continuously (not one every second message
anymore).
If I set a value above the latter one, I only receive the first message
sent on the RX side, and then nothing else.
At a certain value (I guess the default value for the setting), I start
having again my initial issue: one message stays in the TX chain every two
messages.
My goal is to make it work for a bidirectional flowgraph (having both USRP
Source/Sink), but I did not find a correct setting to have a continuous
message transmission.

Does someone know what would cause the messages to be blocked in the OFDM
TX chain ? Is there a relationship between the size of the message sent and
the USB transport parameters I should work on ?

I am using GNU Radio 3.7.14.0 and UHD 3.14.0.

Thanks for any suggestion!

Anthony

Re: gr_modtool

[sarandis. Doulgeris]

I deleted everything and i started over. When cmake ../ i get this

CMake Warning (dev) at
/snap/cmake/323/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (GMP).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /snap/cmake/323/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
(find_package_handle_standard_args)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindGMP.cmake:1 (include)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindMPLIB.cmake:1 (find_package)

/snap/cmake/323/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:26
(find_dependency)
  CMakeLists.txt:88 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.


CMake Warning (dev) at
/snap/cmake/323/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
(message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (MPIR).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /snap/cmake/323/share/cmake-3.17/Modules/FindPkgConfig.cmake:45
(find_package_handle_standard_args)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindMPIR.cmake:1 (include)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindMPLIB.cmake:2 (find_package)

/snap/cmake/323/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:26
(find_dependency)
  CMakeLists.txt:88 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at
/snap/cmake/323/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272
(message):
  The package name passed to `find_package_handle_standard_args` (VOLK) does
  not match the name of the calling package (Volk).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/cmake/volk/VolkConfig.cmake:32
(find_package_handle_standard_args)

/snap/cmake/323/share/cmake-3.17/Modules/CMakeFindDependencyMacro.cmake:47
(find_package)
  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:46
(find_dependency)
  CMakeLists.txt:88 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found VOLK: Volk::volk
-- User set python executable /usr/bin/python3
-- Found PythonInterp: /usr/bin/python3 (found version "3.6.9")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found
suitable exact version "3.6.9")
-- Found Git: /usr/bin/git
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- No C++ sources... skipping lib/
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- No C++ sources... skipping swig/
-- Configuring done
-- Generating done

Re: gr_modtool

[sarandis. Doulgeris]

Yeah it was nothing just install git. But now i think i got a problem. I
got to the last step when you install python block. Everything is going
well. I open Gnuradio-Companion and i see the the multiply_py_ff block. I
drag and drop it in the flowgraph. Nothing happens and i get this error in
the terminal:


/usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning: the
imp module is deprecated in favour of importlib; see the module's
documentation for alternative uses
  import fnmatch, glob, traceback, errno, sys, atexit, locale, imp
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/DrawingArea.py",
line 103, in _handle_drag_data_received
self._flow_graph.add_new_block(selection_data.get_text(), coords)
  File
"/usr/lib/python3/dist-packages/gnuradio/grc/gui/canvas/flowgraph.py", line
175, in add_new_block
block = self.new_block(key)
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/FlowGraph.py",
line 270, in new_block
block = self.parent_platform.make_block(self, block_id, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/platform.py", line
428, in make_block
return cls(parent, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/canvas/block.py",
line 46, in __init__
super(self.__class__, self).__init__(parent, **n)
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/blocks/block.py",
line 83, in __init__
self.sinks = [port_factory(parent=self, **params) for params in
self.inputs_data]
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/blocks/block.py",
line 83, in 
self.sinks = [port_factory(parent=self, **params) for params in
self.inputs_data]
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/platform.py", line
436, in make_port
return cls(parent, **kwargs)
  File "/usr/lib/python3/dist-packages/gnuradio/grc/gui/canvas/port.py",
line 42, in __init__
super(self.__class__, self).__init__(parent, direction, **n)
  File "/usr/lib/python3/dist-packages/gnuradio/grc/core/ports/port.py",
line 65, in __init__
self.vlen = vlen
  File
"/usr/lib/python3/dist-packages/gnuradio/grc/core/utils/descriptors/evaluated.py",
line 73, in __set__
attribs[self.name] = type(self.default)(value)
ValueError: invalid literal for int() with base 10: '...'

Στις Δευ, 13 Απρ 2020 στις 4:02 μ.μ., ο/η Marcus Müller <
mmuel...@gnuradio.org> έγραψε:

> Hello,
>
> On 11.04.20 14:05, sarandis. Doulgeris wrote:
> > /bin/sh: 1: git: not found
> > What seems to be the problem?
>
> Um, git wasn't found (you can install it easily), but that's not a
> problem per se. Does it work otherwise?
>
> Best regards,
> Marcus
>
>

RE: HackRF

[Bernd Schleicher]

Hi Joe,

Cinaed rang a bell, I have borrowed a HackRF from a neighboring department and 
wanted to test it on a pure GRC Windows installation. I don’t recall the exact 
errors, but it looked something like yours.
I searched for a windows driver of the HackRF, but didn’t find one and finally 
switched to the USRP B210. I bought for me privately one of these cheaper 
Chinese clones and got it running on Windows.

Maybe you could try to run a Pentoo Linux from iso-image
https://github.com/mossmann/hackrf/wiki/Getting-Started-with-HackRF-and-GNU-Radio
and see if this helps?

Cheers, Bernd





From: Discuss-gnuradio 
 On Behalf Of 
Cinaed Simson
Sent: Dienstag, 14. April 2020 20:43
To: discuss-gnuradio@gnu.org
Subject: Re: HackRF



Hi Joe - I just noticed you're running the HackRF in a virtualmachine on a PC - 
which implies you're most likely having problems with the USB drivers on 
Windows.

I don't know anything about Windows.

-- Cinaed

On 4/14/20 12:16 AM, Joe crossen wrote:
Hi guys,

I have a HackRF One connected to my PC, and a virtual machine running Ubunutu 
18.04. Getting the following error when running my flow graph (Osmocom source 
to WX GUI Scope Sink).

Traceback (most recent call last):
  File "/home/mike/GNURadio/Programs/HackRF_rx_Osmocom_GUI.py", line 97, in 

main()
  File "/home/mike/GNURadio/Programs/HackRF_rx_Osmocom_GUI.py", line 91, in main
tb = top_block_cls()
  File "/home/mike/GNURadio/Programs/HackRF_rx_Osmocom_GUI.py", line 59, in 
__init__
self.osmosdr_source_0 = osmosdr.source( args="numchan=" + str(1) + " " + '' 
)
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
1170, in make
return _osmosdr_swig.source_make(*args, **kwargs)
RuntimeError: No supported devices found (check the connection and/or udev 
rules).

hackrf_info output:
hackrf_info version: unknown
libhackrf version: unknown (0.5)
Found HackRF
Index: 0
Serial number: 57b068dc24726163
Board ID Number: 2 (HackRF One)
Firmware Version: 2018.01.1 (API:1.02)
Part ID Number: 0xa000cb3c 0x0058474c

Ubuntu 18.04
GNU Radio 3.7.14.0
sudo apt install hackrf libhackrf-dev
gr-osmocom (gr3.7 branch)

I've been googling for hours.
I followed this guide to add a udev file to /etc/udev/rules.d
https://github.com/mossmann/hackrf/wiki/FAQ#permission-problem
didn't work however.

Does anyone have any ideas?

Thanks,
Joe