[Discuss-gnuradio] GSOC 2016: Help Review Project Proposal

[Tanero Juthero]

  I made an update to the proposal,mentors please help me review the
proposal,your opinions highly

awaited.Here is the link
https://github.com/tanerochris/gsoc-2016/blob/master/%20gsoc_2016_application.pdf

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

[Discuss-gnuradio] problem with packet encoder block

[Miguel Santos]

Hi all!
While I was using the block Packet Encoder I realized that my input file
(saved before that block) becomes a lot bigger.
So I made a simple example to show that problem.

Vector Source ---> Packet Encoder ---> Throttle ---> Number Sink
   ---> File Sink

Just to make it clear, File Sink is connected to Vector Source, BEFORE
Packet Encoder.
Running the flow graph the same amount of time, I get an input file of
700~800 MB for this flow graph and ~3MB for the same flow graph with
Packet Encoder bypassed.
Is this a bug? Could it be a larger processing time of that block that's
delaying the data flow? Am I missing something? How can I solve that?
Any help would be nice.

Thanks for your time,
Miguel





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

Re: [Discuss-gnuradio] [USRP-users] Issues with RFNoC and GNU Radio / throttling

[Martin Braun]

On 03/21/2016 03:23 PM, Michael Wentz wrote:
> Once I did that I found that the data coming back exactly matched RTL
> simulations, which I ran for about 1M samples. This led me to put
> another throttle right before my RFNoC block, which solved the problems
> in the larger flowgraph - it just wasn't clear why the second throttle
> (or FIFO) was necessary. Without it the data was somehow being
> corrupted. It looked like samples were being dropped before making it
> back to GNU Radio, since I saw my frame headers, just not in the
> positions I expected them (e.g. every 10k bits). I wasn't able to
> determine exactly what was happening or if there was a pattern to it. I
> may spend some time investigating, but for now the FIFO seems to make my
> CE usable.

OK, I see. That's interesting. This might be a software bug in the
transport code. Thanks for the input!

Cheers,
Martin



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

Re: [Discuss-gnuradio] GNU Radio Website Update

[Ben Hilburn]

Hi all -

Thanks to Johnathan's devops skills, the previously mentioned temporary
URLs have been updated:

1) The website for GRCon is now in it's final place, which you can find
here: http://gnuradio.org/grcon-2016
2) gnuradio.org now redirects to Redmine, as it did previously.

Let us know if you have any questions or spot any issues!

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

Re: [Discuss-gnuradio] Editing usrp_spectrum_sense.py

[Marcus Müller]

Dear Fikrat,

Feed in a known power, note down the digital power, repeat for another
known power.
You'll get three input power->digital power mappings.

Now, assume the power transfer function is a linear one:

$P_{digital} = G\cdot P_{analog} + P_{noise}$

With the two $(P_{digital}, P_{analog})$ measurements you can simply
deduce the slope $G$ of the above function; simple math, subtract the
equations:

$P_{digital,1}-P_{digital,2}=(G\cdot P_{analog,1} + P_{noise})-(G\cdot
P_{analog,2} + P_{noise})=G(P_{analog,1}-P_{analog,2})$

and find $G$ and the offset $P_{noise}$.

Repeat with a few other known powers to make sure you're in the linear
region.

Whatever you do, never feed in more than -15dBm into your device!

Best regards,
Marcus

On 21.03.2016 23:05, Fikrat Al-Kazimi wrote:
> Hi guys,
>
> I hope you're all doing well.
>
> I'm been searching a lot and I read that if I want to measure the
> absolute power ( in W or dBm ) using the usrp_spectrum_sense.py, then
> I must calibrate the USRP by injecting a signal of known physical power. 
>
> Can someone please walk me through the calibration steps? How can I
> accomplish this and what do I edit in the code after calibration is
> complete to help me sense the absolute power instead of power_dB?
>
> Thank you for your help!
>
>
> ___
> 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] Editing usrp_spectrum_sense.py

[Fikrat Al-Kazimi]

Hi guys,

I hope you're all doing well.

I'm been searching a lot and I read that if I want to measure the absolute
power ( in W or dBm ) using the usrp_spectrum_sense.py, then I must
calibrate the USRP by injecting a signal of known physical power.

Can someone please walk me through the calibration steps? How can I
accomplish this and what do I edit in the code after calibration is
complete to help me sense the absolute power instead of power_dB?

Thank you for your help!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Handling of IQ files

[Henry Barton]

I like the concept of your program. It looks just like what I’m trying to write.






Sent from Windows Mail





From: Vitt Benv
Sent: ‎Sunday‎, ‎March‎ ‎20‎, ‎2016 ‎4‎:‎16‎ ‎PM
To: discuss-gnuradio@gnu.org





Hi,
this [ https://sourceforge.net/projects/automodrecog/ ] is my little
effort about handling IQ files.
The input IQ file is recorded with HDSDR, very nice piece of sw, that
as a good recording scheduler. By the way the file provided can be
played with it. I do also some tests with IQ file produced by R
EM100 receiver.
I wrote this [horrible] application for personal use and it's very raw IMO
I'm interested on HF monitoring and the main goal is to find SSB
emission along time, not quite simple task.

In brief:
- read params from input file
- split it in smaller chunk and save FFT for each chunk
- sum (maxhold) or avg (average) all the FFTs
- find relevant ( over threshold) carrier and try to "pack" them to
find "bandwidth" associated
- build a report as .html page with a .png file that represent the result.

The most difficult part is to estimate the best "threshold", and at
the moment I'm almost stuck there and moreover RL reclaims my
presence :-)

... my euro "cent" on the subject.

Victor I3VFJ

___
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] gnu radio installation on windows

[Marcus Müller]

Do you have Cheetah installed?

