Re: [Discuss-gnuradio] warning message

[Sylvain Munaut]

Hi,

> Warning: Block key "blocks_ctrlport_monitor_performance" not found when
> loading category tree.
> Warning: Block key "blocks_ctrlport_monitor_performance" not found when
> loading category tree.

They're harmless and just due to the fact you don't have ctrlport
support compiled it, probably because you're missing ICE.


> due to this i am unable to access any blocks of grc.

Nope, this has nothing to do with it.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] gr.file_sink Issue

[Marcus Müller]

Hi Paul,

if you're using GR 3.7, the "standard" blocks have moved from the /gr/ module 
to the /blocks/ module.
If you're using 3.6, further investigation is necessary.

Greetings,
Marcus

On 10/21/2013 01:45 AM, Paul B. Huter wrote:

I looked everywhere for information pertaining to this question, but nothing 
worked.

I am starting with a sample for recording information from my USRP (N210), but 
I am running into issues with:

self.gr_file_sink = gr.file_sink(gr.sizeof_complex, "data.dat")

When I try running it, I get:

AttributeError: 'module' object has no attribute 'file_sink'

Where am I going wrong? Is this an issue with my installation, something to do 
with C++/Python configuration? I followed the instructions for setup from Ettus 
(http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows).

I was having issues with WX on GNURadio-Companion (Windows), and I cannot get 
my network configured for Linux, so I resorted to a Python script in Windows.

Any help (including pointing me to reference pages or links) will be 
appreciated.

Thank you.


___
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] Using USRP to transmit and receive samples

[Martin Braun (CEL)]

On Fri, Oct 18, 2013 at 06:00:48PM -0500, JPL wrote:
> Question:
> 
> (1) should I just replace the "Vector Source block" into "File Source" in
> tx_ofdm.grc?

This won't work, the input expects a tagged stream (see the
corresponding manual page). You will need to split the file into
packets, and tag them with their length. Currently there's no automatic
way to do that.

> (2) the rx_ofdm.grc, again, am I right just replace "tag debug" with "file
> sink"?

This on the other hand should work, providing your receiver is actually
working.

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


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

[Discuss-gnuradio] audio rate and quadrature rate in gnuradio

[Sandhya G]

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

Re: [Discuss-gnuradio] audio rate and quadrature rate in gnuradio

[Sandhya G]

Hello everyone,

   I'am building an FM transmitter in gnuradio .Well the audio wave
file is connected to wbfm transmitter through resampler block.The audio
sample rate is 48KHZ and according to the wbfm block the quadrature rate
and  audio rate are related by mod function (quad_rate % audio_rate=0) so
i'm setting the output sample rate to the multiplies of 48 but when i set
the audio rate and quad rate equal i'm able listen properly to the
transmitted audio file.If it is set to different values i'm hearing alot of
noise and sometimes samples running very fast or very slow

I'm using the usrp b100 instant kit
Awaiting for the valuable reply

Thanks and regards
Sandhya




On Mon, Oct 21, 2013 at 4:16 PM, Sandhya G  wrote:

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

Re: [Discuss-gnuradio] setup of usrp N100/N200

[Sandhya G]

Yes sir .your right i thought my pc is ethernet capable.I brushed the spec
of pc hardware it just supports maximum 100mbps .so i'm installing gnuradio
on pandaboard which supports gigabyte.


Thanks and regards
Sandhya


On Mon, Oct 21, 2013 at 11:58 AM, Activecat  wrote:

> Chances are your pc hardware is actually not GE capable.
>
>
> On Mon, Oct 21, 2013 at 2:23 PM, Sandhya G  wrote:
>
>> ok sir then i'l try to debug the problem in my os now
>>
>> Thanks
>> Sandhya
>>
>>
>> On Mon, Oct 21, 2013 at 11:49 AM, Activecat  wrote:
>>
>>> As I mentioned in previous email (below), the first thing you need to do
>>> now is to bring up the physical layer of the Ethernet connection.
>>> If the GE port LED is not ON, no point to proceed without this being
>>> solved first.
>>>
>>> If you insist that your hardware support 1000Mbps GE, then make the
>>> Linux recognise this first before troubleshooting at the gnuradio level.
>>>
>>> Now you should troubleshoot your Linux, not gnuradio, if you confirmed
>>> that your hardware is really GE capable.
>>>
>>>
>>> -- Forwarded message --
>>> From: Activecat 
>>> Date: Mon, Oct 21, 2013 at 1:09 PM
>>> Subject: Re: [Discuss-gnuradio] setup of usrp N100/N200
>>> To: Sandhya G 
>>> Cc: Discuss-gnuradio@gnu.org
>>>
>>> You shall troubleshoot in the following steps:
>>>
>>> 1).  Bring up the physical ethernet connection between your PC and the
>>> USRP. Upon successful you will see the LED turns on at the USRP GE port.
>>>
>>> 2). Set your PC IP address to the same subnet but don't crash with the
>>> USRP's ip address.
>>>  If this step is successful then you will be able to ping the USRP.
>>>
>>>  3).  Issue command "uhd_find_devices" and you will see the USRP being
>>> discovered.
>>>
>>> Then you could proceed with "uhd_usrp_probe" to see more details.
>>>
>>>
>>> On Mon, Oct 21, 2013 at 2:02 PM, Sandhya G wrote:
>>>
 OS is linux. my pc is 2010 model,has

