Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)

[Nikos Balkanas]

Hi,

This issue is better addressed to usrp-us...@ettus.com. Briefly I can tell
you that you can never reach 30M samples/sec over a 1 GbE interface.
30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, etc.
you will drop packages. Especially if your NIC is PCI based :(
Try reducing your sample resolution to 8 bits. You may have better luck.

HTH,
Nikos

On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh 
wrote:

> Hello all,
> I stuck on an incridible challenge in sending/receiving a large bandwidth.
> I have an USRP N210 and an WBX daughterboard, while I must be able to
> capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with the sample
> rate of 25Msps or even 20Msps I have some dropped packets. Based on my
> knowledge, this is due to CPU which does not have enough time to capture
> from Ethernet, however, I have the powerful one, 12 core CPU. When I have a
> large GNURadio program to run, there are some dropped packets. I searched
> everywhere but I did not find a complete description of the solution. What
> is (are ) the solution(s )? Please help me with any information! :(
>
> Best regards
> Mostafa
>
> ___
> 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] Packet drop from Ethernet (A BIG PROBLEM)

[Mostafa Alizadeh]

Hello all,
I stuck on an incridible challenge in sending/receiving a large bandwidth.
I have an USRP N210 and an WBX daughterboard, while I must be able to
capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with the sample
rate of 25Msps or even 20Msps I have some dropped packets. Based on my
knowledge, this is due to CPU which does not have enough time to capture
from Ethernet, however, I have the powerful one, 12 core CPU. When I have a
large GNURadio program to run, there are some dropped packets. I searched
everywhere but I did not find a complete description of the solution. What
is (are ) the solution(s )? Please help me with any information! :(

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

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

Hi Nate,

Baudline was my first software spectrum analyzer, 2 yrs ago, until
gr-fosphor came out and I switched. Used it close to a year. Right now I'm
building gnuradio 3.7.9.1 since 3.7.6.1 has a few blocks missing. Then i
plan to continue with my RFNoC work, while Xilinx evaluation licenses are
still valid. I'm not really interested in baudline anymore, but will play
with the apperture and Const block when gnuradio installation finishes :)

BR,
Nikos

On Wed, Mar 9, 2016 at 8:36 AM, Nate Temple  wrote:

> Hi Nikos,
>
> Glad to hear that it is working. As far as it displaying a black screen,
> that is because baudline isn't representing enough dynamic range for the
> USRP. A little trick, if you add a Multi Const block before the baudline
> sink, and enter a value of 1000 or 1, it will artificially increase the
> signal magnitude to where baudline will display.
>
> You can also adjust the Color Aperture [1] , which may or may not help.
>
> [1] http://www.baudline.com/manual/color_picker.html#color_aperture
>
> - Nate
>
>
>
> > On Mar 8, 2016, at 9:45 PM, Nikos Balkanas  wrote:
> >
> > That did it.
> >
> > Thank you all very much. I didn't get any real spectrum out of it, just
> a black screen, but at least i know that my companion flow setup works:)
> > I prefer gr-fosphor to baudline:)
> > I hope that other blocks include more documentation (baudline sink has
> none), and that error messages are more specific (i.e. filename in missing
> file error)
> >
> > BR,
> > Nikos
> >
> > On Wed, Mar 9, 2016 at 7:08 AM, Nate Temple 
> wrote:
> > Hi Nikos,
> >
> > You need the baudline binary which is here [1]. It will unpack to the
> folder baudline_1.08_linux_x86_64/. Put the contents in the folder
> baudline_1.08_linux_x86_64/ in your home directory. You should then be able
> to call the command "baudline" and if that works, the GR sink block should
> work.
> >
> > [1] - http://www.baudline.com/baudline_1.08_linux_x86_64.tar.gz
> >
> >
> > - Nate
> >
> >
> > > On Mar 8, 2016, at 8:59 PM, Nikos Balkanas 
> wrote:
> > >
> > > Hi Nate,
> > >
> > > I imagine you refer to baudline.py which is in the error trace.
> > >
> > > > baudline
> > > baudline: command not found
> > >
> > > For baudline.py to run, I would have to have
> /usr/local/lib/python2.7/... part of my PATH, which i don't.
> > >
> > > > echo $PATH
> > >
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
> > > Is this smt i should add to my PATH?
> > >
> > > > ls -la baudline_1.08_linux_x86_64
> > > total 8
> > > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
> > > drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..
> > >
> > > BR,
> > > Nikos
> > >
> > > On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple 
> wrote:
> > > Hi Nikos,
> > >
> > > Does baudline start if you just run the command "baudline" from the
> terminal?
> > >
> > > Can you send the output of this command:
> > >
> > > ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
> > >
> > >
> > > - Nate
> > >
> > >
> > > > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas 
> wrote:
> > > >
> > > > Hi Marcus,
> > > >
> > > > I imagine you mean the top_block.py generated by the flow.
> > > >
> > > > The output is much longer, includes all x300 initialization
> sequences, but eventually I get the same error as before:(
> > > >
> > > > Nikos
> > > >
> > > > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech 
> wrote:
> > > > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
> > > >> Hi Nate,
> > > >>
> > > >> Not really. I added line to .profile (that's where I maintain PATH)
> and reexported PATH with the new value, b4 starting the companion. It
> shouldn't make a difference.
> > > >> I then rebooted my PC, just to make sure that PATH was updated
> correctly, same error as before.
> > > >>
> > > >> BR,
> > > >> Nikos
> > > > If you just try to execute the generated .py file, from a window
> that apparently has correct PATH, what happens?
> > > >
> > > >
> > > >>
> > > >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple 
> wrote:
> > > >> Hi Nikos,
> > > >>
> > > >> Did you restart gnuradio-companion from a new terminal after adding
> the line to your ~/.bashrc file?
> > > >>
> > > >>
> > > >> - Nate
> > > >>
> > > >>
> > > >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas 
> wrote:
> > > >> >
> > > >> > ​Hi Nate,
> > > >> >
> > > >> > Thank you for your fast reply. I tried your suggestions, but i
> seem to still get the same error:
> > > >> >
> > > >> > > echo $PATH
> > > >> >
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
> ​
> > > >> >
> > > >> > > ls -ld baud*
> > > >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31
> baudline_1.08_linux_x86_64
> > > >> >
> > > >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
> '-samplerate', '4000', '-

Re: [Discuss-gnuradio] Companion flow error

[Nate Temple]

Hi Nikos,

Glad to hear that it is working. As far as it displaying a black screen, that 
is because baudline isn't representing enough dynamic range for the USRP. A 
little trick, if you add a Multi Const block before the baudline sink, and 
enter a value of 1000 or 1, it will artificially increase the signal 
magnitude to where baudline will display. 

You can also adjust the Color Aperture [1] , which may or may not help.

[1] http://www.baudline.com/manual/color_picker.html#color_aperture

- Nate



> On Mar 8, 2016, at 9:45 PM, Nikos Balkanas  wrote:
> 
> That did it.
> 
> Thank you all very much. I didn't get any real spectrum out of it, just a 
> black screen, but at least i know that my companion flow setup works:)
> I prefer gr-fosphor to baudline:)
> I hope that other blocks include more documentation (baudline sink has none), 
> and that error messages are more specific (i.e. filename in missing file 
> error)
> 
> BR,
> Nikos
> 
> On Wed, Mar 9, 2016 at 7:08 AM, Nate Temple  wrote:
> Hi Nikos,
> 
> You need the baudline binary which is here [1]. It will unpack to the folder 
> baudline_1.08_linux_x86_64/. Put the contents in the folder 
> baudline_1.08_linux_x86_64/ in your home directory. You should then be able 
> to call the command "baudline" and if that works, the GR sink block should 
> work.
> 
> [1] - http://www.baudline.com/baudline_1.08_linux_x86_64.tar.gz
> 
> 
> - Nate
> 
> 
> > On Mar 8, 2016, at 8:59 PM, Nikos Balkanas  wrote:
> >
> > Hi Nate,
> >
> > I imagine you refer to baudline.py which is in the error trace.
> >
> > > baudline
> > baudline: command not found
> >
> > For baudline.py to run, I would have to have /usr/local/lib/python2.7/... 
> > part of my PATH, which i don't.
> >
> > > echo $PATH
> > /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
> > Is this smt i should add to my PATH?
> >
> > > ls -la baudline_1.08_linux_x86_64
> > total 8
> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
> > drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..
> >
> > BR,
> > Nikos
> >
> > On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple  wrote:
> > Hi Nikos,
> >
> > Does baudline start if you just run the command "baudline" from the 
> > terminal?
> >
> > Can you send the output of this command:
> >
> > ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
> >
> >
> > - Nate
> >
> >
> > > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas  wrote:
> > >
> > > Hi Marcus,
> > >
> > > I imagine you mean the top_block.py generated by the flow.
> > >
> > > The output is much longer, includes all x300 initialization sequences, 
> > > but eventually I get the same error as before:(
> > >
> > > Nikos
> > >
> > > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech  wrote:
> > > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
> > >> Hi Nate,
> > >>
> > >> Not really. I added line to .profile (that's where I maintain PATH) and 
> > >> reexported PATH with the new value, b4 starting the companion. It 
> > >> shouldn't make a difference.
> > >> I then rebooted my PC, just to make sure that PATH was updated 
> > >> correctly, same error as before.
> > >>
> > >> BR,
> > >> Nikos
> > > If you just try to execute the generated .py file, from a window that 
> > > apparently has correct PATH, what happens?
> > >
> > >
> > >>
> > >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple  
> > >> wrote:
> > >> Hi Nikos,
> > >>
> > >> Did you restart gnuradio-companion from a new terminal after adding the 
> > >> line to your ~/.bashrc file?
> > >>
> > >>
> > >> - Nate
> > >>
> > >>
> > >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas  wrote:
> > >> >
> > >> > ​Hi Nate,
> > >> >
> > >> > Thank you for your fast reply. I tried your suggestions, but i seem to 
> > >> > still get the same error:
> > >> >
> > >> > > echo $PATH
> > >> > /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
> > >> >  ​
> > >> >
> > >> > > ls -ld baud*
> > >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
> > >> >
> > >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause', 
> > >> > >'-samplerate', '4000', '-channels', '2', '-format', 'le32f', 
> > >> > >'-quadrature', '-basefrequency', '21.0']
> > >> > [Errno 2] No such file or directory
> > >> > Traceback (most recent call last):
> > >> > File "/home/nikos/Desktop/top_block.py", line 116, in 
> > >> > tb = top_block()
> > >> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> > >> > **{})
> > >> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 
> > >> > 146, in __init__
> > >> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   
> > >> > # , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> > >> > File "/usr/lib/python2.7/subproce

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

The a and c vectors come from gr:fft objects' internal buffers. These are
internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
fftwf_malloc is obviously not generating buffers with proper alignment so
you're seeing a 50% (per buffer) that this segfaults. I'll note that this
is also only an issue with fftwf buffers when fftwf isn't built with AVX
support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).

Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
ago with a QT sink.

I have a branch that should fix this (
https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also suggest
you look in to getting a version of fftwf built with AVX. I don't know if
there's a good way to tell, but if I run readelf -a on my libfftw3.so I see
some functions with avx in the name.

Cheers,
nw


On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:

> OK, here's my C program:
>
> #include 
> #include 
> #include 
> #include 
>
> int main() {
>
> size_t alignment = volk_get_alignment();
>
> uint8_t* ptr;
>
> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr, *ptr);
> volk_free((void*)ptr);
> ptr = NULL;
>
>
> return 0;
> }
>
>
> Compile:
>
> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>
> It's output:
>
> $ ./volk_test
> Using Volk machine: avx2_64_mmx_orc
> alignment = 32, ptr = 151b040, *ptr = 00
>
> Also, I've attached the output from the preprocessor, this command:
>
> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
> -I/local_disk/gr_3.7.9_src/volk/include
> -I/local_disk/gr_3.7.9_src/volk/kernels
> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
> volk_malloc_preprocessed   -c
> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>
> I just found the compiler step from from doing 'VERBOSE=1 make' then
> changed the output and added -E.  I attached volk_malloc_preprocessed as
> well.
>
> It looks like this is my volk_malloc():
>
>
> void *volk_malloc(size_t size, size_t alignment)
> {
>   void *ptr;
>
>
>
>
>   if (alignment == 1)
> return malloc(size);
>
>   int err = posix_memalign(&ptr, alignment, size);
>   if(err == 0) {
> return ptr;
>   }
>   else {
> fprintf(stderr,
> "VOLK: Error allocating memory "
> "(posix_memalign: error %d: %s)\n", err, strerror(err));
> return ((void *)0);
>   }
> }
>
>
>
> Devin
>
>
>
> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan  > wrote:
>
>>
>> On Tue, Mar 8, 2016 at 10:58 AM, devin kelly  wrote:
>>
>>> Calling 'info variables' (or args or locals) the last few frames didn't
>>> give me any real info so I built a copy of GR/Volk with debug symbols.  I
>>> ran the FG again, this time from GDB, here's my back trace.  In this
>>> backtrace you can see the arguments passed in each call.  I have an
>>> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>>>
>>
>> Excellent. Thanks for going through that extra step. It really helps.
>>
>>
>>>
>>> Here's are the links for the relevant code:
>>>
>>>
>>> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>>>
>>> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>>>
>>> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>>>
>>> Could the problem be that nitems is 257 and num_points is 512?  Or
>>> should nitems really be 256 and not 257?
>>>
>>
>> I don't think so. I'm not familiar with the details of the fft_filter
>> implementations, but usually these things will take in some history if they
>> don't have enough points to operate on (in this case 512).
>>
>> The much more worrying thing is your vector addresses.
>>
>>
>>>
>>> Thanks,
>>> Devin
>>>
>>> (gdb) bt
>>> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>>> (__P=0x3b051b0)
>>> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>>> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>>> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>>>
>>
>> 0x3b1f770 % 32 = 16 (bad)
>> 0x3b051b0 % 32 = 16 (bad)
>> 0x3b240e0 % 32 = 0 (good)
>>
>> Unfortunately it looks like volk_get_alignment is returning the wrong
>> thing or there's a bug in volk_malloc. Can you tell us what
>> volk_get_alignment returns? The easiest thing is probably to write a simple
>> C program that prints out the result (hmm, I should add that to
>> volk-config-info). I'd also like to know which volk_malloc implementation
>> you're using. Unfortunately I don't think we have an easy way to discover
>> that

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

That did it.

Thank you all very much. I didn't get any real spectrum out of it, just a
black screen, but at least i know that my companion flow setup works:)
I prefer gr-fosphor to baudline:)
I hope that other blocks include more documentation (baudline sink has
none), and that error messages are more specific (i.e. filename in missing
file error)

BR,
Nikos

On Wed, Mar 9, 2016 at 7:08 AM, Nate Temple  wrote:

> Hi Nikos,
>
> You need the baudline binary which is here [1]. It will unpack to the
> folder baudline_1.08_linux_x86_64/. Put the contents in the folder
> baudline_1.08_linux_x86_64/ in your home directory. You should then be able
> to call the command "baudline" and if that works, the GR sink block should
> work.
>
> [1] - http://www.baudline.com/baudline_1.08_linux_x86_64.tar.gz
>
>
> - Nate
>
>
> > On Mar 8, 2016, at 8:59 PM, Nikos Balkanas  wrote:
> >
> > Hi Nate,
> >
> > I imagine you refer to baudline.py which is in the error trace.
> >
> > > baudline
> > baudline: command not found
> >
> > For baudline.py to run, I would have to have
> /usr/local/lib/python2.7/... part of my PATH, which i don't.
> >
> > > echo $PATH
> >
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
> > Is this smt i should add to my PATH?
> >
> > > ls -la baudline_1.08_linux_x86_64
> > total 8
> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
> > drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..
> >
> > BR,
> > Nikos
> >
> > On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple 
> wrote:
> > Hi Nikos,
> >
> > Does baudline start if you just run the command "baudline" from the
> terminal?
> >
> > Can you send the output of this command:
> >
> > ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
> >
> >
> > - Nate
> >
> >
> > > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas 
> wrote:
> > >
> > > Hi Marcus,
> > >
> > > I imagine you mean the top_block.py generated by the flow.
> > >
> > > The output is much longer, includes all x300 initialization sequences,
> but eventually I get the same error as before:(
> > >
> > > Nikos
> > >
> > > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech 
> wrote:
> > > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
> > >> Hi Nate,
> > >>
> > >> Not really. I added line to .profile (that's where I maintain PATH)
> and reexported PATH with the new value, b4 starting the companion. It
> shouldn't make a difference.
> > >> I then rebooted my PC, just to make sure that PATH was updated
> correctly, same error as before.
> > >>
> > >> BR,
> > >> Nikos
> > > If you just try to execute the generated .py file, from a window that
> apparently has correct PATH, what happens?
> > >
> > >
> > >>
> > >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple 
> wrote:
> > >> Hi Nikos,
> > >>
> > >> Did you restart gnuradio-companion from a new terminal after adding
> the line to your ~/.bashrc file?
> > >>
> > >>
> > >> - Nate
> > >>
> > >>
> > >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas 
> wrote:
> > >> >
> > >> > ​Hi Nate,
> > >> >
> > >> > Thank you for your fast reply. I tried your suggestions, but i seem
> to still get the same error:
> > >> >
> > >> > > echo $PATH
> > >> >
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
> ​
> > >> >
> > >> > > ls -ld baud*
> > >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
> > >> >
> > >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
> '-samplerate', '4000', '-channels', '2', '-format', 'le32f',
> '-quadrature', '-basefrequency', '21.0']
> > >> > [Errno 2] No such file or directory
> > >> > Traceback (most recent call last):
> > >> > File "/home/nikos/Desktop/top_block.py", line 116, in 
> > >> > tb = top_block()
> > >> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> > >> > **{})
> > >> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line
> 146, in __init__
> > >> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)
># , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> > >> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> > >> > errread, errwrite)
> > >> > File "/usr/lib/python2.7/subprocess.py", line 1327, in
> _execute_child
> > >> > raise child_exception
> > >> > OSError: [Errno 2] No such file or directory
> > >> >
> > >> > >>> Done
> > >> >
> > >> > Attaching new flowgraph and top_block.py.
> > >> >
> > >> > BR
> > >> > Nikos
> > >> >
> > >> >
> > >> >
> > >> > 
> > >>
> > >>
> > >>
> > >>
> > >> ___
> > >> Discuss-gnuradio mailing list
> > >>
> > >> Discuss-gnuradio@gnu.org
> > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > ___
> > > Discuss-gnuradio

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

Marcus D. Leach wrote:

> You have nothing in your baudline directory, other than the usual "." and
".." housekeeping links.

Yeah,

I just created it myself as told in initial posting. I thought it was a
directory needed by the pipe.
Judging from Nate's suggestion i need to install an executable there. Will
update thread, when I do.

Thanks,
Nikos

On Wed, Mar 9, 2016 at 7:08 AM, Marcus D. Leech  wrote:

> On 03/08/2016 11:59 PM, Nikos Balkanas wrote:
>
> Hi Nate,
>
> I imagine you refer to baudline.py which is in the error trace.
>
> > baudline
> baudline: command not found
>
> For baudline.py to run, I would have to have /usr/local/lib/python2.7/...
> part of my PATH, which i don't.
>
> > echo $PATH
>
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
> Is this smt i should add to my PATH?
>
> > ls -la baudline_1.08_linux_x86_64
> total 8
> drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
> drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..
>
> BR,
> Nikos
>
> You have nothing in your baudline directory, other than the usual "." and
> ".." housekeeping links.
>
>
>
> On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple  wrote:
>
>> Hi Nikos,
>>
>> Does baudline start if you just run the command "baudline" from the
>> terminal?
>>
>> Can you send the output of this command:
>>
>> ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
>>
>>
>> - Nate
>>
>>
>> > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas  wrote:
>> >
>> > Hi Marcus,
>> >
>> > I imagine you mean the top_block.py generated by the flow.
>> >
>> > The output is much longer, includes all x300 initialization sequences,
>> but eventually I get the same error as before:(
>> >
>> > Nikos
>> >
>> > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech 
>> wrote:
>> > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
>> >> Hi Nate,
>> >>
>> >> Not really. I added line to .profile (that's where I maintain PATH)
>> and reexported PATH with the new value, b4 starting the companion. It
>> shouldn't make a difference.
>> >> I then rebooted my PC, just to make sure that PATH was updated
>> correctly, same error as before.
>> >>
>> >> BR,
>> >> Nikos
>> > If you just try to execute the generated .py file, from a window that
>> apparently has correct PATH, what happens?
>> >
>> >
>> >>
>> >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple 
>> wrote:
>> >> Hi Nikos,
>> >>
>> >> Did you restart gnuradio-companion from a new terminal after adding
>> the line to your ~/.bashrc file?
>> >>
>> >>
>> >> - Nate
>> >>
>> >>
>> >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas 
>> wrote:
>> >> >
>> >> > ​Hi Nate,
>> >> >
>> >> > Thank you for your fast reply. I tried your suggestions, but i seem
>> to still get the same error:
>> >> >
>> >> > > echo $PATH
>> >> >
>> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
>> ​
>> >> >
>> >> > > ls -ld baud*
>> >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
>> >> >
>> >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
>> '-samplerate', '4000', '-channels', '2', '-format', 'le32f',
>> '-quadrature', '-basefrequency', '21.0']
>> >> > [Errno 2] No such file or directory
>> >> > Traceback (most recent call last):
>> >> > File "/home/nikos/Desktop/top_block.py", line 116, in 
>> >> > tb = top_block()
>> >> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
>> >> > **{})
>> >> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line
>> 146, in __init__
>> >> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)
>>  # , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
>> >> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>> >> > errread, errwrite)
>> >> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>> >> > raise child_exception
>> >> > OSError: [Errno 2] No such file or directory
>> >> >
>> >> > >>> Done
>> >> >
>> >> > Attaching new flowgraph and top_block.py.
>> >> >
>> >> > BR
>> >> > Nikos
>> >> >
>> >> >
>> >> >
>> >> > 
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> Discuss-gnuradio mailing list
>> >>
>> >> Discuss-gnuradio@gnu.org
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

I just changed PYTHONPATH to python2.7. It was pointing to python3.4.
Didn't help, though :(

BR,
Nikos



On Wed, Mar 9, 2016 at 6:59 AM, Nikos Balkanas  wrote:

> Hi Nate,
>
> I imagine you refer to baudline.py which is in the error trace.
>
> > baudline
> baudline: command not found
>
> For baudline.py to run, I would have to have /usr/local/lib/python2.7/...
> part of my PATH, which i don't.
>
> > echo $PATH
>
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
> Is this smt i should add to my PATH?
>
> > ls -la baudline_1.08_linux_x86_64
> total 8
> drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
> drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..
>
> BR,
> Nikos
>
> On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple  wrote:
>
>> Hi Nikos,
>>
>> Does baudline start if you just run the command "baudline" from the
>> terminal?
>>
>> Can you send the output of this command:
>>
>> ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
>>
>>
>> - Nate
>>
>>
>> > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas  wrote:
>> >
>> > Hi Marcus,
>> >
>> > I imagine you mean the top_block.py generated by the flow.
>> >
>> > The output is much longer, includes all x300 initialization sequences,
>> but eventually I get the same error as before:(
>> >
>> > Nikos
>> >
>> > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech 
>> wrote:
>> > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
>> >> Hi Nate,
>> >>
>> >> Not really. I added line to .profile (that's where I maintain PATH)
>> and reexported PATH with the new value, b4 starting the companion. It
>> shouldn't make a difference.
>> >> I then rebooted my PC, just to make sure that PATH was updated
>> correctly, same error as before.
>> >>
>> >> BR,
>> >> Nikos
>> > If you just try to execute the generated .py file, from a window that
>> apparently has correct PATH, what happens?
>> >
>> >
>> >>
>> >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple 
>> wrote:
>> >> Hi Nikos,
>> >>
>> >> Did you restart gnuradio-companion from a new terminal after adding
>> the line to your ~/.bashrc file?
>> >>
>> >>
>> >> - Nate
>> >>
>> >>
>> >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas 
>> wrote:
>> >> >
>> >> > ​Hi Nate,
>> >> >
>> >> > Thank you for your fast reply. I tried your suggestions, but i seem
>> to still get the same error:
>> >> >
>> >> > > echo $PATH
>> >> >
>> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
>> ​
>> >> >
>> >> > > ls -ld baud*
>> >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
>> >> >
>> >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
>> '-samplerate', '4000', '-channels', '2', '-format', 'le32f',
>> '-quadrature', '-basefrequency', '21.0']
>> >> > [Errno 2] No such file or directory
>> >> > Traceback (most recent call last):
>> >> > File "/home/nikos/Desktop/top_block.py", line 116, in 
>> >> > tb = top_block()
>> >> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
>> >> > **{})
>> >> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line
>> 146, in __init__
>> >> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)
>>  # , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
>> >> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>> >> > errread, errwrite)
>> >> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>> >> > raise child_exception
>> >> > OSError: [Errno 2] No such file or directory
>> >> >
>> >> > >>> Done
>> >> >
>> >> > Attaching new flowgraph and top_block.py.
>> >> >
>> >> > BR
>> >> > Nikos
>> >> >
>> >> >
>> >> >
>> >> > 
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> Discuss-gnuradio mailing list
>> >>
>> >> Discuss-gnuradio@gnu.org
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Companion flow error

[Marcus D. Leech]

On 03/08/2016 11:59 PM, Nikos Balkanas wrote:

Hi Nate,

I imagine you refer to baudline.py which is in the error trace.

> baudline
baudline: command not found

For baudline.py to run, I would have to have 
/usr/local/lib/python2.7/... part of my PATH, which i don't.


> echo $PATH
/opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
Is this smt i should add to my PATH?

> ls -la baudline_1.08_linux_x86_64
total 8
drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..

BR,
Nikos
You have nothing in your baudline directory, other than the usual "." 
and ".." housekeeping links.




On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple > wrote:


Hi Nikos,

Does baudline start if you just run the command "baudline" from
the terminal?

Can you send the output of this command:

ls -al /home/nikos/baudline_1.08_linux_x86_64 ​


- Nate


> On Mar 8, 2016, at 8:33 PM, Nikos Balkanas mailto:nbalka...@gmail.com>> wrote:
>
> Hi Marcus,
>
> I imagine you mean the top_block.py generated by the flow.
>
> The output is much longer, includes all x300 initialization
sequences, but eventually I get the same error as before:(
>
> Nikos
>
> On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech
mailto:mle...@ripnet.com>> wrote:
> On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
>> Hi Nate,
>>
>> Not really. I added line to .profile (that's where I maintain
PATH) and reexported PATH with the new value, b4 starting the
companion. It shouldn't make a difference.
>> I then rebooted my PC, just to make sure that PATH was updated
correctly, same error as before.
>>
>> BR,
>> Nikos
> If you just try to execute the generated .py file, from a window
that apparently has correct PATH, what happens?
>
>
>>
>> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple
mailto:nate.tem...@ettus.com>> wrote:
>> Hi Nikos,
>>
>> Did you restart gnuradio-companion from a new terminal after
adding the line to your ~/.bashrc file?
>>
>>
>> - Nate
>>
>>
>> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas
mailto:nbalka...@gmail.com>> wrote:
>> >
>> > ​Hi Nate,
>> >
>> > Thank you for your fast reply. I tried your suggestions, but
i seem to still get the same error:
>> >
>> > > echo $PATH
>> >

/opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
​
>> >
>> > > ls -ld baud*
>> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31
baudline_1.08_linux_x86_64
>> >
>> > >['baudline', '-stdin', '-record', '-spacebar',
'recordpause', '-samplerate', '4000', '-channels', '2',
'-format', 'le32f', '-quadrature', '-basefrequency', '21.0']
>> > [Errno 2] No such file or directory
>> > Traceback (most recent call last):
>> > File "/home/nikos/Desktop/top_block.py", line 116, in 
>> > tb = top_block()
>> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
>> > **{})
>> > File
"/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line
146, in __init__
>> > self.p = subprocess.Popen(baudline_exec,
stdin=subprocess.PIPE)   # , stdout=subprocess.PIPE,
stderr=subprocess.PIPE, bufsize=16384 or -1
>> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>> > errread, errwrite)
>> > File "/usr/lib/python2.7/subprocess.py", line 1327, in
_execute_child
>> > raise child_exception
>> > OSError: [Errno 2] No such file or directory
>> >
>> > >>> Done
>> >
>> > Attaching new flowgraph and top_block.py.
>> >
>> > BR
>> > Nikos
>> >
>> >
>> >
>> > 
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>>
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




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

Re: [Discuss-gnuradio] Companion flow error

[Nate Temple]

Hi Nikos,

You need the baudline binary which is here [1]. It will unpack to the folder 
baudline_1.08_linux_x86_64/. Put the contents in the folder 
baudline_1.08_linux_x86_64/ in your home directory. You should then be able to 
call the command "baudline" and if that works, the GR sink block should work. 

[1] - http://www.baudline.com/baudline_1.08_linux_x86_64.tar.gz


- Nate


> On Mar 8, 2016, at 8:59 PM, Nikos Balkanas  wrote:
> 
> Hi Nate,
> 
> I imagine you refer to baudline.py which is in the error trace.
> 
> > baudline
> baudline: command not found
> 
> For baudline.py to run, I would have to have /usr/local/lib/python2.7/... 
> part of my PATH, which i don't.
> 
> > echo $PATH
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
> Is this smt i should add to my PATH?
> 
> > ls -la baudline_1.08_linux_x86_64
> total 8
> drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
> drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..
> 
> BR,
> Nikos
> 
> On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple  wrote:
> Hi Nikos,
> 
> Does baudline start if you just run the command "baudline" from the terminal?
> 
> Can you send the output of this command:
> 
> ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
> 
> 
> - Nate
> 
> 
> > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas  wrote:
> >
> > Hi Marcus,
> >
> > I imagine you mean the top_block.py generated by the flow.
> >
> > The output is much longer, includes all x300 initialization sequences, but 
> > eventually I get the same error as before:(
> >
> > Nikos
> >
> > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech  wrote:
> > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
> >> Hi Nate,
> >>
> >> Not really. I added line to .profile (that's where I maintain PATH) and 
> >> reexported PATH with the new value, b4 starting the companion. It 
> >> shouldn't make a difference.
> >> I then rebooted my PC, just to make sure that PATH was updated correctly, 
> >> same error as before.
> >>
> >> BR,
> >> Nikos
> > If you just try to execute the generated .py file, from a window that 
> > apparently has correct PATH, what happens?
> >
> >
> >>
> >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple  wrote:
> >> Hi Nikos,
> >>
> >> Did you restart gnuradio-companion from a new terminal after adding the 
> >> line to your ~/.bashrc file?
> >>
> >>
> >> - Nate
> >>
> >>
> >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas  wrote:
> >> >
> >> > ​Hi Nate,
> >> >
> >> > Thank you for your fast reply. I tried your suggestions, but i seem to 
> >> > still get the same error:
> >> >
> >> > > echo $PATH
> >> > /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
> >> >  ​
> >> >
> >> > > ls -ld baud*
> >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
> >> >
> >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause', 
> >> > >'-samplerate', '4000', '-channels', '2', '-format', 'le32f', 
> >> > >'-quadrature', '-basefrequency', '21.0']
> >> > [Errno 2] No such file or directory
> >> > Traceback (most recent call last):
> >> > File "/home/nikos/Desktop/top_block.py", line 116, in 
> >> > tb = top_block()
> >> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> >> > **{})
> >> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, 
> >> > in __init__
> >> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   # 
> >> > , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> >> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> >> > errread, errwrite)
> >> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> >> > raise child_exception
> >> > OSError: [Errno 2] No such file or directory
> >> >
> >> > >>> Done
> >> >
> >> > Attaching new flowgraph and top_block.py.
> >> >
> >> > BR
> >> > Nikos
> >> >
> >> >
> >> >
> >> > 
> >>
> >>
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >>
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 


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

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

Hi Nate,

I imagine you refer to baudline.py which is in the error trace.

> baudline
baudline: command not found

For baudline.py to run, I would have to have /usr/local/lib/python2.7/...
part of my PATH, which i don't.

> echo $PATH
/opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/home/nikos/baudline_1.08_linux_x86_64:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.
Is this smt i should add to my PATH?

> ls -la baudline_1.08_linux_x86_64
total 8
drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 .
drwxr-xr-x 54 nikos nikos 4096 Mar 9 06:52 ..

BR,
Nikos

On Wed, Mar 9, 2016 at 6:51 AM, Nate Temple  wrote:

> Hi Nikos,
>
> Does baudline start if you just run the command "baudline" from the
> terminal?
>
> Can you send the output of this command:
>
> ls -al /home/nikos/baudline_1.08_linux_x86_64 ​
>
>
> - Nate
>
>
> > On Mar 8, 2016, at 8:33 PM, Nikos Balkanas  wrote:
> >
> > Hi Marcus,
> >
> > I imagine you mean the top_block.py generated by the flow.
> >
> > The output is much longer, includes all x300 initialization sequences,
> but eventually I get the same error as before:(
> >
> > Nikos
> >
> > On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech 
> wrote:
> > On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
> >> Hi Nate,
> >>
> >> Not really. I added line to .profile (that's where I maintain PATH) and
> reexported PATH with the new value, b4 starting the companion. It shouldn't
> make a difference.
> >> I then rebooted my PC, just to make sure that PATH was updated
> correctly, same error as before.
> >>
> >> BR,
> >> Nikos
> > If you just try to execute the generated .py file, from a window that
> apparently has correct PATH, what happens?
> >
> >
> >>
> >> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple 
> wrote:
> >> Hi Nikos,
> >>
> >> Did you restart gnuradio-companion from a new terminal after adding the
> line to your ~/.bashrc file?
> >>
> >>
> >> - Nate
> >>
> >>
> >> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas 
> wrote:
> >> >
> >> > ​Hi Nate,
> >> >
> >> > Thank you for your fast reply. I tried your suggestions, but i seem
> to still get the same error:
> >> >
> >> > > echo $PATH
> >> >
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
> ​
> >> >
> >> > > ls -ld baud*
> >> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
> >> >
> >> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
> '-samplerate', '4000', '-channels', '2', '-format', 'le32f',
> '-quadrature', '-basefrequency', '21.0']
> >> > [Errno 2] No such file or directory
> >> > Traceback (most recent call last):
> >> > File "/home/nikos/Desktop/top_block.py", line 116, in 
> >> > tb = top_block()
> >> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> >> > **{})
> >> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line
> 146, in __init__
> >> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)
>  # , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> >> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> >> > errread, errwrite)
> >> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> >> > raise child_exception
> >> > OSError: [Errno 2] No such file or directory
> >> >
> >> > >>> Done
> >> >
> >> > Attaching new flowgraph and top_block.py.
> >> >
> >> > BR
> >> > Nikos
> >> >
> >> >
> >> >
> >> > 
> >>
> >>
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >>
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Companion flow error

[Nate Temple]

Hi Nikos,

Does baudline start if you just run the command "baudline" from the terminal?

Can you send the output of this command:

ls -al /home/nikos/baudline_1.08_linux_x86_64 ​


- Nate


> On Mar 8, 2016, at 8:33 PM, Nikos Balkanas  wrote:
> 
> Hi Marcus,
> 
> I imagine you mean the top_block.py generated by the flow.
> 
> The output is much longer, includes all x300 initialization sequences, but 
> eventually I get the same error as before:(
> 
> Nikos
> 
> On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech  wrote:
> On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
>> Hi Nate,
>> 
>> Not really. I added line to .profile (that's where I maintain PATH) and 
>> reexported PATH with the new value, b4 starting the companion. It shouldn't 
>> make a difference.
>> I then rebooted my PC, just to make sure that PATH was updated correctly, 
>> same error as before.
>> 
>> BR,
>> Nikos
> If you just try to execute the generated .py file, from a window that 
> apparently has correct PATH, what happens?
> 
> 
>> 
>> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple  wrote:
>> Hi Nikos,
>> 
>> Did you restart gnuradio-companion from a new terminal after adding the line 
>> to your ~/.bashrc file?
>> 
>> 
>> - Nate
>> 
>> 
>> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas  wrote:
>> >
>> > ​Hi Nate,
>> >
>> > Thank you for your fast reply. I tried your suggestions, but i seem to 
>> > still get the same error:
>> >
>> > > echo $PATH
>> > /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
>> >  ​
>> >
>> > > ls -ld baud*
>> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
>> >
>> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause', 
>> > >'-samplerate', '4000', '-channels', '2', '-format', 'le32f', 
>> > >'-quadrature', '-basefrequency', '21.0']
>> > [Errno 2] No such file or directory
>> > Traceback (most recent call last):
>> > File "/home/nikos/Desktop/top_block.py", line 116, in 
>> > tb = top_block()
>> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
>> > **{})
>> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, 
>> > in __init__
>> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   # , 
>> > stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
>> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>> > errread, errwrite)
>> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>> > raise child_exception
>> > OSError: [Errno 2] No such file or directory
>> >
>> > >>> Done
>> >
>> > Attaching new flowgraph and top_block.py.
>> >
>> > BR
>> > Nikos
>> >
>> >
>> >
>> > 
>> 
>> 
>> 
>> 
>> ___
>> Discuss-gnuradio mailing list
>> 
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

Hi Marcus,

I imagine you mean the top_block.py generated by the flow.

The output is much longer, includes all x300 initialization sequences, but
eventually I get the same error as before:(

Nikos

On Wed, Mar 9, 2016 at 6:22 AM, Marcus D. Leech  wrote:

> On 03/08/2016 11:10 PM, Nikos Balkanas wrote:
>
> Hi Nate,
>
> Not really. I added line to .profile (that's where I maintain PATH) and
> reexported PATH with the new value, b4 starting the companion. It shouldn't
> make a difference.
> I then rebooted my PC, just to make sure that PATH was updated correctly,
> same error as before.
>
> BR,
> Nikos
>
> If you just try to execute the generated .py file, from a window that
> apparently has correct PATH, what happens?
>
>
>
> On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple  wrote:
>
>> Hi Nikos,
>>
>> Did you restart gnuradio-companion from a new terminal after adding the
>> line to your ~/.bashrc file?
>>
>>
>> - Nate
>>
>>
>> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas  wrote:
>> >
>> > ​Hi Nate,
>> >
>> > Thank you for your fast reply. I tried your suggestions, but i seem to
>> still get the same error:
>> >
>> > > echo $PATH
>> >
>> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
>> ​
>> >
>> > > ls -ld baud*
>> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
>> >
>> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
>> '-samplerate', '4000', '-channels', '2', '-format', 'le32f',
>> '-quadrature', '-basefrequency', '21.0']
>> > [Errno 2] No such file or directory
>> > Traceback (most recent call last):
>> > File "/home/nikos/Desktop/top_block.py", line 116, in 
>> > tb = top_block()
>> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
>> > **{})
>> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line
>> 146, in __init__
>> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   #
>> , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
>> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
>> > errread, errwrite)
>> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
>> > raise child_exception
>> > OSError: [Errno 2] No such file or directory
>> >
>> > >>> Done
>> >
>> > Attaching new flowgraph and top_block.py.
>> >
>> > BR
>> > Nikos
>> >
>> >
>> >
>> > 
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Companion flow error

[Marcus D. Leech]

On 03/08/2016 11:10 PM, Nikos Balkanas wrote:

Hi Nate,

Not really. I added line to .profile (that's where I maintain PATH) 
and reexported PATH with the new value, b4 starting the companion. It 
shouldn't make a difference.
I then rebooted my PC, just to make sure that PATH was updated 
correctly, same error as before.


BR,
Nikos
If you just try to execute the generated .py file, from a window that 
apparently has correct PATH, what happens?





On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple > wrote:


Hi Nikos,

Did you restart gnuradio-companion from a new terminal after
adding the line to your ~/.bashrc file?


- Nate


> On Mar 8, 2016, at 7:09 PM, Nikos Balkanas mailto:nbalka...@gmail.com>> wrote:
>
> ​Hi Nate,
>
> Thank you for your fast reply. I tried your suggestions, but i
seem to still get the same error:
>
> > echo $PATH
>

/opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64
​
>
> > ls -ld baud*
> drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
>
> >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
'-samplerate', '4000', '-channels', '2', '-format', 'le32f',
'-quadrature', '-basefrequency', '21.0']
> [Errno 2] No such file or directory
> Traceback (most recent call last):
> File "/home/nikos/Desktop/top_block.py", line 116, in 
> tb = top_block()
> File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> **{})
> File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py",
line 146, in __init__
> self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE) 
 # , stdout=subprocess.PIPE, stderr=subprocess.PIPE,

bufsize=16384 or -1
> File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
> File "/usr/lib/python2.7/subprocess.py", line 1327, in
_execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
>
> >>> Done
>
> Attaching new flowgraph and top_block.py.
>
> BR
> Nikos
>
>
>
> 




___
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] Companion flow error

[Nikos Balkanas]

Hi Nate,

Not really. I added line to .profile (that's where I maintain PATH) and
reexported PATH with the new value, b4 starting the companion. It shouldn't
make a difference.
I then rebooted my PC, just to make sure that PATH was updated correctly,
same error as before.

BR,
Nikos

On Wed, Mar 9, 2016 at 5:45 AM, Nate Temple  wrote:

> Hi Nikos,
>
> Did you restart gnuradio-companion from a new terminal after adding the
> line to your ~/.bashrc file?
>
>
> - Nate
>
>
> > On Mar 8, 2016, at 7:09 PM, Nikos Balkanas  wrote:
> >
> > ​Hi Nate,
> >
> > Thank you for your fast reply. I tried your suggestions, but i seem to
> still get the same error:
> >
> > > echo $PATH
> >
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64​
> >
> > > ls -ld baud*
> > drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
> >
> > >['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
> '-samplerate', '4000', '-channels', '2', '-format', 'le32f',
> '-quadrature', '-basefrequency', '21.0']
> > [Errno 2] No such file or directory
> > Traceback (most recent call last):
> > File "/home/nikos/Desktop/top_block.py", line 116, in 
> > tb = top_block()
> > File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> > **{})
> > File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146,
> in __init__
> > self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   #
> , stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> > File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> > errread, errwrite)
> > File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> > raise child_exception
> > OSError: [Errno 2] No such file or directory
> >
> > >>> Done
> >
> > Attaching new flowgraph and top_block.py.
> >
> > BR
> > Nikos
> >
> >
> >
> > 
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Companion flow error

[Nate Temple]

Hi Nikos,

Did you restart gnuradio-companion from a new terminal after adding the line to 
your ~/.bashrc file? 


- Nate


> On Mar 8, 2016, at 7:09 PM, Nikos Balkanas  wrote:
> 
> ​Hi Nate,
> 
> Thank you for your fast reply. I tried your suggestions, but i seem to still 
> get the same error:
> 
> > echo $PATH
> /opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64​
> 
> > ls -ld baud*
> drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64
> 
> >['baudline', '-stdin', '-record', '-spacebar', 'recordpause', '-samplerate', 
> >'4000', '-channels', '2', '-format', 'le32f', '-quadrature', 
> >'-basefrequency', '21.0']
> [Errno 2] No such file or directory
> Traceback (most recent call last):
> File "/home/nikos/Desktop/top_block.py", line 116, in 
> tb = top_block()
> File "/home/nikos/Desktop/top_block.py", line 84, in __init__
> **{})
> File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, in 
> __init__
> self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   # , 
> stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
> File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> 
> >>> Done
> 
> Attaching new flowgraph and top_block.py.
> 
> BR
> Nikos
> 
> 
> 
> 


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

Re: [Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

​Hi Nate,

Thank you for your fast reply. I tried your suggestions, but i seem to
still get the same error:

> echo $PATH
/opt/AMDAPPSDK-3.0:/opt/AMD/CodeXL:/home/nikos/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:.:/home/nikos/baud:/home/nikos/baudline_1.08_linux_x86_64​

> ls -ld baud*
drwxrwxr-x 2 nikos nikos 4096 Mar 9 04:31 baudline_1.08_linux_x86_64

>['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
'-samplerate', '4000', '-channels', '2', '-format', 'le32f',
'-quadrature', '-basefrequency', '21.0']
[Errno 2] No such file or directory
Traceback (most recent call last):
File "/home/nikos/Desktop/top_block.py", line 116, in 
tb = top_block()
File "/home/nikos/Desktop/top_block.py", line 84, in __init__
**{})
File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, in
__init__
self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE) # ,
stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

>>> Done

Attaching new flowgraph and top_block.py.

BR
Nikos


Tutorial.grc
Description: Binary data


top_block.py
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Companion flow error

[Nate Temple]

Hi Nikos,

- You should use the UHD: USRP Source block with the x300, instead of the 
Osmocom Source
- Try setting a higher sample rate to start with, 1e6 instead of 32e3
- You need to add the location of baudline to your $PATH variable, you can do 
so by adding the line below to your ~/.bashrc file (Make sure to update to the 
correct path of your baudline folder)

export PATH=$PATH:/home/user/baudline_1.08_linux_x86_64

You'll need to open a new terminal after adding that line and restart 
gnuradio-companion from that new terminal. 

Best Regards, 
Nate



> On Mar 8, 2016, at 6:06 PM, Nikos Balkanas  wrote:
> 
> Hi,
> 
> This is my first attempt at gnuradio flows. I'm trying to run some of the 
> tutorials i have found around. I use Ubuntu 14.04 x64, gnuradio 3.7.1, usrp 
> x300 with latest uhd. I have a very simple flow with an Osmosdr Source 
> connected to a Baudline Sink. I get the following error on execurion:
> 
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 0.032000 MSps
> Actual sample rate: 0.195312 MSps
> ['baudline', '-stdin', '-record', '-spacebar', 'recordpause', '-samplerate', 
> '32000', '-channels', '2', '-format', 'le32f', '-quadrature']
> [Errno 2] No such file or directory
> Traceback (most recent call last):
> File "/home/nikos/Desktop/top_block.py", line 120, in 
> tb = top_block()
> File "/home/nikos/Desktop/top_block.py", line 87, in __init__
> **{})
> File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, in 
> __init__
> self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE)   # , 
> stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
> File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
> errread, errwrite)
> File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
> raise child_exception
> OSError: [Errno 2] No such file or directory
> 
> >>> Done (return code 1)
> 
> Attaching top_block.py and Tutorial.grc. Searching mail archives and the web 
> didn't help. Maybe I don't know yet how to ask it correctly:( Appreciate any 
> suggestions.
> 
> TIA
> Nikos
>  
> 
> ___
> 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] Companion flow error

[Nikos Balkanas]

Hi,

This is my first attempt at gnuradio flows. I'm trying to run some of the
tutorials i have found around. I use Ubuntu 14.04 x64, gnuradio 3.7.1, usrp
x300 with latest uhd. I have a very simple flow with an Osmosdr Source
connected to a Baudline Sink. I get the following error on execurion:

UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.032000 MSps
Actual sample rate: 0.195312 MSps
['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
'-samplerate', '32000', '-channels', '2', '-format', 'le32f', '-quadrature']
[Errno 2] No such file or directory
Traceback (most recent call last):
File "/home/nikos/Desktop/top_block.py", line 120, in 
tb = top_block()
File "/home/nikos/Desktop/top_block.py", line 87, in __init__
**{})
File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, in
__init__
self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE) # ,
stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

>>> Done (return code 1)

Attaching top_block.py and Tutorial.grc. Searching mail archives and the
web didn't help. Maybe I don't know yet how to ask it correctly:(
Appreciate any suggestions.

TIA
Nikos


Tutorial.grc
Description: Binary data


top_block.py
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Companion flow error

[Nikos Balkanas]

Hi,

This is my first attempt at using gnuradio flows with gnuradio-companion. I
am trying to run some flow tutorials i have found around.
I use Ubuntu 14.04 x64, with grc 3.7.1, X300 usrp and latest uhd. Using a
simple flow of an Osmosdr Source connected to a Baudline Sink I get the
following error on execution:

UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 0.032000 MSps
Actual sample rate: 0.195312 MSps
['baudline', '-stdin', '-record', '-spacebar', 'recordpause',
'-samplerate', '32000', '-channels', '2', '-format', 'le32f', '-quadrature']
[Errno 2] No such file or directory
Traceback (most recent call last):
File "/home/nikos/Desktop/top_block.py", line 120, in 
tb = top_block()
File "/home/nikos/Desktop/top_block.py", line 87, in __init__
**{})
File "/usr/local/lib/python2.7/dist-packages/baz/baudline.py", line 146, in
__init__
self.p = subprocess.Popen(baudline_exec, stdin=subprocess.PIPE) # ,
stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=16384 or -1
File "/usr/lib/python2.7/subprocess.py", line 710, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

>>> Done (return code 1)

Attaching top_block.py and Tutorial.grc. Searching mail archives and the
web didn't help. Maybe I don't know yet how to ask it correctly:(
Appreciate any suggestions.

TIA
Nikos


Tutorial.grc
Description: Binary data


top_block.py
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Modulation scheme for DSSS

[Henry Barton]

Thanks, Ed. I figured the PSK’s would work. Do you think the +1/-1 codes used 
in CDMA have anything to do with PSK? If I could somehow send them into a coil 
as voltages at a high rate, would it make an intelligible signal? I’m guessing 
it wouldn’t, which leads me to believe that the +1/-1 codes are just for 
demonstration purposes and in reality you just transmit your spreaded (repeated 
and XOR-ed bits) as ordinary PSK.






Sent from Windows Mail





From: Ed Criscuolo
Sent: ‎Tuesday‎, ‎March‎ ‎8‎, ‎2016 ‎6‎:‎11‎ ‎PM
To: Henry Barton





NASA successfully uses BPSK, QPSK and OQPSK (offset QPSK)
with CDMA DSSS on its TDRS satellites.  For historical reasons,
they don't use differential coding, but it makes the demod much
harder.

@(^.^)@  Ed

On 3/8/16 11:18 AM, Henry Barton wrote:
> As you know, I’ve written a baseband DSSS modulator and demodulator.
> I’ve got the waveform samples, but I know I need a modulation scheme to
> actually send it through the air. I’ve heard somewhere that OFDM can be
> used for CDMA DSSS, and also 4-qam/QPSK. Can anyone tell me what
> modulation schemes are appropriate for CDMA DSSS so multiple
> transmitters can coexist like they’re supposed to? Thanks.
>
> Sent from Windows Mail
>
>
>
> ___
> 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] Google Summer of Code / ham radio

[Tom Rondeau]

On Tue, Mar 8, 2016 at 3:09 PM, Daniel Pocock  wrote:

> On 08/03/16 20:52, Johnathan Corgan wrote:
>
> On Tue, Mar 8, 2016 at 10:06 AM, Daniel Pocock  wrote:
>
>
>> Debian and GNU Radio are both confirmed in GSoC this year, is there
>> interest in advertising this idea[1] for converting the GNU Radio live
>> DVD into a Debian Live project, merging with the Debian Ham CD?
>>
>
> ​The GNU Radio Live SDR environment builder is completely scripted, and
> designed to allow easy customization:
>
> https://github.com/gnuradio/gnuradio-livesdr
>
> For simple binary package installations, you can add a file with a list of
> packages here:
>
>
> https://github.com/gnuradio/gnuradio-livesdr/tree/livesdr/config/install-pkgs.d
>
> To add additional PyBOMBS (1.0) based GNU Radio OOT modules, you can
> modify:
>
>
> https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/config/pybombs.d/install.conf
>
> The conversion to using PyBOMBS 2.0​ is in progress.
>
> So it would be straightforward to create a long-lived branch that focuses
> on ham radio specific content.
>
>
> The Debian Ham Blend produces both a live CD/DVD and also a collection of
> packages that people can conveniently install as part of a normal Debian
> system on their HDD:
>
>https://www.debian.org/blends/hamradio/
>
> Many of the things in the Blend are not specific to ham radio though.  e.g
> you can use the gpredict utility to track any type of satellite.  Browse
> the list of metapackages to see what I mean:
> https://www.debian.org/blends/hamradio/get/metapackages
>
> The benefit of adapting things from the GNU Radio live SDR environment
> into the Debian Ham Blend is that it would involve more people in the long
> term, as you get the experience of the Debian Ham team, the Debian Live
> maintainers and a lot of other Debian resources too.
>
> Parts of this task, such as making a ready-to-run transceiver, would not
> only be for use in the live environment, they would be for users on any
> platform.
>
> I'm not suggesting that the current Live SDR solution is broken, rather, a
> combined solution may be stronger in the long term.
>
> Regards,
>
> Daniel
>


Hi Daniel,

I think this is an interesting project, and I like the idea of getting
students excited about radio through some of these harder challenges in the
amateur space. Yet looking through your ideas here, I think this project
mostly belongs in the Debian space. We're going to be keeping our model and
development method behind the GNU Radio LiveDVD because it very nicely
serves exactly our purpose. It's designed to get people up and developing
on GNU Radio quickly. This is a much different mission than providing an OS
with a known set of end user applications. That's what you're going for and
that's a fantastic, but separate, service.

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

Re: [Discuss-gnuradio] Tutorial on BPSK bursts

[Andy Walls]

On Tue, 2016-03-08 at 21:04 +, Jesse Reich wrote:
> Thank you much Andy. I'll take a look and give it a try tonight when I
> get home. 
> 
> 
> Is the BPSK that is used unusual because of the 1.1 rad phase shifts

Yes.  One would expect BPSK constellation points to be pi radians apart
(aka half way around the unit circle), like at +pi/2 and -pi/2 or at 0
and pi.  Being at +0.35pi and -0.35pi is just weird, but probably done
for robustness of reception (safety of life at sea; someone needs to
hear it!).


>  and is the related to what I've heard that the signal still has power
> in the pure carrier throughout the message?

The FFT of the tx burst shows that.

When phase locked to the carrier, the In-Phase component never vanishes;
it remains at cos(1.1 rad) while the Quadrature part moves between +/-
sin(1.1 rad).  When phase locked to the carrier during the 160 ms of
unmodulated carrier, the In-Phase component is at 1.0.


> 
> Also, do you know if the T.001 beacons use differential BPSK or not? 

This document doesn't make any mention of differential encoding:
http://www.cospas-sarsat.int/images/stories/SystemDocs/Current/cs_t.001_oct_2013.pdf


> 
> 
> I was able to capture a file sink of a PLB transmission last night so
> I'll have to give it a try.  But the frequency I saw seemed unusual;
> around 406.008 MHz. I believe it should be at 406.037 based on the
> beacon I was using. 

Well, if your SDR receiver is not locked to a 10 MHz reference or a 10
MHz reference from a GPSDO, then you could be off freq.

Beacon Test mode is also supposed to use a special freq.

FWIW, the freq plan is here:

http://www.cospas-sarsat.int/images/stories/SystemDocs/Current/cs_t012_oct_2013.pdf

I honestly find these C/S specification to be written in a very
confusing manner.  Just figuring out the allowed bandwidth of a
transmitter was confusing.

Have Fun.

-Andy
 
> 
> 
> Thanks again,
> Jesse 
> 
> On Tue, Mar 8, 2016 at 3:47 PM Andy Walls
>  wrote:
> 
> On Sat, 2016-03-05 at 12:00 -0500,
> discuss-gnuradio-requ...@gnu.org
> wrote:
> > Date: Sat, 5 Mar 2016 00:46:12 -0500
> > From: Tim K 
> 
> >
> > It's not terrifically designed, but you might find my PSK31
> repo
> > helpful.
> > According to Balint though, the PLL is supposed to go after
> clock
> > recovery,
> > not before.
> >
> > https://github.com/tkuester/gr-psk31
> >
> > - Tim
> >
> > On Fri, Mar 4, 2016 at 8:56 PM, Jesse Reich
>  wrote:
> >
> > > So I've been playing with GNU Radio for about 2 months and
> trying to
> > learn
> > > about signals and signal processing in general. Mostly out
> of
> > curiosity
> > > that has sprung up from my profession. I am an Aerospace
> engineer by
> > > training and I work as a satellite ground systems engineer
> for the
> > > Cospas-Sarsat program.
> > >
> > > I've started with what I thought should be an easy task
> with
> > aspirations
> > > of more complex tasks. The first task, decode a BPSK
> signal
> > modulated on a
> > > 406 MHz carrier. The signals consist of a 160 ms carrier,
> 24 sync
> > bits and
> > > then 120 data bits at 400 bits/sec. I'm just trying to
> decode and
> > write the
> > > bits. Sounded to me to be an easy problem to tackle.
> Unfortunately I
> > can't
> > > seem to even get off of the ground. Does anyone know of
> any
> > tutorials that
> > > would be good.
> > >
> > > I've tried the gnuradio tutorials and honestly they don't
> really
> > seem to
> > > help. Any help would be greatly appreciated.
> > >
> > > Thanks,
> > > Jesse
> 
> 
> Hi Jesse:
> 
> See the attached, disasterous flowgraph:
> a) the top half is a simulated EPIRB transmitter and noisy
> channel
> b) the bottom half is an EPIRB PSK receiver I winged together
> 
> The receiver probably needs tweaking on the M&M clock recovery
> parameters.  Also the receiver implementation ends at the
> recovered,
> manchester encoded bits.  You have to decode the bits and
> frame them
> yourself from that point.  Tim K probably has good stuff in
> his github
> repos to do that.
> 
> The C/S T.001 stuff isn't your normal BPSK, so the all-in-one
> PSK demod
> blocks in GNURadio won't work well.  (Heck, the costas loop
> block gets
> confused on the 160 ms of unmodulated carrier.)
> 
> The C/S T.001 BSPK modulation has an unusual constellation:
> 
> (1.0

Re: [Discuss-gnuradio] Tutorial on BPSK bursts

[Jesse Reich]

Thank you much Andy. I'll take a look and give it a try tonight when I get
home.

Is the BPSK that is used unusual because of the 1.1 rad phase shifts and is
the related to what I've heard that the signal still has power in the pure
carrier throughout the message?

Also, do you know if the T.001 beacons use differential BPSK or not?

I was able to capture a file sink of a PLB transmission last night so I'll
have to give it a try.  But the frequency I saw seemed unusual; around
406.008 MHz. I believe it should be at 406.037 based on the beacon I was
using.

Thanks again,
Jesse

On Tue, Mar 8, 2016 at 3:47 PM Andy Walls 
wrote:

> On Sat, 2016-03-05 at 12:00 -0500, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Date: Sat, 5 Mar 2016 00:46:12 -0500
> > From: Tim K 
>
> >
> > It's not terrifically designed, but you might find my PSK31 repo
> > helpful.
> > According to Balint though, the PLL is supposed to go after clock
> > recovery,
> > not before.
> >
> > https://github.com/tkuester/gr-psk31
> >
> > - Tim
> >
> > On Fri, Mar 4, 2016 at 8:56 PM, Jesse Reich  wrote:
> >
> > > So I've been playing with GNU Radio for about 2 months and trying to
> > learn
> > > about signals and signal processing in general. Mostly out of
> > curiosity
> > > that has sprung up from my profession. I am an Aerospace engineer by
> > > training and I work as a satellite ground systems engineer for the
> > > Cospas-Sarsat program.
> > >
> > > I've started with what I thought should be an easy task with
> > aspirations
> > > of more complex tasks. The first task, decode a BPSK signal
> > modulated on a
> > > 406 MHz carrier. The signals consist of a 160 ms carrier,  24 sync
> > bits and
> > > then 120 data bits at 400 bits/sec. I'm just trying to decode and
> > write the
> > > bits. Sounded to me to be an easy problem to tackle. Unfortunately I
> > can't
> > > seem to even get off of the ground. Does anyone know of any
> > tutorials that
> > > would be good.
> > >
> > > I've tried the gnuradio tutorials and honestly they don't really
> > seem to
> > > help. Any help would be greatly appreciated.
> > >
> > > Thanks,
> > > Jesse
>
>
> Hi Jesse:
>
> See the attached, disasterous flowgraph:
> a) the top half is a simulated EPIRB transmitter and noisy channel
> b) the bottom half is an EPIRB PSK receiver I winged together
>
> The receiver probably needs tweaking on the M&M clock recovery
> parameters.  Also the receiver implementation ends at the recovered,
> manchester encoded bits.  You have to decode the bits and frame them
> yourself from that point.  Tim K probably has good stuff in his github
> repos to do that.
>
> The C/S T.001 stuff isn't your normal BPSK, so the all-in-one PSK demod
> blocks in GNURadio won't work well.  (Heck, the costas loop block gets
> confused on the 160 ms of unmodulated carrier.)
>
> The C/S T.001 BSPK modulation has an unusual constellation:
>
> (1.0  , 0.0  ): unmodulated carrier
> (cos( 1.1 rad), sin( 1.1 rad)): '1' symbol
> (cos(-1.1 rad), sin(-1.1 rad)): '0' symbol
>
> This makes it easy to lock on to with a PLL with a very sluggish
> response.  That is what I did in the attached GRC.
>
> Regards,
> Andy
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Daniel Pocock]

On 08/03/16 20:52, Johnathan Corgan wrote:
> On Tue, Mar 8, 2016 at 10:06 AM, Daniel Pocock  > wrote:
>  
>
> Debian and GNU Radio are both confirmed in GSoC this year, is there
> interest in advertising this idea[1] for converting the GNU Radio live
> DVD into a Debian Live project, merging with the Debian Ham CD?
>
>
> ​The GNU Radio Live SDR environment builder is completely scripted,
> and designed to allow easy customization:
>
> https://github.com/gnuradio/gnuradio-livesdr
>
> For simple binary package installations, you can add a file with a
> list of packages here:
>
> https://github.com/gnuradio/gnuradio-livesdr/tree/livesdr/config/install-pkgs.d
>
> To add additional PyBOMBS (1.0) based GNU Radio OOT modules, you can
> modify:
>
> https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/config/pybombs.d/install.conf
>
> The conversion to using PyBOMBS 2.0​ is in progress.
>
> So it would be straightforward to create a long-lived branch that
> focuses on ham radio specific content.
>

The Debian Ham Blend produces both a live CD/DVD and also a collection
of packages that people can conveniently install as part of a normal
Debian system on their HDD:

   https://www.debian.org/blends/hamradio/

Many of the things in the Blend are not specific to ham radio though. 
e.g you can use the gpredict utility to track any type of satellite. 
Browse the list of metapackages to see what I mean:
https://www.debian.org/blends/hamradio/get/metapackages

The benefit of adapting things from the GNU Radio live SDR environment
into the Debian Ham Blend is that it would involve more people in the
long term, as you get the experience of the Debian Ham team, the Debian
Live maintainers and a lot of other Debian resources too.

Parts of this task, such as making a ready-to-run transceiver, would not
only be for use in the live environment, they would be for users on any
platform.

I'm not suggesting that the current Live SDR solution is broken, rather,
a combined solution may be stronger in the long term.

Regards,

Daniel


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

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Marcus Müller]

Ah, cool :) Sorry for the confusion then :)

On 03/08/2016 08:52 PM, Martin Braun wrote:
> Just to put this all into perspective, Daniel got in touch with us prior
> to our acceptance regarding collaboration on such a project. The
> collaboration would be between GNU Radio and the Debian project.
>
> Cheers,
> Martin
>
> On 03/08/2016 11:40 AM, Marcus Müller wrote:
>> Hi Daniel,
>>
>> not to break your enthusiasm, but seeing that the GNU Radio Live DVD
>> works quite well right now, I don't really see the benefit of converting
>> it to Debian.
>>
>> Regarding the Ham things: That's something that I can only emphasize:
>> Students, whatever qualification, experiences and projects you have done
>> with radio, it's probably not the worst idea to mention that! Also,
>> especially Ham Radio has a very active crowd, so if you can find a
>> project that suits you and you'd like to see it do something related
>> with amateur radio operation, it's very likely that you can get active
>> help here.
>>
>> In general: Get in contact, do that early, talk about what you want to
>> do and what skills you bring and think you'll need to acquire. Every
>> positive interaction with the community definitely makes you more
>> valuable to the project :)
>>
>> Cheers,
>> Marcus
>> On 03/08/2016 07:06 PM, Daniel Pocock wrote:
>>> On 04/02/16 18:51, Daniel Pocock wrote:
 On 04/02/16 18:35, Martin Braun wrote:
> Daniel,
>
> that sounds pretty good! We're currently polishing our ideas list (the
> current draft is at
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCIdeas). We could
> probably write up a project idea on our wiki page, and then copy it to
> your ideas list, or vice versa.
>
 Having the idea on both lists is perfectly OK, we should probably create
 links between them though so it is clear that it is a collaboration


> Note that we didn't get accepted into GSoC last year, so I'm not sure
> what our chances are. I'm sure we can find a mentor, though.
>
 That is another reason to have this on the Debian ideas list as well.
 If GNU Radio is not accepted but Debian is accepted then the project can
 still potentially go ahead.  It also depends on the number of slots that
 Google allocates to each selected project.  The Google system allows us
 to register multiple mentors for a student, so we could potentially have
 both a GNU Radio developer and a Debian Developer linked to the same
 student.  Both mentors would also have an equal chance of selection for
 the mentor summit.
>>> Debian and GNU Radio are both confirmed in GSoC this year, is there
>>> interest in advertising this idea[1] for converting the GNU Radio live
>>> DVD into a Debian Live project, merging with the Debian Ham CD?
>>>
>>> For all those students who have joined the mailing list recently, do any
>>> of you have a ham radio license?
>>>
>>> I'm happy to write up a project idea that can go on both the Debian and
>>> GNU Radio wikis (and also my blog) but I would like to find somebody
>>> with more comprehensive GNU Radio knowledge to be part of the mentoring
>>> team for it.
>>>
>>> Regards,
>>>
>>> Daniel
>>>
>>> 1. https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00051.html
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Johnathan Corgan]

On Tue, Mar 8, 2016 at 10:06 AM, Daniel Pocock  wrote:


> Debian and GNU Radio are both confirmed in GSoC this year, is there
> interest in advertising this idea[1] for converting the GNU Radio live
> DVD into a Debian Live project, merging with the Debian Ham CD?
>

​The GNU Radio Live SDR environment builder is completely scripted, and
designed to allow easy customization:

https://github.com/gnuradio/gnuradio-livesdr

For simple binary package installations, you can add a file with a list of
packages here:

https://github.com/gnuradio/gnuradio-livesdr/tree/livesdr/config/install-pkgs.d

To add additional PyBOMBS (1.0) based GNU Radio OOT modules, you can modify:

https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/config/pybombs.d/install.conf

The conversion to using PyBOMBS 2.0​ is in progress.

So it would be straightforward to create a long-lived branch that focuses
on ham radio specific content.

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

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Martin Braun]

Just to put this all into perspective, Daniel got in touch with us prior
to our acceptance regarding collaboration on such a project. The
collaboration would be between GNU Radio and the Debian project.

Cheers,
Martin

On 03/08/2016 11:40 AM, Marcus Müller wrote:
> Hi Daniel,
> 
> not to break your enthusiasm, but seeing that the GNU Radio Live DVD
> works quite well right now, I don't really see the benefit of converting
> it to Debian.
> 
> Regarding the Ham things: That's something that I can only emphasize:
> Students, whatever qualification, experiences and projects you have done
> with radio, it's probably not the worst idea to mention that! Also,
> especially Ham Radio has a very active crowd, so if you can find a
> project that suits you and you'd like to see it do something related
> with amateur radio operation, it's very likely that you can get active
> help here.
> 
> In general: Get in contact, do that early, talk about what you want to
> do and what skills you bring and think you'll need to acquire. Every
> positive interaction with the community definitely makes you more
> valuable to the project :)
> 
> Cheers,
> Marcus
> On 03/08/2016 07:06 PM, Daniel Pocock wrote:
>> On 04/02/16 18:51, Daniel Pocock wrote:
>>> On 04/02/16 18:35, Martin Braun wrote:
 Daniel,

 that sounds pretty good! We're currently polishing our ideas list (the
 current draft is at
 http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCIdeas). We could
 probably write up a project idea on our wiki page, and then copy it to
 your ideas list, or vice versa.

>>> Having the idea on both lists is perfectly OK, we should probably create
>>> links between them though so it is clear that it is a collaboration
>>>
>>>
 Note that we didn't get accepted into GSoC last year, so I'm not sure
 what our chances are. I'm sure we can find a mentor, though.

>>> That is another reason to have this on the Debian ideas list as well.
>>> If GNU Radio is not accepted but Debian is accepted then the project can
>>> still potentially go ahead.  It also depends on the number of slots that
>>> Google allocates to each selected project.  The Google system allows us
>>> to register multiple mentors for a student, so we could potentially have
>>> both a GNU Radio developer and a Debian Developer linked to the same
>>> student.  Both mentors would also have an equal chance of selection for
>>> the mentor summit.
>>
>> Debian and GNU Radio are both confirmed in GSoC this year, is there
>> interest in advertising this idea[1] for converting the GNU Radio live
>> DVD into a Debian Live project, merging with the Debian Ham CD?
>>
>> For all those students who have joined the mailing list recently, do any
>> of you have a ham radio license?
>>
>> I'm happy to write up a project idea that can go on both the Debian and
>> GNU Radio wikis (and also my blog) but I would like to find somebody
>> with more comprehensive GNU Radio knowledge to be part of the mentoring
>> team for it.
>>
>> Regards,
>>
>> Daniel
>>
>> 1. https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00051.html
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Marcus Müller]

Hi Daniel,

not to break your enthusiasm, but seeing that the GNU Radio Live DVD
works quite well right now, I don't really see the benefit of converting
it to Debian.

Regarding the Ham things: That's something that I can only emphasize:
Students, whatever qualification, experiences and projects you have done
with radio, it's probably not the worst idea to mention that! Also,
especially Ham Radio has a very active crowd, so if you can find a
project that suits you and you'd like to see it do something related
with amateur radio operation, it's very likely that you can get active
help here.

In general: Get in contact, do that early, talk about what you want to
do and what skills you bring and think you'll need to acquire. Every
positive interaction with the community definitely makes you more
valuable to the project :)

Cheers,
Marcus
On 03/08/2016 07:06 PM, Daniel Pocock wrote:
> On 04/02/16 18:51, Daniel Pocock wrote:
>> On 04/02/16 18:35, Martin Braun wrote:
>>> Daniel,
>>>
>>> that sounds pretty good! We're currently polishing our ideas list (the
>>> current draft is at
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCIdeas). We could
>>> probably write up a project idea on our wiki page, and then copy it to
>>> your ideas list, or vice versa.
>>>
>> Having the idea on both lists is perfectly OK, we should probably create
>> links between them though so it is clear that it is a collaboration
>>
>>
>>> Note that we didn't get accepted into GSoC last year, so I'm not sure
>>> what our chances are. I'm sure we can find a mentor, though.
>>>
>> That is another reason to have this on the Debian ideas list as well.
>> If GNU Radio is not accepted but Debian is accepted then the project can
>> still potentially go ahead.  It also depends on the number of slots that
>> Google allocates to each selected project.  The Google system allows us
>> to register multiple mentors for a student, so we could potentially have
>> both a GNU Radio developer and a Debian Developer linked to the same
>> student.  Both mentors would also have an equal chance of selection for
>> the mentor summit.
>
> Debian and GNU Radio are both confirmed in GSoC this year, is there
> interest in advertising this idea[1] for converting the GNU Radio live
> DVD into a Debian Live project, merging with the Debian Ham CD?
>
> For all those students who have joined the mailing list recently, do any
> of you have a ham radio license?
>
> I'm happy to write up a project idea that can go on both the Debian and
> GNU Radio wikis (and also my blog) but I would like to find somebody
> with more comprehensive GNU Radio knowledge to be part of the mentoring
> team for it.
>
> Regards,
>
> Daniel
>
> 1. https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00051.html
>
>
>
> ___
> 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] Pybombs Prefix and Modtool

[Richard Bell]

Oh, this is news to me. I'll look into that.

Thanks,
Rich

On Tue, Mar 8, 2016 at 10:54 AM, Martin Braun 
wrote:

> Yeah I think that should be fine. You could also use PyBOMBS to build
> your own OOT :)
>
> M
>
> On 03/08/2016 10:44 AM, Richard Bell wrote:
> > The OOT is not installed by Pybombs, because its my own custom OOT that
> > I made after using Pybombs. With this understanding Martin, would you
> > agree I need to do what Ron said to make custom OOTs work?
> >
> > Rich
> >
> > On Tue, Mar 8, 2016 at 10:18 AM, Martin Braun  > > wrote:
> >
> > If you're using PyBOMBS to install both GNU Radio and the OOT into
> the
> > same prefix, this is already happening. Also, once you've sourced
> > setup_env.sh, GRC_BLOCKS_PATH is also set. Are you mixing prefixes?
> I'm
> > not sure I fully understand your setup.
> >
> > Cheers,
> > Martin
> >
> > On 03/07/2016 10:32 PM, Richard Bell wrote:
> > > Thanks Ron, I will test it later tomorrow.
> > >
> > > Rich
> > >
> > > On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos  
> > > >> wrote:
> > >
> > > When you build your OOT module, you have to use the same
> prefix as
> > > your GNU Radio install. This is done in the cmake stage with
> > > -DCMAKE_INSTALL_PREFIX. For example.
> > >
> > > cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
> > >
> > > Ron
> > >
> > >
> > > On 03/07/2016 02:21 PM, Richard Bell wrote:
> > >> Hi,
> > >>
> > >> I think I've narrowed down what I and some colleagues of mine
> > have
> > >> been experiencing enough to explain it and hopefully get a
> > solution.
> > >>
> > >> When I installed gr using the new pybombs, I specified a
> custom
> > >> prefix location (on several computers). It seems that later
> on,
> > >> when I create an OOT module using modtool, GRC does not
> interact
> > >> properly with these OOT modules, for some reason unknown to me
> > >> that I'm assuming is related to this prefix. The only
> > workaround I
> > >> know to get OOT modules to show up in GRC now is to add each
> OOT
> > >> module directory path to the GRC_BLOCKS_PATH env variable.
> This
> > >> causes XML parser errors to be reported everytime I open GRC,
> and
> > >> slows it down.
> > >>
> > >> So my question is this:
> > >>
> > >> With the old pybombs, I always used the default prefix and
> > >> thereafter modtool always worked. After sudo make install and
> > sudo
> > >> ldconfig, my OOT blocks showed up in GRC. Since now I chose a
> > >> custom prefix, is there an additional step I am supposed to
> take
> > >> when making OOT blocks?
> > >>
> > >> Summary: Installed GR using new Pybombs in custom prefix.
> > >> Installing OOT module custom blocks does not work without
> editing
> > >> GRC_BLOCKS_PATH variable for each OOT path.
> > >>
> > >> Thanks,
> > >> Rich
> > >>
> > >>
> > >> ___
> > >> Discuss-gnuradio mailing list
> > >> Discuss-gnuradio@gnu.org 
> > >
> > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org 
> > >
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org 
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs Prefix and Modtool

[Martin Braun]

Yeah I think that should be fine. You could also use PyBOMBS to build
your own OOT :)

M

On 03/08/2016 10:44 AM, Richard Bell wrote:
> The OOT is not installed by Pybombs, because its my own custom OOT that
> I made after using Pybombs. With this understanding Martin, would you
> agree I need to do what Ron said to make custom OOTs work?
> 
> Rich
> 
> On Tue, Mar 8, 2016 at 10:18 AM, Martin Braun  > wrote:
> 
> If you're using PyBOMBS to install both GNU Radio and the OOT into the
> same prefix, this is already happening. Also, once you've sourced
> setup_env.sh, GRC_BLOCKS_PATH is also set. Are you mixing prefixes? I'm
> not sure I fully understand your setup.
> 
> Cheers,
> Martin
> 
> On 03/07/2016 10:32 PM, Richard Bell wrote:
> > Thanks Ron, I will test it later tomorrow.
> >
> > Rich
> >
> > On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos  
> > >> wrote:
> >
> > When you build your OOT module, you have to use the same prefix as
> > your GNU Radio install. This is done in the cmake stage with
> > -DCMAKE_INSTALL_PREFIX. For example.
> >
> > cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
> >
> > Ron
> >
> >
> > On 03/07/2016 02:21 PM, Richard Bell wrote:
> >> Hi,
> >>
> >> I think I've narrowed down what I and some colleagues of mine
> have
> >> been experiencing enough to explain it and hopefully get a
> solution.
> >>
> >> When I installed gr using the new pybombs, I specified a custom
> >> prefix location (on several computers). It seems that later on,
> >> when I create an OOT module using modtool, GRC does not interact
> >> properly with these OOT modules, for some reason unknown to me
> >> that I'm assuming is related to this prefix. The only
> workaround I
> >> know to get OOT modules to show up in GRC now is to add each OOT
> >> module directory path to the GRC_BLOCKS_PATH env variable. This
> >> causes XML parser errors to be reported everytime I open GRC, and
> >> slows it down.
> >>
> >> So my question is this:
> >>
> >> With the old pybombs, I always used the default prefix and
> >> thereafter modtool always worked. After sudo make install and
> sudo
> >> ldconfig, my OOT blocks showed up in GRC. Since now I chose a
> >> custom prefix, is there an additional step I am supposed to take
> >> when making OOT blocks?
> >>
> >> Summary: Installed GR using new Pybombs in custom prefix.
> >> Installing OOT module custom blocks does not work without editing
> >> GRC_BLOCKS_PATH variable for each OOT path.
> >>
> >> Thanks,
> >> Rich
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org 
> >
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> >
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 


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

Re: [Discuss-gnuradio] Pybombs Prefix and Modtool

[Richard Bell]

The OOT is not installed by Pybombs, because its my own custom OOT that I
made after using Pybombs. With this understanding Martin, would you agree I
need to do what Ron said to make custom OOTs work?

Rich

On Tue, Mar 8, 2016 at 10:18 AM, Martin Braun 
wrote:

> If you're using PyBOMBS to install both GNU Radio and the OOT into the
> same prefix, this is already happening. Also, once you've sourced
> setup_env.sh, GRC_BLOCKS_PATH is also set. Are you mixing prefixes? I'm
> not sure I fully understand your setup.
>
> Cheers,
> Martin
>
> On 03/07/2016 10:32 PM, Richard Bell wrote:
> > Thanks Ron, I will test it later tomorrow.
> >
> > Rich
> >
> > On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos  > > wrote:
> >
> > When you build your OOT module, you have to use the same prefix as
> > your GNU Radio install. This is done in the cmake stage with
> > -DCMAKE_INSTALL_PREFIX. For example.
> >
> > cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
> >
> > Ron
> >
> >
> > On 03/07/2016 02:21 PM, Richard Bell wrote:
> >> Hi,
> >>
> >> I think I've narrowed down what I and some colleagues of mine have
> >> been experiencing enough to explain it and hopefully get a solution.
> >>
> >> When I installed gr using the new pybombs, I specified a custom
> >> prefix location (on several computers). It seems that later on,
> >> when I create an OOT module using modtool, GRC does not interact
> >> properly with these OOT modules, for some reason unknown to me
> >> that I'm assuming is related to this prefix. The only workaround I
> >> know to get OOT modules to show up in GRC now is to add each OOT
> >> module directory path to the GRC_BLOCKS_PATH env variable. This
> >> causes XML parser errors to be reported everytime I open GRC, and
> >> slows it down.
> >>
> >> So my question is this:
> >>
> >> With the old pybombs, I always used the default prefix and
> >> thereafter modtool always worked. After sudo make install and sudo
> >> ldconfig, my OOT blocks showed up in GRC. Since now I chose a
> >> custom prefix, is there an additional step I am supposed to take
> >> when making OOT blocks?
> >>
> >> Summary: Installed GR using new Pybombs in custom prefix.
> >> Installing OOT module custom blocks does not work without editing
> >> GRC_BLOCKS_PATH variable for each OOT path.
> >>
> >> Thanks,
> >> Rich
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org 
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

OK, here's my C program:

#include 
#include 
#include 
#include 

int main() {

size_t alignment = volk_get_alignment();

uint8_t* ptr;

ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr, *ptr);
volk_free((void*)ptr);
ptr = NULL;


return 0;
}


Compile:

$ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib

It's output:

$ ./volk_test
Using Volk machine: avx2_64_mmx_orc
alignment = 32, ptr = 151b040, *ptr = 00

Also, I've attached the output from the preprocessor, this command:

$ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
-DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
-g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
-I/local_disk/gr_3.7.9_src/volk/include
-I/local_disk/gr_3.7.9_src/volk/kernels
-I/local_disk/gr_3.7.9_src/volk/build_debug/lib
-I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
volk_malloc_preprocessed   -c
/local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c

I just found the compiler step from from doing 'VERBOSE=1 make' then
changed the output and added -E.  I attached volk_malloc_preprocessed as
well.

It looks like this is my volk_malloc():


void *volk_malloc(size_t size, size_t alignment)
{
  void *ptr;




  if (alignment == 1)
return malloc(size);

  int err = posix_memalign(&ptr, alignment, size);
  if(err == 0) {
return ptr;
  }
  else {
fprintf(stderr,
"VOLK: Error allocating memory "
"(posix_memalign: error %d: %s)\n", err, strerror(err));
return ((void *)0);
  }
}



Devin



On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan 
wrote:

>
> On Tue, Mar 8, 2016 at 10:58 AM, devin kelly  wrote:
>
>> Calling 'info variables' (or args or locals) the last few frames didn't
>> give me any real info so I built a copy of GR/Volk with debug symbols.  I
>> ran the FG again, this time from GDB, here's my back trace.  In this
>> backtrace you can see the arguments passed in each call.  I have an
>> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>>
>
> Excellent. Thanks for going through that extra step. It really helps.
>
>
>>
>> Here's are the links for the relevant code:
>>
>>
>> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>>
>> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>>
>> Could the problem be that nitems is 257 and num_points is 512?  Or should
>> nitems really be 256 and not 257?
>>
>
> I don't think so. I'm not familiar with the details of the fft_filter
> implementations, but usually these things will take in some history if they
> don't have enough points to operate on (in this case 512).
>
> The much more worrying thing is your vector addresses.
>
>
>>
>> Thanks,
>> Devin
>>
>> (gdb) bt
>> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>> (__P=0x3b051b0)
>> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>>
>
> 0x3b1f770 % 32 = 16 (bad)
> 0x3b051b0 % 32 = 16 (bad)
> 0x3b240e0 % 32 = 0 (good)
>
> Unfortunately it looks like volk_get_alignment is returning the wrong
> thing or there's a bug in volk_malloc. Can you tell us what
> volk_get_alignment returns? The easiest thing is probably to write a simple
> C program that prints out the result (hmm, I should add that to
> volk-config-info). I'd also like to know which volk_malloc implementation
> you're using. Unfortunately I don't think we have an easy way to discover
> that (hmm, something else that should be added to volk-config-info). I
> think the best way might be to look at volk_malloc.c intermediate files
> after the preprocessor has done its work.
>
> If you want to move on while we figure this out then you can edit
> ~/.volk/volk_config and replace the avx2_fma with sse3 on the line that has
> this kernel name on it.
>
>
>> at
>> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
>> #2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
>> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>> at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
>> #3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter(int,
>> std::complex const*, std::complex*) (this=0x3b02f40,
>> nitems=nitems@entry=257, input=input@entry=0x7fffc9cc7000,
>> output=output@entry=0x3b36460)
>> at /local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
>> #4  0x7fffd42910df in gr::digital::corr_est_cc_impl::work(int,
>> std::vector >&, std::vector> std::allocator >&) (this=0x3b01560, nout

Re: [Discuss-gnuradio] GSoC 2016 - Improve and Integrate PyBOMBS & CGRAN

[Martin Braun]

The current PyBOMBS has SDK and cross-compile support. I do like the
integration of bitbake, although I'm not sure how that would look and if
you're turning PyBOMBS into something it's not.

Cheers,
Martin

On 03/07/2016 09:46 PM, Ravi Sharan wrote:
> Hi Nathan,
> 
> I agree that the ideas listed out in my previous mail doesn't take all
> of the summer to implement. I which case, I would like to add another
> point to my proposal.
> 
> PyBOMBS support to Embedded WG -
> 
> The idea is fairly simple. The current Embedded WG provides a
> OpenEmbedded(OE) based SDK to develop and build OOT modules. I intend to
> add a layer on top of PyBOMBS to work with OE tools (bitbake etc.,), for
> setting up the environment for SDK and cross-compiling the OOT Modules.
> The module author will have one less thing to worry about while
> developing apps for supported embedded platforms. I need to do a bit of
> homework on this front before I write the proper proposal and any help
> from the embedded WG (Philip Balister) is appreciated in this direction.
> 
> My plan (tentative) as of now is to roughly dedicate 5 weeks to
> implement the app store in the beginning, 3 weeks for adding PyBOMBS
> support to the embedded working group and 3 weeks for the CGRAN-PyBOMBS
> integration (1 week) & CGRAN only work (2 weeks). Last two weeks will be
> dedicated for sanity checks and bug fixes.
> 
> Cheers,
> Ravi Sharan  
> 
> 
> On Tue, Mar 8, 2016 at 4:14 AM, West, Nathan
> mailto:n...@ostatemail.okstate.edu>> wrote:
> 
> Hi Ravi,
> 
> I like this. My only qualm is that I'd personally like this project
> to include some more pybombs work to round out the still missing
> features. I'm not really a Qt person, so I don't know how much
> effort doing the app store is and if that leaves much room, but I
> know that the CGRAN stuff won't take you all summer if you work full
> time ;-)
> 
> nw
> 
> On Mon, Mar 7, 2016 at 5:40 AM, Ravi Sharan
>  > wrote:
> 
> Hello,
> 
> I am Ravi Sharan, currently pursuing MTech from IIT Hyderabad. I
> am looking forward to participate in GSoC 2016 by improving and
> integrating CGRAN and the newer PyBOMBS. I have earlier worked
> on redesigning the current version of CGRAN with the help of
> Nathan West. Here's a brief description of things I would like
> to contribute to the GNU Radio project:
> 
> *- Qt based GUI app store - *
> Develop a simple, usable Qt based GUI app store to install GNU
> Radio and OOT modules. This sub-idea covers fixing the existing
> bugs in new PyBOMBS as well.
> 
> *- Integrate PyBOMBS & CGRAN -* Enable installing OOT modules
> from CGRAN site
> This is an idea which Martin Braun put forward during the
> initial discussions while developing the CGRAN 2.0. The idea is
> similar to Ubuntu's AptURL
> , where you can
> install the packages from a web browser. Clicking the 'apt'
> (#pun) URL, the browser redirects to the package manager to
> install the package.
> 
> *- Enhance CGRAN  -* (from current level to level awesome?) 
> I intend to implement this sub-idea in two-fold - 
> *** Add features like clickable tags and grouping the OOT
> Modules (to name a few) etc., according to their functionality
> for better usability of the site. [Code Contributions]
> *** Since the relaunch of CGRAN in April 2015, very few OOT
> Modules have surfaced on the site. I would like to add more
> documentation to the individual modules (like what works and
> what doesn't, compatibility with the current GNU Radio API,
> etc.,), thus populating CGRAN with modules listed out on the
> site. This idea is more of documentation, but is a little time
> consuming.
> 
> I will document the above mentioned ideas in the form of
> proposal based on the feedback I receive and would like to work
> with Martin Braun and Nathan West during the GSoC period. Apart
> from the ideas listed above, I am open for suggestions on what
> could make a good proposal and better summer of coding.
> 
> Thanks,
> Ravi Sharan B A G
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] Pybombs Prefix and Modtool

[Martin Braun]

If you're using PyBOMBS to install both GNU Radio and the OOT into the
same prefix, this is already happening. Also, once you've sourced
setup_env.sh, GRC_BLOCKS_PATH is also set. Are you mixing prefixes? I'm
not sure I fully understand your setup.

Cheers,
Martin

On 03/07/2016 10:32 PM, Richard Bell wrote:
> Thanks Ron, I will test it later tomorrow.
> 
> Rich
> 
> On Mon, Mar 7, 2016 at 2:53 PM, Ron Economos  > wrote:
> 
> When you build your OOT module, you have to use the same prefix as
> your GNU Radio install. This is done in the cmake stage with
> -DCMAKE_INSTALL_PREFIX. For example.
> 
> cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio-3.7.10git ../
> 
> Ron
> 
> 
> On 03/07/2016 02:21 PM, Richard Bell wrote:
>> Hi,
>>
>> I think I've narrowed down what I and some colleagues of mine have
>> been experiencing enough to explain it and hopefully get a solution.
>>
>> When I installed gr using the new pybombs, I specified a custom
>> prefix location (on several computers). It seems that later on,
>> when I create an OOT module using modtool, GRC does not interact
>> properly with these OOT modules, for some reason unknown to me
>> that I'm assuming is related to this prefix. The only workaround I
>> know to get OOT modules to show up in GRC now is to add each OOT
>> module directory path to the GRC_BLOCKS_PATH env variable. This
>> causes XML parser errors to be reported everytime I open GRC, and
>> slows it down.
>>
>> So my question is this:
>>
>> With the old pybombs, I always used the default prefix and
>> thereafter modtool always worked. After sudo make install and sudo
>> ldconfig, my OOT blocks showed up in GRC. Since now I chose a
>> custom prefix, is there an additional step I am supposed to take
>> when making OOT blocks?
>>
>> Summary: Installed GR using new Pybombs in custom prefix.
>> Installing OOT module custom blocks does not work without editing
>> GRC_BLOCKS_PATH variable for each OOT path.
>>
>> Thanks,
>> Rich
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] Modifying code rate

[Martin Braun]

Yeah, I think benchmark_rate doesn't even use FEC.

Cheers,
Martin

On 03/07/2016 11:14 PM, Marcus Müller wrote:
> Ah! There's samples per symbol (which I think you're reffering to) and
> "code rate", which is a term from channel coding theory. Don't confuse
> the two!
> 
> So, the minimum samples per symbol is indeed 2 (everything below
> wouldn't really have a pulse shape).
> If you want higher data rate, increase the sampling rate.
> 
> Your questions really indicate that it might really make sense to
> slightly improve your digital communications basics. I think you should
> really take the time to read about modulation, constellations, pulse
> shaping, memoryless channels, symbol error rates, bit error rates,
> noise, SNR, Eb/N0..., i.e. the first half of a textbook on digital
> communications. None of what we've discussed are really GNU Radio
> problems, but things you'd directly deduct from a solid understanding of
> the theory beneath. Getting that understanding will of course take time,
> but not having that understanding costs you at least that much time, too.
> 
> Best regards,
> Marcus
> 
> On 03/08/2016 02:16 AM, SangHyuk Kim wrote:
>> Dear Martin.
>>
>> In benchmark_tx.py example, I want to transmit packet by maximum bit rate.
>>
>> As I know, 1/2 is default coding rate. So, I can't achieve higher speed.
>>
>> So, my question :
>> - How can I modify coding rate (default 1/2) ?
>>   In other word, which source file handle coding rate ?
>>
>> Thanks 
>>
>> 2016-03-08 6:20 GMT+09:00 Martin Braun > >:
>>
>> SangHyuk,
>>
>> you'll need to provide some more detail on what you're asking,
>> what you
>> want to achieve, what you're using... etc.
>>
>> Cheers,
>> M
>>
>> On 03/06/2016 05:43 PM, SangHyuk Kim wrote:
>> > Hi all.
>> >
>> > I want to use high code rate for high throughput
>> >
>> > But, I can't find proper block to do.
>> >
>> > Can I change code rate using GNU radio?
>> >
>> > Also, is it possible using benchmark_tx.py (one of the example file
>> > provided) ?
>> >
>> > Thanks.
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org 
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] gr-uhd timed command messages

[Martin Braun]

On 03/08/2016 05:54 AM, Nigel Steed wrote:
> Hi Marcus,
> 
> I updated my code to (which compiles):
> 
> pmt::pmt_t timeStamp = pmt::mp(pmt::from_long(0), pmt::from_double(1));
> command = pmt::dict_add(command, pmt::mp("time"), timeStamp);
> 
> But my UHD Source gives the following error when it receives the message:

Try making the timestamp a pair, instead of using mp().

Cheers,
Martin


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

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi Stephan,

thanks for your reply. I’m very happy that this is going forward.


> On 08 Mar 2016, at 05:16, Ludwig Stephan (CR/AEH4) 
>  wrote:
> Just to make it clear (to myself):
> alpha_n changes randomly.
> BUT: alpha_n depends on theta, which in turn does a random walk in the code

Yes, theta does a random walk back and forth between [-pi; pi]. Since alpha_n 
is calculated as

float alpha_n = (2*M_PI*n - M_PI + d_theta)/4*d_N;

it is oscillating in a segment/part of the spectrum not the complete [-pi; pi] 
interval. But, that leads to the same amplified effect described earlier.
I don’t know when you checked my IPython notebook. I added another plot, to 
show how (i think that) the variables behave

https://www.bastibl.net/rayleigh-autocorrelation/#Values-over-time 



>  
> > "Efficient Simulation of Rayleigh Fading with Enhanced De-Correlation 
> > Properties” by  Alenka G. Zajic  and Gordon L. Stüber
> > http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1673098 
> > 
> > the authors refer to the paper, stating that:
>  
> Ahh, that is a very good reference. Actually I was searching for that in my 
> literature database but did not find it again.
>  
> > "To improve on previously reported models, Zheng and Xiao proposed several 
> > new statistical models [14]-[16]. By allowing all
> > three parameter sets (amplitudes, phases, and Doppler frequencies) to be 
> > random variables, Zheng and Xiao’s models obtain
> > statistical properties similar to ones required by the reference model. 
> > However, the models are no longer ergodic."
> > 
> > To me it looks like the model was _fixed_ by introducing this random walk 
> > that is supposed to make the model great ergodic 
> > again. I guess this follows some paper or book since the code mentions a 
> > table
> > d_step( powf(0.00125*fDTs, 1.1) ),  // max step size approximated from 
> > Table 2
>  
> No, the model of Zajic/Stüber is ergodic. But yes, they fixed the previous 
> model by choosing the parameters randomly – but constant over time and not 
> updating for every sample. And Table II does definitely not refer to the one 
> in their paper


That was maybe a bit confusing. I cited how Zajic/Stüber are talking about the 
GNU Radio model, to highlight that it is by default non-ergodic. I was not 
talking about the Zajic/Stüber model.


>  
> I try to summarize all the efforts
> · Use sin and cos in the factors for getting (almost) uncorrelated I 
> and Q shares of the complex random variable
> · Introduce a random phase (but constant) argument into every 
> cos(f_D*t) term in order to make the system WSS
> · In order to make the signals ergodic (ever draw of parameters has 
> the equal statistics, which also yield uncorrelated processes) let sin(f_D*t) 
> and cos(f_D*t) have different random (but constant) phases, but thake the 
> cos/sin factors from identical angles of arrival
> · MEDS method produces WSS process of intended auto-correlation 
> function, but introduces correlation between different random process.
> · The Zheng/Xiao model combines all previous advantages: still 
> constant but different phases
> · The Zajic/Stüber model combines all previosu advantages, especially 
> it has a random but constant phase (-> WSS), is ergodic, has uncorrelated I/Q 
> and uncorrelated processes, while converging faster (requires smaller N).

As far as I understand it’s either ergodic, but has suboptimal autocorrelation; 
or it’s non-ergodic. 

>  
> => In conclusion and because nobody remembers why this code was written like 
> that, I vote for adapting the model to Zajic/Stüber by removing the 
> update_theta function and their call (and then unused variables like d_step). 
> Their implementation is one of the best-known ones.
>  

Sounds reasonable to me, but I’m not an expert.

I think that when creating a TDL channel with multiple independent faders, one 
would have to set the parameters of all sinusoids in a special way, i.e., one 
would have to adapt the interface to the flat fader block, too.
…or in other words, the implementation would, at least, not be trivial :-) 
Would you be interested to work on that?

AFAIS, another option would be to remove theta and change the docs to state 
that the model should not be used with one long simulation run, but with 
multiple repetitions.

In general, I think that the current random walk is a pretty cool idea. In the 
best case we would find a paper that describes this method. Maybe, we wait some 
more time to see if someone knows about that.

Anyhow, I think that we should, at least, wait for an opinion of one of the 
developers, otherwise you might waste time implementing a new model and nobody 
cares.

Best,
Bastian









___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Google Summer of Code / ham radio

[Daniel Pocock]

On 04/02/16 18:51, Daniel Pocock wrote:
>
> On 04/02/16 18:35, Martin Braun wrote:
>> Daniel,
>>
>> that sounds pretty good! We're currently polishing our ideas list (the
>> current draft is at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCIdeas). We could
>> probably write up a project idea on our wiki page, and then copy it to
>> your ideas list, or vice versa.
>>
> Having the idea on both lists is perfectly OK, we should probably create
> links between them though so it is clear that it is a collaboration
>
>
>> Note that we didn't get accepted into GSoC last year, so I'm not sure
>> what our chances are. I'm sure we can find a mentor, though.
>>
> That is another reason to have this on the Debian ideas list as well.
> If GNU Radio is not accepted but Debian is accepted then the project can
> still potentially go ahead.  It also depends on the number of slots that
> Google allocates to each selected project.  The Google system allows us
> to register multiple mentors for a student, so we could potentially have
> both a GNU Radio developer and a Debian Developer linked to the same
> student.  Both mentors would also have an equal chance of selection for
> the mentor summit.


Debian and GNU Radio are both confirmed in GSoC this year, is there
interest in advertising this idea[1] for converting the GNU Radio live
DVD into a Debian Live project, merging with the Debian Ham CD?

For all those students who have joined the mailing list recently, do any
of you have a ham radio license?

I'm happy to write up a project idea that can go on both the Debian and
GNU Radio wikis (and also my blog) but I would like to find somebody
with more comprehensive GNU Radio knowledge to be part of the mentoring
team for it.

Regards,

Daniel

1. https://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00051.html



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

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

On Tue, Mar 8, 2016 at 10:58 AM, devin kelly  wrote:

> Calling 'info variables' (or args or locals) the last few frames didn't
> give me any real info so I built a copy of GR/Volk with debug symbols.  I
> ran the FG again, this time from GDB, here's my back trace.  In this
> backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>

Excellent. Thanks for going through that extra step. It really helps.


>
> Here's are the links for the relevant code:
>
>
> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>
> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>
> Could the problem be that nitems is 257 and num_points is 512?  Or should
> nitems really be 256 and not 257?
>

I don't think so. I'm not familiar with the details of the fft_filter
implementations, but usually these things will take in some history if they
don't have enough points to operate on (in this case 512).

The much more worrying thing is your vector addresses.


>
> Thanks,
> Devin
>
> (gdb) bt
> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (__P=0x3b051b0)
> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>

0x3b1f770 % 32 = 16 (bad)
0x3b051b0 % 32 = 16 (bad)
0x3b240e0 % 32 = 0 (good)

Unfortunately it looks like volk_get_alignment is returning the wrong thing
or there's a bug in volk_malloc. Can you tell us what volk_get_alignment
returns? The easiest thing is probably to write a simple C program that
prints out the result (hmm, I should add that to volk-config-info). I'd
also like to know which volk_malloc implementation you're using.
Unfortunately I don't think we have an easy way to discover that (hmm,
something else that should be added to volk-config-info). I think the best
way might be to look at volk_malloc.c intermediate files after the
preprocessor has done its work.

If you want to move on while we figure this out then you can edit
~/.volk/volk_config and replace the avx2_fma with sse3 on the line that has
this kernel name on it.


> at
> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
> #2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
> #3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter(int,
> std::complex const*, std::complex*) (this=0x3b02f40,
> nitems=nitems@entry=257, input=input@entry=0x7fffc9cc7000,
> output=output@entry=0x3b36460)
> at /local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
> #4  0x7fffd42910df in gr::digital::corr_est_cc_impl::work(int,
> std::vector >&, std::vector std::allocator >&) (this=0x3b01560, noutput_items=257,
> input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
> at
> /local_disk/gr_3.7.9_src/gnuradio/gr-digital/lib/corr_est_cc_impl.cc:237
> #5  0x7fffdd064907 in gr::sync_block::general_work(int,
> std::vector >&, std::vector std::allocator >&, std::vector
> >&) (this=0x3b015b8, noutput_items=, ninput_items=...,
> input_items=..., output_items=...) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/sync_block.cc:66
> #6  0x7fffdd02f70f in gr::block_executor::run_one_iteration()
> (this=this@entry=0x7fff83ffedb0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:438
> #7  0x7fffdd06da8a in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
> (this=0x7fff83ffedb0, block=..., max_noutput_items=) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
> #8  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
> #9  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
> #10 0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...) at
> /usr/include/boost/function/function_template.hpp:153
> #11 0x7fffdd016cd0 in
> boost::detail::thread_data >::run() (this= out>)
> at /usr/include/boost/function/function_template.hpp:767
> #12 0x7fffdd016cd0 in
> boost::detail::threa

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

Here's a simpler FG that I can use to reproduce this error.  Hopefully it
actually works for someone else.

Devin

On Tue, Mar 8, 2016 at 10:58 AM, devin kelly  wrote:

> Calling 'info variables' (or args or locals) the last few frames didn't
> give me any real info so I built a copy of GR/Volk with debug symbols.  I
> ran the FG again, this time from GDB, here's my back trace.  In this
> backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>
> Here's are the links for the relevant code:
>
>
> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>
> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>
> Could the problem be that nitems is 257 and num_points is 512?  Or should
> nitems really be 256 and not 257?
>
> Thanks,
> Devin
>
> (gdb) bt
> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (__P=0x3b051b0)
> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at
> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
> #2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
> #3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter(int,
> std::complex const*, std::complex*) (this=0x3b02f40,
> nitems=nitems@entry=257, input=input@entry=0x7fffc9cc7000,
> output=output@entry=0x3b36460)
> at /local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
> #4  0x7fffd42910df in gr::digital::corr_est_cc_impl::work(int,
> std::vector >&, std::vector std::allocator >&) (this=0x3b01560, noutput_items=257,
> input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
> at
> /local_disk/gr_3.7.9_src/gnuradio/gr-digital/lib/corr_est_cc_impl.cc:237
> #5  0x7fffdd064907 in gr::sync_block::general_work(int,
> std::vector >&, std::vector std::allocator >&, std::vector
> >&) (this=0x3b015b8, noutput_items=, ninput_items=...,
> input_items=..., output_items=...) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/sync_block.cc:66
> #6  0x7fffdd02f70f in gr::block_executor::run_one_iteration()
> (this=this@entry=0x7fff83ffedb0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:438
> #7  0x7fffdd06da8a in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
> (this=0x7fff83ffedb0, block=..., max_noutput_items=) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
> #8  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
> #9  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
> #10 0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0,
> void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...) at
> /usr/include/boost/function/function_template.hpp:153
> #11 0x7fffdd016cd0 in
> boost::detail::thread_data >::run() (this= out>)
> at /usr/include/boost/function/function_template.hpp:767
> #12 0x7fffdd016cd0 in
> boost::detail::thread_data >::run() (this= out>)
> at /usr/include/boost/thread/detail/thread.hpp:117
> #13 0x7fffdbe4f24a in thread_proxy () at
> /lib64/libboost_thread-mt.so.1.53.0
> #14 0x77800dc5 in start_thread () at /lib64/libpthread.so.0
> #15 0x76e2528d in clone () at /lib64/libc.so.6
>
> Here are the locals on the last few frames:
>
> (gdb) f 0
> #0  0x7fffdcaccb57 in _mm256_load_ps (__P=0x3b051b0) at
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> 835   return *(__m256 *)__P;
> (gdb) info locals
> No locals.
> (gdb) f 1
> #1  volk_32fc_x2_multiply_32fc_a_avx2_fma (cVector=0x3b1f770,
> aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at
> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
> 242 const __m256 x = _mm256_load_ps((float*)a); // Load the ar +
> ai, br + bi as ar,ai,br,bi
> (gdb) info locals
> y = {-4.87433296e+17, 4.59163468e-41, -3.92813517e+17, 4.59163468e-41,
> 5.15677835e-43, 0, 5.26888223e-43, 0}
> tmp2x = {6.389921e-43, 0, -512.314453, 4.59163468e-41, 1.26116862e-

[Discuss-gnuradio] Modulation scheme for DSSS

[Henry Barton]

As you know, I’ve written a baseband DSSS modulator and demodulator. I’ve got 
the waveform samples, but I know I need a modulation scheme to actually send it 
through the air. I’ve heard somewhere that OFDM can be used for CDMA DSSS, and 
also 4-qam/QPSK. Can anyone tell me what modulation schemes are appropriate for 
CDMA DSSS so multiple transmitters can coexist like they’re supposed to? Thanks.






Sent from Windows Mail___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

Calling 'info variables' (or args or locals) the last few frames didn't
give me any real info so I built a copy of GR/Volk with debug symbols.  I
ran the FG again, this time from GDB, here's my back trace.  In this
backtrace you can see the arguments passed in each call.  I have an
i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.

Here's are the links for the relevant code:

https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214

Could the problem be that nitems is 257 and num_points is 512?  Or should
nitems really be 256 and not 257?

Thanks,
Devin

(gdb) bt
#0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
(__P=0x3b051b0)
at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
#1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
(cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
at
/local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
#2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
(cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
#3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter(int,
std::complex const*, std::complex*) (this=0x3b02f40,
nitems=nitems@entry=257, input=input@entry=0x7fffc9cc7000,
output=output@entry=0x3b36460)
at /local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
#4  0x7fffd42910df in gr::digital::corr_est_cc_impl::work(int,
std::vector >&, std::vector >&) (this=0x3b01560, noutput_items=257,
input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
at
/local_disk/gr_3.7.9_src/gnuradio/gr-digital/lib/corr_est_cc_impl.cc:237
#5  0x7fffdd064907 in gr::sync_block::general_work(int,
std::vector >&, std::vector >&, std::vector
>&) (this=0x3b015b8, noutput_items=, ninput_items=...,
input_items=..., output_items=...) at
/local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/sync_block.cc:66
#6  0x7fffdd02f70f in gr::block_executor::run_one_iteration()
(this=this@entry=0x7fff83ffedb0)
at
/local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:438
#7  0x7fffdd06da8a in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
(this=0x7fff83ffedb0, block=..., max_noutput_items=) at
/local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
#8  0x7fffdd062761 in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
at
/local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
#9  0x7fffdd062761 in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
at
/local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
#10 0x7fffdd062761 in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer&)
(function_obj_ptr=...) at
/usr/include/boost/function/function_template.hpp:153
#11 0x7fffdd016cd0 in boost::detail::thread_data
>::run() (this=)
at /usr/include/boost/function/function_template.hpp:767
#12 0x7fffdd016cd0 in boost::detail::thread_data
>::run() (this=)
at /usr/include/boost/thread/detail/thread.hpp:117
#13 0x7fffdbe4f24a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#14 0x77800dc5 in start_thread () at /lib64/libpthread.so.0
#15 0x76e2528d in clone () at /lib64/libc.so.6

Here are the locals on the last few frames:

(gdb) f 0
#0  0x7fffdcaccb57 in _mm256_load_ps (__P=0x3b051b0) at
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
835   return *(__m256 *)__P;
(gdb) info locals
No locals.
(gdb) f 1
#1  volk_32fc_x2_multiply_32fc_a_avx2_fma (cVector=0x3b1f770,
aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
at
/local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
242 const __m256 x = _mm256_load_ps((float*)a); // Load the ar +
ai, br + bi as ar,ai,br,bi
(gdb) info locals
y = {-4.87433296e+17, 4.59163468e-41, -3.92813517e+17, 4.59163468e-41,
5.15677835e-43, 0, 5.26888223e-43, 0}
tmp2x = {6.389921e-43, 0, -512.314453, 4.59163468e-41, 1.26116862e-44, 0,
-4.87433296e+17, 4.59163468e-41}
x = {-512.314453, 4.59163468e-41, 0, 0, 2.76102662, -3.64918089,
-4.92134571, -1.06491208}
yl = {4.14784345e-43, 0, 1.26116862e-44, 0, -4.87442367e+17,
4.59163468e-41, -4.87439343e+17, 4.59163468e-41}
yh = {-1674752, 4.59163468e-41, 0, 0, -1.50397414e-36, 4.59163468e-41,
-3.31452625e+17, 4.59163468e-41}
tmp2 = {6.72623263e-44, 1.2751816e-43, 2.24207754e-44, 0,

Re: [Discuss-gnuradio] GSOC 2016 - Cyclostationary Tools

[West, Nathan]

Hi,

To make a really good proposal for this you're going to have to come up
with the specifics on your own. Once you have those in mind feel free to
write them up in to a draft proposal for comment.

What cyclostationary algorithms are you interested in working on? Do you
want a particular visualization to be added?

In your other thread you mention interest in signal intelligence as well.
These two projects are pretty similar, so you clearly have a general idea
of your interests. Perhaps you don't have a specific algorithm in mind, but
you have an application. If you tell us about that maybe that can turn in
to your project or people can suggest algorithms.

Nathan

On Tue, Mar 8, 2016 at 10:20 AM, Ilie-Ablachim Denis 
wrote:

> Hi,
>
> My name is Ilie-Ablachim Constantin-Denis and I am a 3rd year student in
> Automatic Control and Computer Science at Politehnica University of
> Bucharest. I am really interested on working with this organization for the
> "Cyclostationary Tools" project.
>
> I am an Undergraded Teaching Assistant at my university, teaching "Signal
> ans Systems" and "Automated System Theory". I have strong knowledge in
> signal and image processing.
>
> I also improved in the past 7 years my skill in programming, especially:
> C/C++ and Matlab and developed for a research center from my university
> some applications in : face detection, face recognition, based on signal
> processing.
>
> I would be more than happy to work on this project or even submit a demo
> or patch for my future proposal assestment. Also I started doing research
> on this project, but I would really appreciate if you could give me some
> extra documentation and information on this.
>
> Thank you in advance!
>
> Yours sincerely, Ilie-Ablachim Constantin-Denis.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GSOC 2016 - Cyclostationary Tools

[Ilie-Ablachim Denis]

Hi,

My name is Ilie-Ablachim Constantin-Denis and I am a 3rd year student in
Automatic Control and Computer Science at Politehnica University of
Bucharest. I am really interested on working with this organization for the
"Cyclostationary Tools" project.

I am an Undergraded Teaching Assistant at my university, teaching "Signal
ans Systems" and "Automated System Theory". I have strong knowledge in
signal and image processing.

I also improved in the past 7 years my skill in programming, especially:
C/C++ and Matlab and developed for a research center from my university
some applications in : face detection, face recognition, based on signal
processing.

I would be more than happy to work on this project or even submit a demo or
patch for my future proposal assestment. Also I started doing research on
this project, but I would really appreciate if you could give me some extra
documentation and information on this.

Thank you in advance!

Yours sincerely, Ilie-Ablachim Constantin-Denis.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSOC '16: Signal Intelligence (gr-sigint)

[sreeraj r]

Hi Christopher,

On Tue, Mar 8, 2016 at 3:14 PM, Richardson, Christopher (richarc2) <
c.richard...@lancaster.ac.uk> wrote:

> Hi everyone,
>
> I'm very interested in working on the Signal Intelligence (gr-sigint)
> project for the Google Summer of Code.
>
> I'm currently a PhD student at Lancaster University, UK, studying attack
> detection
> in a privacy preserving manner.
>
> I achieved an MSc in Bristol, UK, making use of machine learning
> techniques to detect viruses -
> http://www.lancaster.ac.uk/pg/richarc2/dissertation.pdf.
> As mentioned in the idea suggested by Mr Rajendran "Another approach is to
> use available waterfall images and run some image comparison algorithms",
> I am curious if I could make use of such machine learning techniques to
> achieve this.
>

You could refer this new paper [1] to get an idea about the usage of CNN
for modulation classification. The technique mentioned in the paper works
on quadrature data in time.
It would be interesting to see how much accuracy we can get from
spectrogram information. For simple prototyping and analysis you could use
tensorflow [2] along with GNURadio


>
> I am also especially interested in how the performance of such classifiers
> could be measured through conducting real-world experiments,
> with 2 SDRs (one for transmission and one for reception) at a range of
> increasing distances, potentially making use of
> techniques such as Receiver Operating Characteristic (ROC) curves and the
> Area Under Curve (AUC) as a metric for quantifying
> the performance of a classifier.
>
> I'm currently reading more about algorithms to detect cyclostationary
> features along with a survey on Automatic Modulation Recognition.
> I'm also looking at existing GNU Radio modules such as gr-specest.
>
> If anyone could point me at further reading material or suggestions for
> the proposal, that would be great!
>

The first step for GSoC is to come up with a nice project proposal. Martin
already shared a lot of info on this in the mailinglist. You could look
into past GNURadio GSoC projects [3] and some student info [4].  These are
old links, but will give you an idea how to proceed.  For ramping up on
cyclostationarity you could find a lot of sources online, e.g. [5-6].

Good luck.

Best regards,
Sreeraj

[1] http://arxiv.org/abs/1602.04105
[2] https://oshearesearch.com/2016/02/02/gnu-radio-tensorflow-blocks/
[3] https://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCPastProjects
[4] https://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo
[5] http://vtechworks.lib.vt.edu/handle/10919/29981
[6]
http://archives.njit.edu/vol01/etd/2000s/2006/njit-etd2006-115/njit-etd2006-115.pdf


> Kind Regards
>
> Christopher Richardson
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GSOC '16: Signal Intelligence (gr-sigint)

[Richardson, Christopher (richarc2)]

Hi everyone,

I'm very interested in working on the Signal Intelligence (gr-sigint)
project for the Google Summer of Code.

I'm currently a PhD student at Lancaster University, UK, studying attack 
detection 
in a privacy preserving manner.

I achieved an MSc in Bristol, UK, making use of machine learning techniques to 
detect viruses - http://www.lancaster.ac.uk/pg/richarc2/dissertation.pdf. 
As mentioned in the idea suggested by Mr Rajendran "Another approach is to use 
available waterfall images and run some image comparison algorithms", 
I am curious if I could make use of such machine learning techniques to achieve 
this.

I am also especially interested in how the performance of such classifiers 
could be measured through conducting real-world experiments, 
with 2 SDRs (one for transmission and one for reception) at a range of 
increasing distances, potentially making use of
techniques such as Receiver Operating Characteristic (ROC) curves and the Area 
Under Curve (AUC) as a metric for quantifying 
the performance of a classifier.

I'm currently reading more about algorithms to detect cyclostationary features 
along with a survey on Automatic Modulation Recognition.
I'm also looking at existing GNU Radio modules such as gr-specest.

If anyone could point me at further reading material or suggestions for the 
proposal, that would be great!

Kind Regards

Christopher Richardson

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

Re: [Discuss-gnuradio] gr-uhd timed command messages

[Nigel Steed]

Hi Marcus,

I updated my code to (which compiles):

pmt::pmt_t timeStamp = pmt::mp(pmt::from_long(0), pmt::from_double(1));
command = pmt::dict_add(command, pmt::mp("time"), timeStamp);

But my UHD Source gives the following error when it receives the message:

Block gr uhd usrp source(1)>]:pmt_cdr:wrong_type:{0 1}

I have rebuilt gr-uhd with the UHD_USRP_MULTI_USRP_COMMAND_TIME_API defined. 

Have I done something stupid ?

Thanks,

Nigel

-Original Message-
From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
Sent: Friday, March 4, 2016 10:44 AM
To: Nigel Steed ; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-uhd timed command messages

Hi Nigel,

from_long(1), from_double(1)
implies that your timestamp is at 1 [full second] + 1 [fraction of second] = 
2s; usually you'd do from_long(2), from_double(0) for that :)

> Do you think it maybe better for me to modify UHD Source and implement the 
> timed command in the set_center_freq function in the usrp_source_impl.cc (UHD 
> Source Block) ? As I am successfully stepping the UHD Source using the 
> message port successfully and I just need to add a timed command so both 
> channels re-tune together.
Not quite sure. As far as I can tell, the usrp_source does exactly the timed 
command tuning when you issue these commands; however, I've to admit I haven't 
read up on your discussion with Martin, so there might be a bug and it doesn't?

Best regards,
Marcus


On 04.03.2016 11:35, Nigel Steed wrote:
> Thanks Marcus,
>
> The UHD Source finally understand the following:
>
> pmt::pmt_t timeStamp = pmt::cons(pmt::from_long(1), 
> pmt::from_double(1)); d_rxCommand = pmt::dict_add(d_rxCommand, 
> pmt::mp("time"), timeStamp);
>
> Although UHD Source reports processing the message, I eventually get a packet 
> loss error and the N210 disconnects (no control response error).
>
> Do you think it maybe better for me to modify UHD Source and implement the 
> timed command in the set_center_freq function in the usrp_source_impl.cc (UHD 
> Source Block) ? As I am successfully stepping the UHD Source using the 
> message port successfully and I just need to add a timed command so both 
> channels re-tune together.
>
> Thanks,
>
> Nigel
> -Original Message-
> From: discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org 
> [mailto:discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org] On 
> Behalf Of Marcus Müller
> Sent: 04 March 2016 08:35
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] gr-uhd timed command messages
>
> Hi Nigel,
>
>> d_rxCommand = pmt::dict_add(d_rxCommand, pmt::mp("time"), 
>> pmt::mp(0.5));
> Timestamps aren't just doubles for UHD; they ought to be [1]
>
>> timestamp: A pair composed of (long full_secs, double frac_secs).
> Similar to uhd::time_spec_t.
>
> So your timestamp needs to be a pair of long, double
>
> pmt_t timestamp = pmt::make_pair(pmt::from_long(0), 
> pmt::from_double(0.5)); d_rxCommand = pmt::dict_add(d_rxCommand, 
> pmt::mp("time"), timestamp);
>
> if I'm not mistaken.
>
> Best regards,
> Marcus
>
> [1] 
> https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax_cmds
> On 04.03.2016 01:39, Nigel Steed wrote:
>> Hi Martin,
>>
>> I have put the following code into my block.
>>
>>
>>  d_rxCommand = pmt::make_dict();
>>  d_rxCommand = pmt::dict_add(d_rxCommand, pmt::mp("time"), 
>> pmt::mp(0.5));
>>  message_port_pub(pmt::mp("rx_freq_msg"), d_rxCommand );
>>
>> It sends the message to the UHD Sink. But I get this error at run time:
>>
>>  thread[thread-per-block[5]: ]: pmt_cdr: 
>> wrong_type : 1
>>
>> Any ideas ? I am trying to auto step the frequencies, and currently have my 
>> own block to generate frequency messages which works fine. I am now trying 
>> to implement the time commands. Is there any other way to do it ?
>>
>> Thanks,
>>
>> Nigel
>>
>>
>>
>> -Original Message-
>> From: discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org
>> [mailto:discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org] On 
>> Behalf Of Martin Braun
>> Sent: Wednesday, March 2, 2016 9:24 PM
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] gr-uhd timed command messages
>>
>> When using messages, simply add a 'time' key to the command dictionary, and 
>> it will be set for the command you're calling. The time stamp value, is a 
>> long/double pair, for full and fractional time. Example:
>>
>> {'freq': 1e9, 'time': (100, 0.1)}
>>
>> If this is your message, it will set the frequency to 1 GHz at time 100.1.
>>
>> Cheers,
>> Martin
>>
>>
>>
>> On 03/02/2016 05:46 AM, Nigel Steed wrote:
>>> Hi,
>>>
>>>  
>>>
>>> Anyone know or managed to implement the time command using a message 
>>> port to the UHD Source Block ?
>>>
>>>  
>>>
>>> I believe time commands are not implemented in the latest GNURadio 
>>> gr-uhd ? Is that correct ?
>>>
>>>  
>>>
>>> Thanks,
>>>
>>>  
>>>
>>> Nigel
>>>
>>>
>>>
>>> ___

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Ludwig Stephan (CR/AEH4)]

Hi Bastian,

I thought being a bit more thorough on the SOS method never harms ;-)

Aah, I got the point: alpha_n depends on theta and theta increases. I mixed it 
up and thought we were talking about psi and phi.

> It does not grow, but change over time. alpha_n depends on theta, which is 
> updated after each sample. Through theta, alpha_n is
> doing a random walk in the interval [- pi;  pi]  so that the term
>
> d_fDTs *sin(alpha_n)
>
> is a random walk through the Doppler spectrum.

Just to make it clear (to myself):
alpha_n changes randomly.
BUT: alpha_n depends on theta, which in turn does a random walk in the code

Bastian, you are right. In all the papers theta is a randomly chosen constant. 
And it should remain constant – at least for a certain time. After some time, 
the difference between actual process and intended process might run away such 
that a re-initialization might be appropriate. In this case you have to do 
something, which keeps the samples of previous calls continuous with the call 
using new parameters. By alternating the sign of the random variable, someone 
is trying to keep theta “in lanes”. Maybe the random walk of theta is an (I 
think inappropriate, because it does not work, because all other parameters get 
changed independently) way of achieving this.
In fact, the code should not use update_theta for every new output sample, 
because I fear that this makes successive samples non-continuous – and your 
iPython notebook backs this.
And theta should not saturate at +/- pi, either. I do not have a clue, where 
the step size is taken from. It is definitely not Table II in the Zajic/Stüber 
paper.

[…]

> "Efficient Simulation of Rayleigh Fading with Enhanced De-Correlation 
> Properties” by  Alenka G. Zajic  and Gordon L. Stüber
> http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1673098
> the authors refer to the paper, stating that:

Ahh, that is a very good reference. Actually I was searching for that in my 
literature database but did not find it again.

> "To improve on previously reported models, Zheng and Xiao proposed several 
> new statistical models [14]-[16]. By allowing all
> three parameter sets (amplitudes, phases, and Doppler frequencies) to be 
> random variables, Zheng and Xiao’s models obtain
> statistical properties similar to ones required by the reference model. 
> However, the models are no longer ergodic."
>
> To me it looks like the model was _fixed_ by introducing this random walk 
> that is supposed to make the model great ergodic
> again. I guess this follows some paper or book since the code mentions a table
> d_step( powf(0.00125*fDTs, 1.1) ),  // max step size approximated from Table 2

No, the model of Zajic/Stüber is ergodic. But yes, they fixed the previous 
model by choosing the parameters randomly – but constant over time and not 
updating for every sample. And Table II does definitely not refer to the one in 
their paper.

I try to summarize all the efforts

· Use sin and cos in the factors for getting (almost) uncorrelated I 
and Q shares of the complex random variable

· Introduce a random phase (but constant) argument into every 
cos(f_D*t) term in order to make the system WSS

· In order to make the signals ergodic (ever draw of parameters has the 
equal statistics, which also yield uncorrelated processes) let sin(f_D*t) and 
cos(f_D*t) have different random (but constant) phases, but thake the cos/sin 
factors from identical angles of arrival

· MEDS method produces WSS process of intended auto-correlation 
function, but introduces correlation between different random process.

· The Zheng/Xiao model combines all previous advantages: still constant 
but different phases

· The Zajic/Stüber model combines all previosu advantages, especially 
it has a random but constant phase (-> WSS), is ergodic, has uncorrelated I/Q 
and uncorrelated processes, while converging faster (requires smaller N).

=> In conclusion and because nobody remembers why this code was written like 
that, I vote for adapting the model to Zajic/Stüber by removing the 
update_theta function and their call (and then unused variables like d_step). 
Their implementation is one of the best-known ones.


Best regards

Stephan Ludwig

Communication Technology (CR/AEH4)
Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | 
www.bosch.com
Tel. +49(711)811-8809 | Mobile +49(172)5630639 | Fax +49(711)811-5187845 | 
stephan.ludw...@de.bosch.com

Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart, HRB 
14000;
Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors: Dr. 
Volkmar Denner,
Dr. Stefan Asenkerschbaumer, Dr. Rolf Bulander, Dr. Stefan Hartung, Dr. Markus 
Heyn, Dr. Dirk Hoheisel,
Christoph Kübel, Uwe Raschke, Dr. Werner Struth, Peter Tyroller



___
Discuss-gnuradio mailing list