On 03/21/2016 09:18 PM, Rohit Jatana wrote:
> hey!
>
> The error message showing while installing is
>
>
> $ cmake ../
> -- The CXX compiler identification is GNU 5.3.0
> -- The C compiler identification is GNU 5.3.0
> CMake Warning at
> /usr/share/cmake-3.3.2/Modules/Platform/CYGWIN.cmake:15 (messag  
>  
>e):
>   CMake no longer defines WIN32 on Cygwin!
>
>   (1) If you are just trying to build this project, ignore this warning or
>   quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment
> or in
>   the CMake cache.  If later configuration or build errors occur then this
>   project may have been written under the assumption that Cygwin is WIN32.
>   In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.
>
>   (2) If you are developing this project, add the line
>
> set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is
> required
>
>   at the top of your top-level CMakeLists.txt file or set the minimum
>   required version of CMake to 2.8.4 or higher.  Then teach your
> project to
>   build on Cygwin without WIN32.
> Call Stack (most recent call first):
>  
> /usr/share/cmake-3.3.2/Modules/CMakeSystemSpecificInformation.cmake:36
> (includ  
>  e)
>   CMakeLists.txt:29 (project)
>
>
> -- Check for working CXX compiler: /usr/bin/c++.exe
> -- Check for working CXX compiler: /usr/bin/c++.exe -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Build type not specified: defaulting to release.
> -- Found Git: /usr/bin/git.exe
> -- Performing Test HAVE_VISIBILITY_HIDDEN
> -- Performing Test HAVE_VISIBILITY_HIDDEN - Success
> -- Performing Test HAVE_WARN_SIGN_COMPARE
> -- Performing Test HAVE_WARN_SIGN_COMPARE - Success
> -- Performing Test HAVE_WARN_ALL
> -- Performing Test HAVE_WARN_ALL - Success
> -- Performing Test HAVE_WARN_NO_UNINITIALIZED
> -- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
> -- NO PERF COUNTERS
> -- Found PythonLibs: /usr/lib/libpython2.7.dll.a (found suitable
> version "2.7.10  
>  ", minimum
> required is "2")
> -- Found SWIG: /usr/bin/swig.exe (found version "3.0.7")
> -- Minimum SWIG version required is 1.3.31
> --
> -- The build system will automatically enable all components.
> -- Use -DENABLE_DEFAULT=OFF to disable components by default.
> --
> -- Configuring python-support support...
> --   Dependency PYTHONLIBS_FOUND = TRUE
> --   Dependency SWIG_FOUND = TRUE
> --   Dependency SWIG_VERSION_CHECK = TRUE
> --   Enabling python-support support.
> --   Override with -DENABLE_PYTHON=ON/OFF
> -- Found PkgConfig: /usr/bin/pkg-config.exe (found version "0.29")
> -- checking for module 'cppunit'
> --   found cppunit, version 1.12.1
> -- Found CPPUNIT: /usr/lib/libcppunit.dll.a;dl
> --
> -- Configuring testing-support support...
> --   Dependency CPPUNIT_FOUND = TRUE
> --   Enabling testing-support support.
> --   Override with -DENABLE_TESTING=ON/OFF
> --
> -- Configuring volk support...
> --   Enabling volk support.
> --   Override with -DENABLE_VOLK=ON/OFF
> CMake Warning (dev) at volk/CMakeLists.txt:53 (include):
>   Syntax Warning in cmake code at
>
> /cygdrive/c/gnu/gnuradio-3.7.2/volk/cmake/GrPython.cmake:202:44
>
>   Argument not separated from preceding token by whitespace.
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at volk/CMakeLists.txt:53 (include):
>   Syntax Warning in cmake code at
>
> /cygdrive/c/gnu/gnuradio-3.7.2/volk/cmake/GrPython.cmake:202:92
>
>   Argument not separated from preceding token by whitespace.
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at volk/CMakeLists.txt:53 (include):
>   Syntax Warning in cmake code at
>
> /cygdrive/c/gnu/gnuradio-3.7.2/volk/cmake/GrPython.cmake:202:100
>
>   Argument not separated from preceding token by whitespace.
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Found PythonInterp: /usr/bin/python2 (found suitable version
> "2.7.10", minimu  
>  m required is
> "2")
> --
> -- Python checking for python >= 2.5
> -- Python checking for python >= 2.5 - found
> --
> -- Python checking for Cheetah >= 2.0.0
> -- Python checking for 

Re: [Discuss-gnuradio] Upgrading GR in MacPorts

[Michael Dickens]

On 03/21/2016 01:50 PM, Thomas Wagner wrote:
> I will try to upgrade the installation on the Macbook to 3.9.1. It 
> took me all night on Saturday to get in on the Macmini,  I kept 
> getting GnuRadio error messages on compile,   I finally had to 
> uninstall it and start over, then it worked.I used the macports 
> update command. When I do it on the Macbook, should I uninstall 
> 3.7.3 first and then install 3.9.1?

Hi Tom - In general, MacPorts supports upgrading any port while a prior
version is installed. For some specific ports this will not work and the
port upgrade will error out with information on how to do the update.
The GNU Radio ports generally upgrade well without
deactivating/uninstalling any prior version, but if you want to be safe
you can always deactivate the current active version first -- don't
uninstall it in case the upgrade fails!

My advice is to issue the following commands when updating either
MacPorts or any port within MacPorts.

First:
{{{
sudo port selfupdate
sudo port upgrade outdated
}}}
and, if there are errors along the way (say with port 'FOO'), then try:
{{{
sudo port clean FOO
sudo port upgrade FOO
}}}
and see if that helps; or, if port errors out with a specific comment
then follow the instructions in the comment before doing the clean /
upgrade.

The selfupdate will often upgrade the GNU Radio ports too, so look out
for that. If not, then you can install whatever the latest version of
GNU Radio (etc) is via:
{{{
sudo port install gnuradio
}}}

For Mac OS X 10.7 and newer 'port' will usually download a pre-compiled
binary with all default variants. If you need specific variants then the
install will likely need to be from source. In either case if you have
issues with the upgrade then post to this list or, even better, ping me
directly.

Hope this helps! - MLD

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

[Discuss-gnuradio] gnu radio installation on windows

[Rohit Jatana]

hey!

The error message showing while installing is


$ cmake ../
-- The CXX compiler identification is GNU 5.3.0
-- The C compiler identification is GNU 5.3.0
CMake Warning at /usr/share/cmake-3.3.2/Modules/Platform/CYGWIN.cmake:15
(messag
   e):
  CMake no longer defines WIN32 on Cygwin!

  (1) If you are just trying to build this project, ignore this warning or
  quiet it by setting CMAKE_LEGACY_CYGWIN_WIN32=0 in your environment or in
  the CMake cache.  If later configuration or build errors occur then this
  project may have been written under the assumption that Cygwin is WIN32.
  In that case, set CMAKE_LEGACY_CYGWIN_WIN32=1 instead.

  (2) If you are developing this project, add the line

set(CMAKE_LEGACY_CYGWIN_WIN32 0) # Remove when CMake >= 2.8.4 is
required

  at the top of your top-level CMakeLists.txt file or set the minimum
  required version of CMake to 2.8.4 or higher.  Then teach your project to
  build on Cygwin without WIN32.
Call Stack (most recent call first):
  /usr/share/cmake-3.3.2/Modules/CMakeSystemSpecificInformation.cmake:36
(includ
   e)
  CMakeLists.txt:29 (project)


-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found Git: /usr/bin/git.exe
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_WARN_SIGN_COMPARE
-- Performing Test HAVE_WARN_SIGN_COMPARE - Success
-- Performing Test HAVE_WARN_ALL
-- Performing Test HAVE_WARN_ALL - Success
-- Performing Test HAVE_WARN_NO_UNINITIALIZED
-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
-- NO PERF COUNTERS
-- Found PythonLibs: /usr/lib/libpython2.7.dll.a (found suitable version
"2.7.10
   ", minimum required is "2")
-- Found SWIG: /usr/bin/swig.exe (found version "3.0.7")
-- Minimum SWIG version required is 1.3.31
--
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
--
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Enabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
-- Found PkgConfig: /usr/bin/pkg-config.exe (found version "0.29")
-- checking for module 'cppunit'
--   found cppunit, version 1.12.1
-- Found CPPUNIT: /usr/lib/libcppunit.dll.a;dl
--
-- Configuring testing-support support...
--   Dependency CPPUNIT_FOUND = TRUE
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
--
-- Configuring volk support...
--   Enabling volk support.
--   Override with -DENABLE_VOLK=ON/OFF
CMake Warning (dev) at volk/CMakeLists.txt:53 (include):
  Syntax Warning in cmake code at

/cygdrive/c/gnu/gnuradio-3.7.2/volk/cmake/GrPython.cmake:202:44

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at volk/CMakeLists.txt:53 (include):
  Syntax Warning in cmake code at

/cygdrive/c/gnu/gnuradio-3.7.2/volk/cmake/GrPython.cmake:202:92

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at volk/CMakeLists.txt:53 (include):
  Syntax Warning in cmake code at

/cygdrive/c/gnu/gnuradio-3.7.2/volk/cmake/GrPython.cmake:202:100

  Argument not separated from preceding token by whitespace.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.10",
minimu
   m required is "2")
--
-- Python checking for python >= 2.5
-- Python checking for python >= 2.5 - found
--
-- Python checking for Cheetah >= 2.0.0
-- Python checking for Cheetah >= 2.0.0 - not found
CMake Error at volk/CMakeLists.txt:62 (message):
  Cheetah templates required to build VOLK


-- Configuring incomplete, errors occurred!
See also "/cygdrive/c/gnu/gnuradio-3.7.2/build/CMakeFiles/CMakeOutput.log".



someone please help me out.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QPSK demodulator does not operate when the transmission rate is low

[Damindra Bandara]

Hi,

I am trying to transmit messages from a message source modulated using
QPSK. A message is transmitted in every second. At the receiving end I am
writing the messages to a message sink. I am using Etuss USRP N200 to test
the setup.

The problem is I do not receive the message at the other end. When I
observe the constellations at the receiver  it shows that the QPSK
demodulator does not remain synchronized.

When I tried this in a simulation environment (using a channel model) the
experiment works fine. If I transmit a file using this setup it works fine
too. But when I transmit a message every 1 second it is not transmitting.

The transmitter end: msg source -->packet encoder --> QPSK modulator -->
USRP sink

Receiver end: USRP source --> Poly phase clock sync --> CMA equilizer -->
Costas loop --> QPSK demodulator  --> Packet decoder --> msg sink

I really appreciate if you could help me to solve this issue.

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

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Usman Haider]

I have added lambda expression in deliverables based on Tim's comments.
This will allow user to enter lambda expression in GUI. That expression
will be then evaluated on samples and result will be displayed. Rather than
providing fixed mathematical function (scale/normalize), user  can apply
anonymous functions, they want, on samples using Lambda construct. This
will give user more flexibility. I have updated my proposal. You can see it
on following link

https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf

Awaiting feedback.

Regards,
Usman

On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider 
wrote:

> Hi Community,
>
> I have made my proposal for the subject GSoC idea. Please have a look and
> give feedback. Thanks for your time.
>
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>
> Regards,
> Usman
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Scrambler - Descrambler

[devin kelly]

Hello,

I'm a little confused on how to use the scrambler and descrambler, it looks
like the descrambler always preprends a byte to my stream.  When I run this
flowgraph I get this from the message ports (the first message is the
original message, the second message is from the descrambler):

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 4e
***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: 06 d0 22 e7 d5 20 f8 e9 38 a1
***


I'm not totally sure what do about this, I've tried adding a delay block
but that screws up my packet_len tags.

Here's the original work function:

{
const unsigned char *in = (const unsigned char*)input_items[0];
unsigned char *out = (unsigned char*)output_items[0];

for(int i = 0; i < noutput_items; i++) {
out[i] = d_lfsr.next_bit_descramble(in[i]);
}

return noutput_items;
}

I've also tried this work function (my approach here is to ignore the first
byte out of the descrambler and then put junk into the last byte which
would then be ignored on the next call to work() and yes I realize this
isn't a general solution)

{
const unsigned char *in = (const unsigned char*)input_items[0];
unsigned char *out = (unsigned char*)output_items[0];

  unsigned char junk;
  for(int i = 0; i < noutput_items + 8; i++) {
  if (i < 8) {
junk = d_lfsr.next_bit_descramble(in[i]);
  } else if (i > noutput_items) {
out[i - 8] = d_lfsr.next_bit_descramble(0xff);
  } else {
out[i - 8] = d_lfsr.next_bit_descramble(in[i]);
  }
  }

return noutput_items;
}

I run the flowgraph and now my last byte is junk (argh!)


***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 4e
***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 3d

Does anyone have any advice on how to use to the scrambler and
descrambler?  Would writing my own message blocks that use the LFSR be a
better approach?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM tx rx error

[Martin Braun]

Jenny,

we have a limit in place for packet sizes, which depends on your system.
If you type sysctl -a, it'll say something like

kernel.shmmax = 18446744073692774399


100 OFDM symbols seems pretty long, though. If your packet length is 96,
as in the example, that means a total packet length of 100 (including
CRC). With 48 useful carriers, you get 6 bytes per OFDM symbol, which
results in 17 OFDM symbols, plus 2 more for the header. You'll need to
give us some more info for us to help you.

Cheers,
Martin

On 03/19/2016 11:44 AM, Jingyi Sun wrote:
> Hi, 
> 
> I'm using the examples rx_ofdm.grc and tx_ofdm.grc together to transmit
> and receive packets over the air.  Both work over a simulated channel,
> but when I actually transmit and receive over the air, I get the error:
> 
> *"Detected a packet larger than max frame size (100 symbols)"*
> 
> I saw the previous thread on this called "OFDM transmitter receiver"
> which goes as follows, but I don't really know what to make of this... 
> 
> I tried to run /sysctl kernel.shmmax /in terminal, but I got the message
> "No such file or directory". I'm also not sure what kernel.shmmax is.
> 
> These are my parameters:
> 
> fft length= 64
> 
> cyclic prefix = 16
> packet length = 96
> no. of occupied carriers = 53
> no. of pilot carriers = 4
> 
> 
> I'm very new to gnuradio, and any insights into this would be appreciated!!
> 
> 
> Thanks,
> Jenny
> 
> --
> 
> *From*:   Martin Braun
> *Subject*:Re: [Discuss-gnuradio] OFDM transmitter receiver
> *Date*:   Tue, 26 Aug 2014 11:10:53 +0200
> *User-agent*: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
> Thunderbird/24.6.0
> 
> 
> 
> Try and not kill the context in a mailing list thread; these are also
> archived and are used by others for referral.
> 
> Max frame size depends on max_output_buffer(). 80 symbols at a 64-sized
> FFT would be ~40kB... that doesn't seem unreasonable. Not sure if
> there's a problem here. I suggest you have a look at the buffer sizes to
> track down this problem.
> 
> M
> 
> On 08/25/2014 03:31 PM, Martin Braun wrote:
>>/What's your kernel.shmmax value? (run sysctl kernel.shmmax)/
>>//
>>/M/
>>//
>>/On 08/25/2014 12:47 PM, sreena p h wrote:/
>>/> Hi/
>>/> I used the ofdm transmitter receiver blocks to create a simple system as/
>>/> shown in the attachment. I used the system parameters as those used in/
>>/> the example transmitter and receiver grcs. Now I get error that/
>>/> 'Detected a packet larger than max frame size (80 symbols)'. I would/
>>/> like to know how the max frame size is set and should I add more/
>>/> information to the grc. /
>>/>/
>>/> My transmitter- receiver parameters/
>>/>/
>>/> fft length= 64/
>>/> cyclic prefix = 16/
>>/> packet length = 96/
>>/> no. of occupied carriers = 48/
>>/> no. of pilot carriers = 4/
>>/>/
>>/>/
>>/>/
>>/> ___/
> 
> 
> 
> ___
> 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] Installation of gnuradio on windows(cygwin)

[Rohit Jatana]

hey!
I am stuck in installing the gnuradio on windows. I have created the cygwin
environment and stuck in the further part.
So please help me out or maybe you can provide me some steps to complete
the installation( i have refered those on website).

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

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Marcus, many thanks I will do it.

On Mon, Mar 21, 2016 at 11:01 AM, Marcus Müller 
wrote:

> I'd encourage you to either fix the Bit Error Rate block or write
> something that does your job. In fact, the unmodified ofdm_loopback example
> doesn't work as BER test, because all packets are identical, and if a
> packet has errors, the OFDM receiver will drop it, so you'd never see an
> error.
>
> Open rx_ofdm.grc ; it is a very similar example, but instead of having the
> black box "OFDM Receiver", you see how the OFDM receiver internally works.
> Play with the channel model; e.g. set the noise voltage really high (1.0)
> and the frequency offset to e.g. 2.0/fft_len. You'll see a lot of
>
> INFO: Detected and invalid packet at item 
>
> printed.
> Now, change these parameters.
> Your ratio of valid packets and invalid packets gives you a packet error
> rate.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:47, Diyar Muhammed wrote:
>
> Marcus,
> I look at ofdm_loopback.grc example, I made the same scenario but I had
> problem with Error Rate block I got error rate around 4 to 5, as my
> knowledge that is not right I think should be between 0 to 1.
> If there is a transceiver example with measure bit error rate that will be
> helpful for me.
> in advance thank you.
>
> On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller 
> wrote:
>
>> Note that the benchmark_rx/_tx example is really a bit old, and I always
>> try to steer people away from it towards the newer OFDM examples that are
>> far more flexible and behave a lot more like a real system would.
>>
>> Have a look at the ofdm_loopback.grc example; you can replace the
>> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 11:34, Diyar Muhammed wrote:
>>
>> many thanks
>>
>> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Diyar,
>>>
>>> > I look at tx benchmark help I could not find rates but there is packet
>>> size and megabytes to transmit.
>>>
>>> benchmark_tx --help should help you.
>>> You set the bandwidth, which sets the sampling rate; together with the
>>> occupied tones number related to the FFT length, you get a symbol rate.
>>> Together with the modulation you set, this gives you a
>>>
>>> Since only one program can use a USRP at a time, you can't use
>>> benchmark_tx and benchmark_rx at the same time.
>>> Instead, use benchmark_tx with the "--to-file" option to save the
>>> samples to a file, and build a quick GNU Radio flow graph in GRC that has a
>>> file source (reading that file), a USRP sink (fed from the file source), a
>>> USRP source, and a file sink (saving the samples from the USRP source to
>>> another file).
>>>
>>> Then use benchmark_rx with the --from-file option to read in these saved
>>> samples.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 21.03.2016 11:17, Diyar Muhammed wrote:
>>>
>>> Dear Marcus,
>>> Thank you very much indeed for fast replying.
>>> I look at tx benchmark help I could not find rates but there is packet
>>> size and megabytes to transmit.
>>> so that, which one do you mean packet size or megabytes?
>>> it is okay to use USRP B210 for transmitting and receiving by using to
>>> benchmark file?
>>> because when I used one of them (tx or rx) and then I wanted to run
>>> another one the error come up (no device found for empty device address).
>>> in advance many thanks.
>>>
>>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
 Diyar,

 with the benchmark_ scripts, you **set** the rates, and you can only
 observe how many packets were successfully transmitted.
 The rest is really very basic math.

 Best regards,
 Marcus


 On 21.03.2016 10:50, Diyar Muhammed wrote:

 Dear SangHyuk,
 I would like to know how to measure Throughput and BER by using
 benchmark tx and rx?
 could you show or explain with real example as you used.
 in advance thanks.

 On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller <
 marcus.muel...@ettus.com> wrote:

> Hi,
>
> On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote:
> > I want to know other user's performance (avg performance).
> Yes, but what is "user's performance"? Is it more important to have
> higher throughput, or lower error rates? What about robustness?
>
> I mean, the OFDM rx_benchmark is a really static example.
> You might find a setting that maximizes troughput for a given channel,
> but imagine something happens that reduces your receiver's SNR by 3dB:
> Now your suddenly losing a lot of performance.
>
> Really "how can I parameterize this" can only be answered for a single,
> mathematically well-defined target, and for a well-defined channel.
>

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

I'd encourage you to either fix the Bit Error Rate block or write
something that does your job. In fact, the unmodified ofdm_loopback
example doesn't work as BER test, because all packets are identical, and
if a packet has errors, the OFDM receiver will drop it, so you'd never
see an error.

Open rx_ofdm.grc ; it is a very similar example, but instead of having
the black box "OFDM Receiver", you see how the OFDM receiver internally
works.
Play with the channel model; e.g. set the noise voltage really high
(1.0) and the frequency offset to e.g. 2.0/fft_len. You'll see a lot of

INFO: Detected and invalid packet at item 

printed.
Now, change these parameters.
Your ratio of valid packets and invalid packets gives you a packet error
rate.

Best regards,
Marcus

On 21.03.2016 11:47, Diyar Muhammed wrote:
> Marcus,
> I look at ofdm_loopback.grc example, I made the same scenario but I
> had problem with Error Rate block I got error rate around 4 to 5, as
> my knowledge that is not right I think should be between 0 to 1.
> If there is a transceiver example with measure bit error rate that
> will be helpful for me.
> in advance thank you.
>
> On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller
> > wrote:
>
> Note that the benchmark_rx/_tx example is really a bit old, and I
> always try to steer people away from it towards the newer OFDM
> examples that are far more flexible and behave a lot more like a
> real system would.
>
> Have a look at the ofdm_loopback.grc example; you can replace the
> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:34, Diyar Muhammed wrote:
>> many thanks 
>>
>> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller
>> > wrote:
>>
>> Diyar,
>>
>> > I look at tx benchmark help I could not find rates but
>> there is packet size and megabytes to transmit.
>>
>> benchmark_tx --help should help you.
>> You set the bandwidth, which sets the sampling rate; together
>> with the occupied tones number related to the FFT length, you
>> get a symbol rate.
>> Together with the modulation you set, this gives you a
>>
>> Since only one program can use a USRP at a time, you can't
>> use benchmark_tx and benchmark_rx at the same time.
>> Instead, use benchmark_tx with the "--to-file" option to save
>> the samples to a file, and build a quick GNU Radio flow graph
>> in GRC that has a file source (reading that file), a USRP
>> sink (fed from the file source), a USRP source, and a file
>> sink (saving the samples from the USRP source to another file).
>>
>> Then use benchmark_rx with the --from-file option to read in
>> these saved samples.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 11:17, Diyar Muhammed wrote:
>>> Dear Marcus,
>>> Thank you very much indeed for fast replying.
>>> I look at tx benchmark help I could not find rates but there
>>> is packet size and megabytes to transmit.
>>> so that, which one do you mean packet size or megabytes?
>>> it is okay to use USRP B210 for transmitting and receiving
>>> by using to benchmark file?
>>> because when I used one of them (tx or rx) and then I wanted
>>> to run another one the error come up (no device found for
>>> empty device address).
>>> in advance many thanks.
>>>
>>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller
>>> >
>>> wrote:
>>>
>>> Diyar,
>>>
>>> with the benchmark_ scripts, you **set** the rates, and
>>> you can only observe how many packets were successfully
>>> transmitted.
>>> The rest is really very basic math.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 21.03.2016 10:50, Diyar Muhammed wrote:
 Dear SangHyuk,
 I would like to know how to measure Throughput and BER
 by using benchmark tx and rx?
 could you show or explain with real example as you used.
 in advance thanks.

 On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
 > wrote:

 Hi,

 On 21.03.2016 01 :37, SangHyuk
 Kim wrote:
 > I want to know other user's performance (avg
 performance).
 Yes, but what is "user's performance"? Is it more
 important to have
 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Marcus,
I look at ofdm_loopback.grc example, I made the same scenario but I had
problem with Error Rate block I got error rate around 4 to 5, as my
knowledge that is not right I think should be between 0 to 1.
If there is a transceiver example with measure bit error rate that will be
helpful for me.
in advance thank you.

On Mon, Mar 21, 2016 at 10:36 AM, Marcus Müller 
wrote:

> Note that the benchmark_rx/_tx example is really a bit old, and I always
> try to steer people away from it towards the newer OFDM examples that are
> far more flexible and behave a lot more like a real system would.
>
> Have a look at the ofdm_loopback.grc example; you can replace the
> (channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:34, Diyar Muhammed wrote:
>
> many thanks
>
> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller 
> wrote:
>
>> Diyar,
>>
>> > I look at tx benchmark help I could not find rates but there is packet
>> size and megabytes to transmit.
>>
>> benchmark_tx --help should help you.
>> You set the bandwidth, which sets the sampling rate; together with the
>> occupied tones number related to the FFT length, you get a symbol rate.
>> Together with the modulation you set, this gives you a
>>
>> Since only one program can use a USRP at a time, you can't use
>> benchmark_tx and benchmark_rx at the same time.
>> Instead, use benchmark_tx with the "--to-file" option to save the samples
>> to a file, and build a quick GNU Radio flow graph in GRC that has a file
>> source (reading that file), a USRP sink (fed from the file source), a USRP
>> source, and a file sink (saving the samples from the USRP source to another
>> file).
>>
>> Then use benchmark_rx with the --from-file option to read in these saved
>> samples.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 11:17, Diyar Muhammed wrote:
>>
>> Dear Marcus,
>> Thank you very much indeed for fast replying.
>> I look at tx benchmark help I could not find rates but there is packet
>> size and megabytes to transmit.
>> so that, which one do you mean packet size or megabytes?
>> it is okay to use USRP B210 for transmitting and receiving by using to
>> benchmark file?
>> because when I used one of them (tx or rx) and then I wanted to run
>> another one the error come up (no device found for empty device address).
>> in advance many thanks.
>>
>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Diyar,
>>>
>>> with the benchmark_ scripts, you **set** the rates, and you can only
>>> observe how many packets were successfully transmitted.
>>> The rest is really very basic math.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 21.03.2016 10:50, Diyar Muhammed wrote:
>>>
>>> Dear SangHyuk,
>>> I would like to know how to measure Throughput and BER by using
>>> benchmark tx and rx?
>>> could you show or explain with real example as you used.
>>> in advance thanks.
>>>
>>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller <
>>> marcus.muel...@ettus.com> wrote:
>>>
 Hi,

 On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote:
 > I want to know other user's performance (avg performance).
 Yes, but what is "user's performance"? Is it more important to have
 higher throughput, or lower error rates? What about robustness?

 I mean, the OFDM rx_benchmark is a really static example.
 You might find a setting that maximizes troughput for a given channel,
 but imagine something happens that reduces your receiver's SNR by 3dB:
 Now your suddenly losing a lot of performance.

 Really "how can I parameterize this" can only be answered for a single,
 mathematically well-defined target, and for a well-defined channel.

 In a real-world scenario, if using a transceiver with a fixed
 modulation, you usually wouldn't maximize throughput for a given
 setting, but you would define what "it still works sufficiently" means,
 and then you'd define "the worst channel I want the system to still work
 sufficiently".
 Then you'd come up with a metric that gives you a number for "the link
 quality on all considerable channels where this should be working", and
 then you'd try to maximize that metric under the outage constraints set
 before. Notice that this metric has to take things like error rate,
 throughtput, the "cost" of re-sending something (if you have a mechanism
 for that), available channel coding, how much you care about latency,
 computational complexity (that really gets important with iterative
 channel decoding),

 In other words:
 This is digital communications. If there was a single "best" solution,
 we'd all be using that and be done. Use your digital communications
 knowledge to analyze your requirements and challenges!

 Best 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Note that the benchmark_rx/_tx example is really a bit old, and I always
try to steer people away from it towards the newer OFDM examples that
are far more flexible and behave a lot more like a real system would.

Have a look at the ofdm_loopback.grc example; you can replace the
(channelmodel->throttle) by a USRP sink and source. Tadah! Live demo.

Best regards,
Marcus

On 21.03.2016 11:34, Diyar Muhammed wrote:
> many thanks 
>
> On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller
> > wrote:
>
> Diyar,
>
> > I look at tx benchmark help I could not find rates but there is
> packet size and megabytes to transmit.
>
> benchmark_tx --help should help you.
> You set the bandwidth, which sets the sampling rate; together with
> the occupied tones number related to the FFT length, you get a
> symbol rate.
> Together with the modulation you set, this gives you a
>
> Since only one program can use a USRP at a time, you can't use
> benchmark_tx and benchmark_rx at the same time.
> Instead, use benchmark_tx with the "--to-file" option to save the
> samples to a file, and build a quick GNU Radio flow graph in GRC
> that has a file source (reading that file), a USRP sink (fed from
> the file source), a USRP source, and a file sink (saving the
> samples from the USRP source to another file).
>
> Then use benchmark_rx with the --from-file option to read in these
> saved samples.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:17, Diyar Muhammed wrote:
>> Dear Marcus,
>> Thank you very much indeed for fast replying.
>> I look at tx benchmark help I could not find rates but there is
>> packet size and megabytes to transmit.
>> so that, which one do you mean packet size or megabytes?
>> it is okay to use USRP B210 for transmitting and receiving by
>> using to benchmark file?
>> because when I used one of them (tx or rx) and then I wanted to
>> run another one the error come up (no device found for empty
>> device address).
>> in advance many thanks.
>>
>> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller
>> > wrote:
>>
>> Diyar,
>>
>> with the benchmark_ scripts, you **set** the rates, and you
>> can only observe how many packets were successfully transmitted.
>> The rest is really very basic math.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 10:50, Diyar Muhammed wrote:
>>> Dear SangHyuk,
>>> I would like to know how to measure Throughput and BER by
>>> using benchmark tx and rx?
>>> could you show or explain with real example as you used.
>>> in advance thanks.
>>>
>>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
>>> >
>>> wrote:
>>>
>>> Hi,
>>>
>>> On 21.03.2016 01 :37, SangHyuk Kim
>>> wrote:
>>> > I want to know other user's performance (avg performance).
>>> Yes, but what is "user's performance"? Is it more
>>> important to have
>>> higher throughput, or lower error rates? What about
>>> robustness?
>>>
>>> I mean, the OFDM rx_benchmark is a really static example.
>>> You might find a setting that maximizes troughput for a
>>> given channel,
>>> but imagine something happens that reduces your
>>> receiver's SNR by 3dB:
>>> Now your suddenly losing a lot of performance.
>>>
>>> Really "how can I parameterize this" can only be
>>> answered for a single,
>>> mathematically well-defined target, and for a
>>> well-defined channel.
>>>
>>> In a real-world scenario, if using a transceiver with a
>>> fixed
>>> modulation, you usually wouldn't maximize throughput for
>>> a given
>>> setting, but you would define what "it still works
>>> sufficiently" means,
>>> and then you'd define "the worst channel I want the
>>> system to still work
>>> sufficiently".
>>> Then you'd come up with a metric that gives you a number
>>> for "the link
>>> quality on all considerable channels where this should
>>> be working", and
>>> then you'd try to maximize that metric under the outage
>>> constraints set
>>> before. Notice that this metric has to take things like
>>> error rate,
>>> throughtput, the "cost" of re-sending something (if you
>>> have a mechanism
>>> for that), available channel coding, how much you care
>>> about latency,

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

many thanks

On Mon, Mar 21, 2016 at 10:31 AM, Marcus Müller 
wrote:

> Diyar,
>
> > I look at tx benchmark help I could not find rates but there is packet
> size and megabytes to transmit.
>
> benchmark_tx --help should help you.
> You set the bandwidth, which sets the sampling rate; together with the
> occupied tones number related to the FFT length, you get a symbol rate.
> Together with the modulation you set, this gives you a
>
> Since only one program can use a USRP at a time, you can't use
> benchmark_tx and benchmark_rx at the same time.
> Instead, use benchmark_tx with the "--to-file" option to save the samples
> to a file, and build a quick GNU Radio flow graph in GRC that has a file
> source (reading that file), a USRP sink (fed from the file source), a USRP
> source, and a file sink (saving the samples from the USRP source to another
> file).
>
> Then use benchmark_rx with the --from-file option to read in these saved
> samples.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 11:17, Diyar Muhammed wrote:
>
> Dear Marcus,
> Thank you very much indeed for fast replying.
> I look at tx benchmark help I could not find rates but there is packet
> size and megabytes to transmit.
> so that, which one do you mean packet size or megabytes?
> it is okay to use USRP B210 for transmitting and receiving by using to
> benchmark file?
> because when I used one of them (tx or rx) and then I wanted to run
> another one the error come up (no device found for empty device address).
> in advance many thanks.
>
> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller 
> wrote:
>
>> Diyar,
>>
>> with the benchmark_ scripts, you **set** the rates, and you can only
>> observe how many packets were successfully transmitted.
>> The rest is really very basic math.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 21.03.2016 10:50, Diyar Muhammed wrote:
>>
>> Dear SangHyuk,
>> I would like to know how to measure Throughput and BER by using benchmark
>> tx and rx?
>> could you show or explain with real example as you used.
>> in advance thanks.
>>
>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> Hi,
>>>
>>> On 21.03.2016 01 <21.03.2016%2001>:37, SangHyuk Kim wrote:
>>> > I want to know other user's performance (avg performance).
>>> Yes, but what is "user's performance"? Is it more important to have
>>> higher throughput, or lower error rates? What about robustness?
>>>
>>> I mean, the OFDM rx_benchmark is a really static example.
>>> You might find a setting that maximizes troughput for a given channel,
>>> but imagine something happens that reduces your receiver's SNR by 3dB:
>>> Now your suddenly losing a lot of performance.
>>>
>>> Really "how can I parameterize this" can only be answered for a single,
>>> mathematically well-defined target, and for a well-defined channel.
>>>
>>> In a real-world scenario, if using a transceiver with a fixed
>>> modulation, you usually wouldn't maximize throughput for a given
>>> setting, but you would define what "it still works sufficiently" means,
>>> and then you'd define "the worst channel I want the system to still work
>>> sufficiently".
>>> Then you'd come up with a metric that gives you a number for "the link
>>> quality on all considerable channels where this should be working", and
>>> then you'd try to maximize that metric under the outage constraints set
>>> before. Notice that this metric has to take things like error rate,
>>> throughtput, the "cost" of re-sending something (if you have a mechanism
>>> for that), available channel coding, how much you care about latency,
>>> computational complexity (that really gets important with iterative
>>> channel decoding),
>>>
>>> In other words:
>>> This is digital communications. If there was a single "best" solution,
>>> we'd all be using that and be done. Use your digital communications
>>> knowledge to analyze your requirements and challenges!
>>>
>>> Best regards
>>> Marcus
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Regards,
>> Diyar Muhammed
>> Ministry of Higher Education and Scientific Research
>> Duty: Network Administration and Design
>> Website:   www.mhe-krg.org
>> Cell Phone: 009647504690060
>> Office Phone:   00964662554683
>>
>>
>>
>
>
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
>
>


-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Diyar,

> I look at tx benchmark help I could not find rates but there is packet
size and megabytes to transmit.

benchmark_tx --help should help you.
You set the bandwidth, which sets the sampling rate; together with the
occupied tones number related to the FFT length, you get a symbol rate.
Together with the modulation you set, this gives you a

Since only one program can use a USRP at a time, you can't use
benchmark_tx and benchmark_rx at the same time.
Instead, use benchmark_tx with the "--to-file" option to save the
samples to a file, and build a quick GNU Radio flow graph in GRC that
has a file source (reading that file), a USRP sink (fed from the file
source), a USRP source, and a file sink (saving the samples from the
USRP source to another file).

Then use benchmark_rx with the --from-file option to read in these saved
samples.

Best regards,
Marcus

On 21.03.2016 11:17, Diyar Muhammed wrote:
> Dear Marcus,
> Thank you very much indeed for fast replying.
> I look at tx benchmark help I could not find rates but there is packet
> size and megabytes to transmit.
> so that, which one do you mean packet size or megabytes?
> it is okay to use USRP B210 for transmitting and receiving by using to
> benchmark file?
> because when I used one of them (tx or rx) and then I wanted to run
> another one the error come up (no device found for empty device address).
> in advance many thanks.
>
> On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller
> > wrote:
>
> Diyar,
>
> with the benchmark_ scripts, you **set** the rates, and you can
> only observe how many packets were successfully transmitted.
> The rest is really very basic math.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 10:50, Diyar Muhammed wrote:
>> Dear SangHyuk,
>> I would like to know how to measure Throughput and BER by using
>> benchmark tx and rx?
>> could you show or explain with real example as you used.
>> in advance thanks.
>>
>> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
>> > wrote:
>>
>> Hi,
>>
>> On 21.03.2016 01 :37, SangHyuk Kim wrote:
>> > I want to know other user's performance (avg performance).
>> Yes, but what is "user's performance"? Is it more important
>> to have
>> higher throughput, or lower error rates? What about robustness?
>>
>> I mean, the OFDM rx_benchmark is a really static example.
>> You might find a setting that maximizes troughput for a given
>> channel,
>> but imagine something happens that reduces your receiver's
>> SNR by 3dB:
>> Now your suddenly losing a lot of performance.
>>
>> Really "how can I parameterize this" can only be answered for
>> a single,
>> mathematically well-defined target, and for a well-defined
>> channel.
>>
>> In a real-world scenario, if using a transceiver with a fixed
>> modulation, you usually wouldn't maximize throughput for a given
>> setting, but you would define what "it still works
>> sufficiently" means,
>> and then you'd define "the worst channel I want the system to
>> still work
>> sufficiently".
>> Then you'd come up with a metric that gives you a number for
>> "the link
>> quality on all considerable channels where this should be
>> working", and
>> then you'd try to maximize that metric under the outage
>> constraints set
>> before. Notice that this metric has to take things like error
>> rate,
>> throughtput, the "cost" of re-sending something (if you have
>> a mechanism
>> for that), available channel coding, how much you care about
>> latency,
>> computational complexity (that really gets important with
>> iterative
>> channel decoding),
>>
>> In other words:
>> This is digital communications. If there was a single "best"
>> solution,
>> we'd all be using that and be done. Use your digital
>> communications
>> knowledge to analyze your requirements and challenges!
>>
>> Best regards
>> Marcus
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> -- 
>> Regards,
>> Diyar Muhammed
>> Ministry of Higher Education and Scientific Research
>> Duty: Network Administration and Design
>> Website:  www.mhe-krg.org 
>> Cell Phone: 009647504690060
>> Office Phone:   00964662554683
>
>
>
>
> -- 
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> 

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Dear Marcus,
Thank you very much indeed for fast replying.
I look at tx benchmark help I could not find rates but there is packet size
and megabytes to transmit.
so that, which one do you mean packet size or megabytes?
it is okay to use USRP B210 for transmitting and receiving by using to
benchmark file?
because when I used one of them (tx or rx) and then I wanted to run another
one the error come up (no device found for empty device address).
in advance many thanks.

On Mon, Mar 21, 2016 at 9:57 AM, Marcus Müller 
wrote:

> Diyar,
>
> with the benchmark_ scripts, you **set** the rates, and you can only
> observe how many packets were successfully transmitted.
> The rest is really very basic math.
>
> Best regards,
> Marcus
>
>
> On 21.03.2016 10:50, Diyar Muhammed wrote:
>
> Dear SangHyuk,
> I would like to know how to measure Throughput and BER by using benchmark
> tx and rx?
> could you show or explain with real example as you used.
> in advance thanks.
>
> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller 
> wrote:
>
>> Hi,
>>
>> On 21.03.2016 01:37, SangHyuk Kim wrote:
>> > I want to know other user's performance (avg performance).
>> Yes, but what is "user's performance"? Is it more important to have
>> higher throughput, or lower error rates? What about robustness?
>>
>> I mean, the OFDM rx_benchmark is a really static example.
>> You might find a setting that maximizes troughput for a given channel,
>> but imagine something happens that reduces your receiver's SNR by 3dB:
>> Now your suddenly losing a lot of performance.
>>
>> Really "how can I parameterize this" can only be answered for a single,
>> mathematically well-defined target, and for a well-defined channel.
>>
>> In a real-world scenario, if using a transceiver with a fixed
>> modulation, you usually wouldn't maximize throughput for a given
>> setting, but you would define what "it still works sufficiently" means,
>> and then you'd define "the worst channel I want the system to still work
>> sufficiently".
>> Then you'd come up with a metric that gives you a number for "the link
>> quality on all considerable channels where this should be working", and
>> then you'd try to maximize that metric under the outage constraints set
>> before. Notice that this metric has to take things like error rate,
>> throughtput, the "cost" of re-sending something (if you have a mechanism
>> for that), available channel coding, how much you care about latency,
>> computational complexity (that really gets important with iterative
>> channel decoding),
>>
>> In other words:
>> This is digital communications. If there was a single "best" solution,
>> we'd all be using that and be done. Use your digital communications
>> knowledge to analyze your requirements and challenges!
>>
>> Best regards
>> Marcus
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
>
>


-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Diyar,

with the benchmark_ scripts, you **set** the rates, and you can only
observe how many packets were successfully transmitted.
The rest is really very basic math.

Best regards,
Marcus

On 21.03.2016 10:50, Diyar Muhammed wrote:
> Dear SangHyuk,
> I would like to know how to measure Throughput and BER by using
> benchmark tx and rx?
> could you show or explain with real example as you used.
> in advance thanks.
>
> On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller
> > wrote:
>
> Hi,
>
> On 21.03.2016 01 :37, SangHyuk Kim wrote:
> > I want to know other user's performance (avg performance).
> Yes, but what is "user's performance"? Is it more important to have
> higher throughput, or lower error rates? What about robustness?
>
> I mean, the OFDM rx_benchmark is a really static example.
> You might find a setting that maximizes troughput for a given channel,
> but imagine something happens that reduces your receiver's SNR by 3dB:
> Now your suddenly losing a lot of performance.
>
> Really "how can I parameterize this" can only be answered for a
> single,
> mathematically well-defined target, and for a well-defined channel.
>
> In a real-world scenario, if using a transceiver with a fixed
> modulation, you usually wouldn't maximize throughput for a given
> setting, but you would define what "it still works sufficiently"
> means,
> and then you'd define "the worst channel I want the system to
> still work
> sufficiently".
> Then you'd come up with a metric that gives you a number for "the link
> quality on all considerable channels where this should be
> working", and
> then you'd try to maximize that metric under the outage
> constraints set
> before. Notice that this metric has to take things like error rate,
> throughtput, the "cost" of re-sending something (if you have a
> mechanism
> for that), available channel coding, how much you care about latency,
> computational complexity (that really gets important with iterative
> channel decoding),
>
> In other words:
> This is digital communications. If there was a single "best" solution,
> we'd all be using that and be done. Use your digital communications
> knowledge to analyze your requirements and challenges!
>
> Best regards
> Marcus
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> -- 
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org 
> Cell Phone: 009647504690060
> Office Phone:   00964662554683

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

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Diyar Muhammed]

Dear SangHyuk,
I would like to know how to measure Throughput and BER by using benchmark
tx and rx?
could you show or explain with real example as you used.
in advance thanks.

On Mon, Mar 21, 2016 at 8:09 AM, Marcus Müller 
wrote:

> Hi,
>
> On 21.03.2016 01:37, SangHyuk Kim wrote:
> > I want to know other user's performance (avg performance).
> Yes, but what is "user's performance"? Is it more important to have
> higher throughput, or lower error rates? What about robustness?
>
> I mean, the OFDM rx_benchmark is a really static example.
> You might find a setting that maximizes troughput for a given channel,
> but imagine something happens that reduces your receiver's SNR by 3dB:
> Now your suddenly losing a lot of performance.
>
> Really "how can I parameterize this" can only be answered for a single,
> mathematically well-defined target, and for a well-defined channel.
>
> In a real-world scenario, if using a transceiver with a fixed
> modulation, you usually wouldn't maximize throughput for a given
> setting, but you would define what "it still works sufficiently" means,
> and then you'd define "the worst channel I want the system to still work
> sufficiently".
> Then you'd come up with a metric that gives you a number for "the link
> quality on all considerable channels where this should be working", and
> then you'd try to maximize that metric under the outage constraints set
> before. Notice that this metric has to take things like error rate,
> throughtput, the "cost" of re-sending something (if you have a mechanism
> for that), available channel coding, how much you care about latency,
> computational complexity (that really gets important with iterative
> channel decoding),
>
> In other words:
> This is digital communications. If there was a single "best" solution,
> we'd all be using that and be done. Use your digital communications
> knowledge to analyze your requirements and challenges!
>
> Best regards
> Marcus
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM benchmark optimal parameter

