Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[Maitry Raval]

Hello,

Ok, One more query, what is the purpose of the block unpack k=1 bit at output 
of PSK demod block, because the meaning of unpack k=1 means byte to byte 
conversion, right?

With Best Regards,
Maitry Raval,

- Original Message -
From: "Cinaed Simson" 
To: "Maitry Raval" 
Cc: "discuss-gnuradio" 
Sent: Friday, January 11, 2019 2:11:54 AM
Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block

On 1/10/19 2:47 AM, Maitry Raval wrote:
> Hello,
> 
> Thanks for your time!
> 
> It works completely fine, now I understand that we have to give tagged stream 
> at the input of encoder.

Sorry, I didn't mean to imply you needed the stream to tagged stream
block to make it work.

I just put in at the beginning so I could use the tag debug as a brute
force search to find out what was blocking the flow.

There are two sequential tag blocks - the correlate correlate access
code-tag from gnuradio and a block from gr-satellites - I would guess
that is all you need.

Select "pass thru" on the stream to tagged stream block - it should
still work.

-- Cinaed


> 
> 
> With Best Regards,
> Maitry Raval,
> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com
> 
> - Original Message -
> From: "Cinaed Simson" 
> To: "discuss-gnuradio" 
> Cc: "Maitry Raval" 
> Sent: Thursday, January 10, 2019 1:21:34 PM
> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
> 
> Hi Mailry - I was able to get it run.
> 
> I used the "correlate access" block from gnuradio - my installation of
> gnuradio didn't like the block in your flowgraph.
> 
> And then I had to install the python module "construct" in order to get
> the flowgraph to run.
> 
> In order to get the flowchart to work - at least in the sense of filling
> up the output.txt file - I added a "Stream to Tagged Stream" block and
> define a consist tag to get the Tag Debug block to work.
> 
> Also, I had to remove the "unpack" block before the PSK modulation,
> added a "Unpack K=1" block just after the PSK demodulation - and I set
> "Generate Options" to "No Gui" in the Options block.
> 
> -- Cinaed
> 
> 
> 
> On 1/8/19 12:40 AM, Maitry Raval wrote:
>> Hello, 
>> thanks for your guidance.
>> I have also attached the grc file, input/output files and python file for 
>> your reference. after adding tag debug, still didn't get any output. I have 
>> also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version.
>> actually because these psk blocks are deprecated, I have tried it with dpsk 
>> mod, demod block. But as I wanted to do continuous transmission, I didn't 
>> find replaced block for correlate access code-tag block, and the cusom block 
>> from gr-satellites are for extracting syncbits. 
>> I have also tried with simple flow graph by just sream muxing 2 files one 
>> with sync bits and other one is payload file and give that output to 
>> correlate access code-tag block, but that also didn't work.
>>
>> It would be grateful, If you guide me on this. I just want to make that sync 
>> bits searching and extracting from payload and receive only payload at the 
>> output. 
>>
>>
>> With Best Regards,
>> Maitry Raval,
>>
>>
>> - Original Message -
>> From: "Cinaed Simson" 
>> To: "discuss-gnuradio" 
>> Sent: Tuesday, January 8, 2019 1:47:56 PM
>> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
>>
>> I broke down and looked at the image.
>>
>> Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
>> Decoder have been depreciated.
>>
>> And they're usually depreciated because they have problems - and they
>> are usually replaced with different blocks which work better and are
>> typically more general.
>>
>> The tutorials are good place to start looking for the replacements.
>>
>> -- Cinaed
>>
>>
>> On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
>>> Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
>>>
>>> Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
>>> mailto:thomas.lavare...@gmail.com>> a écrit :
>>>
>>>
>>>
>>> Hi,
>>>
>>> But, the issue is that correlate access code-tag block is not
>>> working and producing tags, so that my output file will come
>>> blank. as  I am certain that at the output of FEC extended
>>> decoder, both the sync bits and payload is available which I
>>> have seen by attaching file sink at the output of FEC extended
>>> decoder.
>>>
>>>
>>> There is a block "Tag Debug" to see if the tag is generated behind
>>> "correlate access code - tag block".
>>>
>>> On the other hand, the documentation of "Tagged File sink" indicate
>>> that the block need the keyword "burst" (with value: True) to
>>> trigger the saving of the data.
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>> ___
>>>
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org 

