Re: [Discuss-gnuradio] custom work function gets into an endless loop

[Kolya]

Hi Martin and Sylvain,

I obviously didn't understand the forecast function properly but with your
help it works now. I tried both: 

set_output_multiple & a correct forecast() 
and 
set_output_multiple & set_relative_rate

both approaches worked as expected :)

What threw me off was that I had based my forecast on the forecast function
in gr-dtv's dvb_bbheader_bb_impl.cc and in that example it seems to work.

I also appreciate the pointer to the logging infrastructure and I will adopt
that too. The crc32_bb is next on the list of files to dissect and learn
from. That is good stuff!

This is a great mailing list. Thanks so much for your help.

- Kolya



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/custom-work-function-gets-into-an-endless-loop-tp56304p56323.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] custom work function gets into an endless loop

[Sylvain Munaut]

> /void
> bbframer_bb_impl::forecast (int noutput_items, gr_vector_int
> _items_required)
> {
> ninput_items_required[0] = ((noutput_items - 32) / 8); // 32 bit
> postamble
> }/

You should make sure forecast can never return <0 or even ==0 numbers.
Returning 0 means you can produce output without input and the only
valid case for it is either a 'source' block, or if you _know_ that
you have currently buffered data and you can produce output without
any further inputs.


Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11

[Jeon]

Thank you all of you who have answered to my questions.
I am sorry for anwering too late.

I'll try as many solutions as you suggested
and will let you know how I will have implemented it.

Regards,
Jeon.

2015-09-22 23:31 GMT+09:00 Jan Krämer :