[Marcus Müller]

Hi,

On 21.03.2016 01:37, SangHyuk Kim wrote:
> I want to know other user's performance (avg performance).
Yes, but what is "user's performance"? Is it more important to have
higher throughput, or lower error rates? What about robustness?

I mean, the OFDM rx_benchmark is a really static example.
You might find a setting that maximizes troughput for a given channel,
but imagine something happens that reduces your receiver's SNR by 3dB:
Now your suddenly losing a lot of performance.

Really "how can I parameterize this" can only be answered for a single,
mathematically well-defined target, and for a well-defined channel.

In a real-world scenario, if using a transceiver with a fixed
modulation, you usually wouldn't maximize throughput for a given
setting, but you would define what "it still works sufficiently" means,
and then you'd define "the worst channel I want the system to still work
sufficiently".
Then you'd come up with a metric that gives you a number for "the link
quality on all considerable channels where this should be working", and
then you'd try to maximize that metric under the outage constraints set
before. Notice that this metric has to take things like error rate,
throughtput, the "cost" of re-sending something (if you have a mechanism
for that), available channel coding, how much you care about latency,
computational complexity (that really gets important with iterative
channel decoding),

In other words:
This is digital communications. If there was a single "best" solution,
we'd all be using that and be done. Use your digital communications
knowledge to analyze your requirements and challenges!

Best regards
Marcus

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