Re: [Discuss-gnuradio] anyone know what is the theory of the implementation of pll_freqdet_cf

[WarMonkey]

http://ricesimulink.groups.et.byu.net/pll.phtml


在 2019年1月8日星期二，wu jo  写道：

> Hi ALL,
> I am reading a block that using pll_freqdet_cf. it said pll_freqdet_cf
> detect a frequency then lock to it. but what is the theory of the
> impletation of that? anyone can share the knowledge?
>
> Best Regards
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Single step a stream

[WarMonkey]

Yes you can debug any gnuradio c++ module with gdb.
Step 1 uninstall gnuradio.
Step 2 git clone gnuradio from github.
Step 3 build gnuradio with debug symbols on. ( cmake ..
-DCMAKE_BUILD_TYPE=Debug )
Step 4 reinstall custom build gnuradio.
Step 5 debug your application with gdb ( use qtcreator, vscode, atom as ide
will be good  )

With gdb you can stop anywhere in application. Set a data breakpoint can
trace stray value in variable.

在 2019年1月8日星期二，Rudolf Wigblurr  写道：

> Hi,
>
> Is it possible to single step a flow graph?
>
> I have a recorded stream of FSK modulated data with about 25 bursts of
> messages.
> When this is later decoded I do not get 100% detection, about 4 of 25
> bursts fails.
>
> Now my thinking is can I play this burst by burst and see what is wrong.
> So my plan was to stop the scheduler after each burst.
> Can I control (stop) the scheduler when a 'tag' is detected and restart it
> with a GUI button.
>
> Block,Python,C++ dosen't matter...
>
> /Rudolf
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Ron Economos]

You should check out a tagged release.

git checkout v3.7.10

You need to update volk.

git submodule update --init

Ron

On 1/10/19 16:47, Achilleas Anastasopoulos 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 librarylibgnuradio-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] [UHD] 3.13.1.0 Release Announcement

[Michael West]

UHD 3.13.1.0 is now available. This is an ABI release on the UHD-3.13
branch.  It is API compatible with all 3.13.x.x releases.

Installers for Windows and Fedora are available here:
http://files.ettus.com/binaries/uhd/uhd_003.013.001.000-release/

The PPA for Ubuntu will be available soon and will be found here:
https://launchpad.net/~ettusresearch/+archive/ubuntu/uhd


The tag for this release is located here:
https://github.com/EttusResearch/uhd/releases/tag/v3.13.1.0

There have been 156 commits since the last release which can be viewed here:
https://github.com/EttusResearch/uhd/compare/v3.13.0.2...v3.13.1.0

Please report any bugs found on the UHD issue tracker:
http://github.com/EttusResearch/uhd/issues
* Please do not use the issue tracker for help or support.

Pull requests for direct code changes can be submitted to the UHD or FPGA
repositories:
http://github.com/EttusResearch/uhd/pulls
http://github.com/EttusResearch/fpga/pulls

CHANGELOG:

## 003.013.001.000
* E320: Fix front panel GPIO readback
* E320: Fix master_clock_rate setting
* E320: Print extra ouptut for ref_clock BIST
* E320: Fix gps_locked type
* E320: Fix return value of get_fpga_type()
* N3xx: Enable setting clock and time sources at runtime
* N3xx: Add ref_clock BIST
* N3xx: Improve set_time_source() and set_clock_source()
* N3xx: Add exception for init failure
* N3xx: Remove HA, XA images packages
* N3xx: Change init() procedure to reduce configuration time
* N310: Add frequency bounds
* N310: Fix RX antenna mapping
* N310: Add log messages when re-initializing dboards
* N310: Add skip_rfic argument to reduce time of BIST
* N310: Add initialization of TX bandwidth
* E310: Fix initialization of antenna and frequency values
* E310: Type-cast fix for Boost
* X300: Improve firmware compat error message
* X300: Updated niusrprio driver
* X300: Add recovery for duplicate IP addresses in EEPROM
* X300: Prevent duplicate MAC and IP addresses from being programmed
* X300: New mode to configure master clock rate
* X300: Implement RFNoC get antenna functions
* B2xx: Fix values of MASK_GPIO_SHDN_SW and GPIO_AUX_PWR_ON in firmware
* B2xx: Revert changes to DSP core to fix scaling factor adjustment
* B2xx: Restore asynchronous reset of AD936x
(fixes LIBUSB_TRANSFER_OVERFLOW and unexpected sid errors)
* TwinRX: enable ch1 lo amps if ch2 is using an external lo source
* TwinRX: Correctly initialize antenna mapping on X300
* TwinRX: Revise ADF5356 frac2 register calculation to prevent drifting
spurs
* TwinRX: Fix initialization
* TwinRX: Tuning improvements
* TwinRX: Enable phase resync on ADF535x
* TwinRX: Make routing to LO1 and LO2 mutually exclusive
* BasicRX/LFRX: Fix real mode in rx_frontend_core_3000
* UHD: Define UHD_API as empty string when building static lib
* UHD: Changed to 'all_matching' endpoint resolution for udp_simple
transport
* UHD: Add support for NEON SIMD
* UHD: Fix usb_dummy_impl compilation in MSVC
* UHD: Reconcile time_spec operators with boost concepts
* UHD: Fix rounding in ddc/duc rate calculation
* UHD: Increase MPMD RPC timeout when calling set_time_source()
* UHD: Fix RX streamer SOB and EOB handling
* UHD: Add UHD_SAFE_CALL to block_ctrl_base destructor
* UHD: Change SOVERSION to ABI string and VERSION to full UHD version
* UHD: Update cmake style to use lower case commands
* UHD: Add SOURCE_DATE_EPOCH
* UHD: Improve logic for UHD_IMAGES_DIR
* UHD: Add RUNTIME_PYTHON_EXECUTABLE
* UHD: Fix return value of get_rolloff() for filters
* UHD: Properly register devtest
* UHD: Fix log statement for Port number on RFNoC block
* UHD: Use "MATCHES" instead of "STREQUAL" for "Clang"
* UHD: Fix GPGGA string formatting for gpsd
* Device3: Set default block control response SIDs
* Device3: Fix block control flushing
* RFNoC: Improved flushing mechanism in noc_shell and dma_fifo
* RFNoC: Install missing dma_fifo_block_ctrl header
* RFNoC: Replace some [] with .at() in radio_ctrl_impl
* RFNoC: Fix graph traversal
* MPM: Add Git hash, version to device info
* MPM: Reset the RPC server upon reload
* MPM: TDC: Update PDAC BIST and flatness test to use latest APIs
* MPM: Fix handling of 0-valued dt-compat
* MPM: Fix GPSD sensor names for N3xx and E320
* MPM: Add args to update_ref_clock_freq to properly support dynamic setting
*  of clock and time references
* MPM: Fix Pylint warnings
* MPM: Identify sysfs gpios more generically
* MPM: Add lock_guard() function
* MPM: Factor E320 and N3xx BIST code into common module
* MPM: Add gpsd error handling
* MPM: Add FPGA git hash to device info
* MPMD: Increase RPC timeout during readng mb sensor
* MPMD: Improve error message for compat number mismatches
* Python API: Enable Python API on Windows
* Python API: Change .dll to .pyd for Win32
* Python API: Fixing Boost.Python initializer visibility
* Python API: Fix duration of benchmark rate
* Python API: Add missing constructors of time_spec_t
* Python API: Expose 

Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[Cinaed Simson]

On 1/10/19 2:47 AM, Maitry Raval wrote:
> Hello,
> 
> Thanks for your time!
> 
> It works completely fine, now I understand that we have to give tagged stream 
> at the input of encoder.

Sorry, I didn't mean to imply you needed the stream to tagged stream
block to make it work.

I just put in at the beginning so I could use the tag debug as a brute
force search to find out what was blocking the flow.

There are two sequential tag blocks - the correlate correlate access
code-tag from gnuradio and a block from gr-satellites - I would guess
that is all you need.

Select "pass thru" on the stream to tagged stream block - it should
still work.

-- Cinaed


> 
> 
> With Best Regards,
> Maitry Raval,
> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com
> 
> - Original Message -
> From: "Cinaed Simson" 
> To: "discuss-gnuradio" 
> Cc: "Maitry Raval" 
> Sent: Thursday, January 10, 2019 1:21:34 PM
> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
> 
> Hi Mailry - I was able to get it run.
> 
> I used the "correlate access" block from gnuradio - my installation of
> gnuradio didn't like the block in your flowgraph.
> 
> And then I had to install the python module "construct" in order to get
> the flowgraph to run.
> 
> In order to get the flowchart to work - at least in the sense of filling
> up the output.txt file - I added a "Stream to Tagged Stream" block and
> define a consist tag to get the Tag Debug block to work.
> 
> Also, I had to remove the "unpack" block before the PSK modulation,
> added a "Unpack K=1" block just after the PSK demodulation - and I set
> "Generate Options" to "No Gui" in the Options block.
> 
> -- Cinaed
> 
> 
> 
> On 1/8/19 12:40 AM, Maitry Raval wrote:
>> Hello, 
>> thanks for your guidance.
>> I have also attached the grc file, input/output files and python file for 
>> your reference. after adding tag debug, still didn't get any output. I have 
>> also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version.
>> actually because these psk blocks are deprecated, I have tried it with dpsk 
>> mod, demod block. But as I wanted to do continuous transmission, I didn't 
>> find replaced block for correlate access code-tag block, and the cusom block 
>> from gr-satellites are for extracting syncbits. 
>> I have also tried with simple flow graph by just sream muxing 2 files one 
>> with sync bits and other one is payload file and give that output to 
>> correlate access code-tag block, but that also didn't work.
>>
>> It would be grateful, If you guide me on this. I just want to make that sync 
>> bits searching and extracting from payload and receive only payload at the 
>> output. 
>>
>>
>> With Best Regards,
>> Maitry Raval,
>>
>>
>> - Original Message -
>> From: "Cinaed Simson" 
>> To: "discuss-gnuradio" 
>> Sent: Tuesday, January 8, 2019 1:47:56 PM
>> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
>>
>> I broke down and looked at the image.
>>
>> Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
>> Decoder have been depreciated.
>>
>> And they're usually depreciated because they have problems - and they
>> are usually replaced with different blocks which work better and are
>> typically more general.
>>
>> The tutorials are good place to start looking for the replacements.
>>
>> -- Cinaed
>>
>>
>> On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
>>> Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
>>>
>>> Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
>>> mailto:thomas.lavare...@gmail.com>> a écrit :
>>>
>>>
>>>
>>> Hi,
>>>
>>> But, the issue is that correlate access code-tag block is not
>>> working and producing tags, so that my output file will come
>>> blank. as  I am certain that at the output of FEC extended
>>> decoder, both the sync bits and payload is available which I
>>> have seen by attaching file sink at the output of FEC extended
>>> decoder.
>>>
>>>
>>> There is a block "Tag Debug" to see if the tag is generated behind
>>> "correlate access code - tag block".
>>>
>>> On the other hand, the documentation of "Tagged File sink" indicate
>>> that the block need the keyword "burst" (with value: True) to
>>> trigger the saving of the data.
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>> ___
>>>
>>> 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 mailing list
>> Discuss-gnuradio@gnu.org
>> 

Re: [Discuss-gnuradio] two versions of uhd installed?

[Ali Dormiani]

The repos are outdated. I ran into the same problem when first getting 
started too.



You need to compile both UHD and GNUradio from source to get the 
versions you want.


Ettus has a great (very thorough) guide on how to do this.


https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux


*tip: instead of 'make' you can type 'make -j 2' in order to greatly 
speed you the compiling process. (only if you have 6 gigs of ram or more)



Feel free to post in this thread again if you get an error.





On 01/10/2019 11:09 AM, Achilleas Anastasopoulos wrote:

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


___
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] Regarding correlate access code-tag block

[Daniel Estévez]

El 08/01/19 a las 22:14, Müller, Marcus (CEL) escribió:
> As indicated, have you worked through the tutorials on 
> https://tutorials.gnuradio.org?
> That's the place where I'd start.
> You should drop *all* the blocks that are deprecated. As said, these
> are deprecated for a reason (buggy and no-one is willing or able to fix
> them – most of the ones you're using are simply broken on a conceptual
> level).
> 
> Instead of the correlate access block, my guess is that the
> header_payload_demux-based examples from gr-
> digital/examples/packet/packet_rx.grc and packet_tx.grc and
> packet_loopback_hier.grc will make you much happier.
> 
> You'll probably find them in
> /usr/share/gnuradio/examples/digital/packet.

Hi Marcus,

I'm not following this thread closely, so maybe I missed something that
has already been said.

In gr-satellites I'm using the "Correlate access code - Tag"
extensively, so if this has been deprecated I would like to replace it
by something suitable.

I'm currently using GNU Radio 3.7.13.4 and the block "Correlate access
code" appears as deprecated, but "Correlated access code - Tag" doesn't
appear as deprecated.

If "Correlate access code - Tag" is deprecated or is going to be
deprecated in GNU Radio 3.8 (which I haven't tested yet), what could be
suitable replacements for this block?

Maybe it could be good to make the effort to use the "Header/Payload
Demux" block, which at first glance seems too complicated for the use
I'm doing? In gr-satellites my main use for "Correlate access code -
Tag" is to detect a syncword and add a tag, so then I can use one of my
custom blocks to create a PDU of a fixed size where the tag starts.

Best regards,

Dani.



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

Re: [Discuss-gnuradio] regarding ubuntu GNU radio version

[CEL]

Dear Maitry,

since Ubuntu 18.04 sadly only ships the old GNU Radio 3.7.11, you would
have to do a source build. You can't just download a binary.

It's probably much easier just to update to Ubuntu 18.10, and
afterwards do "sudo apt install gnuradio" or use something with a nicer
release cycle, e.g. current debian.

Best regards,
Marcus

On Thu, 2019-01-10 at 16:21 +0530, Maitry Raval wrote:
> Hello,
> Can anyone provide the link in order to install GNU radio version 3.7.12 to 
> ubuntu 18.04
> 
> With Best Regards,
> Maitry Raval,
> 
> ___
> 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] regarding ubuntu GNU radio version

[Maitry Raval]

Hello, 
Can anyone provide the link in order to install GNU radio version 3.7.12 to 
ubuntu 18.04 

With Best Regards, 
Maitry Raval, 

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

Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[Maitry Raval]

Hello,

Thanks for your time!

It works completely fine, now I understand that we have to give tagged stream 
at the input of encoder.


With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com

- Original Message -
From: "Cinaed Simson" 
To: "discuss-gnuradio" 
Cc: "Maitry Raval" 
Sent: Thursday, January 10, 2019 1:21:34 PM
Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block

Hi Mailry - I was able to get it run.

I used the "correlate access" block from gnuradio - my installation of
gnuradio didn't like the block in your flowgraph.

And then I had to install the python module "construct" in order to get
the flowgraph to run.

In order to get the flowchart to work - at least in the sense of filling
up the output.txt file - I added a "Stream to Tagged Stream" block and
define a consist tag to get the Tag Debug block to work.

Also, I had to remove the "unpack" block before the PSK modulation,
added a "Unpack K=1" block just after the PSK demodulation - and I set
"Generate Options" to "No Gui" in the Options block.

-- Cinaed



On 1/8/19 12:40 AM, Maitry Raval wrote:
> Hello, 
> thanks for your guidance.
> I have also attached the grc file, input/output files and python file for 
> your reference. after adding tag debug, still didn't get any output. I have 
> also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version.
> actually because these psk blocks are deprecated, I have tried it with dpsk 
> mod, demod block. But as I wanted to do continuous transmission, I didn't 
> find replaced block for correlate access code-tag block, and the cusom block 
> from gr-satellites are for extracting syncbits. 
> I have also tried with simple flow graph by just sream muxing 2 files one 
> with sync bits and other one is payload file and give that output to 
> correlate access code-tag block, but that also didn't work.
> 
> It would be grateful, If you guide me on this. I just want to make that sync 
> bits searching and extracting from payload and receive only payload at the 
> output. 
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Cinaed Simson" 
> To: "discuss-gnuradio" 
> Sent: Tuesday, January 8, 2019 1:47:56 PM
> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
> 
> I broke down and looked at the image.
> 
> Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
> Decoder have been depreciated.
> 
> And they're usually depreciated because they have problems - and they
> are usually replaced with different blocks which work better and are
> typically more general.
> 
> The tutorials are good place to start looking for the replacements.
> 
> -- Cinaed
> 
> 
> On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
>> Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
>>
>> Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
>> mailto:thomas.lavare...@gmail.com>> a écrit :
>>
>>
>>
>> Hi,
>>
>> But, the issue is that correlate access code-tag block is not
>> working and producing tags, so that my output file will come
>> blank. as  I am certain that at the output of FEC extended
>> decoder, both the sync bits and payload is available which I
>> have seen by attaching file sink at the output of FEC extended
>> decoder.
>>
>>
>> There is a block "Tag Debug" to see if the tag is generated behind
>> "correlate access code - tag block".
>>
>> On the other hand, the documentation of "Tagged File sink" indicate
>> that the block need the keyword "burst" (with value: True) to
>> trigger the saving of the data.
>>
>> Best regards,
>>
>> Thomas
>>
>> ___
>>
>> 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 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC] REMINDER: Google Summer of Code 2019 is approaching!

[Wunsch, Felix (CEL)]

?Hi all!


Just a quick reminder: The application period is opening in five days and our 
ideas list, although pretty long, still looks pretty much the same as last 
year. So in order to be attractive for students who maybe didn't find "their" 
project on our list past summer, let's add some new ones! I'm sure there's some 
projects or ideas in the back of your heads that would be a good fit for a 
project. Even if it's just a rough idea that needs to be fleshed out, let's 
discuss that here on the list!


Cheers,

Felix



Von: Wunsch, Felix (CEL)
Gesendet: Donnerstag, 13. Dezember 2018 19:33
An: discuss-gnuradio@gnu.org
Betreff: [GSoC] Google Summer of Code 2019 is approaching!


Hi all,


GSoC 2019 is coming closer and it's again time to polish our ideas list [0]! 
There's still quite a number of old projects but we also definitely need new 
ones. I also strongly suspect that having the same ideas on your list as the 
previous year is not a plus when it comes to Googles decision if we're going to 
get accepted or not. So, get creative! Add ideas to the list and/or feel free 
to discuss them here. There's a feature you always wanted that is feasible to 
do in three months of coding and that GR users would benefit from? This is the 
perfect opportunity to introduce new people and future contributors to GR and 
at the same time get stuff done!


For the timeline: GSoC application phase for mentoring organizations starts 
January 15, 2019 and ends about 3 weeks later. So please mark January 15 as the 
deadline in your calendars! We will need the remaining time to go over the 
project ideas and submit the application, there's really no need to become 
hectic in the last 24 hours. On February 26 we will then find out if we're 
accepted and if that's the case, students can start to introduce themselves 
here on the list. Find the full timeline here [1].


GSoC can't work without your ideas and your help, so start thinking and let's 
make this another successful GSoC for GNU Radio!


Cheers,

Felix


[0] https://wiki.gnuradio.org/index.php/GSoCIdeas

[1] https://developers.google.com/open-source/gsoc/timeline?


PS: I have agreed to take on the role as org admin for another year (which I'm 
happy to do). If you, however, want to do the job, please contact me! It's not 
my intention to keep anyone interested from admin'ing.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Regarding correlate access code-tag block

[Cinaed Simson]

Hi Mailry - I was able to get it run.

I used the "correlate access" block from gnuradio - my installation of
gnuradio didn't like the block in your flowgraph.

And then I had to install the python module "construct" in order to get
the flowgraph to run.

In order to get the flowchart to work - at least in the sense of filling
up the output.txt file - I added a "Stream to Tagged Stream" block and
define a consist tag to get the Tag Debug block to work.

Also, I had to remove the "unpack" block before the PSK modulation,
added a "Unpack K=1" block just after the PSK demodulation - and I set
"Generate Options" to "No Gui" in the Options block.

-- Cinaed



On 1/8/19 12:40 AM, Maitry Raval wrote:
> Hello, 
> thanks for your guidance.
> I have also attached the grc file, input/output files and python file for 
> your reference. after adding tag debug, still didn't get any output. I have 
> also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version.
> actually because these psk blocks are deprecated, I have tried it with dpsk 
> mod, demod block. But as I wanted to do continuous transmission, I didn't 
> find replaced block for correlate access code-tag block, and the cusom block 
> from gr-satellites are for extracting syncbits. 
> I have also tried with simple flow graph by just sream muxing 2 files one 
> with sync bits and other one is payload file and give that output to 
> correlate access code-tag block, but that also didn't work.
> 
> It would be grateful, If you guide me on this. I just want to make that sync 
> bits searching and extracting from payload and receive only payload at the 
> output. 
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Cinaed Simson" 
> To: "discuss-gnuradio" 
> Sent: Tuesday, January 8, 2019 1:47:56 PM
> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block
> 
> I broke down and looked at the image.
> 
> Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet
> Decoder have been depreciated.
> 
> And they're usually depreciated because they have problems - and they
> are usually replaced with different blocks which work better and are
> typically more general.
> 
> The tutorials are good place to start looking for the replacements.
> 
> -- Cinaed
> 
> 
> On 1/7/19 11:22 PM, Thomas Lavarenne wrote:
>> Oh, it is "File Sink" not "Tagged file sink", didn't see sorry.
>>
>> Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne
>> mailto:thomas.lavare...@gmail.com>> a écrit :
>>
>>
>>
>> Hi,
>>
>> But, the issue is that correlate access code-tag block is not
>> working and producing tags, so that my output file will come
>> blank. as  I am certain that at the output of FEC extended
>> decoder, both the sync bits and payload is available which I
>> have seen by attaching file sink at the output of FEC extended
>> decoder.
>>
>>
>> There is a block "Tag Debug" to see if the tag is generated behind
>> "correlate access code - tag block".
>>
>> On the other hand, the documentation of "Tagged File sink" indicate
>> that the block need the keyword "burst" (with value: True) to
>> trigger the saving of the data.
>>
>> Best regards,
>>
>> Thomas
>>
>> ___
>>
>> 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 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
> 




  Fri Dec  7 10:23:55 2018
  
options

  author
  


  window_size
  


  category
  [GRC Hier Blocks]


  comment
  


  description
  


  _enabled
  True


  _coordinate
  (8, 8)


  _rotation
  0


  generate_options
  no_gui


  hier_block_src_path
  .:


  id
  top_block


  max_nouts
  0


  qt_qss_theme
  


  realtime_scheduling
  


  run_command
  {python} -u {filename}


  run_options
  prompt


  run
  True


  sizing_mode
  fixed


  thread_safe_setters
  


  title
  


  placement
  (0,0)

  
  
variable

  comment
  


  _enabled
  True