[Discuss-gnuradio] July developers' call

[Tom Rondeau]

We'll be having our monthly developers' call tomorrow as usual,
assuming I can get everything to work properly from my hotel room.

Details can be found here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20120719

Tom

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

[Discuss-gnuradio] Trouble With UHD Tune Request

[Daniel Labarowski]

Hello,
I'm working on a C++ block which accepts a pointer to a uhd sink and 
calls the sink's set_center_frequency method to change to a new 
frequency. Set_center_frequency requires input in the form of a 
uhd::tune_request_t and returns a uhd::tune_result_t. As a bit of 
background, I generated an out of tree module with gr-modtool.py. It 
contains this block as well as two other blocks. The other blocks can be 
used in GRC but this on cannot as it requires a pointer, so I disabled 
the installation of its xml file in grc/CMakeLists.txt and will be using 
it exclusively through c++. The issue that I am having seems to be in 
accessing the libraries for UHD.


//My call to set_center_frequency, where private_UHD_Sink is a pointer 
to a UHD Sink and private_freqs is a pointer to the first member of an 
array and current_freq sets the index of the array
uhd::tune_result_t result_sink = 
private_UHD_Sink->set_center_freq(uhd::tune_request_t(*(private_freqs + 
current_freq)));


I first compiled my flowgraph without #including  and 
 in my source file. Surprisingly, things compile just 
fine without the two files. However, a c++ flowgraph which tries to use 
the block gives a nondescript error ("expected primary-expression before 
‘(’") on the line which instantiates my block. Using one of the other 
blocks (which share the same module) in GRC returns "ImportError: 
/usr/local/lib/libgnuradio-DL_Hitemp_Blocks.so: undefined symbol: 
_ZN3uhd14tune_request_tC1Ed".


I then thought that I would try to include the two files mentioned 
above, and of course it refused to compile because it could not find the 
files. I looked at the CMakeLists.txt file included with the tag demo 
c++ example included in gnuradio and decided to add 
include_directories(${UHD_INCLUDE_DIRS}) and 
link_directories(${UHD_LIBRARY_DIRS}) to my CMakeLists.txt file in my 
src directory. The issue seems to be that many of the cmake directory 
variables on my system were not set properly. Adding "MESSAGE(STATUS, 
"GR include path: ${GNURADIO_CORE_INCLUDE_DIRS}")" to my CMakeLists.txt 
file produces "STATUS,GR include path: /usr/local/include/gnuradio" but 
this is the only GNUradio related cmake variable I have found that seems 
to have been set properly. Adding "MESSAGE(STATUS, "UHD include path: 
${UHD_INCLUDE_DIRS}") MESSAGE(STATUS, "UHD include path: 
${UHD_LIBRARY_DIRS}")" produces "STATUS,UHD include path: STATUS,UHD 
include path: ". I was able to get the source to compile by setting the 
UHD include path absolutely (added 
"include_directories(/usr/local/include/uhd/types)" to my CMakeLists.txt 
file - but I can't seem to find the UHD_Library_Directory so I cannot 
try setting it absolutely. The program now compiles, but the same error 
is produced in GRC as well as in the c++ flowgraph. I am wondering if 
anyone has any idea how I could go about including the appropriate UHD 
libraries or what else could be causing these errors? Thanks ahead of time!


--
Dan

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

Re: [Discuss-gnuradio] CGRAN now breaking projects in to categories, feedback wanted!

[Alexandru Csete]

Hi George,

I think it was a very good idea to break the list up into categories.
It was growing and getting difficult to find things.

Alex

On Tue, Jul 17, 2012 at 7:16 PM, George Nychis  wrote:
> Hi all,
>
> CGRAN has grown significantly beyond my expectations over the past 4 years!
> It started off as two personal projects with the hope of providing somewhere
> for people to develop applications outside of the main GNU Radio code base.
> Now we have 38 projects and a few others in development but not listed!
>
> However, this growth has made our "project list" page a nightmare:
> daunting/challenging to parse through.  So, I've attempted to break it down
> in to categories:
> https://www.cgran.org/wiki/Projects
>
> I'd really like your feedback on the categories.  The "Applications"
> category name is me, but I really couldn't think of how to describe
> these projects which don't fall anywhere else.  The way I broke down the
> standards is decent, but maybe there is a better way to describe "other
> standards" or maybe not use "consumer" standards as a heading.  But, I
> definitely see some separation there.  Trying to nail down what it is, and
> could use your help!
>
> Thanks!
> George

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

Re: [Discuss-gnuradio] Problem with OFDM Mod block

[Michael Dickens]

Hi Francisco - If you read through "gr-digital/python/ofdm.py" carefully (lines 
68:81), you'll find that the number of "occupied tones" cannot be more than 
4512 because of the way the known preamble symbols are pre-generated; feel free 
to regenerate these symbols to as many as you want, but make sure to use the 
new symbols on both the Tx and Rx for proper transmission.  There is no check 
for this value, and the Python script will set the resulting preamble to length 
4512 when the number of occupied tones is greater than 4512.  So, even if you 
set in GRC to not use preambles, one is always created through the known 
symbols.  It wouldn't be too difficult to tweak this Python script to properly 
expand the known symbols' part of the preamble to be of the correct length; 
please feel free to do this tweaking & submit a patch.  Good luck. - MLD

On Jul 16, 2012, at 4:17 AM, frankist wrote:

> Thanks for the response. I am using the GRC and I let the preamble size=0.
> When I use a lower number of occupied tones this error doesn't occur.
> However if I used the values specified in the first post that message
> appears


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

Re: [Discuss-gnuradio] Questions about OOK mod and demod

[Brian Padalino]

On Wed, Jul 18, 2012 at 2:49 PM, lliao003  wrote:
>
> Hi all!
>
> I am a rookie and I am working about OOK mod and demod. I have few questions
> following:
>
> I modify the digital_constellation.cc file as
>
> d_constellation[0]=gr_complex(0,0)
> d_constellation[0]=gr_complex(1,0)
>
> like this, I think after re-make, I already achieve OOK mod. However, in
> order to build ook demod, I modify as following:
>
> return (real(*sample)>0.5)

You really want that to be the magnitude of the sample, not just the
real portion.  If you wanted to avoid the sqrt, magnitude squared can
probably work as well.

> I also embed OOK mod and demod into GRC and try to simulation in GRC whose
> flow graph is
> File Source->packet Encoder->OOk mod->Channel Model->Throttle->OOk
> demod->Packet decoder->File sink.
> If there is no noise in channel model, ook mod and demod work perfect, but
> if there is any noise, I can not receive any file.
>
> Anyone can tell me if I did wrong in modifying the code or there are still
> something I need to modify. Thank you for time and help very much!

Are you filtering your demodulated OOK signal afterwards?  Beforehand?
 How many samples/symbol are you running?

So many questions!  Good luck!

Brian

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

[Discuss-gnuradio] Questions about OOK mod and demod

[lliao003]

Hi all!

I am a rookie and I am working about OOK mod and demod. I have few questions
following:

I modify the digital_constellation.cc file as

d_constellation[0]=gr_complex(0,0)
d_constellation[0]=gr_complex(1,0)

like this, I think after re-make, I already achieve OOK mod. However, in
order to build ook demod, I modify as following:

return (real(*sample)>0.5)

I also embed OOK mod and demod into GRC and try to simulation in GRC whose
flow graph is 
File Source->packet Encoder->OOk mod->Channel Model->Throttle->OOk
demod->Packet decoder->File sink. 
If there is no noise in channel model, ook mod and demod work perfect, but
if there is any noise, I can not receive any file.

Anyone can tell me if I did wrong in modifying the code or there are still
something I need to modify. Thank you for time and help very much!

Linchao
-- 
View this message in context: 
http://old.nabble.com/Questions-about-OOK-mod-and-demod-tp34180717p34180717.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] Creating a signal source block using Python

[Anisha Gorur]

Hello All,

I've been attempting to create my own source block in Python. I have been
reading the blocks coding guide here:
https://github.com/guruofquality/grextras/wiki/Blocks-Coding-Guide#wiki-work-operation-modes,
but so far my source only outputs zeros.
An outline of my code is as follows:

class constSource(gr.block):
def __init__(self):
 gr.block.__init__(self, name = "signal source", in_sig =
None,out_sig = [numpy.complex64])

def work(self, input_items, output_items):
   num_output_items = len(output_items[0])

 #I put the code to create what I want to stream here, the code
creates a numpy.complex64 array with a length of 32. I then return
num_output_items
  return num_output_items

I then write my constSource block to a file and I try to see the output of
the file using a scope sink, but it is just a constant stream of zeros. Am
I missing a key part of creating a source block? Also, the reason I don't
use a file source is that the stream I am trying to create is dependent
upon the time of day, so pulling it from a file source will mean that it is
delayed somewhat. I will eventually want to transmit this data as well, not
just put it in a file sink.

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

Re: [Discuss-gnuradio] Porting cgran AIS to the new cmake build system

[Nick Foster]

Take a look at gr-air-modes for details on how I did it there. gr-osmosdr
follows the UHD API for the most part, so a lot of it drops in pretty
easily. I'm not going to pull in a patch which makes the receiver depend on
gr-osmosdr, but I'm happy to have a command-line option (or even
autodetect) for gr-osmosdr support for FCD and RTL.

I haven't tried AIS on RTL at all, and I expect there to be some
filtering/LO offset tuning required to achieve decent results on it.

--n

On Wed, Jul 18, 2012 at 2:49 AM, Christian Gagneraud wrote:

> On 18/07/12 09:13, Darren Long wrote:
>
>> Hi Chris,
>>
>> Might I be so bold to suggest that in your efforts, you consider using
>> the gr-osmosdr abstraction 
>> (http://sdr.osmocom.org/trac/**wiki/GrOsmoSDR
>> )
>> so that the RTL-SDR could be used too. In fact it supports  UHD, FCD and
>> RTL-SDR, and works well in gqrx for example.
>>
>
> Hi,
>
> That sounds interesting, actually, that was on my plan to try the RTL
> hardware once I'm happy enough. If i'm not wrong this RTL is the related to
> the chip found on some cheap DVB receiver, isn't it?
>
> AFAIU, the ais_rx.py script is half about setting up UHD, and half about
> the decoding itself.
> I just had a look at gr-osmosdr, and it seems so far quite straight
> forward to use.
>
> Nick has just updated his git repo with the cmake branch. I'll give it a
> try tonight.
>
> Nick, do you have any thought on this? It would be really nice to get
> ais_rx.py be usable with different hardware.
>
> Chris
>
>
>
>> Sorry for being cheeky :P
>>
>
> You wasn't, it sounds like a good idea indeed!
>
> Chris
>
>
>
>> Darren
>>
>> On 17/07/12 22:43, Christian Gagneraud wrote:
>>
>>> On 17/07/12 22:24, Nick Foster wrote:
>>>
 Christian,

 Are you using the version found here?

 https://github.com/bistromath/**gr-ais

 If not, please use this version, as it is significantly more up-to-date
 than the one on CGRAN. I'm going to change the CGRAN page to point to
 the Github repository.

>>>
>>> Interesting.
>>>
>>> Would you be interested in getting it ported to the new build system?
>>> If so, I'll redo the work on your tree.
>>> As well, I realised that ais_received.py is tailored for the USRP.
>>> I'm currently using a funcube dongle, so I might as well contribute
>>> with a dedicated script, once i start to get things working.
>>>
>>> Chris
>>>
>>>
>>>
 --n

 On Tue, Jul 17, 2012 at 1:42 PM, Christian Gagneraud <
 ch...@techworks.ie
 > wrote:

  On 17/07/12 21:31, Josh Blum wrote:



  On 07/17/2012 01:27 PM, Christian Gagneraud wrote:

  Hi,

  I tried to build https://cgran.org/wiki/AIS against
  gnuradio-3.6, and i
  fails.
  As 3.6 brings in a new build system, I decided to give it a
  go on the
  AIS module. I based everything on gr-howto-write-a-block

  [...]

  ImportError:
  /usr/local/lib/python2.7/site-**
 __packages/ais/_ais_swig.so:
  undefined symbol: _Z14ais_make_shiftv


  Just a guess, but

  In gnuradio we explicitly export the library symbols. If you
  arent doing
  that for libgnuradioais, make sure that the visibility flag is
  being set
  to default. You can read more here:
  
 http://gcc.gnu.org/wiki/__**Visibility
  
 
 >


  Hi Josh,

  Actually, I've just discovered this was needed! So, yes that was
 it.
  No it's complaining about usrp stuff, but it's another story. I
  don't have a USRP, I'm using a FUNcube dongle.

  BTW, should I make this package install in
  lib/python2.7/site-packages/__**gnuradio/ais instead of
  lib/python2.7/site-packages/__**ais
  Same with the include dir: include/gnuradio/ais instead of
 include/ais?

  I would like to be able to use gnuradio-companion, and pick up the
  AIS block from the selection list, but it's not there. This might
 be
  due to the current install dir. Any comment?

  Chris





  -josh

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

Re: [Discuss-gnuradio] OpenSUSE 11.2

[Christian Gagneraud]

On 18/07/12 17:42, mle...@ripnet.com wrote:

Anyone here running the latest Gnu Radio GIT code on OpenSUSE 11.2, with
a working recipe to make it build (pre-reqs, etc)??


As you, I tried and failed. I ended up using the hamradio repo from 
their OBS.


Let me know if you manage to build everything.

Chris



-Marcus



This body part will be downloaded on demand.




--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



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

[Discuss-gnuradio] OpenSUSE 11.2

[mleech]

 

Anyone here running the latest Gnu Radio GIT code on OpenSUSE 11.2,
with a working recipe to make it build (pre-reqs, etc)?? 

-Marcus 

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

Re: [Discuss-gnuradio] as I can calculate the attenuation in the usrp2 ?

[Ryan Wolfarth]

Hi Julio,

You are simply not giving enough information for us to help you
effectively.  Please include more details about your USRP2 setup
(daughterboard, host specifications, etc).

Regards,
Ryan


On Wed, Jul 18, 2012 at 9:56 AM, Julio Hector Aguilar Renteria <
jhagui...@gmail.com> wrote:

> Hi, all
>
> as I can calculate the attenuation in the usrp2 ?
>
> ___
> 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] as I can calculate the attenuation in the usrp2 ?

[Julio Hector Aguilar Renteria]

Hi, all

as I can calculate the attenuation in the usrp2 ?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Porting cgran AIS to the new cmake build system

[Christian Gagneraud]

On 18/07/12 09:13, Darren Long wrote:

Hi Chris,

Might I be so bold to suggest that in your efforts, you consider using
the gr-osmosdr abstraction (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR)
so that the RTL-SDR could be used too. In fact it supports  UHD, FCD and
RTL-SDR, and works well in gqrx for example.


Hi,

That sounds interesting, actually, that was on my plan to try the RTL 
hardware once I'm happy enough. If i'm not wrong this RTL is the related 
to the chip found on some cheap DVB receiver, isn't it?


AFAIU, the ais_rx.py script is half about setting up UHD, and half about 
the decoding itself.
I just had a look at gr-osmosdr, and it seems so far quite straight 
forward to use.


Nick has just updated his git repo with the cmake branch. I'll give it a 
try tonight.


Nick, do you have any thought on this? It would be really nice to get 
ais_rx.py be usable with different hardware.


Chris



Sorry for being cheeky :P


You wasn't, it sounds like a good idea indeed!

Chris



Darren

On 17/07/12 22:43, Christian Gagneraud wrote:

On 17/07/12 22:24, Nick Foster wrote:

Christian,

Are you using the version found here?

https://github.com/bistromath/gr-ais

If not, please use this version, as it is significantly more up-to-date
than the one on CGRAN. I'm going to change the CGRAN page to point to
the Github repository.


Interesting.

Would you be interested in getting it ported to the new build system?
If so, I'll redo the work on your tree.
As well, I realised that ais_received.py is tailored for the USRP.
I'm currently using a funcube dongle, so I might as well contribute
with a dedicated script, once i start to get things working.

Chris




--n

On Tue, Jul 17, 2012 at 1:42 PM, Christian Gagneraud mailto:ch...@techworks.ie>> wrote:

 On 17/07/12 21:31, Josh Blum wrote:



 On 07/17/2012 01:27 PM, Christian Gagneraud wrote:

 Hi,

 I tried to build https://cgran.org/wiki/AIS against
 gnuradio-3.6, and i
 fails.
 As 3.6 brings in a new build system, I decided to give it a
 go on the
 AIS module. I based everything on gr-howto-write-a-block

 [...]

 ImportError:
 /usr/local/lib/python2.7/site-__packages/ais/_ais_swig.so:
 undefined symbol: _Z14ais_make_shiftv


 Just a guess, but

 In gnuradio we explicitly export the library symbols. If you
 arent doing
 that for libgnuradioais, make sure that the visibility flag is
 being set
 to default. You can read more here:
 http://gcc.gnu.org/wiki/__Visibility
 


 Hi Josh,

 Actually, I've just discovered this was needed! So, yes that was it.
 No it's complaining about usrp stuff, but it's another story. I
 don't have a USRP, I'm using a FUNcube dongle.

 BTW, should I make this package install in
 lib/python2.7/site-packages/__gnuradio/ais instead of
 lib/python2.7/site-packages/__ais
 Same with the include dir: include/gnuradio/ais instead of
include/ais?

 I would like to be able to use gnuradio-companion, and pick up the
 AIS block from the selection list, but it's not there. This might be
 due to the current install dir. Any comment?

 Chris





 -josh

 _
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
 



 --
 Christian Gagneraud,
 Embedded systems engineer.
 Techworks Marine
 1 Harbour road
 Dun Laoghaire
 Co. Dublin
 Ireland
 Tel: + 353 (0) 1 236 5990 
 Web: http://www.techworks.ie/



 _
 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




--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/



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

Re: [Discuss-gnuradio] [USRP-users] Gnu Radio apps freezes (locks up)

[Nazmul Islam]

Hello Rickard,

Could you get a permanent or working solution of your problem? I think that
I am facing a similar issue as you did.

In my application, the receiver USRP senses the channel in a repeated
on-off manner. The receiver USRP run for 200 msec, gathers the complex data
in some files, does some processing, plots the data and waits for my input.
As I press a button, the USRP starts again and repeats the whole
process. The problem is: if I run the code at a very high rate (20 MS/s
with 32 bit/complex sample), sometimes the application freezes up or hangs
without giving any error. Currently, this happens within 15-20 starts. This
problem occurs less frequently if I run it at lower sampling rates (e.g. 2
MS/s).

I am using USRP N210, the latest GNUradio & UHD drivers, Ubuntu 12.04. I
believe that my issues are quite similar to the ones that you faced. It
would be great to know if you found a (somewhat) working solution.

Thanks,

Nazmul

On Fri, Apr 13, 2012 at 10:59 AM, Rickard Radio wrote:

> On Apr 10, 2012, at 11:55 PM, Nick Foster wrote:
>
> On Tue, Apr 10, 2012 at 1:16 PM, Rickard  wrote:
>
>>
>> On 31 mar 2012, at 15.43, Tom Rondeau wrote:
>>
>> > On Thu, Mar 29, 2012 at 6:04 AM, Rickard Radio 
>> wrote:
>> >>
>> >> On Mar 29, 2012, at 3:26 AM, Tom Rondeau wrote:
>> >>
>> >>> On Wed, Mar 28, 2012 at 10:02 AM, Rickard Radio <
>> rickardra...@gmail.com> wrote:
>>  Hi list,
>> 
>>  After I upgraded to latest Gnu Radio 3.5.2, and latest UHD (and
>> images), GR applications just freeze when running. No warnings, error
>> messages or overflows etc. Just freeze.
>>  A simple FFT plot directly on received samples from the USRPN210
>> just freezes after some seconds, or minutes (depending on the sample rate),
>> although the load on the machine is not high. Need to kill GR-app and
>> restart it, with the same problem occurring again.
>> 
>>  This has never been a problem with earlier versions of GR/UHD, from
>> about 6 months ago.
>>  The freezing happens quicker with high sample rate setting but also
>> with lower, eventually. No overflows happen (which was possible to get
>> before with too high sample rates or load, etc.)
>> 
>>  The USRPN210 stops sending samples to the computer at the same
>> moment as GnuRadio freezes (as observed on the system monitor).
>> 
>>  Same thing happen on two identical laptops running Ubuntu 10.10
>> (also upgraded it from 10.04). Not sure if its a strict GnuRadio problem
>> (since it worked before), UHD, or some problem with the Ubuntu Linux 10.10.
>> It work(ed) flawlessly with another machine on OSX (before I tried to
>> upgrade GR on it but then got stuck...) with identical UHD version and
>> images.
>> 
>>  Installation of UHD+GnuRadio with the automatic linux script runs
>> without any problems, as before, no errors or warnings.
>> 
>>  Any de-freezing help or clues appreciated!
>> 
>>  Rickard
>> >>>
>> >>> Rickard,
>> >>>
>> >>> Just to be clear. When you install 3.5.2 from the tarball, it freezes.
>> >>> When you use the build-gnuradio, everything works fine?
>> >>>
>> >>> What's your machine?
>> >>>
>> >>> Tom
>> >>
>> >> Tom,
>> >>
>> >> The installation with build-gnuradio script works just fine, as before
>> (no tarballs).
>> >> Same result on both laptops, Acer Aspire TimelineX with i3 processors
>> (2.26 GHz),  running Ubuntu 10.10.
>> >> I did not have this problem earlier with Ubuntu 10.04. Or on a Mac
>> with OS X (with the source from git).  Could Ubuntu 10.10 cause the problem
>> somehow?
>> >>
>> >> Note: Halting/freezing only happens when running an application (with
>> the N210) as a receiver. (Not transmitter, see below.)
>> >> The flow of receiving samples just halts after a while and the
>> application freezes/halts (as a consequence).
>> >> This happen sooner with high sampling rate (after a few seconds with
>> 25MSPS), but eventually also with a bit lower sample rates. The CPU's are
>> not overwhelmed (< 50%).
>> >> It happens even if the UHD usrp source is connected directly to a null
>> sink only. I do not get any overflows before the halt.
>> >> In fact, I cannot even provoke a continuos stream of overflows since
>> the reception just halts instead of producing overflows, which was the
>> result earlier.
>> >>  GnuRadio itself does not freeze as a whole (like the grc in the
>> background), just the running application, which I then need to abort.
>> >>
>> >> Strangely enough, this "freezing/halting" does NOT happen when
>> transmitting, correspondingly, even with high transmit sample rates such as
>> 25 MSPS (or now possible even with 50MSPS with 8 bit/samples!). Then it
>> works just fine - even without underruns (when using just a file source).
>> >>
>> >>
>> >> / Rickard
>> >
>> >
>> > Rickard,
>> >
>> > Thanks for the data. Unfortunately, I have no idea what to make of
>> > this. There isn't that much difference between the last release
>> > (3.5.2.1) and what you get u

Re: [Discuss-gnuradio] Porting cgran AIS to the new cmake build system

[Darren Long]

Hi Chris,

Might I be so bold to suggest that in your efforts, you consider using
the gr-osmosdr abstraction (http://sdr.osmocom.org/trac/wiki/GrOsmoSDR)
so that the RTL-SDR could be used too. In fact it supports  UHD, FCD and
RTL-SDR, and works well in gqrx for example.

Sorry for being cheeky :P

Darren

On 17/07/12 22:43, Christian Gagneraud wrote:
> On 17/07/12 22:24, Nick Foster wrote:
>> Christian,
>>
>> Are you using the version found here?
>>
>> https://github.com/bistromath/gr-ais
>>
>> If not, please use this version, as it is significantly more up-to-date
>> than the one on CGRAN. I'm going to change the CGRAN page to point to
>> the Github repository.
>
> Interesting.
>
> Would you be interested in getting it ported to the new build system?
> If so, I'll redo the work on your tree.
> As well, I realised that ais_received.py is tailored for the USRP.
> I'm currently using a funcube dongle, so I might as well contribute
> with a dedicated script, once i start to get things working.
>
> Chris
>
>
>>
>> --n
>>
>> On Tue, Jul 17, 2012 at 1:42 PM, Christian Gagneraud > > wrote:
>>
>> On 17/07/12 21:31, Josh Blum wrote:
>>
>>
>>
>> On 07/17/2012 01:27 PM, Christian Gagneraud wrote:
>>
>> Hi,
>>
>> I tried to build https://cgran.org/wiki/AIS against
>> gnuradio-3.6, and i
>> fails.
>> As 3.6 brings in a new build system, I decided to give it a
>> go on the
>> AIS module. I based everything on gr-howto-write-a-block
>>
>> [...]
>>
>> ImportError:
>> /usr/local/lib/python2.7/site-__packages/ais/_ais_swig.so:
>> undefined symbol: _Z14ais_make_shiftv
>>
>>
>> Just a guess, but
>>
>> In gnuradio we explicitly export the library symbols. If you
>> arent doing
>> that for libgnuradioais, make sure that the visibility flag is
>> being set
>> to default. You can read more here:
>> http://gcc.gnu.org/wiki/__Visibility
>> 
>>
>>
>> Hi Josh,
>>
>> Actually, I've just discovered this was needed! So, yes that was it.
>> No it's complaining about usrp stuff, but it's another story. I
>> don't have a USRP, I'm using a FUNcube dongle.
>>
>> BTW, should I make this package install in
>> lib/python2.7/site-packages/__gnuradio/ais instead of
>> lib/python2.7/site-packages/__ais
>> Same with the include dir: include/gnuradio/ais instead of
>> include/ais?
>>
>> I would like to be able to use gnuradio-companion, and pick up the
>> AIS block from the selection list, but it's not there. This might be
>> due to the current install dir. Any comment?
>>
>> Chris
>>
>>
>>
>>
>>
>> -josh
>>
>> _
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
>> 
>>
>>
>>
>> --
>> Christian Gagneraud,
>> Embedded systems engineer.
>> Techworks Marine
>> 1 Harbour road
>> Dun Laoghaire
>> Co. Dublin
>> Ireland
>> Tel: + 353 (0) 1 236 5990 
>> Web: http://www.techworks.ie/
>>
>>
>>
>> _
>> 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