- 3rd Generation Intel® Core™ i5-3317U
- 64-bit.

 And when i give the command sudo ethtool eth1 i'am getting the speed
 has 10Mb/s

 Settings for eth1:
 Supported ports: [ TP MII ]
 Supported link modes:   10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 Supported pause frame use: No
 Supports auto-negotiation: Yes
 Advertised link modes:  10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
 Advertised pause frame use: Symmetric Receive-only
 Advertised auto-negotiation: Yes
 Speed: 10Mb/s
 Duplex: Half
 Port: MII
 PHYAD: 0
 Transceiver: internal
 Auto-negotiation: on
 Supports Wake-on: pumbg
 Wake-on: g
 Current message level: 0x0033 (51)
drv probe ifdown ifup
 Link detected: no

 And ya GE port led is not ON

 Thanks

 Sandhya






 On Mon, Oct 21, 2013 at 11:04 AM, Activecat wrote:

> What operating system are you running, is it Linux or Microsoft
> Windows?
>
>
> On Mon, Oct 21, 2013 at 1:25 PM, Sandhya G wrote:
>
>>  i'm seeing only LED's D and F are on, because host pc is not at all
>> detecting the hardware and i'm unable to run any operation.In my first i
>> mentioned the errors what i'am getting when i run the flowgraph.
>> Even i'am clueless how my device is only showing up 10/100Mbps when i
>> connect the hardware and even i tried with other pc but i'm facing the 
>> same
>> problem.
>>
>>
>> Thanks and regards
>>  Sandhya
>>
>>
>> On Mon, Oct 21, 2013 at 10:42 AM, Activecat wrote:
>>
>>> What operating are you running? How do you get the "10/100Mbps" ?
>>>  Do you see the LED turns on at the USRP GE port?
>>>
>>>
>>> On Mon, Oct 21, 2013 at 1:09 PM, Sandhya G wrote:
>>>
 Sir my pc is capable of supporting 1000Mbps but when i connect the
 hardware and check the speed of the port it will be showing 10/100Mbps.
 What might the issue?and can i boost the pc speed

 Thanks and regards
 Sandhya


 On Mon, Oct 21, 2013 at 10:30 AM, Sandhya G 
 wrote:

> ya its a new one and sir y i'am i getting unknown key format even
> though i give addr=192.168.10.2 and the problem i'm facing is its 
> showing
> me an error has cannot find as a single device.I have no clue the 
> reason
> for that
>
> Thanks and regards
> Sandhya
>
>
> On Mon, Oct 21, 2013 at 10:24 AM, Activecat 
> wrote:
>
>> If that is a new USRP from factory then you don't need to update
>> the firmware.
>>
>>
>>
>> On Mon, Oct 21, 2013 at 12:51 PM, Sandhya G <
>>

Re: [Discuss-gnuradio] setup of usrp N100/N200

[Activecat]

Congradulation and you are most welcome.

activecat.


On Mon, Oct 21, 2013 at 7:10 PM, Sandhya G  wrote:

> Yes sir .your right i thought my pc is ethernet capable.I brushed the spec
> of pc hardware it just supports maximum 100mbps .so i'm installing gnuradio
> on pandaboard which supports gigabyte.
>
>
> Thanks and regards
> Sandhya
>
>
> On Mon, Oct 21, 2013 at 11:58 AM, Activecat  wrote:
>
>> Chances are your pc hardware is actually not GE capable.
>>
>>
>> On Mon, Oct 21, 2013 at 2:23 PM, Sandhya G  wrote:
>>
>>> ok sir then i'l try to debug the problem in my os now
>>>
>>> Thanks
>>> Sandhya
>>>
>>>
>>> On Mon, Oct 21, 2013 at 11:49 AM, Activecat  wrote:
>>>
 As I mentioned in previous email (below), the first thing you need to
 do now is to bring up the physical layer of the Ethernet connection.
 If the GE port LED is not ON, no point to proceed without this being
 solved first.

 If you insist that your hardware support 1000Mbps GE, then make the
 Linux recognise this first before troubleshooting at the gnuradio level.

 Now you should troubleshoot your Linux, not gnuradio, if you confirmed
 that your hardware is really GE capable.


 -- Forwarded message --
 From: Activecat 
 Date: Mon, Oct 21, 2013 at 1:09 PM
 Subject: Re: [Discuss-gnuradio] setup of usrp N100/N200
 To: Sandhya G 
 Cc: Discuss-gnuradio@gnu.org

 You shall troubleshoot in the following steps:

 1).  Bring up the physical ethernet connection between your PC and the
 USRP. Upon successful you will see the LED turns on at the USRP GE port.

 2). Set your PC IP address to the same subnet but don't crash with the
 USRP's ip address.
  If this step is successful then you will be able to ping the USRP.

  3).  Issue command "uhd_find_devices" and you will see the USRP being
 discovered.

 Then you could proceed with "uhd_usrp_probe" to see more details.


 On Mon, Oct 21, 2013 at 2:02 PM, Sandhya G wrote:

> OS is linux. my pc is 2010 model,has
>
>- 3rd Generation Intel® Core™ i5-3317U
>- 64-bit.
>
> And when i give the command sudo ethtool eth1 i'am getting the speed
> has 10Mb/s
>
> Settings for eth1:
> Supported ports: [ TP MII ]
> Supported link modes:   10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Advertised link modes:  10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Speed: 10Mb/s
> Duplex: Half
> Port: MII
> PHYAD: 0
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: pumbg
> Wake-on: g
> Current message level: 0x0033 (51)
>drv probe ifdown ifup
> Link detected: no
>
> And ya GE port led is not ON
>
> Thanks
>
> Sandhya
>
>
>
>
>
>
> On Mon, Oct 21, 2013 at 11:04 AM, Activecat wrote:
>
>> What operating system are you running, is it Linux or Microsoft
>> Windows?
>>
>>
>> On Mon, Oct 21, 2013 at 1:25 PM, Sandhya G wrote:
>>
>>>  i'm seeing only LED's D and F are on, because host pc is not at all
>>> detecting the hardware and i'm unable to run any operation.In my first i
>>> mentioned the errors what i'am getting when i run the flowgraph.
>>> Even i'am clueless how my device is only showing up 10/100Mbps when
>>> i connect the hardware and even i tried with other pc but i'm facing the
>>> same problem.
>>>
>>>
>>> Thanks and regards
>>>  Sandhya
>>>
>>>
>>> On Mon, Oct 21, 2013 at 10:42 AM, Activecat wrote:
>>>
 What operating are you running? How do you get the "10/100Mbps" ?
  Do you see the LED turns on at the USRP GE port?


 On Mon, Oct 21, 2013 at 1:09 PM, Sandhya G 
 wrote:

> Sir my pc is capable of supporting 1000Mbps but when i connect the
> hardware and check the speed of the port it will be showing 
> 10/100Mbps.
> What might the issue?and can i boost the pc speed
>
> Thanks and regards
> Sandhya
>
>
> On Mon, Oct 21, 2013 at 10:30 AM, Sandhya G  > wrote:
>
>> ya its a new one and sir y i'am i getting unknown key format even
>> though i give addr=192.168.10.2 and the problem i'm facing is its 
>> showing
>> me an error has cannot find as a single device.I have no clue the 
>> reason
>> for that
>>
>> Thanks and regards
>> Sandhya
>>
>

Re: [Discuss-gnuradio] setup of usrp N100/N200

[Marcus Leech]

The default IP address of the N2XX devices is 192.168.10.2, so:
uhd_usrp_probe --args "addr=192.168.10.2"
 
Should work.  EXCEPT, you only have a 10/100 Ethernet interface, which won't work.  The N2XX devices support ONLY 1GiGe.
 
 
on Oct 21, 2013, Sandhya G  wrote:


HI all,
 
I have followed as per the instructions given in the webpage for set up of the Usrp N200/N210 but still i am unable to communicate between the  hardware and host pc
 
    1.I have set the static ip of the host pc to 192.168.10.1(ifconfig eth0 192.168.10.1).
2.Whenever i give the device address=addr=192.168.10.1 and run the grc i am getting the error has “unknown key format” 
3.Whenever i ping 192.168.10.2 or use the command  uhb_find_device  i am getting warning as “NO DEVICE FOUND “
4. Is that a must i have to upload the fpga and firmware images when using the device for the first time.
5.Sometimes i am getting an error like” unable to find as single device”.
6.The host pc is supporting only 10/100MBPS .Is that the only problem so that i am unable to communicate with the hardware.
 
Can anybody help me on this issue.Awaiting for your valuable reply
 
Thanks in advance 
Sandhya.G

___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

Re: [Discuss-gnuradio] zero ninput_items_required[0]

[Marcus Müller]

  
  
Hm, I don't know why this should really
  happen before your source's work function is called.
  But basically, maybe this is part of GNU Radio trying to figure
  out how to assign buffers; I haven't dived very deep into that
  aspect of the runtime. 
  However, since your forecast told GR that you're able to produce
  samples without input, I could imagine that your work gets
  scheduled simultaneously with those of your sources. 
  To circumvent that, just don't lie ;) and tell the scheduler that
  you need input to produce output.
  
  Greetings,
  Marcus
  On 20.10.2013 13:11, Nemanja Savic wrote:


  

  
Thank you Marcus very much. I would like to ask some
  more questions.

For me it looks like the problem is at very begining when
source has not produced any output, and it looks like
forecast of my block is called before the work functino of
the source? How should one cope with this? By checking if
required number of input samples is zero and solving that
case? How is that ensured for interpolator.

  
  Thanks and kind regards,

Nemanja
  
  

On Sat, Oct 19, 2013 at 10:35 AM,
  Marcus Müller 
  wrote:
  

  Hi Nemanja,

Considering following flowgraph, assume your block is A,
and assume all blocks work with the same itemsize.


good question, but basically, when running, when A is
done with a run of work, it's thread notifies blocks
"upstream" (B in this case) that it has consumed  input items, making that space
available for new output; GNU radio then calls forecast
of B with a noutput_items 
to fill that space. However, if the upstream block B
needs more input items than C has provided, GNU Radio
will repeatedly reduce the number of samples it asks for
until B needs less or equal samples as C has produced. 

In your case, this only happens for 0 output items; thus
your general_work gets called with 0 input items, as
Martin already stated. 
So what happens then? Since A has not provided any more
output items for the blocks downstream, D can't do
anything that it has not already been doing. The
downstream part of the flowgraph stalls. Upstream part:
Since GNU Radio has not been able to supply you with
more than 0 input items, we can assume that the upstream
part of the flowgraph is stuck, or done.
Therefore, execution ends here.

Greetings,
Marcus

  


On 10/18/2013 03:19 PM, Nemanja Savic wrote:
  

  
  

  

  

  Thank you Martin, I will try with the
sync_decimator, but it is also important for
me to unterstand what's happening here.
  
  So, I have vector source -> throttle ->
  fsk_modulator -> scope sink.

Vector source generates 8 symbols. From where
scheduler starts, from source or from the sink?
And why it didn't stop for any value before 0?
What should I add into general block to avoid
this?

  
  Thank you


  
  On Fri, Oct 18, 2013 at
2:59 PM, Martin Braun (CEL) 
wrote:

  On Fri, Oct 18, 2013 at 02:32:48PM +0200,
Nemanja Savic wrote:
> The body of my forecast function is:
>
> ninput_items_required[0] =
noutput_items * d_sym_rate /
d_sampling_freq;
> printf("ninput_items_required %d,
noutput_items %d\n", ninput_items_required
> [0], noutput_items);
 

[Discuss-gnuradio] Valgrind & gr_fir_fff_simd::set_taps - memory leak

[Luke Berndt]

I am trying to track down an insidious little memory leak in a Block that
wraps the DSD vocoder. I have run Valgrind against it and didn't find
anything obvious. Valgrind didn't like the way memory was being assigned by
set_taps and it seems like this came up in a previous thread too:
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00015.html

It doesn't look like there was a definitive answer if this was a real
problem or just Valgrind getting confused.

For Background:
I am running GNURadio 3.6.5.1 and my program is all in C++ without any
python. The DSD Vocoder block run the DSD program (which is a C program) in
a pthread and passes it samples using a shared array and some mutex. For
each separate talkgroup conversation on a trunking radio system, the
TopBlock gets locked, a new logging flow with the DSD block in it gets
created and then connected. When the conversation is over the tb get
locked/unlocked and the flows is destroyed. Are there any obvious gotchas
that might leak with this approach? I am using detached threads to run
DSDand deleting all of the
mutex/cond I init.

Here is the Valgrind output concerning the set_taps:

Decoding only P25 Phase 1 frames.
Enabling only C4FM modulation optimizations.
 Recv [ 0 ]   Tg: 1616  Freq: 856.6