> Hi all,
>
> my repo is here https://github.com/SpectreJan.
> Though the decoder that I presented last year at GRCON is not in
> there...long and shitty story. There is an optimized version of the
> gr-trellis decoder in gr-celec. You have to clone gr-celec and volk-fec
> from my repo. Then build volk-fec and then gr-celec. I renewed my fork of
> GNURadio and am starting implementing a generic version of cc_decoder that
> is cc_encoder compatible but to be honest, work is pretty slow.
>
> cheers and happy hacking,
> Jan
>
> 2015-09-22 15:24 GMT+02:00 Tom Rondeau :
>
>> On Tue, Sep 22, 2015 at 1:52 AM, Jeon  wrote:
>>
>>> Thanks for your answers, Ron and Marcus.
>>>
>>> I posted this question since my module is using both Reed Solomon (
>>> https://github.com/pjkundert/ezpwd-reed-solomon) and Convolutional Code
>>> (IT++).
>>> And I saw that CC is extremely slower than RS. Thus, I posted this
>>> question, but I made a question too short and lack some information.
>>> (Of course, this is because mechanism of RS is much much simpler than
>>> that of CC.
>>> Or it could be because ezpwd RS which I am using is optimized well, but
>>> IT++ CC is not.)
>>>
>>> To improve my OOT's performance, thus, I need to replace IT++ with other
>>> some heavily optimized library or module.
>>> I remember that...one of gr-fec, gr-dtv, gr-trellis can do this for me.
>>>
>>> Now I wonder which gr module supports some arbitrary polynomials and
>>> code rate.
>>> Specifically, I want one of three set of polynomials:
>>>
>>> - Polynomial 1 (g0 = 133, g1 = 171, g2 = 165)
>>> - Polynomial 2 (g0 = 131, g1 = 145, g2 = 133)
>>> - Polynomial 3 (g0 = 131, g1 = 171, g2 = 133)
>>>
>>> (Common: Code rate 1/4, 2/3 and 1/3, where 1/4 = repeat of code rate 1/2)
>>>
>>> The reason that I try to implement one of three is,
>>> document describing specification has some wrong points.
>>> Text says polynomial 1, but figure shows polynomial 2.
>>>
>>> One thing is hopeful:
>>>
>>> I think that polynomial 3 seems a sort of widely used one
>>> and that it has been already implemented by someone in GNU Radio,
>>> which has been heavily optimized... I hope...
>>>
>>> (While I am writing this, I've checked that gr-fec can do CC with
>>> arbitrary polynomials.
>>> gnuradio/gr-fec/examples/fecapi_cc_decodres.grc
>>> I still don't know optimization.)
>>>
>>> I will keep looking into those gr-fec, dtv, trellis modules.
>>> If someone have suggestions, I will appreciate it.
>>>
>>> Thanks a lot.
>>>
>>> Regards,
>>> Jeon.
>>>
>>
>>
>> Jeon,
>>
>> No, as the docs say, this block is only designed to handle rate 1/2, K=7
>> codes:
>> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__decoder.html
>>
>> We had some work done for GSoC last year to improve the speed of the
>> Viterbi algorithm for other cases, but we have not yet merged that into the
>> code. This was Jan Kramer's work, though I'm having trouble finding a link
>> to his repo.
>>
>> Tom
>>
>>
>>
>>
>> ___
>> 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] GRC python block

[Chad R]

Good day every one

Ive been working on the creating a python block.
Ive worked through the tutorial and my block passes make test. However when
I try make install. I get an error with the /lib/_impl.cc file. Do I need
to link the python block in this file and if so is there some where I can
read up on how to do this?

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

Re: [Discuss-gnuradio] CDMA

[Achilleas Anastasopoulos]

OK, now tell us which directory is your gr-cdma downloaded to?
Ie, when you did
 > git clone https://github.com/anastas/gr-cdma.git
where was this downloaded to?

Achilleas

On Mon, Sep 28, 2015 at 3:47 PM, alfred noble 
wrote:

> Thank you for your immediate respond
> the variable "prefix" in my cdma_parameters.py has the following value .
>
> prefix="/home/gr-cdma"  # put the prefix of your gr-cdma trunk
> I opened that file and searched for the word "prefix" using Ctrl + f
> shortcut then I attached that file below .
>
> will be waiting for your reply
> Thanks in advanced
> Alfred
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT Module & Epiphany SDK (Parallella Board)

[Ivan Santa]

Hi list.
I started the journey of trying to write an OOT module containing functions
of the Epiphany SDK.  So over my parallella board I compiled GNU Radio and
I created an OOT module called Epiphany and then I created a block called
toggle, with the idea of turn on and off a led from an epiphany core.

gr_modtool newmod epiphany
cd gr_epiphany
gr_modtool add -t sync toggle_led

Then I did a few changes on toggle_impl.cc (To start, I only added the
function e_init(NULL))

.

#include "toggle_impl.h"
#include 
#include 

namespace gr {
namespace epiphany {

.
  : gr::sync_block("toggle",
  gr::io_signature::make(1, 1, sizeof(int)),
  gr::io_signature::make(0, 0, 0))

const int *in = (const int *) input_items[0];
// Do <+signal processing+>
e_platform_t platform;
e_epiphany_t dev;
e_mem_t emem;
char emsg[1024];
unsigned int row, col;
unsigned int data, led_state;
int i;
e_init(NULL);


Then I added a line in the CMakeLists.txt in the lib folder:

...
include_directories(/opt/adapteva/esdk.2015.1/tools/host.armv7l/include)
add_executable(test-epiphany ${test_epiphany_sources})
...

I put almost all the sources and headers of eSDK on the module folders.
When I compile I don't get any error, but when I run the top block I obtain
an AttributeError: 'module' object has no attribute.

If I run it on python, I observe that SWIG didn't wrap all the code:

import epiphany
>>> dir(epiphany)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__path__']


If I comment the line e_init(NULL); and recompile I obtain:
>>> dir(epiphany)
['__builtins__', '__doc__', '__file__', '__name__', '__package__',
'__path__', 'epiphany_swig', 'high_res_timer_epoch', 'high_res_timer_now',
'high_res_timer_now_perfmon', 'high_res_timer_tps', 'toggle',
'toggle_make', 'toggle_sptr', 'toggle_sptr_swigregister',
'toggle_swigregister']

It is logic because in this case I didn't use real functions of e-hal, only
objects.

So, additionally I changed the file epiphany_swig.i trying to understand
the functionality of SWIG (inventing):

%{
#include "epiphany/toggle.h"
#include 
#include 
%}

%include "epiphany/toggle.h"
%include 
%include 

GR_SWIG_BLOCK_MAGIC2(epiphany, toggle);
GR_SWIG_BLOCK_MAGIC2(epiphany, e-hal);
GR_SWIG_BLOCK_MAGIC2(epiphany, e-loader);

But I got an epiphany_swig.i:22: Error: Syntax error in input(1).

So here I'm stucked and I'm not a GNU Radio expert, and I know that trying
to put external functions in an OOT block is not easy for a newbie.

Aditional information:
Linux parallella 3.14.12-parallella-xilinx-g40a90c3 #1 SMP PREEMPT Fri Jan
23 22:01:51 CET 2015 armv7l armv7l armv7l GNU/Linux
GNU Radio  3.7.8
swig 2.0.11-1ubuntu2 armhf
eSDK 2015.1

Many thanks in advance for any information, or suggestion.
Best Regards.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[Marcus D. Leech]

On 09/28/2015 05:14 AM, David Halls wrote:


​Thanks for your reply Marcus, but does that mean there is no way 
around the problem?



Regards,


David


Naked UDP provides no framing overlay, which means you are limited to 
MTU-sized packets.


You should perhaps look into either using TCP, and/or ZMQ.

Others can provide guidance on ZMQ usage.



*From:* mle...@ripnet.com 
*Sent:* 25 September 2015 20:24
*To:* Andy Walls
*Cc:* David Halls; discuss-gnuradio@gnu.org; 
discuss-gnuradio-bounces+mleech=ripnet@gnu.org
*Subject:* Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send 
error:send_to: Message too long


If the sending machine sets DF in the IP header, then any interstitial 
machine that must fragment will drop the packet as well.


Best to stick to MTU-sized payloads with UDP, since IP fragmentation 
is handled poorly in many cases--either due to policy, or bad 
implementations.


On 2015-09-25 15:17, Andy Walls wrote:

From: David Halls Subject: [Discuss-gnuradio] UDP Sink Size Limit - 
ERROR: send

error:send_to: Message too long

Date: Fri, 25 Sep 2015 09:05:56 +
Dear All, When I increase my packet length in a transmission flow 
graph to over 16,000 bits, I get the following error "ERROR: send 
error:send_to: Message too long​"

This looks like the underlying sendto() system call is returning
EMSGSIZE.  From man sendto:

  EMSGSIZE
   The  socket  type  requires that message be sent atomically, and
   the size of the message to be sent made this impossible.
this is from the UDP block which I am using in order to send the 
transmitted bits to the destination in order to perform BER. I am 
sending the packets in bursts, one packet every two seconds.
I currently have the Payload size set to 147.2k and Send Null Pkt as 
EOF set to true.

Is this some fundamental limit, or can I overcome the issue?

16,000 bits is 2000 bytes.  The default MTU is usually 1500 bytes (for
IP header, UDP header, and payload together).  Try modifying the MTU on
your machine's network interface to something larger, say 4000.

The MTU of the receiving machine or other network hardware might still
be only 1500, so the the UDP packet could get IP fragmented.  I'm not
sure how well UDP works when fragmented.

-Andy


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




NOTE: The information in this email and any attachments may be 
confidential and/or legally privileged. This message may be read, 
copied and used only by the intended recipient. If you are not the 
intended recipient, please destroy this message, delete any copies 
held on your system and notify the sender immediately.


Toshiba Research Europe Limited, registered in England and Wales 
(2519556). Registered Office 208 Cambridge Science Park, Milton Road, 
Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl





This email has been scanned for email related threats and delivered 
safely by Mimecast.

For more information please visit http://www.mimecast.com



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

Re: [Discuss-gnuradio] GRC python block

[Martin Braun]

On 28.09.2015 03:07, Chad R wrote:
> Good day every one
> 
> Ive been working on the creating a python block.
> Ive worked through the tutorial and my block passes make test. However
> when I try make install. I get an error with the /lib/_impl.cc file. Do
> I need to link the python block in this file and if so is there some
> where I can read up on how to do this?

If you have a Python block, you don't need a _impl file.

Cheers,
M


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

Re: [Discuss-gnuradio] Questions about burst communication

[Washbourne, Logan]

My guess is no, the receiver doesn't have its own thread, because I'm not
sure how to tell.


On Fri, Sep 25, 2015 at 11:21 AM, Martin Braun 
wrote:

> On 24.09.2015 16:31, lwas...@ostatemail.okstate.edu wrote:
> > Julian and Martin,
> >
> > Typically 2 U's appear then a stream of O's. Ya, I don't have any sort
> > of correlation block on the receiver side so that is definitely a
> > problem. Next week I'll work on implementing a correlation block with a
> > barker code preamble.
> >
> > Do you have any suggestions for quick testing and validation? What I've
> > been doing to check the bytes, if my acknowledgment fails, is to save
> > the bytes to a file and use MATLAB to inspect them. Is there an easier
> > way to quickly look at individual bytes?
>
> If you have lots of O's, looking at bytes won't help -- the O's are
> because your receive part is somehow too slow or stalling. You'll need
> to fix that first.
>
> Does your receiver have it's own dedicated thread?
>
> M
>
>
> ___
> 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] CDMA

[Achilleas Anastasopoulos]

open a python interpreter

> python

and write

>>> from cdma import cdma_parameters as cp


WHAT DO YOU GET?


if you get an error, ie, something like:

Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named cdma


Then you have not set correctly the PYTHONPATH in your system, so python
does not know where to search to load the cdma module.


Achilleas



On Mon, Sep 28, 2015 at 10:00 AM, alfred noble 
wrote:

> Thank you one more Achilleas you are of great help to me.
>
> but the problem is that when I open the "file *amp_var_est_hier.grc"
> manually I don't have any errors then I compile and reload the blocks
> successfully , but when I close this file and open the file
> "cdma_tx_hier.grc**" I can NOT compile it since there are so many errors
> in this file. *
> *I send you the picture of GNURadio companion when the second file , is
> open in its environment *
> *as an example in the 'import' block I have the following error. *
> *"**Param - Import(import):*
> * Bad import syntax: "import cdma.cdma_parameters as cp".**"*
> *and along with some other errors that are visible in the attached
> picture. *
>
> *last but NOT least , I never meant to disrespect anyone, specially you 
> *Achilleas.
> I just wanted to clarify my problem completely and vividly .
>
> sincerely
> Alfred
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CDMA

[alfred noble]

Thank you for your immediate respond
the variable "prefix" in my cdma_parameters.py has the following value .

prefix="/home/gr-cdma"  # put the prefix of your gr-cdma trunk
I opened that file and searched for the word "prefix" using Ctrl + f
shortcut then I attached that file below .

will be waiting for your reply
Thanks in advanced
Alfred
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# 
# Copyright 2014 Achilleas Anastasopoulos, Zhe Feng.
# 
# This is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
# 
# This software is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this software; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
import random
import numpy
from gnuradio import digital,trellis
import math
import cdma
from fractions import Fraction,gcd
from operator import mul
#from gnuradio.digital.utils import tagged_streams


class cdma_parameters:

def __init__(self):
	"""
 Description:
 This file contains most of the basic design parameters of the cdma system. Users can modify these parameters for their applications. 
 
 header parameters:
 length_tag_name is the length tag key used in the packet header generator. 
 num_tag_name is the num tag key used in the packet header generator. 
 bits_per_header denotes the number of bits per header. 
 header_mod denotes the modulation scheme for header symbols. In this CDMA system, the header is BPSK modulated. 
 header_formatter generates the header by using these above parameters. 
 To avoid evaluation error in symbols per header, bits per header and then symbols per header are automatically adjusted if error occurs. 

 modulation parameters:
 payload_mod is a list containing constellation objects to be used in a possibly adaptive modulation setup.

 coding parameters:
 A list of fsm objects to be used in conjunction with each constellation object defined above.
 The bits_per_coded_symbol of trellis codes are compared to their corresponding bits_per_symbol of modulations to ensure consistency.
 
 payload parameters:
 There are four parameters are set by the users.
 payload_bytes_per_frame is preset by the user to denote the number of payload bytes per frame. 
 symbols_per_frame is preset by the user to denote the number of symbols per frame. 
 bits_per_uncoded_symbols is preset by the user.
 crc_bytes denotes the number of crc bytes per frame generated by the stream crc32 generator. 
 crc_coded_payload_bytes_per_frame denotes the payload bytes per frame after outer crc code. 
 crc_coded_payload_symbols_per_frame denotes the the payload symbols per frame after outer crc code. 
 trellis_coded_payload_symbols_per_frame denotes the payload symbols per frame after inner trellis code.
 Trellis_coded_bytes_per_frame is the number of bytes after trellis coding.
 additional_symbols_per_frame denotes the additional symbols needed to satisfy the symbols_per_frame. It must be greater or equal to zero.
 additional_bytes_per_frame denotes the additional bytes per frame. Since we don't encode the additional bits.
 redudant_bytes_percent is the percent of the additional bytes in total bytes.
 
 training parameters:
 training_long denotes the randomly generated training sequence with the same length to symbols_per_frame. 
 training is the adjusted training sequence (maybe shorter than one frame) 
 training_percent is the percentage of power for training at the transmitter. It takes value in [0,100]. 
 
 cdma parameters:
 chips_per_symbol denotes the spreading factor which is ratio of the chip rate to baseband symbol rate.
 chips_per_frame denotes the total number of chips per frame. 
 pulse_training denotes the spreading code sequence for the training channel. 
 pulse_data denotes the spreading code sequence for the data channel. Pulse_training and pulse_data should better be orthogonal. 

 timing parameters:
 peak_o_var denotes the output correlation peak over variance value of the matched filter in frequency timing estimator. It is used for the rise and fall threshold factor of the peak detector in the frequency timing estimator. 
 EsN0dBthreshold is the SNR threshold of switching between Acquisition and Tracking mode when auto switch mode is selected. If the estimated SNR is greater than EsN0dBthreshold, the system switches to tracking mode automatically and vice versa. 
 epsilon is a small number used in estimating the SNR to avoid division by zero, etc. 
 n_filt denotes the number of matched filters used in the frequency timing estimator. 
 freqs denotes the center 

Re: [Discuss-gnuradio] custom work function gets into an endless loop

[Martin Braun]

On 27.09.2015 15:25, Kolya wrote:
> Hi,
> 
> I'm trying to build a custom block that takes in a stream of input samples
> and simply adds a postamble of 32bits every 352 bits. The package structure
> is illustrated below (payload_bits = msg_bits+postamble_bits):
> ---
> |   msg_bits = 352 |  postamble_bits = 32  |
> ---
> 
> For some reason the code below gets into an endless loop when I run it
> through a test and stimulate it with a non-repeating vector source. The
> debug printf statements show that the loop keeps iterating even without
> input.
> I derived from gr_block because the number of output samples is higher than

I'm guessing you mean gr::block? If so, that's the correct choice.

>   }
> #ifdef VERBOSE
>   printf(">>> offset= %d\n",out_offset);
>   printf(">>> consumed= %d\n",consumed);
> #endif

FYI, we have a great logging infrastructure for these kinds of things,
see http://gnuradio.org/doc/doxygen/page_logger.html.

>   this->consume_each(consumed);
>   return out_offset;
> }/
> 
> I also overrode the forecast function to account for the fact that fewer
> input samples are needed than output samples are produced:
> 
> /void
> bbframer_bb_impl::forecast (int noutput_items, gr_vector_int
> _items_required)
> {
> ninput_items_required[0] = ((noutput_items - 32) / 8); // 32 bit
> postamble
> }/

There's several issues here. First, your math is broken; you want
ninput_items_required to always be a positive, non-zero number which
you're not checking. Say it's 0, then that means it's fine to call your
work function with no input. What you want is something like
'(noutput_items / 47) * 44.
Second, you don't necessarily need forecast. If your packet size is
always the same, I recommend using set_output_multiple and
relative_rate. Or you can even use tagged streams, check out crc32_bb
which does pretty much the same as your block, albeit at varying packet
lengths.

Cheers,
M



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

Re: [Discuss-gnuradio] CDMA

[Achilleas Anastasopoulos]

Clearly, you have an issue with importing the cdma module into python.

Can you tell me what is the value of the variable  "prefix" in your
cdma_parameters.py file?
(you can find it in gr-cdma/python/ directory)

Achilleas



On Mon, Sep 28, 2015 at 2:47 PM, alfred noble 
wrote:

> Thanks
> I opened the terminal in gr-cdma folder and ran the following command
> "python"
> after that I ran this :
> "from cdma import cdma_parameters as cp"
> as you told me ,
> I received this ,
>
>  CDMA PARAMETERS : for adaptive modulation
> bits_per_header= 36
> symbols_per_header= 36
>
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34,
> in 
> import cdma_parameters
>   File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py",
> line 122, in 
> bits_per_coded_symbol=[int(math.log(trellis.fsm(fsm[i]).O(),2)) for i
> in range(len(payload_mod))]
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/trellis/trellis_swig.py",
> line 471, in __init__
> this = _trellis_swig.new_fsm(*args)
> RuntimeError: fsm::fsm(const char *name): file open error
>
> I really appreciate your help if could help me here once again
> thank you in advance
>
> Alfred
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CDMA

[alfred noble]

Thanks
I opened the terminal in gr-cdma folder and ran the following command
"python"
after that I ran this :
"from cdma import cdma_parameters as cp"
as you told me ,
I received this ,

 CDMA PARAMETERS : for adaptive modulation
bits_per_header= 36
symbols_per_header= 36


Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34,
in 
import cdma_parameters
  File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py",
line 122, in 
bits_per_coded_symbol=[int(math.log(trellis.fsm(fsm[i]).O(),2)) for i
in range(len(payload_mod))]
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/trellis/trellis_swig.py",
line 471, in __init__
this = _trellis_swig.new_fsm(*args)
RuntimeError: fsm::fsm(const char *name): file open error

I really appreciate your help if could help me here once again
thank you in advance

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

[Discuss-gnuradio] GNU Radio Companion error: segmentation fault (core dumped)

[Mike Gilmer]

I am trying to follow the steps for the tutorials for GNU radio - at
one point I'm instructed to install/build/run the "Companion"

http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC

 All's fine, until:

$ gnuradio-companion


I get thrown the error: Segmentation fault (core dumped)

Any ideas?

-Mike

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

[Discuss-gnuradio] GRC qtgui_sink "Clicked Freq Variable" not working.

[Jeremy Butler]

Hello, this is my first post to the mailing list! Thanks in advance for
taking the time to help me out!

I'm using gnuradio v3.7.6git and Ubuntu 12.04

I am having issues with the "Clicked Freq Variable" option in the
qtgui_sink block in GRC. If I understand this correctly, it should
basically act just as the "Freq Set Varname" option of the WX GUI FFT Sink.

The qtgui_sink block doesn't seem to be changing the variable that I put
into this option when I click or double click on the frequency graph.

I've attached a small GRC flowgraph to illustrate the issue. I would expect
the label to change every time that I click on the frequency graph.

I've looked into the source code a little bit and done some debugging and
I've found that it doesn't seem like the plotPointSelected signal is even
being emitted, or if it is, it isn't being captured and the appropriate
callback is not being called to update the variable.

I'm at a loss now. Any help would be greatly appreciated!

Thank you all for your time!


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

[Discuss-gnuradio] Eleventh Cyberspectrum SDR Meetup this Wed (30th Sept)

[Balint Seeber]

Dear all,

Announcing the eleventh Cyberspectrum meetup at Noisebridge in San
Francisco!

Come along at 6:30pm for a 7pm sharp kickoff in the Hackatorium, and for
those unable to attend we'll set up a live stream like last time (stay
tuned to the event's page/Twitter for more info closer to the time).
There's also IRC: #cyberspectrum on Freenode.

Full details, including the speaker lineup/topics, are here:
http://www.meetup.com/Cyberspectrum/events/224928223/

We'll be hearing about:

   - Etch-A-SDR by Nate @devnulling 
   - Spread Spectrum SATCOM Hacking by Colby Moore
   

Recordings of, and materials from, previous meetups can be found here:
http://www.meetup.com/Cyberspectrum/about/

If you're not familiar with Cyberspectrum: "The Bay Area SDR Meetup will
serve as a forum to exchange knowledge and ideas related to Software
Defined Radio (the software and hardware), and generally aim to get people
excited about all the applications that can be realised with the
technology. At each meetup, attendees will have the opportunity to present
their work/ideas to the group. Engineers, enthusiasts, hobbyists and people
of all experience levels are welcome, no matter what your software/hardware
background."

As always, if you would like to present at a future event about a project
you're working on, or something interesting you've discovered, please get
in touch!

Hope to see you there,
Balint
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send error:send_to: Message too long

[David Halls]

?Thanks for your reply Marcus, but does that mean there is no way around the 
problem?


Regards,


David



From: mle...@ripnet.com 
Sent: 25 September 2015 20:24
To: Andy Walls
Cc: David Halls; discuss-gnuradio@gnu.org; 
discuss-gnuradio-bounces+mleech=ripnet@gnu.org
Subject: Re: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send 
error:send_to: Message too long


If the sending machine sets DF in the IP header, then any interstitial machine 
that must fragment will drop the packet as well.

Best to stick to MTU-sized payloads with UDP, since IP fragmentation is handled 
poorly in many cases--either due to policy, or bad implementations.







On 2015-09-25 15:17, Andy Walls wrote:

From: David Halls Subject: [Discuss-gnuradio] UDP Sink Size Limit - ERROR: send

error:send_to: Message too long

Date: Fri, 25 Sep 2015 09:05:56 +
Dear All, When I increase my packet length in a transmission flow graph to over 
16,000 bits, I get the following error "ERROR: send error:send_to: Message too 
long?"

This looks like the underlying sendto() system call is returning
EMSGSIZE.  From man sendto:

 EMSGSIZE
  The  socket  type  requires that message be sent atomically, and
  the size of the message to be sent made this impossible.

this is from the UDP block which I am using in order to send the transmitted 
bits to the destination in order to perform BER. I am sending the packets in 
bursts, one packet every two seconds.
I currently have the Payload size set to 147.2k and Send Null Pkt as EOF set to 
true.
Is this some fundamental limit, or can I overcome the issue?

16,000 bits is 2000 bytes.  The default MTU is usually 1500 bytes (for
IP header, UDP header, and payload together).  Try modifying the MTU on
your machine's network interface to something larger, say 4000.

The MTU of the receiving machine or other network hardware might still
be only 1500, so the the UDP packet could get IP fragmented.  I'm not
sure how well UDP works when fragmented.

-Andy


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




NOTE: The information in this email and any attachments may be confidential 
and/or legally privileged. This message may be read, copied and used only by 
the intended recipient. If you are not the intended recipient, please destroy 
this message, delete any copies held on your system and notify the sender 
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556). 
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, 
England. Web: www.toshiba.eu/research/trl
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio