Re: [Discuss-gnuradio] [USRP-users] continous Tx voice transmission

[Ian Buckley]

Brian, I think your idea does work. I think the tricky bit to doing this really 
well is having a control loop that reacts quickly enough that we don’t have to 
be stuck with a giant buffer that adds undesirable latency, but then conversely 
a control loop that adapts at a slow enough rate and with small enough steps 
that we don’t introduce human perceptible audio artifacts. 

> On Mar 7, 2019, at 7:46 AM, Brian Padalino via USRP-users 
>  wrote:
> 
> On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller  > wrote:
> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
> 
> Could message passing from the real-time blocks solve this issue in a 
> flexible way?
> 
> Imagine the following: blocks connected to actual hardware use the computer 
> wall clock to try to determine an average sample clock as it relates to the 
> CPU clock.  The USRP source block would be able to determine how many 
> samples/(sec of CPU clock) were coming in and Audio sink blocks would be able 
> to determine how many samples/(sec of CPU clock) were being consumed.  The 
> same idea for Audio sources and USRP sinks.  Since the blocking calls for 
> USRP or Audio blocks could be wrapped in a high precision timer, once any 
> initial buffering had been filled up, the rate should settle out.
> 
> The modified blocks could then send a message of actual sample rate to 
> whoever needed to listen, and the appropriate sample rate could be figured 
> out in the "resampling FIFO".
> 
> What am I missing?  Why won't this work?
> 
> Brian
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

[Discuss-gnuradio] patch -- fix pkgconfig libs

[Maitland Bottoms]

As part of the goal to fix bugs for a 3.8, please consider this patch
against current gnuradio master.

A small patch for the build system.
It removes a few lines and a few variables of CMake,
and yields a better gnuradio-runtime.pc file.

Looking forward to 3.8,
-Maitland

enc:
fix-pkgconfig-libs.patch
can be applied to git via
`git am fix-pkgconfig-libs.patch`
>From 2b1c8dde0fe4d4ae4b1b1bb623f3a7945b8cc014 Mon Sep 17 00:00:00 2001
From: "A. Maitland Bottoms" 
Date: Thu, 7 Mar 2019 20:02:10 -0500
Subject: [PATCH] fix pkgconfig libs

Lintian reported
 pkg-config-references-unknown-shared-library
  usr/lib/x86_64-linux-gnu/pkgconfig/gnuradio-runtime.pc -lgmpxx (line 10)
 pkg-config-references-unknown-shared-library
  usr/lib/x86_64-linux-gnu/pkgconfig/gnuradio-runtime.pc -lgmp (line 10)

from the pkg-config man page:
 "Libs:  This line should give the link flags specific to your package.
  Don't add any flags for required packages; pkg-config will add those
  automatically."

No need to have a CMake variable to keep track of these. Just let ld work.
---
 cmake/Modules/FindGMP.cmake | 1 -
 cmake/Modules/FindMPIR.cmake| 1 -
 cmake/Modules/FindMPLIB.cmake   | 2 --
 gnuradio-runtime/CMakeLists.txt | 1 -
 gnuradio-runtime/gnuradio-runtime.pc.in | 2 +-
 5 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/cmake/Modules/FindGMP.cmake b/cmake/Modules/FindGMP.cmake
index 8782334e80..b2fe51d328 100644
--- a/cmake/Modules/FindGMP.cmake
+++ b/cmake/Modules/FindGMP.cmake
@@ -38,7 +38,6 @@ find_library(
   /usr/lib64
 )
 set(GMP_LIBRARIES ${GMPXX_LIBRARY} ${GMP_LIBRARY})
-set(GMP_PC_ADD_LIBS "-lgmpxx -lgmp")
 
 include(FindPackageHandleStandardArgs)
 find_package_handle_standard_args(GMP DEFAULT_MSG GMPXX_LIBRARY GMP_LIBRARY GMP_INCLUDE_DIR)
diff --git a/cmake/Modules/FindMPIR.cmake b/cmake/Modules/FindMPIR.cmake
index 647b3815a4..1ba5682484 100644
--- a/cmake/Modules/FindMPIR.cmake
+++ b/cmake/Modules/FindMPIR.cmake
@@ -38,7 +38,6 @@ find_library(
   /usr/lib64
 )
 set(MPIR_LIBRARIES ${MPIRXX_LIBRARY} ${MPIR_LIBRARY})
-set(MPIR_PC_ADD_LIBS "-lmpirxx -lmpir")
 
 include(FindPackageHandleStandardArgs)
 find_package_handle_standard_args(MPIR DEFAULT_MSG MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
diff --git a/cmake/Modules/FindMPLIB.cmake b/cmake/Modules/FindMPLIB.cmake
index 37673b136b..7353604cad 100644
--- a/cmake/Modules/FindMPLIB.cmake
+++ b/cmake/Modules/FindMPLIB.cmake
@@ -8,7 +8,6 @@ if(GMP_FOUND)
 set(MPLIB_LIBRARY ${GMP_LIBRARY})
 set(MPLIBXX_LIBRARY ${GMPXX_LIBRARY})
 set(MPLIB_PC_ADD_CFLAGS ${GMP_PC_ADD_CFLAGS})
-set(MPLIB_PC_ADD_LIBS ${GMP_PC_ADD_LIBS})
 else(GMP_FOUND)
 set(GR_MPLIB_MPIR True)
 set(MPLIB_DEFINITIONS "-DGR_MPLIB_MPIR" ${MPIR_DEFINITIONS})
@@ -16,7 +15,6 @@ else(GMP_FOUND)
 set(MPLIB_LIBRARY ${MPIR_LIBRARY})
 set(MPLIBXX_LIBRARY ${MPIRXX_LIBRARY})
 set(MPLIB_PC_ADD_CFLAGS ${MPIR_PC_ADD_CFLAGS})
-set(MPLIB_PC_ADD_LIBS ${MPIR_PC_ADD_LIBS})
 endif(GMP_FOUND)
 
 set(MPLIB_INCLUDE_DIRS ${MPLIB_INCLUDE_DIR})
diff --git a/gnuradio-runtime/CMakeLists.txt b/gnuradio-runtime/CMakeLists.txt
index e24ffab344..f53adc7b7c 100644
--- a/gnuradio-runtime/CMakeLists.txt
+++ b/gnuradio-runtime/CMakeLists.txt
@@ -84,7 +84,6 @@ install(FILES
 DESTINATION ${GR_PREFSDIR}
 )
 
-set(PC_ADD_LIBS "${MPLIB_PC_ADD_LIBS} ${PC_ADD_LIBS}")
 set(PC_ADD_CFLAGS ${MPLIB_PC_ADD_CFLAGS})
 
 
diff --git a/gnuradio-runtime/gnuradio-runtime.pc.in b/gnuradio-runtime/gnuradio-runtime.pc.in
index 280adaddd1..e10deceb97 100644
--- a/gnuradio-runtime/gnuradio-runtime.pc.in
+++ b/gnuradio-runtime/gnuradio-runtime.pc.in
@@ -7,5 +7,5 @@ Name: gnuradio-runtime
 Description: GNU Radio core runtime infrastructure
 Requires:
 Version: @LIBVER@
-Libs: -L${libdir} -lgnuradio-runtime -lgnuradio-pmt @PC_ADD_LIBS@
+Libs: -L${libdir} -lgnuradio-runtime -lgnuradio-pmt
 Cflags: -I${includedir} @PC_ADD_CFLAGS@
-- 
2.11.0

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

Re: [Discuss-gnuradio] GSoC project idea discussion

[Andrej Rode]

Hi Arpit, 

> Also, pygccxml parser code
> itself is easy to visualize. libclang in python does a pretty good
> job in parsing all the header files, but it parses all the include
> files, and also the standard C++ ones because of it's compiler level
> parsing, which is not required, at least in our particular case.

Looking at both pygccxml and the python bindings for clang is
definitely a good thing and will give you an idea about which is the
better tool for the job. Looking at the pygccxml project it seems it's
active & mature enough to be used in GNU Radio from a technical
perspective.

Cheers
Andrej


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

Re: [Discuss-gnuradio] Extending and Updating gr-radar

[Martin Braun]

Welcome!

If you want to run gr-radar on Windows, please try running this as part of
your application, and then provide some "proof" that you were able to do
this in your application. If you can't effectively edit and publish code,
you won't get very far, so please make sure you have that part down.

Thanks,
Martin


On Sun, Mar 3, 2019 at 12:32 PM Müller, Marcus (CEL) 
wrote:

> Hi Talha,
>
> thanks for reaching out! We're the "GNU Radio" project. "GNU" is more
> of an umbrella project, so when referring to our software, we always
> say "GNU Radio".
>
> As a recommendation: Although we do have a working Windows port, very
> little of the GNU Radio development happens on Windows; most of it
> happens on Linux, some on Mac OS X.
> Since I don't know of anybody who has even tested gr-radar on Windows,
> I'd recommend you start with familiarizing yourself with GNU Radio on
> Linux, where it's trivial to install (for example, if you boot up a
> Fedora Linux Live Image, you can just install it with a single command
> line). Getting to know git would be worthwhile, too.
>
> While that is certainly something that can take a while, this is just
> the community introduction phase – so tell us a bit about yourself, for
> example, what you know about radar so far, and what ideas you've had
> when watching one of the demonstrations of gr-radar that you can find
> on the internet.
>
> Best regards,
> Marcus
>
> On Sun, 2019-03-03 at 23:32 +0500, Talha Farooq wrote:
> > Hi
> > I am willing to work on "Extending and Updating gr-radar" as I have
> > studied radar course in my degree. Currently I am reviewing GNU
> > software for windows later on I will work with gr-radar files to
> > achieve milestones.
> > Regards;
> > Talha Farooq.
> > ___
> > 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

Re: [Discuss-gnuradio] GSoC project idea discussion

[Martin Braun]

A nice design could also abstract the implementation of the code parsing
tool (clang vs. pygccxml) and use either one under the hood.

-- M

On Thu, Mar 7, 2019 at 7:07 AM Arpit Gupta  wrote:

> Hi,
> As I'm working on block header parsing tool as my GSoC project, I would
> like to have an opinion on pygccxml, which is another C++ file parsing tool
> in python and is working quite well on parsing GNU Radio header files
> because of their brilliant, elegant yet simple and most importantly their
> generic structure. Also, pygccxml parser code itself is easy to visualize.
> libclang in python does a pretty good job in parsing all the header files,
> but it parses all the include files, and also the standard C++ ones because
> of it's compiler level parsing, which is not required, at least in our
> particular case. Whereas in pygccxml, it only parses that particular file,
> and so the included non-standard C++ header files particular to GNU Radio
> can be parsed by recursively opening them, parsing them using the same tool
> till we reach all the standard C++ header files thus leaving out all the
> standard C++ ones.
> So, I would definitely like to have an opinion on this.
> Thank you
>
> Best regards,
> Arpit Gupta
>
> ___
> 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] Problem building FPGA image in RFNOC

[Martin Braun]

John,

have you tried building a "vanilla" RFNoC image? That might help narrow
things down. Run 'make X310_RFNOC_HG' from your usrp3/top/x300 directory
(after loading the environment, which uhd_image_builder does for you).

-- M

On Tue, Feb 19, 2019 at 1:49 PM John_w_g  wrote:

> I am going through the *Getting Started with RFNOC *guide and the
> following command fails
>
> $ ./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 
> --fill-with-fifos
>
> I have installed a licensed version of Vivado 2017.4
>
> When I run the above command the output is:
>
> --Using the following blocks to generate image:
> * window
> * fft
> Adding CE instantiation file for 'X310_RFNOC_HG'
> changing temporarily working directory to
> /home/mpnta-rx/rfnoc/src/uhd-fpga/usrp3/tools/scripts/../../top/x300
> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
> - Vivado: Found (/opt/Xilinx/Vivado/2017.4/bin)
>
> Environment successfully initialized.
> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
> PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
> RFNOC=1 X310=1 TOP_MODULE=x300 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1
> SFP0_1GBE=1 SFP1_10GBE=1  RFNOC=1 X310=1"
> make[1]: Entering directory
> '/home/mpnta-rx/rfnoc/src/uhd-fpga/usrp3/top/x300'
> BUILDER: Checking tools...
> * GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
> * Python 2.7.12
> * Vivado v2017.4 (64-bit)
> *make[1]: *** No rule to make target
> '/home/mpnta-rx/rfnoc/src/uhd-fpga/usrp3/lib/xge/rtl/verilog/generic_mem_xilinx_block.v',
> needed by 'bin'.  Stop.*
> make[1]: Leaving directory
> '/home/mpnta-rx/rfnoc/src/uhd-fpga/usrp3/top/x300'
> Makefile:112: recipe for target 'X310_RFNOC_HG' failed
> make: *** [X310_RFNOC_HG] Error 2
>
> I have searched my computer for the referenced mission file
> *generic_mem_xilinx_block.v*  and it is not anywhere on the computer.  I
> assume that it should have been written when I installed Vivavdo.
>
> I am fully stuck here.  I need to build a custom image, and next add an
> OOT FPGA function, but I cant even start until I get past this stage.
>
> John G
>
>
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> 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] GSOC - Introduction and Project Idea Discussion

[Mayank Jhamtani]

Hi Johannes,
Thank you for your detailed response.

I would look into the two approaches you suggested, and get back once I
have something concrete.
I also welcome any suggestions as to which approach might be more suitable.

-Cheers,
Mayank

On Thu, Mar 7, 2019 at 2:42 PM Johannes Demel 
wrote:

> Hi Mayank,
>
> I'm glad you're interested in optimized codes.
>
> There are quite a lot of comms standards out there. They all come with
> their standardized codes. Unlike their general definition, standards use
> a small subset of all possible configurations a code might have.
> e.g. in general frozen bits in polar codes just need to have fixed
> values. In practice, frozen bits are all set to '0'. This simplifies
> decoders. Also, you could identify possible decoder functions that would
> benefit from specialization. This might be facilitated via templates or
> different implementations. Probably a combination of different
> techniques will be applied.
>
> This project may be approached in 2 different ways. Others may comment
> on these options.
> 1. Choose a specific standard code and implement it such that encoder
> and decoder exhibit maximum throughput/ minimum latency.
> 2. Find high performance implementations of standard codes and integrate
> them into the FECAPI. Make sure they seamlessly integrate into FECAPI.
> This might encompass discussions on how to integrate these
> implementations. Technical issues might come up but also license issues.
> Also, it would be challenging to add multiple new dependencies to GNU
> Radio.
>
> In most cases FEC in comms standards include:
> - encoder
> - decoder
> - puncturing
> - interleaver
>
> All in all, an information word goes into the encoder and a 'rate
> matched' codewords is emitted. On the decoder side a received vector
> represented as LLRs goes into the decoder and a decoded information word
> goes out.
>
> Clearly, the focus should be on the decoder in terms of performance
> because we expect this component to be the one with the heaviest load.
> Though, the other parts of the FEC standard should be implemented as well.
>
> Cheers
> Johannes
>
>
> Am 06.03.19 um 18:52 schrieb Mayank Jhamtani:
> > Hello all,
> > My name is Mayank, and I am interested to participate in GSoC'19 as a
> > student.
> >
> > I would want to work on the project "Standardized High Throughput FEC
> > Codes". This project interests me because I have been studying coding
> > theory for the past two years, and I would love to work on implementing
> > the same. I also have decent experience of coding in C++.
> > I am currently familiarizing myself with GNU Radio, and the gr-fec API
> > in particular.
> >
> > Also, I would be grateful if someone could clarify the exact expected
> > outcomes of the project idea, or give any other useful pointers, so that
> > I can better orient my efforts.
> >
> > Regards,
> > -Mayank
> >
> > ___
> > 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

Re: [Discuss-gnuradio] [USRP-users] continous Tx voice transmission

[Brian Padalino]

On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller 
wrote:

> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
>

Could message passing from the real-time blocks solve this issue in a
flexible way?

Imagine the following: blocks connected to actual hardware use the computer
wall clock to try to determine an average sample clock as it relates to the
CPU clock.  The USRP source block would be able to determine how many
samples/(sec of CPU clock) were coming in and Audio sink blocks would be
able to determine how many samples/(sec of CPU clock) were being consumed.
The same idea for Audio sources and USRP sinks.  Since the blocking calls
for USRP or Audio blocks could be wrapped in a high precision timer, once
any initial buffering had been filled up, the rate should settle out.

The modified blocks could then send a message of actual sample rate to
whoever needed to listen, and the appropriate sample rate could be figured
out in the "resampling FIFO".

What am I missing?  Why won't this work?

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

[Discuss-gnuradio] GSoC project idea discussion

[Arpit Gupta]

Hi,
As I'm working on block header parsing tool as my GSoC project, I would
like to have an opinion on pygccxml, which is another C++ file parsing tool
in python and is working quite well on parsing GNU Radio header files
because of their brilliant, elegant yet simple and most importantly their
generic structure. Also, pygccxml parser code itself is easy to visualize.
libclang in python does a pretty good job in parsing all the header files,
but it parses all the include files, and also the standard C++ ones because
of it's compiler level parsing, which is not required, at least in our
particular case. Whereas in pygccxml, it only parses that particular file,
and so the included non-standard C++ header files particular to GNU Radio
can be parsed by recursively opening them, parsing them using the same tool
till we reach all the standard C++ header files thus leaving out all the
standard C++ ones.
So, I would definitely like to have an opinion on this.
Thank you

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

Re: [Discuss-gnuradio] PC requirements for DVB-S2 processing at a high bandwidth

[Milos Milosavljevic]

Hi Brennan,

This is great. I am curious, has this been released or you are still
working on it?

Thanks
Milos

On Thu, 31 Jan 2019 at 20:35, Brennan Ashton 
wrote:

> In addition to what Ron mentioned there is an FPGA implementation of the
> LDPC portion of DVB-S2 that I will be releasing late February (I hoped to
> be ready to relase it by FOSDEM, but work got in the way) which achieves
> the full bitrate. The initial release will not be integrated with RFNoC,
> but that could be added at a later date. Right now it is mostly running on
> the Ultra96 board.
>
> --Brennan
>
> On Thu, Jan 31, 2019, 11:56 AM Ron Economos 
>> The processing requirement for DVB-S2 are significant, especially the
>> receiver. Since you're using an X-series USRP, I'll guess you're
>> interested in satellite downlinks which can be 30 to 50 Msyms/s.
>>
>> Basically, the requirement would be the most powerful system you can
>> afford. Something with an Intel i9 or Xeon Gold/Platinum series processor.
>>
>> Even then, real-time processing for the receiver will be limited unless
>> you use an FPGA or GPU for the LDPC decoding.
>>
>> The good news is that I've ported an SIMD optimized LDPC decoder to GNU
>> Radio.
>>
>> https://github.com/drmpeg/gr-dvbs2rx
>>
>> Which is ported from:
>>
>> https://github.com/xdsopl/LDPC
>>
>> However, it's still not capable of satellite bitrates.
>>
>> Ron
>>
>> On 1/31/19 10:33, Maria Jesus Cañavate Sanchez wrote:
>> > Hi there!
>> >
>> > My name is Maria and I would like to make a question regarding the
>> > kind of PC characteristics which would be required to be able to
>> > process the signal in real-time (on the PC) when using the maximum
>> > bandwidth available on the USRP X-series.
>> >
>> > The scenario would be the following one: we would like to use GNU
>> > radio to send and receive DVB-S2 signals. Hence, the PC will do all
>> > the processing to check the BER, constellation, EVM, etc. Do you think
>> > it is possible to use a PC (with SSD drive and some suggested
>> > requirements) which could do the processing in real time or the only
>> > way to achieve that bandwidth in real time would be using the FPGA of
>> > the USRP? If the second case, then I guess we will do the processing
>> > off-line =)
>> >
>> > Thank you very much in advance!
>> >
>> > Best regards,
>> >
>> > Maria Jesus
>> >
>> > ___
>> > 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
>


-- 
*Dr. Milos Milosavljevic*
Communications DSP/FPGA Engineer

*Spire Global UK Limited*

Unit 5A, Sky Park 5, 45 Finnieston Street, Glasgow, G3 8JU United Kingdom

*+44 (0)1413 439  <+44%207881%20295658>146*

*+44 (0)7954 161 6 <+44%207881%20295658>79*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting Background on GNU Radio on Android (was: GSOC : GNU Radio Projects)

[Andrej Rode]

Hi, 


On Thu, 7 Mar 2019 09:27:50 +
"Müller, Marcus (CEL)"  wrote:

> Very little… https://wiki.gnuradio.org/index.php/Android 
> of which https://wiki.gnuradio.org/index.php/GRAndDeps is probably the
> most important, but it's pretty dated. I don't think modern GNU Radio
> has problems with GCC 4.9 anymore, but it does not work with GCC
> before 4.8.4.
> 
> You'll notice the dependency tarball from the first link URL is dead.
> Andrej, you don't happen to know where that went?


You can rebuild the tarball using the script from the third link since
the old dependencies tarball would be pretty useless by now anyway.
(Or fix the script to the point it builds again).

Since there wasn't a big push for changing dependencies the linked deps
should still work (minus updated versions).

Cheers
Andrej


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

[Discuss-gnuradio] Getting Background on GNU Radio on Android (was: GSOC : GNU Radio Projects)

[CEL]

Very little… https://wiki.gnuradio.org/index.php/Android 
of which https://wiki.gnuradio.org/index.php/GRAndDeps is probably the
most important, but it's pretty dated. I don't think modern GNU Radio
has problems with GCC 4.9 anymore, but it does not work with GCC before
4.8.4.

You'll notice the dependency tarball from the first link URL is dead.
Andrej, you don't happen to know where that went?

Best regards,
Marcus

On Thu, 2019-03-07 at 09:32 +0530, Isuru Nuwanthilaka wrote:
> Hi,
> 
> I am searching on the background details of Android/GR development.
> What are the available resources in the community?
> 
> Best
> 
> On Mon, Mar 4, 2019 at 2:07 AM Müller, Marcus (CEL) 
> wrote:
> > Hi Isuru,
> > 
> > nice hearing from you!
> > Although I'd not be your mentor directly, it's exciting to hear you
> > want make GNU Radio accessible for Android users.
> > It's pretty exciting to hear you're using an N210 from Android. Can
> > you
> > tell us how that works? What software did you need to write, what
> > device does Android run on? How does that device connect to the
> > N210?
> > 
> > Best regards,
> > Marcus
> > 
> > On Sun, 2019-03-03 at 10:34 +0530, Isuru Nuwanthilaka wrote:
> > > Hi,
> > > 
> > > I am final year undergraduate following Electronic and
> > > Telecommunication Engineering at University of Moratuwa, Sri
> > Lanka.I
> > > am very keen to learn new things,contribute and improve my
> > skills. I
> > > have a good academic and practical knowledge.
> > > 
> > > So far, I have used Java,Python and Go programming languages in
> > my
> > > projects. 
> > > 
> > > During my internship  period, I have contributed to two
> > industrial
> > > software projects; One was to build  Quota  Management System for
> > a
> > > Wifi Solution. There I got exposure to Java(Springboot),
> > PostgreSQL
> > > databases, Docker for creating a development environment, also
> > some
> > > network devices like Cisco ISG, Radiator AAA Server. The other
> > > project was to build an IoT system to monitor production lane in
> > a
> > > Soap Manufacturing factory. There I was working with ESP8266
> > based
> > > dev boards, Java, Azure IoT Hub etc.
> > > 
> > > Addition to these things, I have experience in Android
> > development
> > > with Java. I have two demo projects in Google Play 
> > > 1. GPA calculator App : 
> > > https://play.google.com/store/apps/details?id=com.isumalab.gpa 
> > > 2. Tutorial Distributing App : 
> > > https://play.google.com/store/apps/details?id=com.isumalab.learn
> > > 
> > > Currently, I am working on a D2D communication project using
> > Android,
> > > USRP N210. Here we are trying to looking into features like
> > caching
> > > at devices, algorithms to find what contents to cache, paring
> > etc.
> > > 
> > > In the GSOC GNU radio project list , I found interest in
> > Android/GR
> > > project (https://wiki.gnuradio.org/index.php/GSoCIdeas#Android) .
> > I
> > > think my exposure to Android, Java,Docker and the knowledge in
> > > DSP,telecommunication will help to contribute to this project.
> > And
> > > also I have access to USRP N210 this year. Therefore I like to
> > > discuss details and contribute t o improve the Android support
> > for
> > > GNU Radio.
> > > 
> > > Best
> > > Isuru 
> > > 
> > > On Sun, Mar 3, 2019 at 2:16 AM Wunsch, Felix (CEL) <
> > > felix.wun...@kit.edu> wrote:
> > > > Hi, 
> > > > 
> > > > glad to hear you're interested! Your email was quite generic.
> > Why
> > > > don't you give us some more details, for example about your
> > > > background, your skills, software projects you have worked on
> > > > before, programming languages you know, and  (most
> > > > importantly) specific projects you would like to work on?
> > > > 
> > > > Cheers,
> > > > Felix
> > > > 
> > > > Von: Discuss-gnuradio <
> > > > discuss-gnuradio-bounces+felix.wunsch=kit@gnu.org> im
> > Auftrag
> > > > von Isuru Nuwanthilaka 
> > > > Gesendet: Samstag, 2. März 2019 11:09
> > > > An: discuss-gnuradio@gnu.org
> > > > Betreff: [Discuss-gnuradio] GSOC : GNU Radio Projects
> > > >  
> > > > Hi,
> > > > 
> > > > I am interested in GNU projects listed in GSOC program.
> > Therefore I
> > > > want to discuss the ideas with the dev team/mentors.
> > > > 
> > > > Best regards
> > > > -- 
> > > > Isuru Nuwanthilaka,
> > > > Undergraduate,
> > > > Department of Electronics and Telecommunication Engineering,
> > > > University of Moratuwa.
> > > > Tel | 0773871605
> > > 
> > > 
> > > ___
> > > 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] GSOC - Introduction and Project Idea Discussion

[Johannes Demel]

Hi Mayank,

I'm glad you're interested in optimized codes.

There are quite a lot of comms standards out there. They all come with 
their standardized codes. Unlike their general definition, standards use 
a small subset of all possible configurations a code might have.
e.g. in general frozen bits in polar codes just need to have fixed 
values. In practice, frozen bits are all set to '0'. This simplifies 
decoders. Also, you could identify possible decoder functions that would 
benefit from specialization. This might be facilitated via templates or 
different implementations. Probably a combination of different 
techniques will be applied.

This project may be approached in 2 different ways. Others may comment 
on these options.
1. Choose a specific standard code and implement it such that encoder 
and decoder exhibit maximum throughput/ minimum latency.
2. Find high performance implementations of standard codes and integrate 
them into the FECAPI. Make sure they seamlessly integrate into FECAPI.
This might encompass discussions on how to integrate these 
implementations. Technical issues might come up but also license issues. 
Also, it would be challenging to add multiple new dependencies to GNU Radio.

In most cases FEC in comms standards include:
- encoder
- decoder
- puncturing
- interleaver

All in all, an information word goes into the encoder and a 'rate 
matched' codewords is emitted. On the decoder side a received vector 
represented as LLRs goes into the decoder and a decoded information word 
goes out.

Clearly, the focus should be on the decoder in terms of performance 
because we expect this component to be the one with the heaviest load.
Though, the other parts of the FEC standard should be implemented as well.

Cheers
Johannes


Am 06.03.19 um 18:52 schrieb Mayank Jhamtani:
> Hello all,
> My name is Mayank, and I am interested to participate in GSoC'19 as a 
> student.
> 
> I would want to work on the project "Standardized High Throughput FEC 
> Codes". This project interests me because I have been studying coding 
> theory for the past two years, and I would love to work on implementing 
> the same. I also have decent experience of coding in C++.
> I am currently familiarizing myself with GNU Radio, and the gr-fec API 
> in particular.
> 
> Also, I would be grateful if someone could clarify the exact expected 
> outcomes of the project idea, or give any other useful pointers, so that 
> I can better orient my efforts.
> 
> Regards,
> -Mayank
> 
> ___
> 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