==5138== Thread 9:
==5138== Invalid read of size 8
==5138==at 0x4F3F48C: float_dotprod_sse (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F40770: gr_fir_fff_generic::filterN(float*, float const*,
unsigned long) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F41D02: gr_fir_filter_fff::work(int, std::vector >&, std::vector >&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F29EF3: gr_sync_decimator::general_work(int,
std::vector >&, std::vector >&, std::vector
>&) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F099D5: gr_block_executor::run_one_iteration() (in /usr
/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F33B32: gr_tpb_thread_body::gr_tpb
_thread_body(boost::shared_ptr, int) (in /usr/local/lib/
libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F27077:
boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::function_buffer&)
(in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x581F14E: boost::detail::thread_data
>::run() (in /usr/local/lib/libgruel-3.6.5.1.so.0.0.0)
==5138==by 0x76716E8: ??? (in /usr/lib/libboost_thread.so.1.49.0)
==5138==by 0x5A39F8D: start_thread (pthread_create.c:311)
==5138==by 0x7394E1C: clone (clone.S:113)
==5138==  Address 0xfc63288 is 88 bytes inside a block of size 95 alloc'd
==5138==at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck
-amd64-linux.so)
==5138==by 0x4F79FBE: malloc16Align (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F7A009: calloc16Align (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3D435: gr_fir_fff_simd::set_taps(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3D553: gr_fir_fff_simd::gr_fir_fff_simd(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3D7F8: gr_fir_fff_sse::gr_fir_fff_sse(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F3BAE0:
gr_fir_sysconfig_x86::create_gr_fir_fff(std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F41FF5: gr_fir_filter_fff::gr_fir_filter_fff(int,
std::vector > const&) (in /usr/local/lib/
libgnuradio-core-3.6.5.1.so.0.0.0)
==5138==by 0x4F4217B: gr_make_fir_filter_fff(int, std::vector > const&) (in /usr/local/lib/libgnuradio
-core-3.6.5.1.so.0.0.0)
==5138==by 0x482D55: log_dsd::log_dsd(float, float, long, int)
(logging_receiver_dsd.cc:76)
==5138==by 0x482531: make_log_dsd(float, float, long, int)
(logging_receiver_dsd.cc:8)
==5138==by 0x46116F: main (smartnet.cc:394)


And here is the code that creates the fir_filter_fff (in the
constructorfor the logger):

const float a[] = { 0.1, 0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1};
std::vector data( a,a + sizeof( a ) / sizeof( a[0] ) );
sym_filter = gr_make_fir_filter_fff(1, data);
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Valgrind & gr_fir_fff_simd::set_taps - memory leak

[Philip Balister]

On 10/21/2013 01:43 PM, Luke Berndt wrote:
> I am trying to track down an insidious little memory leak in a Block that
> wraps the DSD vocoder. I have run Valgrind against it and didn't find
> anything obvious. Valgrind didn't like the way memory was being assigned by
> set_taps and it seems like this came up in a previous thread too:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00015.html

Look at https://scan.coverity.com/ . You'll need to make an account and
we'll need to grant you access. It is scanning the 3.7 code, but you
might be able to gain some insight by looking at the static analysis.

Philip


> 
> It doesn't look like there was a definitive answer if this was a real
> problem or just Valgrind getting confused.
> 
> For Background:
> I am running GNURadio 3.6.5.1 and my program is all in C++ without any
> python. The DSD Vocoder block run the DSD program (which is a C program) in
> a pthread and passes it samples using a shared array and some mutex. For
> each separate talkgroup conversation on a trunking radio system, the
> TopBlock gets locked, a new logging flow with the DSD block in it gets
> created and then connected. When the conversation is over the tb get
> locked/unlocked and the flows is destroyed. Are there any obvious gotchas
> that might leak with this approach? I am using detached threads to run
> DSDand deleting all of the
> mutex/cond I init.
> 
> Here is the Valgrind output concerning the set_taps:
> 
> Decoding only P25 Phase 1 frames.
> Enabling only C4FM modulation optimizations.
>  Recv [ 0 ]   Tg: 1616  Freq: 856.6
> ==5138== Thread 9:
> ==5138== Invalid read of size 8
> ==5138==at 0x4F3F48C: float_dotprod_sse (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F40770: gr_fir_fff_generic::filterN(float*, float const*,
> unsigned long) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F41D02: gr_fir_filter_fff::work(int, std::vector const*, std::allocator >&, std::vector std::allocator >&) (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F29EF3: gr_sync_decimator::general_work(int,
> std::vector >&, std::vector std::allocator >&, std::vector
>> &) (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F099D5: gr_block_executor::run_one_iteration() (in /usr
> /local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F33B32: gr_tpb_thread_body::gr_tpb
> _thread_body(boost::shared_ptr, int) (in /usr/local/lib/
> libgnuradio-core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F27077:
> boost::detail::function::void_function_obj_invoker0 tpb_container>, void>::invoke(boost::detail::function::function_buffer&)
> (in /usr/local/lib/libgnuradio-core-3.6.5.1.so.0.0.0)
> ==5138==by 0x581F14E: boost::detail::thread_data
>> ::run() (in /usr/local/lib/libgruel-3.6.5.1.so.0.0.0)
> ==5138==by 0x76716E8: ??? (in /usr/lib/libboost_thread.so.1.49.0)
> ==5138==by 0x5A39F8D: start_thread (pthread_create.c:311)
> ==5138==by 0x7394E1C: clone (clone.S:113)
> ==5138==  Address 0xfc63288 is 88 bytes inside a block of size 95 alloc'd
> ==5138==at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck
> -amd64-linux.so)
> ==5138==by 0x4F79FBE: malloc16Align (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F7A009: calloc16Align (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F3D435: gr_fir_fff_simd::set_taps(std::vector std::allocator > const&) (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F3D553: gr_fir_fff_simd::gr_fir_fff_simd(std::vector std::allocator > const&) (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F3D7F8: gr_fir_fff_sse::gr_fir_fff_sse(std::vector std::allocator > const&) (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F3BAE0:
> gr_fir_sysconfig_x86::create_gr_fir_fff(std::vector std::allocator > const&) (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F41FF5: gr_fir_filter_fff::gr_fir_filter_fff(int,
> std::vector > const&) (in /usr/local/lib/
> libgnuradio-core-3.6.5.1.so.0.0.0)
> ==5138==by 0x4F4217B: gr_make_fir_filter_fff(int, std::vector std::allocator > const&) (in /usr/local/lib/libgnuradio
> -core-3.6.5.1.so.0.0.0)
> ==5138==by 0x482D55: log_dsd::log_dsd(float, float, long, int)
> (logging_receiver_dsd.cc:76)
> ==5138==by 0x482531: make_log_dsd(float, float, long, int)
> (logging_receiver_dsd.cc:8)
> ==5138==by 0x46116F: main (smartnet.cc:394)
> 
> 
> And here is the code that creates the fir_filter_fff (in the
> constructorfor the logger):
> 
> const float a[] = { 0.1, 0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1};
> std::vector data( a,a + sizeof( a ) / sizeof( a[0] ) );
> sym_filter = gr_make_fir_filter_fff(1, data);
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.g

[Discuss-gnuradio] Misc questions, regarding Interrupt coalescing

[Naceur]

Hello GR Forum,

I got some questions:

1/ Did anyone already tested the effect of Interrupt coalescing on reducing
the latency when host and USRP N2X0 are communicating and how far did he
reduce this latency

2/ I want to check first if my NIC got this feature enabled ?
How do I have to proceed to check then how to test ? 

3/ When running a stream of packets over the USRP I got the following error: 

thread[thread-per-block[24]: ]: msg length is
not a multiple of d_itemsize  
This error is raised after a fixed number N of successfully sent packets
Could you please give me some hints on this issue.

Best regards,



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Misc-questions-regarding-Interrupt-coalescing-tp44285.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] GNU Radio 3.7 installation issue

[Activecat]

Dear Sir,

I was using GNU Radio 3.6.5.1 previously but now try migrating to version
3.7.1.
So I remove all existing installation, then start using the latest
"build-gnuradio" script.

This error comes out:

Building extra module gr-baz
-- The CXX compiler identification is GNU 4.7.2
-- The C compiler identification is GNU 4.7.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   system
--   thread
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'gruel'
--   package 'gruel' not found
-- Could NOT find GRUEL (missing:  GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
--   package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing:  GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:135 (message):
  Gruel required to compile baz



I know in version 3.7 I need to remove all GRUEL_ references and replace
GNURADIO_CORE variables with GNURADIO_RUNTIME_.
But how to do that?  It seems the "build-gnuradio" script starts from
scratch and it automatically uninstall libgruel3.5.3.2 installed by me.

Thanks in advance.
Regards,
activecat

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

Re: [Discuss-gnuradio] GNU Radio 3.7 installation issue

[Marcus D. Leech]

Dear Sir,

I was using GNU Radio 3.6.5.1 previously but now try migrating to 
version 3.7.1.
So I remove all existing installation, then start using the latest 
"build-gnuradio" script.


This error comes out:

Building extra module gr-baz
-- The CXX compiler identification is GNU 4.7.2
-- The C compiler identification is GNU 4.7.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   system
--   thread
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'gruel'
--   package 'gruel' not found
-- Could NOT find GRUEL (missing:  GRUEL_LIBRARIES
GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
--   package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing:  GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:135 (message):
  Gruel required to compile baz



I know in version 3.7 I need to remove all GRUEL_ references and 
replace GNURADIO_CORE variables with GNURADIO_RUNTIME_.
But how to do that?  It seems the "build-gnuradio" script starts from 
scratch and it automatically uninstall libgruel3.5.3.2 installed by me.


Thanks in advance.
Regards,
activecat



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I don't think gr-baz has been converted to using 3.7 yet, so, the build 
of gr-baz will fail, but that's not fatal to the overall build process




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] GNU Radio 3.7 installation issue

[Activecat]

Dear Sir,
Both "gr-baz" and "grextras" fail in compilation of gnuradio 3.7.
It seems that we have no other choice but to ignore the compilation errors.

But what are gr-baz and grextras being used for, and how this compilation
error will affect the functionality of gnuradio 3.7 ?

Regards,
activecat



On Tue, Oct 22, 2013 at 6:25 AM, Marcus D. Leech  wrote:
I don't think gr-baz has been converted to using 3.7 yet, so, the build of
gr-baz will fail, but that's not fatal to the overall build process

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org



**
>
> Dear Sir,
>
>  I was using GNU Radio 3.6.5.1 previously but now try migrating to
> version 3.7.1.
> So I remove all existing installation, then start using the latest
> "build-gnuradio" script.
>
> This error comes out:
>
> Building extra module gr-baz
> -- The CXX compiler identification is GNU 4.7.2
> -- The C compiler identification is GNU 4.7.2
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.49.0
> -- Found the following Boost libraries:
> --   system
> --   thread
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
> -- checking for module 'gruel'
> --   package 'gruel' not found
> -- Could NOT find GRUEL (missing:  GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
> -- checking for module 'gnuradio-core'
> --   package 'gnuradio-core' not found
> -- Could NOT find GNURADIO_CORE (missing:  GNURADIO_CORE_LIBRARIES
> GNURADIO_CORE_INCLUDE_DIRS)
> CMake Error at CMakeLists.txt:135 (message):
>   Gruel required to compile baz
>
>
>  I know in version 3.7 I need to remove all GRUEL_ references and replace
> GNURADIO_CORE variables with GNURADIO_RUNTIME_.
> But how to do that?  It seems the "build-gnuradio" script starts from
> scratch and it automatically uninstall libgruel3.5.3.2 installed by me.
>
>  Thanks in advance.
> Regards,
> activecat
>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio 3.7 installation issue

[Marcus D. Leech]

Dear Sir,
Both "gr-baz" and "grextras" fail in compilation of gnuradio 3.7.
It seems that we have no other choice but to ignore the compilation 
errors.


But what are gr-baz and grextras being used for, and how this 
compilation error will affect the functionality of gnuradio 3.7 ?
They're used for extra functionality that most people aren't currently 
using.


Josh and Balint can both chime-in with opinions on whether I should 
leave them in build-gnuradio or not. For now, they stay in, and

  "harmlessly" fail.




Regards,
activecat



On Tue, Oct 22, 2013 at 6:25 AM, Marcus D. Leech > wrote:
I don't think gr-baz has been converted to using 3.7 yet, so, the 
build of gr-baz will fail, but that's not fatal to the overall build 
process

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org  


__

Dear Sir,

I was using GNU Radio 3.6.5.1 previously but now try migrating to
version 3.7.1.
So I remove all existing installation, then start using the
latest "build-gnuradio" script.

This error comes out:

Building extra module gr-baz
-- The CXX compiler identification is GNU 4.7.2
-- The C compiler identification is GNU 4.7.2
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   system
--   thread
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- checking for module 'gruel'
--   package 'gruel' not found
-- Could NOT find GRUEL (missing:  GRUEL_LIBRARIES
GRUEL_INCLUDE_DIRS)
-- checking for module 'gnuradio-core'
--   package 'gnuradio-core' not found
-- Could NOT find GNURADIO_CORE (missing:
 GNURADIO_CORE_LIBRARIES GNURADIO_CORE_INCLUDE_DIRS)
CMake Error at CMakeLists.txt:135 (message):
  Gruel required to compile baz


I know in version 3.7 I need to remove all GRUEL_ references and
replace GNURADIO_CORE variables with GNURADIO_RUNTIME_.
But how to do that?  It seems the "build-gnuradio" script starts
from scratch and it automatically uninstall libgruel3.5.3.2
installed by me.

Thanks in advance.
Regards,
activecat








--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Repeatability of delivery ratios using benchmark_tx/rx

[Aditya Dhananjay]

On Wed, Oct 16, 2013 at 10:29 PM, Aditya Dhananjay wrote:

>
>
> On Wed, Oct 16, 2013 at 10:22 PM, Aditya Dhananjay wrote:
>
>> Hi All,
>>
>> I have two USRP N210 devices connected by an attenuator cable. I set up
>> the following experiments.
>>
>> -- BEGIN EXPERIMENT 1
>>
>> Step 1) Use benchmark_tx on one of the USRPs and send 100 packets. At the
>> receiver, I simply record the incoming samples and save them into a file
>> called samples1.dat. This file is static and does not change from now on.
>>
>> Step 2) Run benchmark_rx with the --from-file=samples1.dat option. The
>> other parameters (modulation, fft-length, occupied-tones, etc) are
>> identical to those I used at the transmitter in Step 1. Measure the packet
>> delivery rate.
>>
>> Step 3) Repeat Step 2 a bunch of times. Sometimes, I notice differences
>> in the packet delivery ratios, even though all runs of the experiment use
>> the identical 'samples1.dat' file and an identical set of parameters These
>> differences are small (1-2 packet difference), but I don't understand why
>> they exist.
>>
>> Is this normal behavior? If so, could someone please let me know what the
>> probable causes are?
>>
>> -- END EXPERIMENT 1
>>
>> The next experiment does not use either of the USRP devices.
>>
>> -- BEGIN EXPERIMENT 2
>>
>> 1) Use benchmark_tx to generate 100 packets, and write the samples into a
>> file (samples2.dat) using the --to-file option.
>>
>> 2) Use benchmark_rx with the --from-file=samples2.dat option and check
>> the packet delivery rate. The parameters used (fft-length, etc) are
>> obviously identical to those used to generate the samples in Step 1. I
>> observe that the delivery rate is never even close to 100%.
>>
>> 3) Change to a different parameter set and repeat steps 1 and 2. Across
>> different runs, I observe that the delivery rate is anywhere between 30%
>> and 85%.
>>
>> This cannot be the expected behavior. Any pointers on what I'm
>> doing wrong would be much appreciated!
>>
>> -- END EXPERIMENT 2
>>
>> Thanks!
>>
>> Aditya
>>
>
>
> I should have made a brief mention of my environment:
>
> GNU Radio 3.7.1 installed from source
> Ubuntu 12.04 LTS (64-bit)
> Thanks!
>
> Aditya
>

Update:

In experiment 1, I began to notice large variations in packet delivery
ratios across different runs of step 3. If I modified benchmark_rx to just
sleep for a few seconds between tb.start() and tb.wait(), these large
variations disappeared. It seems like once the EOF is reached, it simply
kills all threads that run inside the flow graph.

However, even with the sleep, there are small variations (~1-2 packets) in
an experiment with a total of 1000 packets being generated. Could anyone
please give me a little hint on why this might be the case?

Thanks.

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

Re: [Discuss-gnuradio] Using USRP to transmit and receive samples

[JPL]

Hello, Martin

1. Would you please tell me where the "manual page" is?
Because I cannot understand
*How the Vector source works*
(tagged_streams.make_lengthtags((packet_len,),(0,).length_tag_name)?
and *where the "Import"block grab the value from* (from
gnuradio.digital.utils import tagged_streams), (import numpy), and (import
random)?
I just need to know how *vector source *related to those *import *block

2. And you are saying keep "*vector source*" block not replace with "*file
source*" block.
How can *vector source* import and read my *.dat?

Thanks again.


















On Mon, Oct 21, 2013 at 2:52 AM, Martin Braun (CEL) wrote:

> On Fri, Oct 18, 2013 at 06:00:48PM -0500, JPL wrote:
> > Question:
> >
> > (1) should I just replace the "Vector Source block" into "File Source" in
> > tx_ofdm.grc?
>
> This won't work, the input expects a tagged stream (see the
> corresponding manual page). You will need to split the file into
> packets, and tag them with their length. Currently there's no automatic
> way to do that.
>
> > (2) the rx_ofdm.grc, again, am I right just replace "tag debug" with
> "file
> > sink"?
>
> This on the other hand should work, providing your receiver is actually
> working.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> 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] cgran is weird

[Activecat]

I was trying to install the 802.11b Receiver from
https://cgran.org/wiki/SPAN80211b

So I followed the instruction to download the source files using the svn as
follows:
 svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596

It gave following message but no file was downloaded.
$ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': 200 OK (
http://gnuradio.org)

Another attempt gave following error message:
$ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': could not
connect to server (http://gnuradio.org)

What was wrong?  Has cgran been migrated to another location ..?

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

Re: [Discuss-gnuradio] cgran is weird

[Marcus D. Leech]

On 10/21/2013 11:40 PM, Activecat wrote:
I was trying to install the 802.11b Receiver from 
https://cgran.org/wiki/SPAN80211b


So I followed the instruction to download the source files using the 
svn as follows:

 svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596

It gave following message but no file was downloaded.
$ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': 200 OK 
(http://gnuradio.org)


Another attempt gave following error message:
$ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': could 
not connect to server (http://gnuradio.org)


What was wrong?  Has cgran been migrated to another location ..?

Regards,
activecat


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
That project is wildly out-of-date.Gnu Radio hasn't been using SVN 
for many years.


CGRAN is just a hosting site for these projects--it's up to the 
maintainers of said projects to keep their info up-to-date, which 
clearly hasn't been done

  with that project.


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

Re: [Discuss-gnuradio] cgran is weird

[George Nychis]

CGRAN founder, here!

Like Marcus said, it's just out of date code and instructions. This is
bound to happen with the majority of projects over time. But, the benefit
to anyone is that parts of them can be used to build new things, and if you
really need functionality provided by one of those projects: something is
better than nothing to build from.

That said, if you do get this project installed and running: please update
the wiki instructions :)

George
On Oct 21, 2013 11:50 PM, "Marcus D. Leech"  wrote:

>  On 10/21/2013 11:40 PM, Activecat wrote:
>
> I was trying to install the 802.11b Receiver from
> https://cgran.org/wiki/SPAN80211b
>
>  So I followed the instruction to download the source files using the svn
> as follows:
>  svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
>
>  It gave following message but no file was downloaded.
>  $ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
> svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': 200 OK (
> http://gnuradio.org)
>
>  Another attempt gave following error message:
>  $ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
>  svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': could not
> connect to server (http://gnuradio.org)
>
>  What was wrong?  Has cgran been migrated to another location ..?
>
>  Regards,
>  activecat
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  That project is wildly out-of-date.Gnu Radio hasn't been using SVN
> for many years.
>
> CGRAN is just a hosting site for these projects--it's up to the
> maintainers of said projects to keep their info up-to-date, which clearly
> hasn't been done
>   with that project.
>
>
>
> ___
> 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] cgran is weird

[Vanush Vaswani]

It would be good to have a list of up to date modules.

On Tue, Oct 22, 2013 at 2:58 PM, George Nychis  wrote:
> CGRAN founder, here!
>
> Like Marcus said, it's just out of date code and instructions. This is bound
> to happen with the majority of projects over time. But, the benefit to
> anyone is that parts of them can be used to build new things, and if you
> really need functionality provided by one of those projects: something is
> better than nothing to build from.
>
> That said, if you do get this project installed and running: please update
> the wiki instructions :)
>
> George
>
> On Oct 21, 2013 11:50 PM, "Marcus D. Leech"  wrote:
>>
>> On 10/21/2013 11:40 PM, Activecat wrote:
>>
>> I was trying to install the 802.11b Receiver from
>> https://cgran.org/wiki/SPAN80211b
>>
>> So I followed the instruction to download the source files using the svn
>> as follows:
>>  svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
>>
>> It gave following message but no file was downloaded.
>> $ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
>> svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': 200 OK
>> (http://gnuradio.org)
>>
>> Another attempt gave following error message:
>> $ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
>> svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': could not
>> connect to server (http://gnuradio.org)
>>
>> What was wrong?  Has cgran been migrated to another location ..?
>>
>> Regards,
>> activecat
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> That project is wildly out-of-date.Gnu Radio hasn't been using SVN for
>> many years.
>>
>> CGRAN is just a hosting site for these projects--it's up to the
>> maintainers of said projects to keep their info up-to-date, which clearly
>> hasn't been done
>>   with that project.
>>
>>
>>
>> ___
>> 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] cgran is weird

[George Nychis]

I've found less projects being contributed to CGRAN in general right now.
 This is likely to due with the migration to git and github providing a
nice interface with wikis for each project.  So, the majority of projects
on CGRAN right now are a bit dated :\

That said, I've been thinking of overhauling CGRAN a bit to be more
friendly to externally hosted projects and github in general.  Really, it's
meant to be a way for people to find 3rd party applications.

Once I finish my Ph.D. defense (tomorrow-- woot!), I'll have some more time
to think about it...

- George


On Tue, Oct 22, 2013 at 12:48 AM, Vanush Vaswani  wrote:

> It would be good to have a list of up to date modules.
>
> On Tue, Oct 22, 2013 at 2:58 PM, George Nychis  wrote:
> > CGRAN founder, here!
> >
> > Like Marcus said, it's just out of date code and instructions. This is
> bound
> > to happen with the majority of projects over time. But, the benefit to
> > anyone is that parts of them can be used to build new things, and if you
> > really need functionality provided by one of those projects: something is
> > better than nothing to build from.
> >
> > That said, if you do get this project installed and running: please
> update
> > the wiki instructions :)
> >
> > George
> >
> > On Oct 21, 2013 11:50 PM, "Marcus D. Leech"  wrote:
> >>
> >> On 10/21/2013 11:40 PM, Activecat wrote:
> >>
> >> I was trying to install the 802.11b Receiver from
> >> https://cgran.org/wiki/SPAN80211b
> >>
> >> So I followed the instruction to download the source files using the svn
> >> as follows:
> >>  svn co -r7596 http://gnuradio.org/svn/gnuradio/trunk gnuradio_r7596
> >>
> >> It gave following message but no file was downloaded.
> >> $ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunkgnuradio_r7596
> >> svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': 200 OK
> >> (http://gnuradio.org)
> >>
> >> Another attempt gave following error message:
> >> $ svn co -r7596 http://gnuradio.org/svn/gnuradio/trunkgnuradio_r7596
> >> svn: OPTIONS of 'http://gnuradio.org/svn/gnuradio/trunk': could not
> >> connect to server (http://gnuradio.org)
> >>
> >> What was wrong?  Has cgran been migrated to another location ..?
> >>
> >> Regards,
> >> activecat
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >> That project is wildly out-of-date.Gnu Radio hasn't been using SVN
> for
> >> many years.
> >>
> >> CGRAN is just a hosting site for these projects--it's up to the
> >> maintainers of said projects to keep their info up-to-date, which
> clearly
> >> hasn't been done
> >>   with that project.
> >>
> >>
> >>
> >> ___
> >> 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