[Discuss-gnuradio] Time controlling block

[Sandhya G]

Hi,
Today i got a idea about implementing three different modulations on
single message signal. But i want the modulations to happen after certain
time has searched (can say exactly like counter). which is the block in GNU
Radio that i can use has a counter.


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

[Discuss-gnuradio] gr-ieee802-11: connecting two usrp devices

[Nasi]

 Dear All,

I need your help. May be someone did it before:

I use 'IEEE 802.11 a/g/p OFDM Transceiver' project, Ubuntu 13.04, GNURADIO 3.7.

I start the transmission using the first laptop and USRP N200 device by running 
the ./ofdm_tx.py.
It is transmitting; 

Meanwhile I use the second laptop and USRP N200 device as the receiver by 
running the ./ofdm_rx.py.
I activated the ofdm_decode_mac debuging function to see the messages.

The problem is that all frames are dropped. The copy paste of the terminal is 
below:
SHORT Frame!
SHORT copied 1039
Decode MAC: input 7
Decode MAC: frame start -- len 153 symbols 7 encoding 6
received complete frame - decoding
coding rate 0.67
2016
80 1f 3a c7 6f b6 fb 4e 7a 24 e8 6d 23 bb 44 a2 
60 24 21 26 93 3e d8 98 e0 df 0f 0f 8a ba 3c d2 
a5 a4 68 13 71 e8 56 bd ec 4c 79 ea 5a 9b 7d e0 
1a ae 3b 3d 8c 68 93 7c b6 ca 3b 08 33 70 73 78 
6c 23 47 a2 9d 01 e4 e0 3e 73 6a 84 8f fb 23 a8 
01 fa 13 40 6e 62 96 3d 53 76 f6 09 2d fe 4e bd 
3e cc 79 97 71 e3 22 1c c7 54 5c 36 5f 50 24 fb 
2f f3 41 0f 1e a7 30 c2 9d 71 cc 66 b5 8f 9f 97 
94 ba f4 b9 48 27 28 f6 c8 d9 b4 81 75 56 f3 43 
f8 98 9d 5d a8 aa 1a 49 85 1a 22 fc 70 e2 20 d1 
48 6d 6a 8c 26 c3 ae 
..:.o..Nz$.m#.D.`$!&.><...h.q.V..Ly.Z.}...;=.h.|..;.3psxl#G.>sj...#@nb.=Sv..-.N.>.y.q."..T\6_P$./.A...0..q.fH'(.uV.C...]...I..".p.
 .Hmj.&..
Checksum wrong -- dropping
  Do you know what can cause this?

Thanks in advance!

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

[Discuss-gnuradio] LTE framework receiver gr-lte

[Baier]

Hi,

I tried to compile gr-lte package from github (version 3.7 not master), 
but it doesnt't work. GRUEL and GNURADIO_CORE have been still there.
I removed GRUEL and replaced GNURADI_CORE with GNURADIO_RUNTIME,but it 
is still not working. Has somebody experience with this package?

Thanks!
A. Baier


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

Re: [Discuss-gnuradio] LTE framework receiver gr-lte

[Ralph A. Schmid, dk5ras]

Hi.

> Hi,
> 
> I tried to compile gr-lte package from github (version 3.7 not master),
but it

I guess this package needs gr 3.6...

> doesnt't work. GRUEL and GNURADIO_CORE have been still there.


> A. Baier

Ralph.



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

Re: [Discuss-gnuradio] Performance of 3.7

[Dirk Van Bruggen]

Thanks Steve.

I ran volk_profile and the performance seemed to improve a bit.  That is,
CPU usage increased to 700% using many more cores of the processor.
 However, I still see buffers filling up and taking longer than realtime to
process.  In 3.6 the benchmark_rx program could keep up at 5MHz and process
data in real time.

Regards,

Dirk


On Tue, Nov 26, 2013 at 8:39 PM, Steve Glass  wrote:

> Hi Dirk,
>
> You maybe comparing apples with oranges. The live CD will be built to take
> into account a pretty ordinary CPU (all that stuff in volk is about
> optimizing for your CPU) and will probably not be making best use of your
> nice, shiny, i7. Try building 3.7 on your machine and compare the 3.6 you
> build to the 3.7 you build. I suspect that 3.7 will perform a good deal
> better.
>
> ATB
>
> Steve
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] LTE framework receiver gr-lte

[Johannes Demel]

Hi,

on branch gr37 there are 2 directories with code. The 'code' directory
contains GR 3.6 blocks for reference and gr37-lte contains the new 3.7 API
blocks. 3.6 API blocks will eventually be removed as soon as it seems fit.

Happy hacking
Johannes


On Mon, Dec 2, 2013 at 5:18 AM, Ralph A. Schmid, dk5ras wrote:

> Hi.
>
> > Hi,
> >
> > I tried to compile gr-lte package from github (version 3.7 not master),
> but it
>
> I guess this package needs gr 3.6...
>
> > doesnt't work. GRUEL and GNURADIO_CORE have been still there.
>
>
> > A. Baier
>
> Ralph.
>
>
>
> ___
> 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] Status of GNU Radio with OSX 10.9

[Arturo Rinaldi]

Nella citazione in data Wed Nov 20 00:50:52 2013, Michael Dickens ha 
scritto:

Earlier today I pushed r113561 to MacPorts < 
https://trac.macports.org/changeset/113561 > which should allow pretty much any 
compiler should work on 10.8 or 10.9 (and, likely, any other OSX version) to build 
any version of gnuradio (legacy, release, devel, next). If your build is broken, 
please try:
{{{
sudo port clean gnuradio gnuradio-devel
sudo port -f -p uninstall gnuradio gnuradio-devel
sudo port selfupdate
sudo port install gnuradio-devel
}}}
and then see if the dial_tone works; see if gnuradio-companion works.  Compared 
with previous fixes, this one seems to work across the board.  So please give 
this change a try if you're using GNU Radio on OSX via MacPorts.  Enjoy! - MLD

ps> The issue, as has been the case before, comes down the compiling VOLK.  This time, 
the problem is that Apple's clang is some version of 3.3, which has issues with the 
cvtpi32_ps intrinsic on ACX.  Clang 3.4 has the fixes for this intrinsic.  So ... long story 
short is that in MacPorts only, I patch volk/lib/CMakeLists.txt to test for not just xgetbv 
but also for cvtpi32_ps.  I'm not sure it is important to include this patch within GNU 
Radio proper, but it does specify "if (APPLE)" to it could be done.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Hi folks, can you give some good news about the building from source of 
the gnuradio tarball ? As I previously said, i need to work with 
gnuradio 3.6.5.1 and above.


Kind Regards,

   Arturo

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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

Hi Arturo - GNU Radio 3.6.5.1 should now work within MacPorts; I've tested on 
10.8 and 10.9, but the fixes should be backward compatible to at least 10.6, 
maybe 10.5.  All of the GNU Radio ports should work right now within MacPorts.  
If you want to build these from source outside MacPorts, I'd advise to pretty 
much follow what the Portfile does including needed patches.  For example, to 
get SWIG working on 10.9 you have to copy the whole swig/std directory to a 
place where SWIG files will be looked for, then patch the correct files in the 
copy.  Hope this helps! - MLD

On Dec 2, 2013, at 1:30 PM, Arturo Rinaldi  wrote:
> Hi folks, can you give some good news about the building from source of the 
> gnuradio tarball ? As I previously said, i need to work with gnuradio 3.6.5.1 
> and above.

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

Re: [Discuss-gnuradio] Time controlling block

[Wayne Roberts]

you could keep a class variable which is added to every time work() is
called, adding to it each time the value of noutput_items or
input_items.size().

Its also useful to know the scheduler, because it feeds work() an arbitrary
number of samples each time.
There is a presentation on gnuradio scheduler.


On Mon, Dec 2, 2013 at 1:07 AM, Sandhya G  wrote:

> Hi,
> Today i got a idea about implementing three different modulations on
> single message signal. But i want the modulations to happen after certain
> time has searched (can say exactly like counter). which is the block in GNU
> Radio that i can use has a counter.
>
>
> Thanks and regards,
> Sandhya
>
> ___
> 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] Status of GNU Radio with OSX 10.9

[Arturo Rinaldi]

Nella citazione in data Mon Dec  2 19:42:56 2013, Michael Dickens ha 
scritto:

Hi Arturo - GNU Radio 3.6.5.1 should now work within MacPorts; I've tested on 
10.8 and 10.9, but the fixes should be backward compatible to at least 10.6, 
maybe 10.5.  All of the GNU Radio ports should work right now within MacPorts.  
If you want to build these from source outside MacPorts, I'd advise to pretty 
much follow what the Portfile does including needed patches.  For example, to 
get SWIG working on 10.9 you have to copy the whole swig/std directory to a 
place where SWIG files will be looked for, then patch the correct files in the 
copy.  Hope this helps! - MLD

On Dec 2, 2013, at 1:30 PM, Arturo Rinaldi  wrote:

Hi folks, can you give some good news about the building from source of the 
gnuradio tarball ? As I previously said, i need to work with gnuradio 3.6.5.1 
and above.





Thank you again Michael, I was wondering If I could redirect the 
installation path of the port to


/usr/local/lib/python2.7/site-packages

instead of

/opt/local/lib/python2.7/site-packages

would this be possible or not ? Basically, it's what I really need to 
install custom gnuradio modules without messing with the "/opt/local" 
root path. This will totally cancel my need to perform a building from 
tarball.


Regards again,

Arturo

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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

I think you should be able to have GNU Radio installed into /opt/local but then 
you create an OOT module which installs into /usr/local .  I used to do this 
"way back in the day"; I would assume it still works. Maybe you can send me 
off-list more info on what you're trying to do and I can point you in the right 
directions?

I think you could probably copy the files from 
/opt/local/lib/python2.7/site-packages into 
/usr/local/lib/python2.7/site-packages and they would probably work about 
right.  No guarantees though, since some libraries might be linked against 
other libraries already in /opt/local somewhere.  But, it's worth a try IMHO 
... - MLD

On Dec 2, 2013, at 1:52 PM, Arturo Rinaldi  wrote:

> Thank you again Michael, I was wondering If I could redirect the installation 
> path of the port to
> 
> /usr/local/lib/python2.7/site-packages
> 
> instead of
> 
> /opt/local/lib/python2.7/site-packages
> 
> would this be possible or not ? Basically, it's what I really need to install 
> custom gnuradio modules without messing with the "/opt/local" root path. This 
> will totally cancel my need to perform a building from tarball.


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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Arturo Rinaldi]

Nella citazione in data Mon Dec  2 20:03:22 2013, Michael Dickens ha 
scritto:

I think you should be able to have GNU Radio installed into /opt/local but then you 
create an OOT module which installs into /usr/local .  I used to do this "way back 
in the day"; I would assume it still works. Maybe you can send me off-list more info 
on what you're trying to do and I can point you in the right directions?

I think you could probably copy the files from 
/opt/local/lib/python2.7/site-packages into 
/usr/local/lib/python2.7/site-packages and they would probably work about 
right.  No guarantees though, since some libraries might be linked against 
other libraries already in /opt/local somewhere.  But, it's worth a try IMHO 
... - MLD

On Dec 2, 2013, at 1:52 PM, Arturo Rinaldi  wrote:


Thank you again Michael, I was wondering If I could redirect the installation 
path of the port to

/usr/local/lib/python2.7/site-packages

instead of

/opt/local/lib/python2.7/site-packages

would this be possible or not ? Basically, it's what I really need to install custom 
gnuradio modules without messing with the "/opt/local" root path. This will 
totally cancel my need to perform a building from tarball.






mmm I see.ok let's do it this way. Let's say that i untar the 
3.6.5.1 tarball and write a script that patches all the needed files 
before running the usual steps of configuration.


If I have understood well what I have to do I need to use all the 8 
diff files you uploaded on the macports server, join them and apply the 
result to the extracted tarball directory. I can try that with


patch --dry-run

to find if the patching is properly perfromed and the files are not 
affected by patching. Now i have to figure out which are the right diff 
files to patch the legacy version and the new version since I'm 
noticing that the source path structure is different in the new 
tarball. Do I have to use all of them or not ? Can i write just one 
single diff file to apply before building from source as usual ? I was 
thinlking thah once the work is finished i could post it on the mailing 
list so it'd be available for everyone.let me know if you like the 
idea.


Regards, Arturo



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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

Hi Arturo - You don't need all 8 diff files.  If you read through the Portfile 
for GNU Radio, you'll find that you need just 5 of those patches to build 
3.6.5.1 on 10.9; if you want to build on 10.8, you need just 3.

Needed for 10.8 and 10.9 (and, likely, 10.7 or earlier):

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

Needed just for 10.9/libc++:

patch-gnuradio-core_swig_std_std_container.i.diff
patch-gnuradio-core_swig_include-std_string.i.diff

If you use those patches on your OOT build of GNU Radio, you should be able to 
build it with minimal defines added to the cmake command line. - MLD

On Dec 2, 2013, at 2:23 PM, Arturo Rinaldi  wrote:
> mmm I see.ok let's do it this way. Let's say that i untar the 3.6.5.1 
> tarball and write a script that patches all the needed files before running 
> the usual steps of configuration.
> 
> If I have understood well what I have to do I need to use all the 8 diff 
> files you uploaded on the macports server, join them and apply the result to 
> the extracted tarball directory. I can try that with
> 
> patch --dry-run
> 
> to find if the patching is properly perfromed and the files are not affected 
> by patching. Now i have to figure out which are the right diff files to patch 
> the legacy version and the new version since I'm noticing that the source 
> path structure is different in the new tarball. Do I have to use all of them 
> or not ? Can i write just one single diff file to apply before building from 
> source as usual ? I was thinlking thah once the work is finished i could post 
> it on the mailing list so it'd be available for everyone.let me know if 
> you like the idea.


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

Re: [Discuss-gnuradio] Volk machine

[Paul B. Huter]

I finally got around to trying writing to RAM, and the result is worse - my
replay FFT is static.

I am trying to record a chunk of spectrum (in this case the shortwave
chunk, 0-30MHz) and then go back and look at small pieces to find my
specific data. If someone can provide insight into how to do this, I would
appreciate it.

Thank you all for all the assistance to date.

Paul B. Huter
On Nov 25, 2013 9:38 AM, "West, Nathan"  wrote:

> I agree with Nick: that VOLK stuff is all expected behavior. If you're
> trying to write to a file at high rates you should look in to using a
> ramdisk/tmpfs. You'll be limited by how much RAM you have rather than
> IO speed.
>
> However, based on your other threads I wonder if you've taken Tom's
> recent suggestion to just lower your input sampling rate? If you're
> only interested in ~1MHz bandwidth you shouldn't be sampling at 50
> MHz.
>
> -nathan
>
> On Mon, Nov 25, 2013 at 12:08 AM, Nick Foster 
> wrote:
> > Your file sink only records a few seconds of data because your hard drive
> > can't keep up, not because of any problem with Volk. The Volk machine
> being
> > used does not indicate which particular architecture is used for each
> kernel
> > -- that isn't printed at runtime.
> >
> > --n
> >
> > On Nov 24, 2013 9:58 PM, "Paul B. Huter"  wrote:
> >>
> >> When running with a USRP source at 25M and a low pass filter down to
> >> 10MHz, I get something saying "Using Volk machine: sse4_a_64", and my
> file
> >> sink only records a couple seconds of data. I ran the volk_profile
> script,
> >> but still get the same result. The script returned something other than
> >> "sse4_a_64" as the best volk to use. My GNU Radio seems to have trouble
> >> reading configuration files, so is there a way to manually point to the
> volk
> >> parameter to use when I load GNU Radio?
> >>
> >> Paul B. Huter
> >>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Go-back is possible?

[Raydel Abreu (CM2ESP)]

Hello,

Is it possible to go back and convert a Python GNU Radio code back into the
GRC Flow Graph from which it was generated?

Cheers,

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

Re: [Discuss-gnuradio] Go-back is possible?

[Marcus Leech]

There's no automatic mechanism for doing that.
 
on Dec 02, 2013, Raydel Abreu (CM2ESP)  wrote:



Hello,Is it possible to go back and convert a Python GNU Radio code back into the GRC Flow Graph from which it was generated?
Cheers,
Raydel, CM2ESP
___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] Volk machine

[Nick Foster]

Paul,

30MHz is a big chunk of data to be streaming to anything. A 4GB ramdisk
will be full in 30 seconds at this rate. Do you really not know *a
priori* where
in the whole 0-30MHz spectrum your signal will be?

I notice now in your first post that you're streaming 25Msps with a
low-pass filter to 10MHz -- if this is the case, why use a 25Msps rate in
the first place? You can make the USRP work for you by asking for 10Msps
(or less, if you know you need less bandwidth) -- it'll handle the
downsampling and filtering.

--n


On Mon, Dec 2, 2013 at 1:32 PM, Paul B. Huter wrote:

> I finally got around to trying writing to RAM, and the result is worse -
> my replay FFT is static.
>
> I am trying to record a chunk of spectrum (in this case the shortwave
> chunk, 0-30MHz) and then go back and look at small pieces to find my
> specific data. If someone can provide insight into how to do this, I would
> appreciate it.
>
> Thank you all for all the assistance to date.
>
> Paul B. Huter
> On Nov 25, 2013 9:38 AM, "West, Nathan" 
> wrote:
>
>> I agree with Nick: that VOLK stuff is all expected behavior. If you're
>> trying to write to a file at high rates you should look in to using a
>> ramdisk/tmpfs. You'll be limited by how much RAM you have rather than
>> IO speed.
>>
>> However, based on your other threads I wonder if you've taken Tom's
>> recent suggestion to just lower your input sampling rate? If you're
>> only interested in ~1MHz bandwidth you shouldn't be sampling at 50
>> MHz.
>>
>> -nathan
>>
>> On Mon, Nov 25, 2013 at 12:08 AM, Nick Foster 
>> wrote:
>> > Your file sink only records a few seconds of data because your hard
>> drive
>> > can't keep up, not because of any problem with Volk. The Volk machine
>> being
>> > used does not indicate which particular architecture is used for each
>> kernel
>> > -- that isn't printed at runtime.
>> >
>> > --n
>> >
>> > On Nov 24, 2013 9:58 PM, "Paul B. Huter" 
>> wrote:
>> >>
>> >> When running with a USRP source at 25M and a low pass filter down to
>> >> 10MHz, I get something saying "Using Volk machine: sse4_a_64", and my
>> file
>> >> sink only records a couple seconds of data. I ran the volk_profile
>> script,
>> >> but still get the same result. The script returned something other than
>> >> "sse4_a_64" as the best volk to use. My GNU Radio seems to have trouble
>> >> reading configuration files, so is there a way to manually point to
>> the volk
>> >> parameter to use when I load GNU Radio?
>> >>
>> >> Paul B. Huter
>> >>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Go-back is possible?

[Raydel Abreu (CM2ESP)]

Oh, that's bad, I guess I should use instead the old code-reading method

Raydel


2013/12/2 Marcus Leech 

> There's no automatic mechanism for doing that.
>
>
> on Dec 02, 2013, *Raydel Abreu (CM2ESP)*  wrote:
>
>  Hello,
>
> Is it possible to go back and convert a Python GNU Radio code back into
> the GRC Flow Graph from which it was generated?
>
> Cheers,
>
> Raydel, CM2ESP
>
> --
>
> ___
> 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] Go-back is possible?

[Marcus Leech]

Think of the Python that gets emitted by GRC as object code.  What you're asking is to convert said object code back into reasonable source code.
Such things exist for *actual* machine object-code, but, they produce damned-ugly results.
 
on Dec 02, 2013, Raydel Abreu (CM2ESP)  wrote:


Oh, that's bad, I guess I should use instead the old code-reading method
Raydel

2013/12/2 Marcus Leech 

There's no automatic mechanism for doing that.
 
on Dec 02, 2013, Raydel Abreu (CM2ESP)  wrote:



Hello,Is it possible to go back and convert a Python GNU Radio code back into the GRC Flow Graph from which it was generated?
Cheers,
Raydel, CM2ESP
___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] Volk machine

[Paul B. Huter]

Nick:

I tried downsampling the 25MHz to 10, but still was not recording the whole
time I ran (about 10 seconds, with only a couple seconds of playback). That
was when I tried using a RAM disk, albeit at 50 downsampled to 30. I am
using the following for my disk:

mount -o size=1G -t tmpfs none /mnt/tmpfs

I then store my data file to /mnt/tmpfs

Am I doing that wrong? Or is there some other explanation for not storing
data (other than storage size)?

Again, all feedback and help is appreciated.

Nick Foster  wrote:

Paul,

30MHz is a big chunk of data to be streaming to anything. A 4GB ramdisk
will be full in 30 seconds at this rate. Do you really not know *a
priori* where
in the whole 0-30MHz spectrum your signal will be?

I notice now in your first post that you're streaming 25Msps with a
low-pass filter to 10MHz -- if this is the case, why use a 25Msps rate in
the first place? You can make the USRP work for you by asking for 10Msps
(or less, if you know you need less bandwidth) -- it'll handle the
downsampling and filtering.

--n


On Mon, Dec 2, 2013 at 1:32 PM, Paul B. Huter wrote:

> I finally got around to trying writing to RAM, and the result is worse -
> my replay FFT is static.
>
> I am trying to record a chunk of spectrum (in this case the shortwave
> chunk, 0-30MHz) and then go back and look at small pieces to find my
> specific data. If someone can provide insight into how to do this, I would
> appreciate it.
>
> Thank you all for all the assistance to date.
>
> Paul B. Huter
> On Nov 25, 2013 9:38 AM, "West, Nathan" 
> wrote:
>
>> I agree with Nick: that VOLK stuff is all expected behavior. If you're
>> trying to write to a file at high rates you should look in to using a
>> ramdisk/tmpfs. You'll be limited by how much RAM you have rather than
>> IO speed.
>>
>> However, based on your other threads I wonder if you've taken Tom's
>> recent suggestion to just lower your input sampling rate? If you're
>> only interested in ~1MHz bandwidth you shouldn't be sampling at 50
>> MHz.
>>
>> -nathan
>>
>> On Mon, Nov 25, 2013 at 12:08 AM, Nick Foster 
>> wrote:
>> > Your file sink only records a few seconds of data because your hard
>> drive
>> > can't keep up, not because of any problem with Volk. The Volk machine
>> being
>> > used does not indicate which particular architecture is used for each
>> kernel
>> > -- that isn't printed at runtime.
>> >
>> > --n
>> >
>> > On Nov 24, 2013 9:58 PM, "Paul B. Huter" 
>> wrote:
>> >>
>> >> When running with a USRP source at 25M and a low pass filter down to
>> >> 10MHz, I get something saying "Using Volk machine: sse4_a_64", and my
>> file
>> >> sink only records a couple seconds of data. I ran the volk_profile
>> script,
>> >> but still get the same result. The script returned something other than
>> >> "sse4_a_64" as the best volk to use. My GNU Radio seems to have trouble
>> >> reading configuration files, so is there a way to manually point to
>> the volk
>> >> parameter to use when I load GNU Radio?
>> >>
>> >> Paul B. Huter
>> >>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Volk machine

[Nick Foster]

What was the size of the recorded file on the RAM disk? Are you seeing "O"
indications (for overflow)?

--n


On Mon, Dec 2, 2013 at 1:59 PM, Paul B. Huter wrote:

> Nick:
>
> I tried downsampling the 25MHz to 10, but still was not recording the
> whole time I ran (about 10 seconds, with only a couple seconds of
> playback). That was when I tried using a RAM disk, albeit at 50 downsampled
> to 30. I am using the following for my disk:
>
> mount -o size=1G -t tmpfs none /mnt/tmpfs
>
> I then store my data file to /mnt/tmpfs
>
> Am I doing that wrong? Or is there some other explanation for not storing
> data (other than storage size)?
>
> Again, all feedback and help is appreciated.
>
> Nick Foster  wrote:
>
> Paul,
>
> 30MHz is a big chunk of data to be streaming to anything. A 4GB ramdisk
> will be full in 30 seconds at this rate. Do you really not know *a priori* 
> where
> in the whole 0-30MHz spectrum your signal will be?
>
> I notice now in your first post that you're streaming 25Msps with a
> low-pass filter to 10MHz -- if this is the case, why use a 25Msps rate in
> the first place? You can make the USRP work for you by asking for 10Msps
> (or less, if you know you need less bandwidth) -- it'll handle the
> downsampling and filtering.
>
> --n
>
>
> On Mon, Dec 2, 2013 at 1:32 PM, Paul B. Huter wrote:
>
>> I finally got around to trying writing to RAM, and the result is worse -
>> my replay FFT is static.
>>
>> I am trying to record a chunk of spectrum (in this case the shortwave
>> chunk, 0-30MHz) and then go back and look at small pieces to find my
>> specific data. If someone can provide insight into how to do this, I would
>> appreciate it.
>>
>> Thank you all for all the assistance to date.
>>
>> Paul B. Huter
>> On Nov 25, 2013 9:38 AM, "West, Nathan" 
>> wrote:
>>
>>> I agree with Nick: that VOLK stuff is all expected behavior. If you're
>>> trying to write to a file at high rates you should look in to using a
>>> ramdisk/tmpfs. You'll be limited by how much RAM you have rather than
>>> IO speed.
>>>
>>> However, based on your other threads I wonder if you've taken Tom's
>>> recent suggestion to just lower your input sampling rate? If you're
>>> only interested in ~1MHz bandwidth you shouldn't be sampling at 50
>>> MHz.
>>>
>>> -nathan
>>>
>>> On Mon, Nov 25, 2013 at 12:08 AM, Nick Foster 
>>> wrote:
>>> > Your file sink only records a few seconds of data because your hard
>>> drive
>>> > can't keep up, not because of any problem with Volk. The Volk machine
>>> being
>>> > used does not indicate which particular architecture is used for each
>>> kernel
>>> > -- that isn't printed at runtime.
>>> >
>>> > --n
>>> >
>>> > On Nov 24, 2013 9:58 PM, "Paul B. Huter" 
>>> wrote:
>>> >>
>>> >> When running with a USRP source at 25M and a low pass filter down to
>>> >> 10MHz, I get something saying "Using Volk machine: sse4_a_64", and my
>>> file
>>> >> sink only records a couple seconds of data. I ran the volk_profile
>>> script,
>>> >> but still get the same result. The script returned something other
>>> than
>>> >> "sse4_a_64" as the best volk to use. My GNU Radio seems to have
>>> trouble
>>> >> reading configuration files, so is there a way to manually point to
>>> the volk
>>> >> parameter to use when I load GNU Radio?
>>> >>
>>> >> Paul B. Huter
>>> >>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Go-back is possible?

[Dan CaJacob]

I have an interesting (to me anyway) idea:

What if we added a default option to the GRC-XML-to-python converter to add
the contents of the original GRC file as a big, delineated comment blob.
 Then, a simple tool could pull the GRC back out of the python file anytime
and you could go back and forth.  An option when building would disable the
verbose output for those publishing code or who just don't want the extra
cruft.

It's a little lame, but it solves the problem.  I know I've had to
hand-craft many old GRCs from python files when the original GRC was lost
or the originator was other than myself.  The problem has often crept up
with GRCs not properly updated for new versions of code, where the blocks
go missing in the GRC representation (I think there was talk of fixing this
- graying them out or something).

Very Respectfully,

Dan CaJacob


On Mon, Dec 2, 2013 at 4:48 PM, Marcus Leech  wrote:

> Think of the Python that gets emitted by GRC as object code.  What you're
> asking is to convert said object code back into reasonable source code.
>
> Such things exist for *actual* machine object-code, but, they produce
> damned-ugly results.
>
> on Dec 02, 2013, *Raydel Abreu (CM2ESP)*  wrote:
>
>  Oh, that's bad, I guess I should use instead the old code-reading
> method
>
> Raydel
>
>
> 2013/12/2 Marcus Leech 
>
>> There's no automatic mechanism for doing that.
>>
>>
>> on Dec 02, 2013, *Raydel Abreu (CM2ESP)*  wrote:
>>
>>  Hello,
>>
>> Is it possible to go back and convert a Python GNU Radio code back into
>> the GRC Flow Graph from which it was generated?
>>
>> Cheers,
>>
>> Raydel, CM2ESP
>>
>> --
>>
>> ___
>> 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] Go-back is possible?

[Tim]

gzip -> base64 encode the grc file into some comments in the python file
perhaps?
a smallish grc file appears to be on the order of 1000 chars with such
an encoding

On 12/02/2013 05:11 PM, Dan CaJacob wrote:
> I have an interesting (to me anyway) idea:
>
> What if we added a default option to the GRC-XML-to-python converter
> to add the contents of the original GRC file as a big, delineated
> comment blob.  Then, a simple tool could pull the GRC back out of the
> python file anytime and you could go back and forth.  An option when
> building would disable the verbose output for those publishing code or
> who just don't want the extra cruft.
>
> It's a little lame, but it solves the problem.  I know I've had to
> hand-craft many old GRCs from python files when the original GRC was
> lost or the originator was other than myself.  The problem has often
> crept up with GRCs not properly updated for new versions of code,
> where the blocks go missing in the GRC representation (I think there
> was talk of fixing this - graying them out or something).
>
> Very Respectfully,
>
> Dan CaJacob
>
>
> On Mon, Dec 2, 2013 at 4:48 PM, Marcus Leech  > wrote:
>
> Think of the Python that gets emitted by GRC as object code.  What
> you're asking is to convert said object code back into reasonable
> source code.
>
> Such things exist for *actual* machine object-code, but, they
> produce damned-ugly results.
>  
> on Dec 02, 2013, *Raydel Abreu (CM2ESP)*  > wrote:
>
> Oh, that's bad, I guess I should use instead the old
> code-reading method
>
> Raydel
>
>
> 2013/12/2 Marcus Leech  >
>
> There's no automatic mechanism for doing that.
>
>  
> on Dec 02, 2013, *Raydel Abreu (CM2ESP)*  > wrote:
>
> Hello,
>
> Is it possible to go back and convert a Python GNU
> Radio code back into the GRC Flow Graph from which it
> was generated?
>
> Cheers,
>
> Raydel, CM2ESP
>
> 
> 
>
> ___
> 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] Volk machine

[Paul B. Huter]

The recorded file was only about 80MB for 10 seconds of recording, and FFT
playback was static. Without using the low pass filter, I was seeing a
bunch of 'D' (I think) markers, and my playback was choppy.

Nick Foster  wrote:

What was the size of the recorded file on the RAM disk? Are you seeing "O"
indications (for overflow)?

--n


On Mon, Dec 2, 2013 at 1:59 PM, Paul B. Huter wrote:

> Nick:
>
> I tried downsampling the 25MHz to 10, but still was not recording the
> whole time I ran (about 10 seconds, with only a couple seconds of
> playback). That was when I tried using a RAM disk, albeit at 50 downsampled
> to 30. I am using the following for my disk:
>
> mount -o size=1G -t tmpfs none /mnt/tmpfs
>
> I then store my data file to /mnt/tmpfs
>
> Am I doing that wrong? Or is there some other explanation for not storing
> data (other than storage size)?
>
> Again, all feedback and help is appreciated.
>
> Nick Foster  wrote:
>
> Paul,
>
> 30MHz is a big chunk of data to be streaming to anything. A 4GB ramdisk
> will be full in 30 seconds at this rate. Do you really not know *a priori* 
> where
> in the whole 0-30MHz spectrum your signal will be?
>
> I notice now in your first post that you're streaming 25Msps with a
> low-pass filter to 10MHz -- if this is the case, why use a 25Msps rate in
> the first place? You can make the USRP work for you by asking for 10Msps
> (or less, if you know you need less bandwidth) -- it'll handle the
> downsampling and filtering.
>
> --n
>
>
> On Mon, Dec 2, 2013 at 1:32 PM, Paul B. Huter wrote:
>
>> I finally got around to trying writing to RAM, and the result is worse -
>> my replay FFT is static.
>>
>> I am trying to record a chunk of spectrum (in this case the shortwave
>> chunk, 0-30MHz) and then go back and look at small pieces to find my
>> specific data. If someone can provide insight into how to do this, I would
>> appreciate it.
>>
>> Thank you all for all the assistance to date.
>>
>> Paul B. Huter
>> On Nov 25, 2013 9:38 AM, "West, Nathan" 
>> wrote:
>>
>>> I agree with Nick: that VOLK stuff is all expected behavior. If you're
>>> trying to write to a file at high rates you should look in to using a
>>> ramdisk/tmpfs. You'll be limited by how much RAM you have rather than
>>> IO speed.
>>>
>>> However, based on your other threads I wonder if you've taken Tom's
>>> recent suggestion to just lower your input sampling rate? If you're
>>> only interested in ~1MHz bandwidth you shouldn't be sampling at 50
>>> MHz.
>>>
>>> -nathan
>>>
>>> On Mon, Nov 25, 2013 at 12:08 AM, Nick Foster 
>>> wrote:
>>> > Your file sink only records a few seconds of data because your hard
>>> drive
>>> > can't keep up, not because of any problem with Volk. The Volk machine
>>> being
>>> > used does not indicate which particular architecture is used for each
>>> kernel
>>> > -- that isn't printed at runtime.
>>> >
>>> > --n
>>> >
>>> > On Nov 24, 2013 9:58 PM, "Paul B. Huter" 
>>> wrote:
>>> >>
>>> >> When running with a USRP source at 25M and a low pass filter down to
>>> >> 10MHz, I get something saying "Using Volk machine: sse4_a_64", and my
>>> file
>>> >> sink only records a couple seconds of data. I ran the volk_profile
>>> script,
>>> >> but still get the same result. The script returned something other
>>> than
>>> >> "sse4_a_64" as the best volk to use. My GNU Radio seems to have
>>> trouble
>>> >> reading configuration files, so is there a way to manually point to
>>> the volk
>>> >> parameter to use when I load GNU Radio?
>>> >>
>>> >> Paul B. Huter
>>> >>
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Arturo Rinaldi]

Il 02/12/13 22:15, Michael Dickens ha scritto:

Hi Arturo - You don't need all 8 diff files.  If you read through the Portfile 
for GNU Radio, you'll find that you need just 5 of those patches to build 
3.6.5.1 on 10.9; if you want to build on 10.8, you need just 3.

Needed for 10.8 and 10.9 (and, likely, 10.7 or earlier):

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

Needed just for 10.9/libc++:

patch-gnuradio-core_swig_std_std_container.i.diff
patch-gnuradio-core_swig_include-std_string.i.diff

If you use those patches on your OOT build of GNU Radio, you should be able to 
build it with minimal defines added to the cmake command line. - MLD

On Dec 2, 2013, at 2:23 PM, Arturo Rinaldi  wrote:

mmm I see.ok let's do it this way. Let's say that i untar the 3.6.5.1 
tarball and write a script that patches all the needed files before running the 
usual steps of configuration.

If I have understood well what I have to do I need to use all the 8 diff files 
you uploaded on the macports server, join them and apply the result to the 
extracted tarball directory. I can try that with

patch --dry-run

to find if the patching is properly perfromed and the files are not affected by 
patching. Now i have to figure out which are the right diff files to patch the 
legacy version and the new version since I'm noticing that the source path 
structure is different in the new tarball. Do I have to use all of them or not 
? Can i write just one single diff file to apply before building from source as 
usual ? I was thinlking thah once the work is finished i could post it on the 
mailing list so it'd be available for everyone.let me know if you like the 
idea.


ok let's sum up and see if i have understood what is coded in the 
Portfile. Let's examine it case by case :


10.7

*LEGACY (3.6.5.1 and lower) and *

/cat/ of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

then apply resulting patch, then build as usual

PS : I have always built from source any latest tarball of gnuradio 
legacy successfully, so I don't think I'll ever apply this modifications


*NEW releases (3.7 and above)

*nothing to patch or to modify

10.8
*
LEGACY (3.6.5.1 and lower) and *

/cat/ of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

then apply resulting patch, then build as usual

*NEW releases (3.7 and above)

*nothing to patch or to modify (at least applying the swig/std "trick" 
but it seems working without it as well)


10.9

first of all I have to perform the copy of the directory *std* of SWIG 
in my source directory according to :


*LEGACY**(3.6.5.1 and lower)*

cp -r /opt/local/share/swig/*/std to /gnuradio-core/src/lib/swig

/cat/ of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff
patch-gnuradio-core_swig_std_std_container.i.diff
patch-gnuradio-core_swig_include-std_string.i.diff

then apply resulting patch, then build as usual

*NEW releases (3.7 and above)*

cp -r /opt/local/share/swig/*/std to 
/gnuradio-runtime/src/lib/swig


/cat/ of :

patch-gnuradio-runtime_swig_std_std_container.i.diff
patch-gnuradio-runtime_swig_include-std_string.i.diff

then apply resulting patch, then build as usual

Have I nailed it or not yet ? Let me know.

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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Michael Dickens]

Hi Arturo - Yes, I think you've nailed it. - MLD

On Dec 2, 2013, at 8:33 PM, Arturo Rinaldi  wrote:
> ok let's sum up and see if i have understood what is coded in the Portfile. 
> Let's examine it case by case :
> 
> 10.7
> 
> LEGACY (3.6.5.1 and lower) and 
> 
> cat of :
> 
> patch-path-order.diff 
> patch-volk_lib_CMakeLists.txt.legacy.diff 
> patch-volk_gen_archs.xml.legacy.diff 
> 
> then apply resulting patch, then build as usual
> 
> PS : I have always built from source any latest tarball of gnuradio legacy 
> successfully, so I don't think I'll ever apply this modifications
> 
> NEW releases (3.7 and above)
> 
> nothing to patch or to modify
> 
> 10.8
> 
> LEGACY (3.6.5.1 and lower) and 
> 
> cat of :
> 
> patch-path-order.diff 
> patch-volk_lib_CMakeLists.txt.legacy.diff 
> patch-volk_gen_archs.xml.legacy.diff 
> 
> then apply resulting patch, then build as usual
> 
> NEW releases (3.7 and above)
> 
> nothing to patch or to modify (at least applying the swig/std "trick" but it 
> seems working without it as well)
> 
> 10.9
> 
> first of all I have to perform the copy of the directory  std of SWIG in my 
> source directory according to :
> 
> LEGACY (3.6.5.1 and lower)
> 
> cp -r /opt/local/share/swig/*/std to /gnuradio-core/src/lib/swig
> 
> cat of :
> 
> patch-path-order.diff
> patch-volk_lib_CMakeLists.txt.legacy.diff 
> patch-volk_gen_archs.xml.legacy.diff
> patch-gnuradio-core_swig_std_std_container.i.diff 
> patch-gnuradio-core_swig_include-std_string.i.diff 
> 
> then apply resulting patch, then build as usual
> 
> NEW releases (3.7 and above)
> 
> cp -r /opt/local/share/swig/*/std to 
> /gnuradio-runtime/src/lib/swig
> 
> cat of :
> 
> patch-gnuradio-runtime_swig_std_std_container.i.diff 
> patch-gnuradio-runtime_swig_include-std_string.i.diff 
> 
> then apply resulting patch, then build as usual
> 
> Have I nailed it or not yet ? Let me know. 


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

Re: [Discuss-gnuradio] Status of GNU Radio with OSX 10.9

[Arturo Rinaldi]

Nella citazione in data Tue Dec  3 02:44:13 2013, Michael Dickens ha 
scritto:

Hi Arturo - Yes, I think you've nailed it. - MLD

On Dec 2, 2013, at 8:33 PM, Arturo Rinaldi  wrote:

ok let's sum up and see if i have understood what is coded in the Portfile. 
Let's examine it case by case :

10.7

LEGACY (3.6.5.1 and lower) and

cat of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

then apply resulting patch, then build as usual

PS : I have always built from source any latest tarball of gnuradio legacy 
successfully, so I don't think I'll ever apply this modifications

NEW releases (3.7 and above)

nothing to patch or to modify

10.8

LEGACY (3.6.5.1 and lower) and

cat of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff

then apply resulting patch, then build as usual

NEW releases (3.7 and above)

nothing to patch or to modify (at least applying the swig/std "trick" but it 
seems working without it as well)

10.9

first of all I have to perform the copy of the directory  std of SWIG in my 
source directory according to :

LEGACY (3.6.5.1 and lower)

cp -r /opt/local/share/swig/*/std to /gnuradio-core/src/lib/swig

cat of :

patch-path-order.diff
patch-volk_lib_CMakeLists.txt.legacy.diff
patch-volk_gen_archs.xml.legacy.diff
patch-gnuradio-core_swig_std_std_container.i.diff
patch-gnuradio-core_swig_include-std_string.i.diff

then apply resulting patch, then build as usual

NEW releases (3.7 and above)

cp -r /opt/local/share/swig/*/std to /gnuradio-runtime/src/lib/swig

cat of :

patch-gnuradio-runtime_swig_std_std_container.i.diff
patch-gnuradio-runtime_swig_include-std_string.i.diff

then apply resulting patch, then build as usual

Have I nailed it or not yet ? Let me know.






Thank you very much again for your support. You're a priceless asset to 
me and the whole gnuradio mailing list of course. Keep doing this great 
work.


Regards, Arturo

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

Re: [Discuss-gnuradio] Time controlling block

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This is redundant. The block base class has methods
nitems_read() and nitems_written() that do exactly what you want.

However: I'm totally interested in this presentation on the current
scheduler; URL?

Greetings,
Marcus

On 02.12.2013 19:45, Wayne Roberts wrote:
> you could keep a class variable which is added to every time work()
> is called, adding to it each time the value of noutput_items or 
> input_items.size().
> 
> Its also useful to know the scheduler, because it feeds work() an
> arbitrary number of samples each time. There is a presentation on
> gnuradio scheduler.
> 
> 
> On Mon, Dec 2, 2013 at 1:07 AM, Sandhya G 
> wrote:
> 
>> Hi, Today i got a idea about implementing three different
>> modulations on single message signal. But i want the modulations
>> to happen after certain time has searched (can say exactly like
>> counter). which is the block in GNU Radio that i can use has a
>> counter.
>> 
>> 
>> Thanks and regards, Sandhya
>> 
>> ___ 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnYTwAAoJEAFxB7BbsDrLjH8H/1b7Ocr4McViRZUThAb0Q0b5
yFlbSJe+5fKbbwJXptLq8/UZSOIVVHeekd3937RKHpHOmxkXY2FTZr8TQmadM/w0
L5wYSflm4VxA3F6OkAOAUpZDNX7KTL7uRDGRS0X7EqiVyjai3BCakwiYEDZTNrQB
n/cLUgum0qt0eDCSIF4OiPYc4nDHiQJd+iswR3Le476/qJA5Is/08I84muSDCCnM
pDtHvwaDuV87fYuZGmxHuBDyknNAJAnhWcatUh8B1SIquWBieezhMkNQAGOLKWRV
7y+cCVyXWPMchkN73vUWcuKPIis4U2kMkXF9f3q8cV3I83RqWizg1aA/lEpBBqI=
=B3bM
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Go-back is possible?

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frankly, if you *really* want to inline the GRC file in the generated
python, I'd just have one large multiline Python string holding that
file as-is. With a little magic you could even let the python program
re-synthesize itself given a certain command line argument.
Anyway: I can't imagine how the single-line-comment will not clutter
the source code tremendously and make it hard to read and build upon
(which is what I use GRC mainly for).

I think the main problem with GRC-generated python is not the fact
that it's hard to recraft (unless your GRC graphs span multiple
screens and you run out of pencil retracing that on paper), but the
fact that due to progress, block names change between releases, and so
do arguments; thus, reading the source code often brings more clarity
than looking at a half-decapitated flowgraph, even when it's embedded
in the source.

Greetings,
Marcus

On 02.12.2013 23:22, Tim wrote:
> gzip -> base64 encode the grc file into some comments in the python
> file perhaps? a smallish grc file appears to be on the order of
> 1000 chars with such an encoding
> 
> On 12/02/2013 05:11 PM, Dan CaJacob wrote:
>> I have an interesting (to me anyway) idea:
>> 
>> What if we added a default option to the GRC-XML-to-python
>> converter to add the contents of the original GRC file as a big,
>> delineated comment blob.  Then, a simple tool could pull the GRC
>> back out of the python file anytime and you could go back and
>> forth.  An option when building would disable the verbose output
>> for those publishing code or who just don't want the extra
>> cruft.
>> 
>> It's a little lame, but it solves the problem.  I know I've had
>> to hand-craft many old GRCs from python files when the original
>> GRC was lost or the originator was other than myself.  The
>> problem has often crept up with GRCs not properly updated for new
>> versions of code, where the blocks go missing in the GRC
>> representation (I think there was talk of fixing this - graying
>> them out or something).
>> 
>> Very Respectfully,
>> 
>> Dan CaJacob
>> 
>> 
>> On Mon, Dec 2, 2013 at 4:48 PM, Marcus Leech > > wrote:
>> 
>> Think of the Python that gets emitted by GRC as object code.
>> What you're asking is to convert said object code back into
>> reasonable source code.
>> 
>> Such things exist for *actual* machine object-code, but, they 
>> produce damned-ugly results.
>> 
>> on Dec 02, 2013, *Raydel Abreu (CM2ESP)* > > wrote:
>> 
>> Oh, that's bad, I guess I should use instead the old code-reading
>> method
>> 
>> Raydel
>> 
>> 
>> 2013/12/2 Marcus Leech > >
>> 
>> There's no automatic mechanism for doing that.
>> 
>> 
>> on Dec 02, 2013, *Raydel Abreu (CM2ESP)* > > wrote:
>> 
>> Hello,
>> 
>> Is it possible to go back and convert a Python GNU Radio code
>> back into the GRC Flow Graph from which it was generated?
>> 
>> Cheers,
>> 
>> Raydel, CM2ESP
>> 
>> 
>>
>>
>> 
___
>> 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnYc5AAoJEAFxB7BbsDrLcP8H/1GqveUwP02dqD0TtX0ZhADM
nSUd/HOx/rGqC1ATHq1vItKTv98spB0ZVf2EUCyOZK5uvES2YMu8KqrTUXemchzH
93nwJ6/Z2apAYAccRtpf5r83Cx9DRyKwUlR4KvW3LBVmqlgYbFE3eYgG2mmsDODz
VgOqgg+fcMQQP+h0rsETiCHb8kN/STayPp6iVxsLDSXlTXKqNu4yXZfy5WvCQOm/
C6Lj3R7DXMKVJEcs/Z0KYvHIYdaK6fVLjsp9ltwDe5qqQaZPkOs+YnJKur3ND++F
ayDdmySX5PevAeSJLsRmFWmOh62sI03JyP4NjYiE+kOS5te/hakqA1qiyFOWfbc=
=xJtK
-END PGP SIGNATURE-

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