Re: [Discuss-gnuradio] [SOCIS] CNNs

[Vanush Vaswani]

Nice work. BTW, What's the application for this method?

On Tue, Jul 19, 2016 at 6:11 AM, Christopher Richardson
 wrote:
> Hi Everyone
>
> I've just been working on an alternative approach
> for classification based on the following paper -
>
> Convolutional Radio Modulation Recognition Networks – Timothy J. O’Shea ,
> Johnathan Corgan , and T. Charles Clancy
>
> I've posted my results here -
>
> https://signalsintelligence.wordpress.com/2016/07/16/cnns/
>
> cheers
>
> Chris
>
> ___
> 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] gnuradio.org spam activity and user accounts

[Vanush Vaswani]

Maybe consider using the 'no CAPTCHA' recaptcha?

Vanush

On Tue, Feb 9, 2016 at 9:45 AM, Tom Rondeau  wrote:
> Hi list,
>
> I wanted to let everyone know that gnuradio.org has been hit with a serious
> amount of spam activity today. We restrict much of the editing to signed-in
> users and use a recaptcha plugin to prevent bots from creating bogus
> accounts, which is something we dealt with a while ago. They are now getting
> around the recaptcha, creating bogus users, and posting Issue and editing
> the wiki page of our site.
>
> Johnathan Corgan and I have removed the bogus issues, fixed the main wiki,
> and locked all of the accounts under suspicion. We have also disabled
> automatic authentication of users, and so new users must now be manually
> activated. I will be monitoring this activity for the next few days and hope
> it dies down. In the meantime, if you make an account that I don't activate
> (within a reasonable amount of time), ping me on the side about it.
>
> Meanwhile, I don't think there was any other damage done to the site besides
> the front page that has already been fixed. But if you are looking around at
> pages and it seems like spam (and it's pretty obvious -- talks about phone
> numbers to call for tech support about various products), please report it
> to us.
>
> It looks like this kind of thing has been happening for a while on other
> sites. It just managed to hit us today.
>
> Thanks,
> Tom
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Re: [Discuss-gnuradio] SOCIS project update 7

[Vanush Vaswani]

Nice work, looking forward to seeing what you produce.

On Sat, Jul 18, 2015 at 2:34 AM, Johannes Demel 
wrote:

> Hey GNU Radio'ers!
>
> another week has passed. So it's time for a project update.
> This week was dedicated to channel construction. Finally, all channel
> construction algorithms work. I added a couple of convenience
> functions too.
> First, there's a command line tool 'polar_channel_construction' which
> will do channel construction according to the parameters you'll pass
> to it.
> Secondly, there's a GRC block which takes all the parameters and
> returns a dictionary with the desired parameters. Most importantly,
> ['positions'] and ['values'] contain the
> Numpy arrays of interest. I hope they're self-explanatory.
> For all channels but BEC, channel construction is quite a
> computationally heavy task. Thus, Z-parameters which are generated
> once for a user are saved in '~/.gnuradio/polar'. Afterwards they are
> available. If a new set of parameters is encountered, the
> corresponding z-parameters will be calculated automatically. There's a
> progress bar and everything. So you can keep track of construction
> progress.
> Z-parameters are saved in text files. A header holds all the info on
> construction parameters and.
> I worked on further integrating polar codes into FECAPI. So, now you
> can just open an example flowgraph and another flowgraph generates BER
> curves for SC decoder and SC list decoder and for comparability a
> convolutional code.
> One odd thing about FECAPI, that I noticed, is bit-to-symbol mapping.
> As far as I've seen it so far, most applications map 1 -> -1 and 0 ->
> 1, or 2 * bit - 1. FECAPI handles this the other way round. At least
> 'BER curve generator' behaves this way, so I assume that the other
> decoder blocks expect the same mapping.
>
> That's it for the week. So far, I've dealt with all aspects of polar
> codes. Now it's time to focus on VOLK optimization and algorithmic
> optimization.
>
> A little goodie at the end [3]. I uploaded a BER comparison pic to
> imgur. Be careful with absolute values though. I doubt Es/N0 is
> accurate. But it gives you an impression.
>
> More info and current project progress can be found in [1] and [2].
>
> Cheers
> Johannes
>
> [1] https://github.com/jdemel/gnuradio
> [2] https://github.com/jdemel/socis-proposal
> [3] http://i.imgur.com/QXWdSPj.jpg
>
> ___
> 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] question on implementing a state machine

[Vanush Vaswani]

I believe this is a very common pattern for decoding simple protocols
(once you have the bits)

Here's an example
https://github.com/jmalsbury/gr-tnc/blob/master/lib/hdlc_deframer_impl.cc

On Tue, Jun 9, 2015 at 2:22 PM, Martin Braun  wrote:
> On 06/08/2015 07:16 PM, Anil Kumar Yerrapragada wrote:
>> I am trying to implement a state machine based synchronization
>> algorithm. The 2 states being "search for synch sequence" and "pass data
>> through".
>>
>> As far as I can see, the ideal way to do this is to have the work
>> function check what state it is in before proceeding. If it is in search
>> state, the work function will search for the synch sequence and once
>> found, switch to "pass data" and get out.
>>
>> Next time work is called (use forecast to make sure that the number of
>> input items available matches the amount I have data I have after the
>> synch sequence), it will pass data through. Switch state back to
>> "search" and so on.
>
> FYI, the header/payload demux block does just that. It's pretty generic,
> so it'll catch more cases than you need, but have a look at its source code.
>>
>> My questions are these:
>>
>> 1. Before each work call, does GNURadio automatically know the state
>> that I left it in in the previous call? (Am I allowed to make work
>> return anything else apart from len(output_items)?
>
> No, but class attribute will persist between work calls.
>
>>
>> 2. Is it better/possible to implement a separate block for the state
>> machine that can somehow make the system aware of what state it is in?
>
> Just make the state a class variable / attribute.
>
> Have fun and good luck,
>
> M
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] DVB-T/T2

[Vanush Vaswani]

Hey guys, why does digital video need its own standard?

On Thu, Apr 9, 2015 at 7:45 PM, Ralph A. Schmid, dk5ras
 wrote:
> Short update: I was able to transmit my own stream now, audio stuttered a
> bit, but for sure I will find out how to fix this. It was a short iPhone
> video of a snake in front of our office (we do not have so much snakes here
> in Germany), and it was fun seeing this transmitted via DVB-T :)
>
>
>
> Ralph.
>
>
>
> From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com]
> Sent: Wednesday, April 8, 2015 5:13 PM
> To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] DVB-T/T2
>
>
>
> Hi Ralf,
>
>
>
> having Us when moving the mouse does not looks good. Can you show a picture
> taken with htop (on Linux).
>
>
>
> the coding is a setting of the transmitter and receiver and it just need to
> be the same on both. It does impact the maximum bitrate of the stream as in
> the table.
>
>
>
> Look into the 4.5.4 and 4.5.5 chapters. It says that reference information
> is sent at "boosted" power level with imaginary equal zero. This is what you
> see in the two dots on left and right.
>
>
>
> Bogdan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wednesday, April 8, 2015 5:34 PM, "Ralph A. Schmid, dk5ras"
>  wrote:
>
>
>
> Hi,
>
>
>
> The Us are when I do something else with the machine. They do not show when
> I keep my fingers off the mouse, so no reason to worry, it runs for ages
> without a single U when the machine is kept alone.
>
>
>
> I already found out about the rate. The coding also needs to be reflected by
> the transport stream, or just regarding the bitrate? I did not find a
> setting for that, but I will look deeper into it during the next days, when
> I find some time. My first test trying to set identical settings like from
> the working test stream brought just a black picture.
>
>
>
> Another question...when looking into the constellation, what are the two dot
> clouds on the X/I-axis, outside the expected 4*4 cloud matrix? Some embedded
> BPSK? I could not find this in the DVB-T specs at first glance...
>
>
>
> Ralph.
>
>
>
>
>
> From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com]
> Sent: Wednesday, April 8, 2015 2:57 PM
> To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] DVB-T/T2
>
>
>
> Hi Ralph,
>
>
>
> DVB-T.png shows some u's on the command line which means the whole flowgraph
> do not provide data to USRP at the right speed. It basically mean the
> computer cannot cope with the required processing requirement.
>
>
>
> As for the video parameters, in the DVB-T specs
> (http://www.etsi.org/deliver/etsi_en/300700_300799/300744/01.06.01_60/en_300744v010601p.pdf)
> you will find Table 17 where the rates are presented. FYI, the settings you
> have used are 8Mhz bandwidth, QAM-16 constellation, coding 1/2, guard
> interval 1/32. The video should be constant bit rate but it is not a hard
> requirement (see below).
>
>
>
> If you just broadcast video from a file and not plan to use a live streaming
> from camera, the rate should not matter too much. The video is sent at the
> rate of the DVB-T according to it's parameters and with RTL2832 receiver it
> is buffered and played at the correct speed (at least for short files like
> test.ts).
>
>
>
> Bogdan
>
>
>
>
>
> On Wednesday, April 8, 2015 11:55 AM, "Ralph A. Schmid, dk5ras"
>  wrote:
>
>
>
> Yep, this would be quite useful!
>
> Bogdan, as you are here, too - I don't know very much about all the crazy
> video file stuff, but maybe you can give me some basic parameters I need to
> comply with for a transport stream, to be able to transmit it with your
> package?! I need to use Windows for the conversion, as my Linux installation
> is only on a virtual machine, with limited space and power. A capable
> looking Windows program is available, but there are so many options I have
> no clue about :(
>
>
>
> I modified your flow graph according to Rons hints, and now I have a stable
> and reliable DVB-T transmission path with your package. See
> http://dk5ras.dyndns.org/tmp/DVB/ with a screenshot. I am using the Ettus
> B210, and for reception a second PC with DVB-T stick, or a DVB-x tester that
> does them all, DVB-C/S/S2/T/T2.
>
>
>
> You and Ron really did a great job with coding those DVB-x packages!
>
>
>
> Ralph.
>
>
>
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> Bogdan Diaconescu
> Sent: Wednesday, April 8, 2015 8:01 AM
> To: Ron Economos; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] DVB-T/T2
>
>
>
> Ok, it would be useful to have receivers too like for the DVB-T.
>
>
>
> Bogdan
>
>
>
>
>
> On Tuesday, April 7, 2015 11:23 PM, Ron Economos  wrote:
>
>
>
> Only transmitter implementations for now. They are here:
>
> https://github.com/drmpeg/gr-dvbs2
>
> https://github.com/drmpeg/gr-dvbt2
>
> The DVB-T2 implementation supports T2-Lite, t

Re: [Discuss-gnuradio] Announcing cgran.org: Re-launching the Comprehensive GNU Radio Archive Network

[Vanush Vaswani]

Looks great.. congrats.

On Sun, Apr 5, 2015 at 2:52 AM, West, Nathan
 wrote:
> Hi all,
>
> I am happy to be able to announce that the Comprehensive GNU Radio Archive
> Network (CGRAN) is now live at http://cgran.org. It's a bit different from
> the previous version.
>
> Some notes:
>
> 1) The primary purpose of this rendition of CGRAN is to provide a place to
> filter and sort through the growing number of OOT modules that meet your
> needs.
>
> 2) If you want to add a bookmark to jump to project listings the best URL is
> cgran.org/projects/
>
> 3) No code is hosted by CGRAN. If you need a place to host your projects
> there are several free services to do that which have features and services
> we could not possible match, some of which run on completely free software.
>
> 4) The list of modules on CGRAN comes from PyBOMBS and CGRAN heavily depends
> on PyBOMBS. If a module has a manifest file we use it to get most of the
> information. If there is no manifest file we only know a small amount of
> information.
>
> 5) For module authors that want to improve their presence on CGRAN, add a
> MANIFEST.md to the top level of your module repo. The skeleton is at
> https://raw.githubusercontent.com/gnuradio/gnuradio/master/gr-utils/python/modtool/gr-newmod/MANIFEST.md
> and you can view the module repos that have more content on CGRAN for
> examples.
>
> Finally, this wouldn't look nearly as well as it does without Ravi Sharan
> who put together the overall site layout and feedback from those in the
> CGRAN/PyBOMBS working group. This is not the final state of CGRAN as we
> tweak the layout and operation, but we want to get it out there for use and
> encourage module authors to add manifest files.
>
> -Nathan
>
> ___
> 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] Understanding the limitations of USRP1

[Vanush Vaswani]

Aliasing on purpose?

On Thu, Feb 12, 2015 at 11:25 AM, Marcus D. Leech  wrote:
> On 02/11/2015 06:15 PM, Tommy Tracy wrote:
>
> I am using a USRP1, and I'm trying to receive FM radio. I'm using a BasicRX
> daughterboard with a 0-250MHz range. The USRP itself has a LO frequency of
> 64MHz. Does this limit my frequency range to 0-32MHz, or can I get into the
> 100MHz range by somehow multiplying that Local Oscillator frequency?
>
> I get the following error:
>
> -- Opening a USRP1 device...
> -- Using FPGA clock rate of 64.00MHz...
> -- Tune Request: 102.90 MHz
> --   The RF LO does not support the requested frequency:
> -- Requested LO Frequency: 102.90 MHz
> -- RF LO Result: 0.00 MHz
> --   Attempted to use the DSP to reach the requested frequency:
> -- Desired DSP Frequency: -102.90 MHz
> -- DSP Result: 25.10 MHz
> --   Successfully tuned to -25.10 MHz
>
> --
> --
>  Sincerely,
> Tommy James Tracy II
>  Ph.D Candidate
> Computer Engineering
>   University of Virginia
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> You might be better off getting a TVRX2 card for it.
>
> You're limited on the USRP1 to 64Msps, and since the BASIC_RX does no
> downconversion--it's just an ADC "buffer", you'd be limited to <= 32MHz in
> the
>   first Nyquist zone.
>
> You *could* put a very stiff FM-band-only filter and some gain in front of
> the BASIC_RX, and calculate the appropriate "Nyquist folding" for your
> desired
>   frequencies, and tune to those frequencies in the DC-32Mhz region.
>
>
>
> --
> 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
>

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

Re: [Discuss-gnuradio] Testing an GRC project runs nearly 200% CPU

[Vanush Vaswani]

Post a screenshot of your flowgraph. Sounds like a sample rate mismatch.

On Fri, Jan 16, 2015 at 8:38 AM, Andreas Ladanyi
 wrote:
> Hi,
>
> iam testing an UKW Radio Receiver GRC project (gr-rds) on bananapi. The
> application starts. The tuned radio station sounds clicking. Changing any
> parameter in the GUI is very difficult/slow.
>
> top tells me a memory usage about 20 %. CPU usage is nearly 200 % (bananapi
> has 2 CPUs). At any webside i read that working with no throttle blocks
> could run a CPU to maximum. In my project which iam testing i see no
> throttle blocks. I am not sure if that could be the reason because iam
> working on the bananapis real hardware ?
>
> Is there something wrong with the sample rate ?
>
> Andreas
>
> ___
> 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] Help me help myself

[Vanush Vaswani]

Use cscope and/or ctags next time

On Tue, Dec 23, 2014 at 11:47 AM, Marcus D. Leech  wrote:
> On 12/22/2014 07:31 PM, Richard Bell wrote:
>>
>> MLeech I really understand where you're coming from. But I think that's
>> the point of a community. If you are personally tired of answering low level
>> questions, then you should not feel like you have to. Others in the
>> community might be happy to do it, and you can stick to the advanced
>> questions. Correct me if I'm wrong, but this is how other communities seem
>> to work that I've been involved with.
>>
>> MMuller, thank you. I do my best to help myself before I ask a question
>> here. Often, I feel like I'm asking a legit question, until the responses
>> make me feel like i just asked the equivalent of "what does 2+2 equal?" Its
>> always hard until you ask. Shrug.
>>
>> Rich
>
> Richard:
>
> I certainly didn't mean to imply that you'd asked a "stupid question".
> There aren't any stupid questions.  Only stupid/ill-considered answers.
>
> Your post just triggered one of my many soap-box moments.  If I had a beard,
> it would be grey.  Think of me as the grumpy old greybeard
>   muttering incoherently over there in the corner...
>
>
> --
> 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

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

Re: [Discuss-gnuradio] [USRP-users] RFNoC -- Making FPGA design easy from GNU Radio

[Vanush Vaswani]

How does the system know that the downstream block is on host or FPGA?

On Fri, Dec 5, 2014 at 8:58 AM, Nowlan, Sean
 wrote:
>
>
>>Ettus Research is very excited to announce the release of RFNoC!
>
>
>
> […]
>
>
>
> This is very cool. I’ve been looking forward to working with this
> development.
>
>
>
>> Mixing and matching host-based and FPGA-based processing is transparent to
>> the user, and that processing can scale across multiple FPGAs and devices
>> across a network
>
>
>
> Does this imply that I could run a GNU Radio application on a Zedboard, for
> instance, with the following data flows:
>
>
>
> (1) GR on Zynq ARM --> Zynq FPGA --> GR on Zynq ARM --> B2x0 RF/radio
>
> (2) GR on Zynq ARM --> Zynq FPGA --> GR on Zynq ARM --> X3x0 FPGA --> X3x0
> RF/radio
>
>
>
> I think (1) is similar or identical to Jonathon Pendlum’s FPGA filter demo.
> What I’m more curious about is how easy it is to build a single GR flowgraph
> that mixes GR processing with FPGAs that live either in Zynq or connected
> 3x0 series devices. It sounds like this kind of support is an explicit goal
> of RFNoC.
>
>
> ___
> 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] GRC, Recording chunks of spectrum triggered on input signal level

[Vanush Vaswani]

All these workarounds seems hacky
Is there a paradigm that can handle this.

On Wed, Nov 19, 2014 at 8:17 AM, Staffan Bruce  wrote:
> It works, many thanks!
>
> It seems like the changing of a variable in itself does not trigger an
> update of other variables (that are depending on the first one), but using a
> button or probe will trigger an update of the variables that are depending
> on them. Could this be something to consider for GnuRadio/Companion, i.e.,
> dependencies between variables and assuring that they are updated when a
> change is occurring in one of them?
>
> Still, file sink notices the change of the variable it is depending on and
> that is enough. Now I have a good way of making separate recordings - great!
>
> ...and yes - time to start learning how to code.
>
> Regards,
>  Staffan
>
> -Original Message- From: madengr
> Sent: Monday, November 17, 2014 6:58 PM
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GRC, Recording chunks of spectrum triggered
> on input signal level
>
> If you are using an "if" statement to switch between filename and /dev/null,
> try putting the filename construction in the "if" statement, instead of a
> separate variable.  That may make it evaluate every time the "if" statement
> is called.
>
> My example used the LO frequency as part of the filename, and every time the
> QT GUI slider changed the LO, it probably updated the filename.
>
> If that does not work, maybe you can use a probe to examine a signal, say
> 10x a second.  Then the probe level() function could be used as part of the
> filename.  That would at least change it 10x a second.
>
> For the counter, maybe you could also use a probes to look at a signal
> before and after a N sample delay, where delay and sample rate is about the
> same time as your probe rate; then this pseudocode:
>
> if now.level() != delayed.level() then count = count +1
>
> At this point though you ought to delve into the Python.  As long as you are
> not using the QT GUI, the code is pretty straight forward.  You can use
> probes to pull values out of the flow and evaluate them in Python.
>
> Thanks,
> Lou
> KD4HSO
>
>
>
>
> Staffan wrote
>>
>> Hello,
>>
>> After some weekend experimenting I believe I have most (most...) of it
>> working. Sinking to a USB stick is not working so well by the way...
>> One thing that is still a challenge is how to set the filename. You
>> provided
>> a very good way of timestamping, but when I try this, it only evaluates
>> once - when I start the script. Is there any way to force re-evaluation of
>> a
>> variable?
>> In addition, it would be great to have some kind of a counter (variable, x
>> =
>> x + 1) that can be updated depending on a state change - for example when
>> a
>> trigger event occurrs. I tried some different versions, but mainly ended
>> up
>> in circular references...
>>
>> Any suggestions would be highly appreciated!
>>
>> Regards,
>>   Staffan
>
>
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/GRC-Recording-chunks-of-spectrum-triggered-on-input-signal-level-tp51302p51339.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 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] stop() the flow graph

[Vanush Vaswani]

Try putting wait() after stop() to make sure the resources are teared down.

On Sat, Nov 15, 2014 at 6:56 PM, Syed Aqeel Raza  wrote:
> Hi,
>
> Currently, I am using a single usrp as a transmitter. The program is
> changing the transmission frequency with respect to (external) switching
> time. In order to change the frequency in usrp box; I set the following
> programming conditions.
>
> while 1:
> if ((time!=0) and ((ch1=1) or (ch2==1))):
>   tb1.start()
>   time = int(time) - int(1)
>   sleep(external time which provide the active channel time of
> channel 1 and channel 2)
>elif (time==0):
>   tb1.stop()
>
> But (I think) due to this frequent start() and stop() activities; after
> maximum of 15 minutes time I have received the following error.
>
> /Traceback (most recent call last):
> File "source_test.py", line 121, in 
> tb1 = gmsk_tx()
> File "source_test.py", line 88, in __init__
> self.blocks_udp_source_0 = blocks.udp_source(gr.sizeof_char*1, "127.0.0.1",
> 1234, 1472, True)
> File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/blocks/blocks_swig5.py",
> line 1969, in make
> return _blocks_swig5.udp_source_make(*args, **kwargs)
> RuntimeError: boost::thread_resource_error: Resource temporarily unavailable
>
> I want the program to be run continuously. Kindly propose some solution.
>
> Regards,
> Syed Aqeel Raza
>
> On Thu, Nov 13, 2014 at 6:32 PM, Syed Aqeel Raza 
> wrote:
>>
>> I can't use sleep() here; because there're other threads as well in the
>> program which need to be executed as well. Sleep() stop the execution of
>> program; which is not a solution. Thanks.
>>
>> On Thu, Nov 13, 2014 at 5:53 PM, Syed Aqeel Raza 
>> wrote:
>>>
>>> Thanks Sylvain for your reply; but if I introduced sleep(14) then during
>>> that time it won't perform the tasks in tb1 as well.
>>>
>>> On Thu, Nov 13, 2014 at 3:28 PM, Syed Aqeel Raza 
>>> wrote:

 Hi All,

 I am looking for a solution that start() the flow graph for a definite
 period of time (in seconds) and after that it stop() it automatically. For
 example

 # let suppose initial value of time is 14 seconds; it means that the
 flowgraph defined in tb1 should need to executed during that time; and when
 the time reaches zero it must be stop.

 while 1:
 if (time!=0):
   tb1.run()
   time = int(time) - int(1)
 elif (time==0):
   tb1.stop()


 I tried this; but once the flow graph started; then it never comes to
 the elif condition. How can I stop() the flowgraph in this condition.
 Waiting for reply.

 Regards,



>>>
>>>
>>
>
>
> ___
> 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] Looking for 802.11 MAC & PHY Package

[Vanush Vaswani]

Learn 802.11. hehe.

On Mon, Oct 20, 2014 at 6:38 PM, Martin Braun  wrote:
> On 10/16/2014 11:50 AM, Vanush Vaswani wrote:
>> Is it possible to do 11ac on SDR?
>
> Vanush,
>
> the answer to *any* question of the type "can we do standard X on SDR"
> is always 'yes'.
>
> Are you planning to do this yourself, or are you looking for a finished
> solution? Also, what's your goals?
>
> M
>
>>
>> On Wed, Oct 15, 2014 at 10:07 PM, Bastian Bloessl  
>> wrote:
>>> Hi,
>>>
>>> On 10/10/2014 06:20 PM, Zhang, Jiayi wrote:
>>>>
>>>> Dear Marcus and Bloessl,
>>>>
>>>> Thanks for the reply. I also notice the fully functional gr-ieee802-11
>>>> package provide by Bloessl. Previously I thought it's only PHY, but as
>>>> Marcus mentioned it also include MAC. It seems to me in the
>>>> gr-ieee802-11-master package, the MAC does not run csma. I also find the
>>>> gr-ieee802-11-csma package, which is smaller than the master package but
>>>> indicate "csma" in name and one of examples.
>>>
>>>
>>> Sorry, I don't get what you mean with smaller. Are you talking about the
>>> file size of the sources?
>>> All branches add / parse the MAC header as defined in the standard. So the
>>> frame format is OK on all branches. The 'csma' branch implements channel
>>> access for broadcast frames.
>>>
>>>> After checking the Readme
>>>> and other pulications from WIME project, I cannot find detail
>>>> description regarding the MAC and CSMA function for the package.
>>>
>>>
>>> It's the one at the top
>>> http://www.ccs-labs.org/bib/bloessl2014timings/
>>>
>>>>
>>>> 1. Does the csma package should be used with the master package?
>>>
>>>
>>> No. 'csma' is the name of a branch. You would checkout and use that branch.
>>>
>>>> 2. Does the csma package support multiple nodes in an ad-hoc network?
>>>
>>>
>>> The CSMA implementation is for broadcast frames only. So depends on what you
>>> want to do.
>>>
>>>>
>>>> Return to Marcus's advice, do you mean that to realize the MAC (CSMA),
>>>> we still need implement FPGA (not the one in USRP?) to handle it in
>>>> hardware, no matter we use the software lib, e.g. GRU Radio or Click
>>>> Module Router?
>>>
>>>
>>> To support CSMA functionality you will have to change the FPGA otherwise you
>>> will not be able to meet the timing constraints of 802.11. For the broadcast
>>> case you only need some small changes.
>>> If you want to support ACKS and RTS/CTS you need a lot of functionality on
>>> the FPGA. In my opinion this will not happen on a N210, but AFAIK Ettus has
>>> a 802.11 implementation for RFNoC (i.e. for the FPGA) which most likely
>>> meets all timing constraints.
>>>
>>> Best,
>>> Bastian
>>>
>>>>
>>>> Many thanks for your help again!
>>>>
>>>> Best regards,
>>>> Jiayi
>>>>
>>>>
>>>> On Thu, Oct 9, 2014 at 4:05 PM, Marcus Müller >>> <mailto:marcus.muel...@ettus.com>> wrote:
>>>>
>>>> Hi Jiayi,
>>>>
>>>> :) gr-ieee802-11 is, as far as I know, the most comprehensive,
>>>> functional implementation so far. It *can* talk to consumer cards --
>>>> but
>>>> of course, that's not because it has a complete MAC implementation.
>>>> Actually, doing a really standards-compliant IEEE802.11agp MAC can't
>>>> really be done in host software alone -- the gigabit ethernet
>>>> interface
>>>> alone just has too much latency, and you'll have to be really fast
>>>> when
>>>> detecting ACK's, calculating checksums and sending out the reply. I
>>>> doubt you can implement a fully working IEEE802.11 MAC in software
>>>> alone
>>>> without touching the FPGA.
>>>>
>>>> Here's the official source code:
>>>> https://github.com/bastibl/gr-ieee802-11 has the source code, btw.
>>>>
>>>>
>>>> Greetings,
>>>> Marcus
>>>> On 09.10.2014 21:47, Zhang, Jiayi wrote:
>>>>  > Dear Marcus and all,
>>>>  >
&g

Re: [Discuss-gnuradio] Looking for 802.11 MAC & PHY Package

[Vanush Vaswani]

Is it possible to do 11ac on SDR?

On Wed, Oct 15, 2014 at 10:07 PM, Bastian Bloessl  wrote:
> Hi,
>
> On 10/10/2014 06:20 PM, Zhang, Jiayi wrote:
>>
>> Dear Marcus and Bloessl,
>>
>> Thanks for the reply. I also notice the fully functional gr-ieee802-11
>> package provide by Bloessl. Previously I thought it's only PHY, but as
>> Marcus mentioned it also include MAC. It seems to me in the
>> gr-ieee802-11-master package, the MAC does not run csma. I also find the
>> gr-ieee802-11-csma package, which is smaller than the master package but
>> indicate "csma" in name and one of examples.
>
>
> Sorry, I don't get what you mean with smaller. Are you talking about the
> file size of the sources?
> All branches add / parse the MAC header as defined in the standard. So the
> frame format is OK on all branches. The 'csma' branch implements channel
> access for broadcast frames.
>
>> After checking the Readme
>> and other pulications from WIME project, I cannot find detail
>> description regarding the MAC and CSMA function for the package.
>
>
> It's the one at the top
> http://www.ccs-labs.org/bib/bloessl2014timings/
>
>>
>> 1. Does the csma package should be used with the master package?
>
>
> No. 'csma' is the name of a branch. You would checkout and use that branch.
>
>> 2. Does the csma package support multiple nodes in an ad-hoc network?
>
>
> The CSMA implementation is for broadcast frames only. So depends on what you
> want to do.
>
>>
>> Return to Marcus's advice, do you mean that to realize the MAC (CSMA),
>> we still need implement FPGA (not the one in USRP?) to handle it in
>> hardware, no matter we use the software lib, e.g. GRU Radio or Click
>> Module Router?
>
>
> To support CSMA functionality you will have to change the FPGA otherwise you
> will not be able to meet the timing constraints of 802.11. For the broadcast
> case you only need some small changes.
> If you want to support ACKS and RTS/CTS you need a lot of functionality on
> the FPGA. In my opinion this will not happen on a N210, but AFAIK Ettus has
> a 802.11 implementation for RFNoC (i.e. for the FPGA) which most likely
> meets all timing constraints.
>
> Best,
> Bastian
>
>>
>> Many thanks for your help again!
>>
>> Best regards,
>> Jiayi
>>
>>
>> On Thu, Oct 9, 2014 at 4:05 PM, Marcus Müller > > wrote:
>>
>> Hi Jiayi,
>>
>> :) gr-ieee802-11 is, as far as I know, the most comprehensive,
>> functional implementation so far. It *can* talk to consumer cards --
>> but
>> of course, that's not because it has a complete MAC implementation.
>> Actually, doing a really standards-compliant IEEE802.11agp MAC can't
>> really be done in host software alone -- the gigabit ethernet
>> interface
>> alone just has too much latency, and you'll have to be really fast
>> when
>> detecting ACK's, calculating checksums and sending out the reply. I
>> doubt you can implement a fully working IEEE802.11 MAC in software
>> alone
>> without touching the FPGA.
>>
>> Here's the official source code:
>> https://github.com/bastibl/gr-ieee802-11 has the source code, btw.
>>
>>
>> Greetings,
>> Marcus
>> On 09.10.2014 21:47, Zhang, Jiayi wrote:
>>  > Dear Marcus and all,
>>  >
>>  > Many thanks for the advice regarding the Hydra and ORBIT project.
>>  >
>>  > Actually I'm looking for the open-source 802.11 PHY&MAC packages
>> which are
>>  > compatible with Recent GNU Radio and USRP N210/X310.
>>  >
>>  > I've searched from internet and got some findings listed below:
>>  > 1) Hydra PHY & MAC from University of Texas at Austin [1]
>>  > 2) FTW IEEE802.11a/g/p OFDM Frame Encoder [2]
>>  > 3) UWICORE m-HOP 802.11 MAC for USRP based on the FTW PHY [3]
>>  > http://www.uwicore.umh.es/mhop-software.html
>>  > *** All (1-3) only compatible with gnuradio-3.2.2 which was too
>> many years
>>  > ago.
>>  >
>>  > 4) WIME IEEE 802.11a/g/p Transceiver for GNU Radio v3.7 [3]
>>  > http://www.ccs-labs.org/software/gr-ieee802-11/
>>  > *** This is a most recent package for gnuradio 3.7, but is PHY
>> only. Are
>>  > there any MAC package which compatible with this WIME PHY?
>>  >
>>  > 5) ORBIT Project [5]
>>  > *** This is a huge project which can be studied. Are there any
>> project
>>  > provide both 802.11 MAC & PHY like Hydrd did before?
>>  >
>>  > Best regards,
>>  > Jiayi
>>  >
>>  > [1] K. Mandke, Soon-Hyeok Choi, Gibeom Kim, R. Grant, R. Daniels,
>> Wonsoo
>>  > Kim, R. W. Heath, Jr., and S. Nettles, “Early Results on Hydra: A
>> Flexible
>>  > MAC/PHY Multihop Testbed,” Proc. of IEEE Vehicular Tech. Conf. ,
>> pp.
>>  > 1896-1900, Dublin, Ireland, April 23 – 25, 2007.
>>  > [2] http://www.cgran.org/wiki/ftw80211ofdmtx
>>  > [3] J.R. Gutierrez-Agullo, B. Coll-Perales and J. Gozalvez, "An
>> IEEE 802.11
>>  > MAC Software 

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Vanush Vaswani]

I ran into this problem when doing 57.6kbps BPSK decoding, AX.25. The
only way I was able to fix it was to reduce GR_FIXED_BUFFER_SIZE in
flat_flowgraph.cc.
This is regarded as a dodgy hack by all the GR developers here, but it
worked for me (and I read the article on latency). I believe the guy
who wrote GMSKSpacecraftGroundstation had the same problem, and found
it in one of his old threads.

On Sat, Oct 11, 2014 at 5:55 AM, Dan CaJacob  wrote:
> Hey John,
>
> I am way out of my depth here, but while working on a custom python block
> the other day, I saw some weird behavior in 3.7.5 that was similar.  Setting
> the global max output had no effect, but setting the just-upstream block(s)
> min/max output buffer size(s) low fixed my apparent slowliness.
>
> Very Respectfully,
>
> Dan CaJacob
>
> On Fri, Oct 10, 2014 at 2:14 PM, John Malsbury
>  wrote:
>>
>> Default scheduler.
>>
>> tb.start(1024), with different values, etc, etc.
>>
>> Most of the downstream blocks are stock GNU Radio blocks - a delay block
>> (max delay is 1 sample), logical operators, etc.  I guess I'll add some
>> printf debugging?
>>
>> -John
>>
>>
>>
>>
>> On Fri, Oct 10, 2014 at 11:07 AM, Marcus Müller 
>> wrote:
>>>
>>> Hi John,
>>> On 10.10.2014 19:33, John Malsbury wrote:
>>>
>>> Toward the end of the receive chain, there are a multitude of blocks that
>>> are used for Viterbi node synchronization. I've found that the number of
>>> blocks in series (3-5), combined with the low datarates at this point in
>>> the flowgraph, lead to latencies on the order of 1-2 minutes.  That is to
>>> say, once the node synchronization is accomplished, it takes 1-2 minutes
>>> to
>>> flush these blocks and get the fresh, good data through.  This is
>>> measured
>>> with function probes on the state of the sync process, and BERT analysis
>>> of
>>> the demodulator output [through TCP/IP socket].
>>>
>>> I see you found the hidden interplanetary signal delay simulator.
>>> Congrats! Watch out for the red shift in downstream samples.
>>>
>>> No, seriously, that sounds like a lot.
>>> You are using 3.6.4.1 with the default scheduler, tpb?
>>>
>>>- I've tried messing around with the output buffer size option in the
>>>flowgraph, but this seems l to have a negligible impact.
>>>
>>> That surprises me. How did you mess around? top_block->run(1024)?
>>>  Do your blocks really get called with smaller input item sizes? (do a
>>> little printf-debugging)
>>>
>>>- I can write some custom blocks to reduce the overall block count,
>>> but
>>>I have demonstrated that this provides a linear improvement, rather
>>> than
>>>the two-order-magnitude improvement I need.
>>>
>>> Any general advice anyone can offer?  It feels like the right solution is
>>> to force small buffer sizes on the relevant blocks...
>>>
>>> agreed. But still. That sounds *bad*. Are you sure none of the block
>>> demands a large input/output multiple?
>>>
>>>
>>> Greetings,
>>> Marcus
>>>
>>> -John
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Re: [Discuss-gnuradio] inserting code into top_block.py

[Vanush Vaswani]

Shouldn't he "cut" the code?

On Wed, Sep 24, 2014 at 5:53 AM, Jeff Long  wrote:
> The most straightforward way is to make a small Python program that calls
> the class generated by GRC. Copy the autogenerated code after
>
> if __name__ == '__main__'
>
> into another file, and insert your logic before the tb.start() line.
>
> - Jeff
>
>
> On 09/23/2014 03:14 PM, Martin Braun wrote:
>>
>> You might be able to trick the 'Variable' block into doing what you want.
>>
>> M
>>
>> On 23.09.2014 12:01, Ryan Marlow wrote:
>>>
>>> Hey All,
>>> I'm trying to figure out if what I want to do is possible in GNU Radio
>>> Companion or if there's a better way to achieve this functionality.
>>> I have some code that I want to execute after all the blocks and
>>> connections have been initialized in the top_block init()but before the
>>> tb.Start(). Is there some way I can create a custom block that inserts
>>> code into top_block.py at that point or inserts the code at the end of
>>> the init()? I currently have my code running in gnuradio-runtime, but I
>>> want to have this same functionality without altering the gnuradio trunk
>>> code, hence why I'm thinking of a custom block that can insert the code
>>> where I want.
>>> Thanks,
>>> Ryan Marlow
>>>
>>> --
>>> Ryan L. Marlow
>>> Research Assistant in CCM Lab 
>>> Virginia  Polytechnic Institute and State University
>>>
>>>
>>> ___
>>> 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] Problems building GNURadio

[Vanush Vaswani]

Damn, I missed the trick with tmpfs. Usually leave it building overnight on BBB.

On Tue, Sep 23, 2014 at 9:27 AM, Tom Tsou  wrote:
> On Mon, Sep 22, 2014 at 4:08 PM, Philip Balister  wrote:
>> On 09/22/2014 02:13 PM, Tom Tsou wrote:
>>> cmake ../ -DCMAKE_C_FLAGS="-march=armv7-a -mthumb-interwork
>>> -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a15"
>>> -DCMAKE_ASM_FLAGS="-march=armv7-a -mthumb-interwork -mfloat-abi=hard
>>> -mfpu=neon-vfpv4 -mtune=cortex-a15"
>>>
>>
>> We should add the ASM fags to the toolchain files.
>
> For native build, the missing piece is architecture detection. Until
> that works sufficiently well, some type of setting(s) will need to
> feed in manually.
>
> Alternatively, the default gcc target could be setup with reasonable
> values. The arndale-linaro image can also compile gnuradio without any
> command line switches since the gcc defaults are sane.
>
> --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard
>
> Not so with the OE based distros.
>
>>> In this case, the native gnuradio build in tmpfs took a very
>>> reasonable, IMO, 42 min 31 sec.
>>
>> Reasonable for a patient man :)
>
> And power efficient too!
>
>   -TT
>
> ___
> 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 control port monitor

[Vanush Vaswani]

That doesn't specify what the underlying concern was.

On Sat, Sep 13, 2014 at 11:46 PM, Tom Rondeau  wrote:
> On Sat, Sep 13, 2014 at 8:35 AM, Vanush Vaswani  wrote:
>>
>> What are the issues?
>
>
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2014-08/msg00166.html
>
>
> Tom
>
>
>>
>> On Sat, Sep 13, 2014 at 3:38 PM, Sylvain Munaut <246...@gmail.com> wrote:
>> >> Pleas help me to use control port monitor.
>> >
>> > You can't.
>> >
>> > See a mail from Tom Rondeau a few weeks back : ctrl port has been
>> > temporarly removed from gnuradio due to some issues with its
>> > middleware. It's being worked on.
>> >
>> >
>> > Cheers,
>> >
>> > Sylvain
>> >
>> > ___
>> > 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] using control port monitor

[Vanush Vaswani]

What are the issues?

On Sat, Sep 13, 2014 at 3:38 PM, Sylvain Munaut <246...@gmail.com> wrote:
>> Pleas help me to use control port monitor.
>
> You can't.
>
> See a mail from Tom Rondeau a few weeks back : ctrl port has been
> temporarly removed from gnuradio due to some issues with its
> middleware. It's being worked on.
>
>
> Cheers,
>
> Sylvain
>
> ___
> 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] A little bug in GNURadio 3.7.5 API page

[Vanush Vaswani]

Revealing

On Sat, Sep 13, 2014 at 5:57 AM, Carlos Alberto Ruiz Naranjo
 wrote:
> Hello,
>
> the inlude files have the Tom Rondeau path:
>
> http://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1rational__resampler__base__fff.html
>
> #include
> 
>
>
>
> ___
> 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] USRP I/O Buffering

[Vanush Vaswani]

Try messing around with the buffer size in
gnuradio-runtime/lib/flat_flowgraph.cc

#define GR_FIXED_BUFFER_SIZE

On Mon, Sep 8, 2014 at 6:24 AM, Peter Witkowski  wrote:
> Hello,
>
> I have a simple application written in Python using GNURadio.  All I am
> trying to accomplish is to have the USRP data be written to disk.  The
> application works fine when I dump data to /dev/null or run it at reduced
> sampling rates.  However, when I run at my desired sampling rate, I have a
> good amount of buffer overflows (a series of "O" characters get printed).
>
> The host machine that I am working on should have no problems sampling at
> the higher rates, but I have found a curious issue in that not a whole lot
> of memory is used up by my GNURadio application.
>
> As a result, I am wondering if there is any way to tell GNURadio to use
> larger buffers (on the order of a few GB) in order to prevent data from
> being dropped.  I noted that there seem to be several function calls
> available in the C++ API, but there seems to be a limited set of these calls
> in the Python wrappers.  Latency is a non-issue for me at the moment, but I
> need to capture all the data without dropping a large amount of data.  Note
> that I have the code running with "real-time" priorities in Linux.
>
> Thanks for your help.  FYI I am running GNURadio on Ubuntu 14.04.  Also, I
> know that my RAID set-up is capable of writing to disk at twice the rate of
> data coming in per benchmarking the HDDs.
>
> --
> Peter Witkowski
> pwitkow...@gmail.com
>
> ___
> 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] PSK demodulator and Doppler

[Vanush Vaswani]

My solution involved the frequency translating block and a third party
application. As part of the initial channel filter, I set the the "Center
Frequency" attribute to -4+fftshift*rx_shift_factor (assuming my LO
tuned to +40 KHz from the carrier). The satellite tracking program,
PREDICT, provides a Doppler shift calculation assuming a 100 MHz carrier.
rx_shift_factor is the satellite carrier frequency divided by 100 MHz. I
then polled PREDICT, which provides a UDP server interface and then in
Python called set_fftshift method on the flowgraph object generated by
gnuradio-companion. In turn, this would update the taps of the FIR filter
to provide a desired frequency shift.

As for temperature drift, I assumed that with a strong enough signal, the
inbuilt Costas loop would be able to bring the signal back to baseband.

The drawback of this solution is that it's not fully contained within
gnuradio-companion, and like you said, requires the orbital elements to be
known. One solution that uses the PLL block is here:
https://www.cgran.org/wiki/ESTCube-1Receiver




On Wed, Sep 3, 2014 at 4:53 PM, Mike Willis  wrote:

> Hi Colin,
>
>
>
> Not really, though there is an AX25 style header. Far from ideal 0110
> flags.
>
>
>
> Mike
>
>
>
> *From:* Colby Boyer [mailto:colby.bo...@gmail.com]
> *Sent:* 03 September 2014 03:11
> *To:* Mike Willis
> *Cc:* GNU Radio Discussion
> *Subject:* Re: [Discuss-gnuradio] PSK demodulator and Doppler
>
>
>
> On Tue, Sep 2, 2014 at 10:09 AM, Mike Willis  wrote:
>
> I am trying to develop a satellite ground station using the PSK
> demodulator block. This works fine when tuned accurately. However, with low
> satellites there is quite a bit of Doppler at VHF / UHF and there is also
> some frequency drift with satellite temperature as it enters or comes out
> of eclipse. This is a problem as the signals are relatively narrow in
> bandwidth compared to the Doppler and drift. I am wondering how to track
> this Doppler in Gnuradio. I have tried a PLL block and while this works it
> isn’t quite right unless the signal is very strong. It can also get fooled
> by one of the many spurious signals encountered on the bands.
>
>
>
> To some extent the Doppler can be predicted and compensated for, but only
> when the orbital parameters are known accurately. Even a few seconds error
> at TCA can make quite a difference.
>
>
>
> Has anyone solved this one?
>
>
>
> Mike
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> Is there a preamble/training sequence you can search for? If so, you can
> use that to get the initial frequency offset estimate to correct and then
> use the PLL to track the fine phase correction.
>
> ___
> 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] Question about ZeroMQ Sub source

[Vanush Vaswani]

I tried it but it's still very choppy.

I'm not 100% on the scheduler, but if the downstream graph requests 4096
items, and the zmq message size is 8192 items, wouldn't this result in
choppy audio?

Regards,
Vanush


On Sun, Aug 31, 2014 at 3:56 AM, Johnathan Corgan 
wrote:

> On 08/30/2014 10:12 AM, Vanush Vaswani wrote:
> > I've got a question relating to the zmq sub source.
> > I've got a flowgraph that has rtlsdr -> pub sink
>
> With pub/sub, the subscribers must keep up--a pub sinks have fire and
> forget semantics.
>
> Your are better off with push/pull here, the downstream flowgraph will
> pull as needed and the upstream push block will wait.
>
> --
> Johnathan Corgan, Corgan Labs
> SDR/DSP Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about ZeroMQ Sub source

[Vanush Vaswani]

Setting max number of output items in both graphs seems to help this.


On Sun, Aug 31, 2014 at 3:12 AM, Vanush Vaswani  wrote:

> I've got a question relating to the zmq sub source.
> I've got a flowgraph that has rtlsdr -> pub sink
>
> In another graph, I decode FM radio using WBFM receive.
> I noticed that it sounds horrible and choppy (sped up).
> I looked in the code of the sub source, and saw this
>
> // Copy to output buffer and return
> if (msg.size() >= d_itemsize*noutput_items)
> {
> memcpy(out, (void *) msg.data(), d_itemsize*noutput_items);
> return noutput_items;
> } else
> {
> memcpy(out, (void *) msg.data(), msg.size());
> return msg.size() / (d_itemsize);
> }
>
> Does this mean that if the message size is greater then the number of
> items requested by scheduler * item size (e.g. complex = 8), the rest of
> the message is simply dropped?
>
> This is probably the reason for the choppy audio. How can a situation like
> this be avoided?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Question about ZeroMQ Sub source

[Vanush Vaswani]

I've got a question relating to the zmq sub source.
I've got a flowgraph that has rtlsdr -> pub sink

In another graph, I decode FM radio using WBFM receive.
I noticed that it sounds horrible and choppy (sped up).
I looked in the code of the sub source, and saw this

// Copy to output buffer and return
if (msg.size() >= d_itemsize*noutput_items)
{
memcpy(out, (void *) msg.data(), d_itemsize*noutput_items);
return noutput_items;
} else
{
memcpy(out, (void *) msg.data(), msg.size());
return msg.size() / (d_itemsize);
}

Does this mean that if the message size is greater then the number of items
requested by scheduler * item size (e.g. complex = 8), the rest of the
message is simply dropped?

This is probably the reason for the choppy audio. How can a situation like
this be avoided?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Hier block I/O's

[Vanush Vaswani]

I have a custom application which consists of a top block with an inter
changeable hier block as the guts. It is then possible to dynamically alter
the final, "real" sink that the Pad Sink connects to. I can discern the IO
type of the pad sink from the signature of the hier block, but it would be
good if I could describe it in a user friendly way, e.g., this output will
be the "FFT", this output will be some time series data and so on.
Unfortunately, it doesn't look like the label is stored in Python.


On Sat, Feb 15, 2014 at 6:34 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Vanush,
>
> I don't really understand your question. Could you rephrase/elaborate?
> Also, what would you want to do with that reference?
>
> Greetings,
> Marcus
>
> On 15.02.2014 04:50, Vanush Vaswani wrote:
> > When including a hier block in a custom Python application, is
> > there any way to retrieve a reference to the pad source/sink with
> > it's label?
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJS/xijAAoJEAFxB7BbsDrLNRoH/39n5dNFX6o8CuhCcOCcNobY
> XvCOMkMErWfgUyogQpXcRe4b6zazYsv62mGLQvdIFe7ZftVgLfq118u9QbydJcse
> tkDAEu9eM1IuwpGimPSbVI5zKuatonbrdL2cPZSeU7dQRYyku2Vj3T/XKUOvJkfJ
> njYFs7WwIKhAWYWTfXmLJpq0a4qCsdln9LdNuK5SdljIPZtyAVYOk9NL0hPGSvg+
> nH9OJJAxcdVy9PejBMwwVQxMwqRXw/UlCKGDwHhkXzhKmBjmt0uN68WHUumpiH3B
> gDfXurmD7rmeAvIT4CMmWIuX1p8o6Z7TNO8aEfDeaHfTAGaNJ5G077LoxytOOI0=
> =PJhi
> -END PGP SIGNATURE-
>
> ___
> 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] New GR Tutorials Posted

[Vanush Vaswani]

There's no indications of who authored the material?




On Tue, Aug 12, 2014 at 9:25 AM, Tom Rondeau  wrote:

> On Mon, Aug 11, 2014 at 7:10 PM, madengr  wrote:
>
>> I stumbled upon these a couple weeks ago; they look really good!  If we
>> find
>> any needed corrections, do we post them to this thread?
>>
>> Thanks,
>> Lou
>> KD4HSO
>>
>
> Well, you had to be clever and jump ahead of the rest of the class! I
> moved the page names and added a front page that's linked below. On there
> you'll see to send all feedback and bug reports to tutori...@gnuradio.org.
>
> Tom
>
>
>
>> Tom Rondeau-2 wrote
>> > Hi everyone,
>> >
>> > I would like to invite you all to check out and beta test our new GNU
>> > Radio
>> > Tutorials:
>> >
>> > http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>>
>
> ___
> 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] gnuradio on ubuntu touch

[Vanush Vaswani]

On those single board computers I don't bother writing to SD. I just route
it through the network (assuming large enough bandwidth) to another graph
or Python script that dumps it to a disk with faster storage bus.

You can use gr-zmqblocks for that.


On Wed, Aug 6, 2014 at 11:51 PM, Marcus Müller 
wrote:

> The overflow is not a result of buffering; in fact, buffering helps.
>
> overflows happen because at any bottleneck in your processing chain,
> samples start to stagnate, causing back pressure. When all buffers are
> filled, there's nothing the rtl source can do but drop samples. That's
> an overflow.
>
> A computationally intense filter might also lead to overflows, but here
> it's because your CPU can't keep up with the sample rate, whereas with
> the file sink, your storage can't sustain the write rates.
>
> Greetings,
> Marcus
>
> On 06.08.2014 15:44, rejunte wrote:
> > I tried what Vanush said and just connected RTL-SDR Source to a Null
> Sink and
> > got no overflows.
> >
> > I'm using a class 10 sd card, that must be the problem.
> >
> > I did some demodulation with no problem, but when I add a Low Pass
> Filter,
> > the overflow happens again.
> >
> > Would the filter do the same thing as the file sink and buffer the data
> > causing the overflow?
> >
> >
> >
> > --
> > View this message in context:
> http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49799.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 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] gnuradio on ubuntu touch

[Vanush Vaswani]

It might be Disk I/O is too slow. Try going from RTL-SDR source to Null
Sink.



On Wed, Aug 6, 2014 at 7:46 AM, rejunte  wrote:

> Hi Marcus, back to this discussion after a few tests.
>
> I decided to try RTL-SDR and GNU Radio on a Single Board Computer.
>
> I'm currently using the Banana Pi which is a ARM Cortex-A7 dual-core, 1GHz,
> Mali400MP2 GPU, 1GB DDR3 DRAM, using a debian based system.
>
> The first thing I tried was just a simple RTL-SDR Source to File Sink -
> just
> saving the receiving data to a file at 2e6 sample_rate.
>
> The problem is that I get the "0" characters on the terminal indicating
> overflow status.
>
> I don´t know if I'm doing something wrong or if the banana pi can´t handle
> real-time signal process.
>
> What do you think about that?
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49773.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVB-S2X update to gr-dvbs2

[Vanush Vaswani]

Wonderful. Now we need a constellation that follows the golden spiral.


On Sat, Jul 26, 2014 at 10:20 AM, Ron Economos  wrote:

>  gr-dvbs2 has been updated to include all of the normal frame size
> code rates, roll-off factors and constellations in the DVB-S2 extension
> specification, DVB-S2X. Note that gr-dvbs2 is transmit only.
>
> https://github.com/drmpeg/gr-dvbs2
>
>
> https://www.dvb.org/resources/public/standards/a83-2_dvb-s2x_den302307-2.pdf
>
> Since the specification was just released in March 2014, there
> are no consumer of prosumer receivers available yet. Therefore,
> the new DVB-S2X modes are not fully tested. However,
> there are only minor software changes required, so confidence
> is high that the new modes will work properly. Regular DVB-S2
> modes have been retested to ensure there are no regression
> problems.
>
> Here's what one of the 256APSK constellations looks like in GRC.
>
> [image: 256APSK]
>
> Ron
>
>
> ___
> 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] gnuradio dataflow, buffering and scheduling

[Vanush Vaswani]

http://www.trondeau.com/storage/tutorial/gr_scheduler_overview.pdf


On Wed, Jul 23, 2014 at 2:32 AM, Anh Duc Nguyen  wrote:

> Dear all,
>
> I wish to study how gnuradio handles the dataflow,e.g., buffering,
> scheduling, synchronization, optimization as well as resultant latency in
> detail. However, I can not find any material that explain such things
> clearly. Could you please point me to direct or indirect resources e.g., in
> literature which present I need. I would appreciate it much,
>
> With best regards,
>
> Nguyen Anh Duc
>
> ___
> 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] Good example of AGC after RTL_SDR

[Vanush Vaswani]

Wouldn't it be easier to add some front-end filtering?

On Fri, Jul 18, 2014 at 1:32 AM,   wrote:
> Thanks Tom ... you are right it is not surprising -- but what I am surprised
> at is how good a job the builtin AGC does for most cases and maximizes the
> value of the limited dynamic range. Also, your explanation of the AGC
> matches my observations so its out.
>
> This is what I'm thinking (out-loud  so don't laugh) ... I have a channel
> that should be free of most signals (through FCC allocation and observation
> ... lets call it dark_channel). I can put that through an xlat_fir and get
> the resulting power of the noise floor in that channel ( should be relative
> noise floor of the sampled spectrum, call it dark_channel_power). I assume I
> can also measure the peak coming out of the source (call this
> peak_source_power). I'm envisioning a block that would set a gain based on
> the limiting peak_source_power to less than say 80% of signal peak and
> limiting dark_channel_power to some acceptable upper limit (probably derived
> from experimentation). The gain value would have to be filtered obvious to
> some reasonable time-constant.
>
> Questions:
> -- Does this sound reasonable? Can anyone poke a hole in it? Is there a more
> conventional approach?
> -- What would be a good block would measure the power of the dark_channel
> and source signals?
> -- For the near-far paradox ... dark_channel_power sets my max gain for far
> signals and source_power sets my min_gain for near signals -- is this a
> reasonable approach
> -- Is there a good starting point for the block to convolve these two power
> measurements into a hardware gain setting? (remote, but had to ask)
>
> Jim
>
>
> ___
> 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] [GSoC] gr-radar: Dual CW Radar and Tracking Algorithms

[Vanush Vaswani]

Nice. I don't know much about radar. Is range related to EIRP?

On Wed, Jul 16, 2014 at 1:14 AM, Stefan Wunsch
 wrote:
> Hi,
>
> The Radar Toolbox has new features!
>
> First new feature of the Radar Toolbox is a Dual CW Radar. It is
> implemented as simulation and tested with USRPs. This setup is much more
> better than the previous FSK Radar!
> Check out my development blog for a demonstration video and further
> information. [0]
>
> Second feature is a cooperation with a bachelor student at the CEL [2].
> His thesis is about tracking algorithms for radar signal processing.
> Realtime tracking with a SIR particle filter and an unscented kalman
> filter is implemented and tested on hardware.
> There is also a video on my blog with the comparison of the tracking and
> the not past processed detections. [1]
>
> Furthermore OFDM Radar signal processing with a new GUI block is coming
> these days!
>
> Greetings,
> Stefan
>
> [0] Dual CW Radar
> https://grradar.wordpress.com/2014/07/15/dual-cw-radar-demonstration/
>
> [1] Tracking Algorithms
> https://grradar.wordpress.com/2014/07/04/realtime-tracking-with-particle-filter-algorithm/
>
> [2] Communications Engineering Lab
> http://www.cel.kit.edu/english/index.php
>
> ___
> 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] GMSK Transmit

[Vanush Vaswani]

It is dependent on sample rate of graph. You may check this video for
an example to transmit 9600 bps GFSK

https://www.youtube.com/watch?v=N1hR6VgWeow&feature=youtu.be

In this case, sample rate effectively set by throttle block because of
no real hardware:
96000 samples/second

GFSK modulator:
10 samples/symbol

results in 9600 symbols/second and assuming 1 bit per symbol, 9600 bps.

On Wed, Jul 16, 2014 at 9:01 AM, John Malsbury
 wrote:
> Fortunately, the rate is set by the USRP sample rate, not by the rate of the
> UDP block.
>
>
> -John
>
>
> On Tue, Jul 15, 2014 at 3:50 PM, Al Anderson  wrote:
>>
>> I am working a project where I need to receive bytes via a UDP source,
>> encode as GMSK and transmit via Ettus UHD.
>>
>> My main question is how do I set the bit rate since I really cannot
>> control the UDP source? My receiving radio is expecting 9600 bps.
>>
>> Thank you,
>>
>> Al
>>
>> --
>>
>>
>> 
>> Al Anderson, N0XV
>> Director, IT Services
>> Salish Kootenai College
>> (p) 406.275.4833
>> (c) 406.214.8292
>> al_ander...@skc.edu
>>
>>
>>
>>
>> ___
>> 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] 'Counts' in WX Scope Plot

[Vanush Vaswani]

I think 'Magnitude' is better than counts, which is just confusing.

On Wed, Jul 9, 2014 at 7:19 PM, Sylvain Munaut <246...@gmail.com> wrote:
> On Wed, Jul 9, 2014 at 11:09 AM, jsam45  wrote:
>> The vertical axis in Scope Plot is labelled as Counts. What does it mean? How
>> is it related to the physical parameters of the signal like amplitude/power?
>
> It's dependent on your hardware.
>
> Basically 'count' is just the raw value and what that value means is
> whatever the source block returned. It can be normalized between -1.0
> and 1.0 or represent the raw adc value, and then what voltage the
> represents depends on the ADC reference used in your hw. What power it
> represent at the input depends on the total gain in the rx chain from
> input to ADC ...
>
> All of that is out-of-scope for GR, you have to calibrate it out if
> you want absolute/known units.
>
> Cheers,
>
>Sylvain
>
> ___
> 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] Morse code (CW) decoder for GNURadio

[Vanush Vaswani]

Dear all, I am looking for a morse code decoder for gnuradio, does
anyone have a link?

Regards
Vanush

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

Re: [Discuss-gnuradio] difference b/w sample rate and symbols per second

[Vanush Vaswani]

You may refer to this example to see how to transmit 9.6kbps GFSK
signal through an AWGN channel.

https://www.youtube.com/watch?v=N1hR6VgWeow&feature=youtu.be



On Sun, Jul 6, 2014 at 12:00 AM, Marcus Müller  wrote:
> We might be talking about different blocks.
> I'm referring to gr::analog::frequency_modulator_fc, where the
> documentation only says[1]
>
> radians/sample = amplitude * sensitivity
>
> From what you paste as formulas this does not look like the general
> frequency modulation, but like a digital modulation scheme, e.g. GMSK.
>
> Anyway, we will not be able to tell you what you'll need to use as
> parameters for your transmitter -- that is something that you, based on
> your communication engineering skills, will need to decide yourself.
>
> Sincerely,
> Marcus Müller
>
> [1]http://gnuradio.org/doc/doxygen/classgr_1_1analog_1_1frequency__modulator__fc.html#a9c252eeb8c9daf6ccd50427d3bc55bd3
>
> On 05.07.2014 09:59, jason sam wrote:
>> Sorry for prolonging the discussion but I am a bit confused here.The
>> sensitivity parameter for Freq Mod block is defined as:
>>
>> sensitivity = (pi * modulation_index) / samples_per_symbol
>> where,
>>
>> modulation_index = deviation / (baud_rate / 2)
>>
>> So what values should i plug in for samples_per_symbol and baud_rate
>> in the formulas?
>>
>>
>> On Fri, Jul 4, 2014 at 9:14 PM, Marcus Müller  
>> wrote:
>>> Not at all, because for these blocks, symbols have no meaning.
>>>
>>> On 04.07.2014 17:38, jason sam wrote:
 Yes Marcus,u are r right and i am also asking about such blocks like
 the FM Mod block..In this block u have an option to set sample rate
 but how can u set samples per symbol??

 On Fri, Jul 4, 2014 at 6:08 PM, Marcus Müller  
 wrote:
> Hi Ali,
> as said several times: Sampling rate, samples per symbol etc are
> concepts that are meaningful only for certain blocks, and thus there is
> no sense in setting those globally.
>
> Greetings,
> Marcus
> On 04.07.2014 08:33, jason sam wrote:
>> Thanx Martin,but where in GRC we can set samples per symbol??I am new
>> to this so i don't know yet...
>>
>> Ali
>>
>> On Tue, Jul 1, 2014 at 2:18 PM, Martin Braun  
>> wrote:
>>> On 06/26/2014 11:06 AM, jason sam wrote:
 I am bit confused b/w the two terms.I have read some material and i
 got the following relationship b/w the two:
 samples/second =samples/symbol * symbols/second
 And i think in GRC samples per symbol is 1(plz correct if i am
 wrong).So sample rate becomes equal to baud rate(symbols/second)??
>>> samples per symbol is whatever you set it to; common values are 2 and 4
>>> (this also depends on the modulation used). Higher values are often used
>>> for demo purposes.
>>>
>>> M
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> 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] BER measurement for GMSK transmission with USRP wirelessly

[Vanush Vaswani]

GMSK Mod takes in packed bytes, Demod outputs unpacked bytes (e.g. 1
bit per byte). You may need to perform a conversion. Best way to
figure out is to post a screenshot of your flowgraph.

On Fri, Jul 4, 2014 at 6:18 PM, Sun Wenbin  wrote:
> Good day everyone,
>
> My sincere apology in advance if this question has been asked before, but i
> tried search thru the archives but to no avail.
>
>
> Currently, I am trying to calculate the BER for GMSK, But first I started
> off on a perfect channel without USRP.
>
>
> My current block diagram is as follows:
>
> "Random Source"
> 0s and 1s, 10^6 windows -> "Throttle" -> "GMSK Mod (default settings)" ->
> "GMSK Demod (default settings)" -> "Error Rate Block"
>
> I am feeding in "Error Rate block" with the random source and the "GMSK
> Demod" Output.
>
> I am getting BER of 50%... Anyone knows what is wrong?
>
> In fact, I saved the input and output as binary files. I found out that they
> are not very identical especially in terms of binary length. I tried input 9
> bits of binary and I obtained 63 bits from the GMSK Demod Output.
>
> Is there something that is missing?
>
> Hope someone can advise me. Thank you :)
>
> Best Regards,
> Sun
>
> ___
> 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] post_guard and pre_guard in Pecog implementation

[Vanush Vaswani]

You may check here

https://github.com/guruofquality/gras/wiki/History


On Sun, Jun 8, 2014 at 1:14 AM, Jay Prakash 
wrote:

>
> I was revisiting my previous work on FHSS based CR test bed setup designed
> using GRAS.
>
> 1. I could not appreciably acknowledge the use of post_gurad and pre_guard
> in FHSS implementation of Pre-Cog.
> Could some one explain?
>
> I guess it would be for tuning/ stabilization time!
>
> 2. Has FHSS been implemented using new Messaging API of GRAS, as earlier
> implementation using gr-extras?
>
> 3. Has there been new additions/ projects to GRAS? I read past few months
> mail list archive. I was surprised to see there has been hardly any
> reference to this beautiful feature!
>
> Jay Prakash
>
>
> ___
> 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] Writing wav file in GMSK TX, RX

[Vanush Vaswani]

Make sure you close the .wav file by pressing 'x' (close) button on a
graphical sink, otherwise it won't write the wav file correctly.
Check here: http://gnuradio.org/redmine/issues/544

Otherwise, try playing in VLC.


On Mon, Jun 9, 2014 at 4:57 PM, dushyant.marathe 
wrote:

> Hi Activecat,
>
> Thanks for the reply.
>
> I am playing wav file using windows media player. When I execute the flow
> graph it writes wav file. Wav file's size increases, unless I stop the flow
> graph. But when I played it using media player it doesn't play any more.
>
> Also I am ensuring that amplitude is in the range of -1 and +1.
>
> Plz note that I am not using Audio sink. I am using 'Wav sink block'
>
> I want to tell you that, I am using Gnu Radio 3.7.3. Moreover My Ubuntu
> 12.04 is installed on Virtual machine.
>
> Regards,
> Dushyant
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Writing-wav-file-in-GMSK-TX-RX-tp48857p48860.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Measurement Toolbox -- GSoC '14 Project

[Vanush Vaswani]

https://github.com/guruofquality/gras/wiki/History


On Mon, May 26, 2014 at 6:46 AM, Bogdan Diaconescu
wrote:

> Hi Marcus,
>
> take your time :) this is not a simple problem to solve and hence it does
> not have a simple solution. I like the idea of starting with changing the
> scheduler behaviour first to experiment with. Indeed it will take a lot of
> measurements, talks, experiments (not exactly in this order) to understand
> what is to be optimized.
>
> But this talk is touching the gnuradio scheduler area which is an area of
> its own and it brings me to one question: what happen with GRAS?
>
> Thanks,
> Bogdan
>
>
>   On Sunday, May 25, 2014 10:14 PM, Marcus Müller 
> wrote:
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Bogdan,
>
> thanks for your comment :)
>
> Such an optimizer would be really, really fancy.
>
> In a way, though, GNU Radio already does this when running a flow
> graph: It just asks blocks to compute a reasonable amount of items to
> fill up the downstream buffer. This actually (conceptually simple)
> approach is one great strength, because it just keeps the computer
> "busy" as much as possible.
>
> There might be space for optimization, though, I agree: Maybe it would
> be better for some blocks just to wait longer (and thus, not utilize
> the CPU) if it was computationally beneficial to work on larger
> chunks, as long as there are enough other blocks competing for CPU power.
>
> However, this leads to the problem of balancing average throughput
> with latency.
>
> What the GNU Radio infrastructure does to approach this is actually
> quite simple:
> 1. Although it might be "fastest" to process all data at once, buffer
> lengths set a natural limit to the chunk size, and thus latency. So we
> have an upper boundary.
> 2. It is best to be closest possible to that upper boundary. To
> achieve that, block developers are always encouraged to consume as
> many input items and produce as much output as possible, even if the
> overhead of having multiple (general_)work calls is minute. This
> ensures that adjacent blocks don't get asked to produce / consume
> small item chunks (which will happen if they were in a waiting state
> and a small number of items was produced or a small amount of output
> buffer was marked as read).
>
> Optimizing this will be hard. Maybe one could profile the same
> flowgraph with a lot of different settings of per-block maximum output
> chunk sizes, but I do believe this will only give as little more
> information than what the block developer already knew when he
> optimized the block in the first place. If he didn't optimize, his
> main interest will be if his block poses a problem at at all; for
> that, standard settings should be employed.
>
> To give developers an API to inform the runtime of item amount
> preference, different methods exist, however. I'll give a short
> rundown of them.
>
> 1. Most notable are the ``fixed_rate properties`` of ``gr::block``, as
> implemented in ``sync_block``, and the ``decimator`` and
> ``interpolator`` block types
> 2. If your block will only produce a multiples of a certain number of
> items, the ``set_output_multiple`` is a method that will potentially
> decrease overhead introduced by pointless calls to ``forecast`` and/or
> ``work``.
> 3. In hardware optimization, alignment is often the performance
> critical factor. To account for that, set_alignment was introduced.
> It's working very similar to ``set_output_multiple``, but does not
> *enforce* the multiples, but sets an unaligned flag if non-multiple
> consumption occurred. The runtime will always try to achieve that the
> start of your current item chunk is memory-aligned to a certain item
> multiple. If however less was produced, your block might still be
> called, to keep the data flowing.
>
> To properly apply these flags, you'll basically need a human
> understanding of what the block does. It may, nevertheless, be very
> helpful to understand how well your block performs with different item
> chunk sizes. To realize that, some mechanism to change scheduling
> behavior
>
> I will look into that; I think it should be possible to manipulate the
> ``block_executors`` to manipulate them into changing their
> forecasting/work calling behavior at runtime, but I'm quite sure that
> this will bring new code into the main tree[1].
>
> All in all, right now I'm really stuck with what I actually want to
> improve with the performance analysis of GNU Radio flowgraphs offered
> by performance counters/gr-perf-monitorx, because they address many of
> these issues already. Your execution-per-item over chunk size idea is
> excellent!
>
> So long,
> Greetings,
> Marcus
>
> [1] I'll really have to take a dp look at block_executor and the
> tpb scheduler to tell; if I decide to add functionality that
> introduces significant runtime overhead or changes too much of
> internal behaviour, noone will be pleased, so I might take this slow
> and will have to di

Re: [Discuss-gnuradio] gnu radio - vhdl

[Vanush Vaswani]

maybe one day
http://gnuradio.squarespace.com/storage/grcon13_presentations/grcon13_ettus_rfnoc.pdf


On Wed, May 28, 2014 at 4:51 AM, Martin Braun wrote:

> On 05/27/2014 04:10 PM, MHMND Herath wrote:
> > Is there a way to convert c++ blocks and connections to VHDL code for
> > implementing them in digital way
>
> Not out of the box.
>
> M
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Build on ubuntu 14.04

[Vanush Vaswani]

Cython?


On Sun, May 25, 2014 at 9:48 PM, Robert McGwier  wrote:

> And what is the size of the VM disk limited to and how much RAM have you
> allowed it?  The step you are showing as exiting in (SWIG) requires lots of
> resources in building gnuradio.  I hate SWIG, but have no idea what in the
> world we would do without it.
>
>
> On Sun, May 25, 2014 at 6:16 AM, Marcus Müller 
> wrote:
>
>> Hi Michael,
>>
>> build-grc.sh is not known to me; I think you're referring to
>> build-gnuradio? (grc is short for GNU Radio Companion, the graphical
>> Flowgraph Designer included in GNU Radio).
>>
>> There have been problems with builds on Ubuntu 14.04.
>>
>> However, your output indicates no error; so I'm not quite sure how to
>> help you. Maybe put the complete log somewhere on pastebin or
>> gist.github.com?
>> By the way, pybombs is the recommended way to go for modern systems.
>>
>> If you really just want a running Linux VM with GNU Radio installed, try
>> the LiveDVD images:
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
>>
>> Greetings,
>> Marcus
>>
>>
>> On 25.05.2014 11:29, Michael Hartje wrote:
>> > Dear list,
>> >
>> > I try to compile the new GR 3.7.4-git.
>> >
>> > But it breaks with pybombs as well as with the script build-grc.sh
>> > The job is done inside of a virtualbox-environment. host: win8.1, guest
>> > ubuntu 14.04 + updates
>> >
>> > Mem 1600 MB
>> >
>> > cut of the script build-grc.sh  log
>> > -8<
>> > -- CPU missing cvtpi32_ps, Overruled arch avx
>> > -- Check size of void*[8]
>> > -- Check size of void*[8] - done
>> > -- CPU width is 64 bits, Overruled arch 32
>> > -- Available architectures:
>> >
>> generic;64;3dnow;abm;popcount;mmx;sse;sse2;orc;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2
>> > -- Available machines:
>> >
>> generic_orc;sse2_64_mmx_orc;sse3_64_orc;ssse3_64_orc;sse4_a_64_orc;sse4_1_64_orc;sse4_2_64_orc
>> > -- BUILTTYPERELWITHDEBINFO
>> > -- Base cflags = -O2 -g -DNDEBUG
>> > -- BUILD INFO ::: generic_orc ::: GNU ::: -O2 -g -DNDEBUG
>> > -- BUILD INFO ::: sse2_64_mmx_orc ::: GNU ::: -O2 -g -DNDEBUG  -m64
>> > -mmmx -msse -msse2
>> > -- BUILD INFO ::: sse3_64_orc ::: GNU ::: -O2 -g -DNDEBUG  -m64 -mmmx
>> > -msse -msse2 -msse3
>> > -- BUILD INFO ::: ssse3_64_orc ::: GNU ::: -O2 -g -DNDEBUG  -m64 -mmmx
>> > -msse -msse2 -msse3 -mssse3
>> > -- BUILD INFO ::: sse4_a_64_orc ::: GNU ::: -O2 -g -DNDEBUG  -m64 -mmmx
>> > -msse -msse2 -msse3 -msse4a -mpopcnt
>> > -- BUILD INFO ::: sse4_1_64_orc ::: GNU ::: -O2 -g -DNDEBUG  -m64 -mmmx
>> > -msse -msse2 -msse3 -mssse3 -msse4.1
>> > -- BUILD INFO ::: sse4_2_64_orc ::: GNU ::: -O2 -g -DNDEBUG  -m64 -mmmx
>> > -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mpopcnt
>> > -- Compiler Version: cc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
>> > Copyright (C) 2013 Free Software Foundation, Inc.
>> > This is free software; see the source for copying conditions.  There is
>> NO
>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>> > -- Loading build date Thu, 22 May 2014 18:56:46 into constants...
>> > -- Loading version 0.1 into constants...
>> > -- Using install prefix: /usr/local
>> > -- ENABLE_GR_LOG set to ON.
>> > -- HAVE_LOG4CPP set to False.
>> > -- LOG4CPP_LIBRARIES set to .
>> > -8<
>> > and some lines down during config of gnuradio
>> > -8<
>> > -- Boost version: 1.54.0
>> > -- Found the following Boost libraries:
>> > --   date_time
>> > --   program_options
>> > --   filesystem
>> > --   system
>> > --   thread
>> > -- Enabling use of known bad versions of Boost.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Bob McGwier
> Co-Owner and Technical Director, Federated Wireless, LLC
> Professor Virginia Tech
> Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
> Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
>
> ___
> 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] Error building with new ZMQ

[Vanush Vaswani]

https://github.com/zeromq/cppzmq/blob/master/zmq.hpp


On Tue, May 20, 2014 at 12:27 PM, Michael Dickens  wrote:

> If I change all of the "zmq.hpp" #include lines to be instead "zmq.h",
> then I get the following errors:
> {{{
> :info:build In file included from
> /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-devel/work/gnuradio-cb0bc7f070c41825ab7aee7f093dc326e62e2fdb/gr-zeromq/lib/sub_source_impl.cc:28:
> :info:build
> /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-devel/work/gnuradio-cb0bc7f070c41825ab7aee7f093dc326e62e2fdb/gr-zeromq/lib/sub_source_impl.h:38:7:
> error: use of undeclared identifier 'zmq'
> :info:build   zmq::context_t  *d_context;
> :info:build   ^
> :info:build
> /opt/local/var/macports/build/_opt_MacPorts_trunk_dports_science_gnuradio/gnuradio-devel/work/gnuradio-cb0bc7f070c41825ab7aee7f093dc326e62e2fdb/gr-zeromq/lib/sub_source_impl.h:39:7:
> error: use of undeclared identifier 'zmq'
> :info:build   zmq::socket_t   *d_socket;
> :info:build   ^
> }}}
>
> So ... it seems like unless there's some standard way to get zmq.hpp then
> we won't be using gr-zeromq on OSX.  Any ideas?  Can someone send me that
> file? - MLD
>
> On May 19, 2014, at 3:59 PM, Michael Dickens 
> wrote:
> > If I look through the tarball for zmq 3.2.4 or 4.0.4, I find only zmq.h,
> no zmq.hpp.  From the look of it, zmq is written as mixed C/C++, and the
> API header is purely C (wrapped with extern "C" if included as C++).
>  Hence, I think the CMake Find file needs to check for both zmq.hpp and
> zmq.h as the header, then somehow get that info into the gr-zeromq sources.
> - MLD
>
>
> ___
> 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] Merge multiple complex streams

[Vanush Vaswani]

What about the passive radar - didn't the author daisy chain the clocks of
several RTLSDR?

Regards,
Vanush


On Wed, May 14, 2014 at 4:31 PM, Imre  wrote:

> We must not forget that each device has its own USB connection.
> One reason that getting all in sync on a ' per sample'  base must be
> impossible.
>
> Still a multi user system like the websdr can achieved by overlapping the
> channels and let the software decide what channel the user's choice fits.
>
> For a nice graphical representation (Spectrum analyzer, waterfall) this
> principle could work well.
>
> Imre
>
>
>
>
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Merge-multiple-complex-streams-tp48146p48198.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python chaos

[Vanush Vaswani]

Tom,

Have you looked at PyQtGraph? I've had some success with it.

Vanush


On Thu, Dec 5, 2013 at 1:50 AM, Tom Rondeau  wrote:

> On Wed, Dec 4, 2013 at 4:49 AM, Stefan Gofferje 
> wrote:
> > Well, joy was short... I added a QT GUI range item and...
> >
> > Traceback (most recent call last):
> >   File "/home/sgofferj/top_block.py", line 16, in 
> > import PyQt4.Qwt5 as Qwt
> > ImportError: No module named Qwt5
> >
> > libqwt5 *is* installed and there's no "qwt5" package in any repo I know
> > off...
>
>
> You must also have python-qwt5 (or PyQWT) installed to use these widgets.
>
> And to respond to the above comment from the OpenSUSE mailing list you
> posted, this is /not/ reinventing the wheel. We are doing something
> completely different with Qwt than what PyQwt does to make all of the
> blocks work in C++. We make our own QWT widgets in C++ and then export
> those. But we also use PyQWT for things that are naturally supported
> there.
>
> Plus, PyQWT has stopped development and has even stated that they will
> not support QWT6, which is a shame and will eventually cause us and
> anyone else trying to use PyQWT real issues in the future. I've been
> looking for an alternative to it.
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USB Hub with software controllable power supply for SDR

[Vanush Vaswani]

Hi all,

I'm looking for a USB hub that allows software control of each port.
I have a FunCube Dongle Pro+ trying to pick up satellite signals; but as
the dongle is plugged in continously, I believe it heats up and degrades
SNR.
Let me know if you can think of any solutions

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

Re: [Discuss-gnuradio] Python chaos

[Vanush Vaswani]

The lack of notice for Generate Options is a killer. Not to mention, if
using QT sinks with WX GUI set, a cryptic error message is the reuslt.


On Mon, May 5, 2014 at 8:20 PM, activecat  wrote:

> Tom Rondeau-2 wrote
> > Plus, PyQWT has stopped development and has even stated that they will
> > not support QWT6, which is a shame and will eventually cause us and
> > anyone else trying to use PyQWT real issues in the future. I've been
> > looking for an alternative to it.
>
> Will this affect gnuradio moving away from wxwidgets toward Qt ?
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Python-chaos-tp45076p47953.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] On air 16_QAM transmission problem with USRP N210

[Vanush Vaswani]

You'll have to attach the flowgraph.


On Wed, Apr 30, 2014 at 7:22 AM, zielalaoui  wrote:

> Hi all,
> I am trying to build transmission on air by using USRPs N210. The
> transmission is good with MPSK modulations but when i try to use 16_QAM i
> could not receive data (0 bytes at the reception). I tried to adapte
> transmission power, gain at the tranmitter, gain at receiver, samp_rate but
> the reception file still always empty. This is my flow graph:
> Tx: file source => packet encoder => QAM mod => mult constant = 0.4 => UHD
> usrp sink
> Rx : UHD usrp source => QAM demod => packet decoder => file sink
> samp_rate= 2M
> samples/symbol = 8
> centre frequency=2.4G
> Any proposition will be appreciate
> Thanks to all
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to reduce reconfiguration latency

[Vanush Vaswani]

Try decreasing the buffer size in gnuradio-runtime/lib/flat_flowgraph.cc
I use:
#define GR_FIXED_BUFFER_SIZE 2048


On Fri, Apr 25, 2014 at 9:08 AM, Bolin Hsu  wrote:

> I found pausing the flow graph to be the wrong action for my situation.
>
> I tried to find out how many samples are in my flow graph. I inserted
> logging to the work function of two blocks in my flow graph. One is the
> signal source whose frequency is altered if a frequency shift is detected.
> The other is the last block of my flow graph. The log prints the value of
> nitems_written() of the blocks. The difference of the items written
> between these two blocks is roughly equal to the samples I lost waiting for
> the new setting to take effect. So I think the latency is the time it takes
> to drain the samples that has gone too far down the flow graph to be
> affected by the new setting.
>
> Obviously pausing the flow graph won't help. Instead, it would be helpful
> if I could speed up draining the samples that can't be affected by the new
> setting, something like flowgraph.clear_downstream(basic_block_sptr
> start_block), which discards all samples in blocks that is reachable from
> start_block's output ports according to the flow graph. The time spent on
> moving and processing useless samples could be saved. Does this idea make
> sense?
>
> Thanks,
> Bolin
>
>
> On Wed, Apr 23, 2014 at 5:11 PM, Bolin Hsu  wrote:
>
>> I wish to report my findings on the idea of pausing the flow graph, and
>> hope to get feedback from the experts on this list. I only started using
>> GNU radio last month so it is likely I didn't have enough experience to
>> understand it properly.
>>
>> My understanding of the flow graph execution was a scheduler checks the
>> blocks in a round robin fashion, and execute the work function of a block
>> if the block can make progress. So my intention was to add functions to the
>> scheduler to allow pause and resume from python via top block. When paused,
>> the scheduler won't run any block's work function.
>>
>> I looked into the scheduler source code to find ways of implementing
>> pause and resume. It seems very hard to pass the intention to pause or
>> resume to the scheduler. Specifically, top_block_impl creates a
>> scheduler_tpb, and scheduler_tpb creates a thread using the 
>> functorthread_body_wrapper. The thread_body_wrapper contains another
>> functor tpb_container. In tpb_container's () operator, a tpb_thread_body
>> is constructed. So the way scheduler_tpb runs a block is by creating a
>> thread that runs the constructor of tpb_thread_body through two levels
>> of functors. The tpb_thread_body constructor contains an infinite loop.
>> In every iteration of the loop, the work function of the block running on
>> the thread is called if permissible. So tpb_thread_body seems to be a
>> good place to pause the flow graph, and I need to send the intention to
>> pause or resume to tpb_thread_body. The intention can easily go from
>> python to top_block to top_block_impl to scheduler_tpb. But the 
>> tpb_thread_body
>> is created by the thread library and not readily accessible by scheduler_
>> tpb. Furthermore, there are two level functor indirection between
>> scheduler_tpb and tpb_thread_body.
>>
>> I did find two existing ways of passing information to tpb_thread_body:
>> thread interrupt and message passing. But they don't seem to be the proper
>> ways of sending the pause and resume information.
>>
>> Any suggestion is welcomed.
>>
>> Thanks,
>> Bolin
>>
>>
>> On Wed, Apr 23, 2014 at 8:22 AM, Bolin Hsu  wrote:
>>
>>> Hi Marcus,
>>>
>>> Thanks for reply. Let me try to answer the questions.
>>>
>>> Yes. The signal frequency shifted by +/- 5%.
>>>
>>> The transfer burst is constant.
>>>
>>> The frequency shift remains constant during a burst. So I estimate the
>>> shift in the beginning of a burst, and fix the setting of demodulator and
>>> resampler over the whole burst. I use FFT and interpolation to estimate the
>>> frequency shift.
>>>
>>> The "estimate frequency shift then configure demodulator" approach
>>> works, except it takes 600-700 ms for the demodulator to start outputting
>>> meaning data after receiving correct configuration. I call this 600-700ms
>>> time the reconfiguration latency.
>>>
>>> Maybe I used wrong term. By reconfiguration I mean I made two function
>>> calls: one is the set_frequency of signal source, the other is
>>> set_resamp_ratio of the fractional resampler. My data rate is 44.1k. So I
>>> lost about 30k samples when I was waiting for the reconfiguration to take
>>> effect.
>>>
>>> Regards,
>>> Bolin
>>>
>>
>>
>
> ___
> 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] dealing with framed data

[Vanush Vaswani]

Use the packet encoder block

Regards,
Vanush


On Thu, Apr 24, 2014 at 1:05 AM, Matthieu Imbert
wrote:

> Hi,
>
> I'm currently trying to take the output of a fft block and pipe it in a
> tcp sink for (near) real-time processing outside of gnuradio.
>
> My question is:
>
> Assuming that I have vectors of n floats (the fft block outputs vectors of
> floats or complexes, so I may need to pipe it to a complex-to-mag2 block to
> convert it to an array of floats, but that's not the main point of my
> question here), if I send them directly to the tcp sink, it will become a
> stream of bytes, and my code outside of gnuradio won't be able to detect
> the boundaries between vectors of n bytes. Actually it won't even be able
> to detect the boundaries between floats.
>
> So I need to "frame" the data in a kind of basic protocol. For example:
> each vector of n floats, insert a m bytes header with a magic identifier,
> and perhaps a length and/or sequence number.
>
> I'm confused about what technique to use to achieve this, between tagged
> streams, messages, pdus, packets:
>
> - I tried using tagged stream (with "stream to tagged stream"), and piping
> it to "Packet Header Generator", but the output of the "packet header
> generator" seems to be only the packet header, and I don't know how to
> recombine it with the payload.
>
> - I tried using "tagged stream to pdu", but then I don't know what to do
> of the pdu output, the only block I found which may input this data type is
> "Socket PDU" but I don't understand its purpose.
>
> - Or should I use "simple framer"?
>
> I'd appreciate some advice on the best / most simple way to achieve this.
> I'm new to gnuradio, so feel free to correct me on any errors (and accept
> my apologizes if my question seems trivial).
>
> best,
>
> --
> Matthieu Imbert 
> http://graal.ens-lyon.fr/~mimbert/
> INRIA / LIP ENS-Lyon research engineer
> http://www.inria.fr http://www.ens-lyon.fr/LIP
> +33(0)472728149
> Monod campus, room GN1 Nord 3.52
> LIP ENS-Lyon, 46 allée d'Italie
> 69364 Lyon cedex 07, FRANCE
>
> ___
> 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] GRC vs python flow-graph by hand

[Vanush Vaswani]

I would also suggest to use hier blocks, as you can continue designing the
DSP in GRC while integrating it in a Python application



On Tue, Apr 15, 2014 at 12:04 AM, Tom Rondeau  wrote:

> On Sun, Apr 13, 2014 at 1:10 AM, Activecat  wrote:
>
>> It seems that in normal usage the GRC is able to accomplish most of the
>> tasks without modifying the python flow-graph by hand...
>>
>
> Generally, we move away from GRC when we require a lot of logic and
> control to set up the flowgraph. You might have a lot of branches to enable
> one type of block over another automatically based on some user input.
> Other reasons are for better UI and packaging. While we can do a lot of
> that inside GRC, there's still plenty of limitations that you can do
> directly in Python.
>
> I tell people to work as far as you can in GRC until you hit these kinds
> of boundaries where you are then bending over backwards to make it work
> inside GRC. At that point, save the Python file somewhere and start
> architecting your program around that core.
>
> Tom
>
>
>
>
>> On Sat, Apr 12, 2014 at 9:10 PM, Vanush Vaswani  wrote:
>>
>>> Interactivity, controlling flowgraph timing (start/stop), dynamic
>>> reconfiguration (lock/unlock), integration with Python libraries and so on.
>>>
>>>
>>> On Sat, Apr 12, 2014 at 9:25 PM, Activecat  wrote:
>>>
>>>> Dear Sir,
>>>>
>>>> As an amateur I use GRC to create flow-graphs, but I see many other
>>>> users create their flow-graphs in python by hand.
>>>>
>>>> In what kind of cases the flow graphs must be coded by hand ?
>>>> (where GRC couldn't accomplish the task)
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GR Windows install

[Vanush Vaswani]

I am planning to use the Ettus guide to install GR 3.7. One question, is it
possible to compile OOT modules with this installation?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC vs python flow-graph by hand

[Vanush Vaswani]

Interactivity, controlling flowgraph timing (start/stop), dynamic
reconfiguration (lock/unlock), integration with Python libraries and so on.


On Sat, Apr 12, 2014 at 9:25 PM, Activecat  wrote:

> Dear Sir,
>
> As an amateur I use GRC to create flow-graphs, but I see many other users
> create their flow-graphs in python by hand.
>
> In what kind of cases the flow graphs must be coded by hand ?
> (where GRC couldn't accomplish the task)
>
> ___
> 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] repository of examples of gnuradio and GRC?

[Vanush Vaswani]

I don't think anything like that exists.

Ideas: You will need a similar intuitive interface (improvement over
pyBOMBS/github), gracefully handle different "start/end" hardware (i.e.
sources and sinks), integration with github for custom blocks, a gallery
per flowgraph showing example in operation and so on.


On Mon, Mar 31, 2014 at 1:41 AM, Fernando Peral wrote:

>  Yeah, fine. But this is some examples "This project is a collection of
> GNU Radio examples created for a
> tutorial session given at the Ottawa Amateur Radio Club.."   that
> someone have in their own repository.
> What I wish to find (or create) is something like this:
>
> http://www.thingiverse.com
>
>
> Where anybody can easily share one desing, and where you can find anything
> you are looking for.
>
>
>
> El 30/03/14 16:32, Vanush Vaswani escribió:
>
> https://github.com/argilo/sdr-examples
>
>
> On Mon, Mar 31, 2014 at 1:20 AM, Fernando Peral wrote:
>
>>  I was thinking on something as simple as a repo where anybody can find a
>> .GRC  file for a FM receiver using STL-SDR or a .GRC  for reading the
>> signal send by my car keys (if my car keys where a RF one which is not the
>> case  :-( ) as you can see I'm focused on GRC diagrams, and I can't
>> find something like what I'm proposing.
>> If it does not exist I am willing to participe in the creation of
>> something like that if there is more people who want to work in it.
>>
>> regards
>>
>>
>>
>> El 30/03/14 14:00, Marcus Müller escribió:
>>
>> Hi Fernando,
>>
>> there's been CGRAN for eternity now; it was meant to be exactly what you
>> are describing:
>> https://www.cgran.org/wiki/Projects
>> It's getting a little old, but it's still a nice directory of projects.
>>
>> Also, nowadays many developers write a pybombs recipe when they develop
>> a new GR-based application, so you might also take a look at what's
>> available via pybombs :)
>>
>> Anyway, there has been a lot of discussion about how to bring GR devs
>> together and make a really useful directory of projects. I think we
>> should be pushing this forward -- however, this, as everything, is a
>> matter of available working time for that. You're very welcome to
>> contribute ideas and time, I guess :)
>>
>> Greetings,
>> Marcus
>>
>> On 30.03.2014 13:42, Fernando Peral wrote:
>> > Everyone (or almost) who writes here is testing different systems,
>> > with different hardware and creating examples. There are some
>> > people who publish their work in their own web pages, git
>> > repositories, etc., and the rest of us are using them (thank to all
>> > of you!!!). But Is there any repository where anybody can publish
>> > is work?. I mean a king of collaborative repo such wikipedia for
>> > documentation, thingiverse for 3d printing models, etc.?
>>
>> > regards
>>
>>
>>
>> > ___ Discuss-gnuradio
>> > mailing list Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> y
>>
>> >
>> > ___
>> > 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 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] repository of examples of gnuradio and GRC?

[Vanush Vaswani]

https://github.com/argilo/sdr-examples


On Mon, Mar 31, 2014 at 1:20 AM, Fernando Peral wrote:

>  I was thinking on something as simple as a repo where anybody can find a
> .GRC  file for a FM receiver using STL-SDR or a .GRC  for reading the
> signal send by my car keys (if my car keys where a RF one which is not the
> case  :-( ) as you can see I'm focused on GRC diagrams, and I can't
> find something like what I'm proposing.
> If it does not exist I am willing to participe in the creation of
> something like that if there is more people who want to work in it.
>
> regards
>
>
>
> El 30/03/14 14:00, Marcus Müller escribió:
>
> Hi Fernando,
>
> there's been CGRAN for eternity now; it was meant to be exactly what you
> are describing:
> https://www.cgran.org/wiki/Projects
> It's getting a little old, but it's still a nice directory of projects.
>
> Also, nowadays many developers write a pybombs recipe when they develop
> a new GR-based application, so you might also take a look at what's
> available via pybombs :)
>
> Anyway, there has been a lot of discussion about how to bring GR devs
> together and make a really useful directory of projects. I think we
> should be pushing this forward -- however, this, as everything, is a
> matter of available working time for that. You're very welcome to
> contribute ideas and time, I guess :)
>
> Greetings,
> Marcus
>
> On 30.03.2014 13:42, Fernando Peral wrote:
> > Everyone (or almost) who writes here is testing different systems,
> > with different hardware and creating examples. There are some
> > people who publish their work in their own web pages, git
> > repositories, etc., and the rest of us are using them (thank to all
> > of you!!!). But Is there any repository where anybody can publish
> > is work?. I mean a king of collaborative repo such wikipedia for
> > documentation, thingiverse for 3d printing models, etc.?
>
> > regards
>
>
>
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> y
>
> >
> > ___
> > 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] Received power measurement

[Vanush Vaswani]

Is there any reason that this isn't done at a few frequencies during
manufacturing and provided in the datasheet?
I've noticed this with a few SDR's. Surely, it would provide a ballpark
figure for those who could not afford expensive test equipment.


On Wed, Mar 26, 2014 at 11:21 PM, Marcus D. Leech  wrote:

>  On 03/26/2014 07:04 AM, Medhat Hamdy wrote:
>
>   Hi all,
>
> I need to know if there is any method to measure the received signal
> power using USRP N210. I am using gr_probe_avg_mag_sqrd_x_0 to measure
> the signal strength, however, the results are not accurate.
>
> Thanks
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  To get accurate readings, you have to calibrate with an external, known,
> source.
>
>
>
> ___
> 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] For Sale: bladeRF x115 with GPIO expansion

[Vanush Vaswani]

BladeRF have released an transverter that extends the frequency range down
to 60KHz. Are you sure you want to sell?


On Sun, Mar 16, 2014 at 12:12 PM, Louis Brown  wrote:

> I just don't use it much since I primarily use 2m amateur band.  Very
> clean and little use; never left my lab bench.  The x115 is the large FPGA
> version.  Also included is the GPIO expander board and the 1m USB 3.0
> cable.  Works great with GNU Radio via gr-osmosdr.
>
> Asking $600 via PayPal with USPS Priority Mail shipping in USA.
>
> Pics here:
>
>
> http://forums.qrz.com/showthread.php?428974-bladeRF-x115-SDR-and-GPIO-Expansion
>
> Thanks,
> Lou
> KD4HSO
>
>
>
> ___
> 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] Hier block I/O's

[Vanush Vaswani]

When including a hier block in a custom Python application, is there
any way to retrieve a reference to the pad source/sink with it's
label?

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

Re: [Discuss-gnuradio] Spectrum sensing with RLT-SDR on Android WITHOUT Gnu Radio

[Vanush Vaswani]

Liquid dsp

On Thu, Feb 13, 2014 at 6:04 AM, Marcus Müller  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Przemek,
> well, since this is the open source world, you shouldn't need to write
> everything from scratch.
> You can of course start off with Martin Marinov's source code,
> https://github.com/martinmarinov/rtl_tcp_andro-
> which will give you an tcp server serving samples (the code says it's
> a port of rtl_tcp from the rtl-sdr package); from there on it's java
> all the way down ;)
> However, I'd expect the average smartphone not to be the device you'd
> want to do FFT on, in Java, which doesn't even offer you access to
> your own memory, but then again I have no clue about android and if it
> offers any accelerators for stuff like that. Googling FFT Java turned
> up quite a bit, so I think you'd might be in luck ;) Generally, as I
> understand the situation with rtl_tcp_andro, you'll need C code to
> interact with the device (makes sense to me) and then you're free to
> use basically every C lib (and most probably even C++) you want within
> the restriction imposed by hardware and android, which, for signal
> processing, shouldn't be harsh.
>
> So: Happy hacking,
> Marcus Müller
>
> On 12.02.2014 17:37, Przemysław Pawełczak wrote:
>> Hello,
>>
>> This is my first post to this mailing list and my apologies if I
>> ask a lame/irrelevant question. Unfortunately, me and my hacking
>> friend could not find the answer to the issue we are trying to
>> solve (Google, etc.) so here is my post.
>>
>> We want to implement the most fundamentally simple spectrum
>> sensing algorithm (energy detector for example) directly on Android
>> device, where our raw I/Q samples are gathered through RTL-SDR
>> dongle ( http://sdr.osmocom.org/trac/wiki/rtl-sdr).
>>
>> Yes, we are aware of http://sdr.martinmarinov.info - but this is
>> not what we want. What we want is a set of functions (FFT, etc.)
>> that will do the signal processing/signal detection directly on
>> Android. Thus - we don't want (wish we could) any Gnu Radio
>> wrappers. Ideally - we look for Java-based implementation of the
>> thing described above.
>>
>> Thus - is there anything out there that we can use or we need to
>> write all from scratch?
>>
>> Best regards, Przemek
>>
>>
>>
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJS+8XMAAoJEAFxB7BbsDrLPVsH/1gP/TvkANDxKsPJG7xJmHq5
> vHeh62OfCJuHqMiIYOk+CnAYfAFgwGsgYQl2EAqZIKHWA6CDaWvq+Ds1sKIuslPY
> fW+bIXcM+QkWkskypdrogGANQArd3sS7tJ0ToiNMkIIX0iTKzHh81nKjSGi3neSt
> 9YqYAhqMbQtUBKQw5/ArOTrqkYpis6gwNCcu58Bdmshr8+cud7i/ZRIuqTD1kiv1
> h0ZUxHIIWA1IMFJDH/21FKZJ2VBJlZ61BIE26WGpB13Vvva3VMmm4AinTZ6nZTo+
> S0ZVIXKtbwuAbSJf7jZPHZhCe7auW59Ja6btKbAm/ToljQ7Vy5VOxN4dAseKcV0=
> =c7a4
> -END PGP SIGNATURE-
>
> ___
> 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] Problem with receiving signal from satellite Thuraya-3

[Vanush Vaswani]

The polarisation loss in your case might be 30 dB. Have a look into that.

Regards,
Vanush

On Wed, Jan 29, 2014 at 7:45 PM, Sylvain Munaut <246...@gmail.com> wrote:
> Hi,
>
>> I am trying to collect signal from Thuraya-3. Here is the setup I used:
>> - USRP N210 + WBX
>> - LNA with 30dB gain (ZHL-1217MLN)
>> - Iridium Antenna (I don't have specific antenna for Thuraya right now.
>> Since Iridium and Thuraya frequency bands are quite close, I suppose it
>> would work more or less)
>>
>> Center frequency: 1530MHz
>> Sampling rate: 10MHz
>>
>> From the spectrum (attached), I can see the Inmarsat signal, but no sign of
>> Thuraya signal. Anyone has suggestion about how to receive the thuraya
>> signal?
>
> Several issues to improve :
>
>  - Your antenna has the wrong polarization, this will definitely kill
> your signals
>  - You can also try more directional types of antenna like described
> here : https://gmr.osmocom.org/trac/wiki/Receiver_Setup
>  - Ideally if you have some GSM1800 nearby, it's good to have a filter
> as those signals tend to swamp / saturate inputs when amplified ...
>
> fwiw, I have had some success receiving thuraya by using a GPS antenna
> and just using a big metal surface as a reflector (to swap
> polarization).
>
>
> Cheers,
>
>Sylvain
>
> ___
> 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] how to use FFT without grc block

[Vanush Vaswani]

Check the FFTW documentation.

On Fri, Jan 24, 2014 at 12:45 PM, Nasi  wrote:
> Thanks!
>
> with doxygen docs do you mean these:
> http://gnuradio.org/doc/doxygen/classgr_1_1fft_1_1fft__complex.html ?
> this redundant information is hopeless...
>
> Do you know any normal good mature documentation?
>
>
>
> Четверг, 23 января 2014, 20:57 +01:00 от Marcus Müller :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yes, you can. Look into the gr-fft module documentation in the doxygen
> docs.
> Alternatively, you can simply link against FFTW [1] yourself and use
> the FFT algorithms; gr-fft is a wrapper for that functionality
> offering simplification and ease of use. But if an FFT is all that
> you're after, going directly for FFTW might be the best choice; if you
> need something non-standard such as 2D-FFT (or higher dimensions),
> real-only transforms, sliced/strided, hundreds of transforms at
> once... use FFTW. If you just want an N-Point FFT and are linking
> against GR anyway, use gr-fft.
>
> Greetings,
> Marcus
>
> [1] Fastest Fourier Transform in the West, http://www.fftw.org/
>
> On 23.01.2014 20:17, Nasi wrote:
>> Hi all,
>>
>> I know there is an FFT block in gnuradio 3.7. I want to create a cc
>> file and add some gnuradio classes there. Can I use FFT without
>> .grc file without using blocks, just as a c++ function?
>>
>>
>>
>>
>>
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJS4XQPAAoJEAFxB7BbsDrLyfEIAJLH45hnH5DpkMpU/bV4s3Pl
> 2IXkAzZYJ1+JzotL0s9I4FMoQiwWe3t1ICzcP7U1p/kcZbA4nXaZ+JnTdLrQLGTG
> 9+G7vWDsNYtsxmxzDScFPsxzathATbM5k0VDqXoDf1sPd1RMP0TyOZ0hl9E+tugK
> HWvZcLjwEUdNoW/ZdHA8DVohXS05qF9doeF5vQI33ftUq9iWEaXCAYM3r/Vudbi0
> OcwyloLhdaKw47qiclLvlKUfI8va8YbknSB0WU2laiIK59qsl/87bd6K01jfAyWf
> QZgbYJ8SoRtr9to04iW4DUjaX59PESJhSZYnpf8ZEhXcKw8i+kM0c7lPC9mnCww=
> =vK/B
> -END PGP SIGNATURE-
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> NE
>
> ___
> 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] Install: qa_volk_test_all fails on armv7

[Vanush Vaswani]

Check that you are powered from 5V, otherwise BBB runs at 300 MHz.

On Wed, Jan 15, 2014 at 10:27 AM, Ken Adams  wrote:
> Has there been any progress on this bug?
> Would this effect performance enough to cause The under run uUuUuU at 250k
> sample rate on a beaglebone black (1ghz arm v7- nothing running)?
>
>
> On Sunday, December 15, 2013, Tom Tsou wrote:
>>
>> On Sun, Dec 15, 2013 at 12:23 PM, Tom Rondeau  wrote:
>> > On Wed, Dec 11, 2013 at 10:35 AM, Monahan-Mitchell, Tim
>> >> OK, good to hear. Does that mean bugs 582 and 583 should be re-opened?
>> >
>> > I've reopened the tickets as "Works for some". Philip, Nathan, and I
>> > agreed to work together this week to try to resolve it seeing as how
>> > Philip can replicate the problems.
>>
>> Just another data point. Similar results here with native A15 build on
>> Linaro 13.11.
>>
>> $ make test
>> Running tests...
>> Test project /tmp/gnuradio/build
>> Start 1: qa_volk_test_all
>> 1/1 Test #1: qa_volk_test_all .***Failed1.88 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) =   1.94 sec
>>
>> The following tests FAILED:
>>  1 - qa_volk_test_all (Failed)
>> Errors while running CTest
>> make: *** [test] Error 8
>>
>>   -TT
>>
>> ___
>> 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] GNURadio on Zync: thanks for the excellent tutorial

[Vanush Vaswani]

Is there any difference in using this stack compared to say, the
Ubuntu distribution available on www.armhf.com, and compiling gnuradio
from source?

Vanush

On Fri, Dec 27, 2013 at 2:31 AM, Philip Balister  wrote:
> On 12/26/2013 02:28 AM, Jean-Michel FRIEDT wrote:
>> I have used the opportunity of the more relaxed days of this Christmas
>> period to try and run the tutorial at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
>
> We need to update the OE section of this page to use:
>
> https://github.com/balister/oe-gnuradio-manifest
>
> for managing the OE layers. I'd suggest not starting a new checkout if
> you have something working until after I update UHD to 3.6.2 though :)
>
> Also, https://github.com/balister/meta-sdr/wiki/CrossCompile has
> instructions for cross compiling GNU Radio and testing the result. We
> need to verify this approach works for OOT module development also.
>
> Merry Christmas,
>
> Philip
>
>>
>> Wonderful page, works nearly perfectly, thanks a lot.
>>
>> A few minor comments to the author or useful to other readers of the
>> mailing
>> list:
>> 1/ using a brand new Debian/testing installation, it seems that the latest
>> version of tar will not accept both -c and -s options in its command line.
>> I hence edited all entries of openembedded-core/meta/lib/oe/ and replaced
>> the -ps option of tar with -p. Same for the meta/classes entries.
>> Apparently
>> this has been patched in the latest release of openembedded, but indeed the
>> zync script will not run out of the box on the latest openembedded release
>> and, as advised on the web page, I git commited against a given older
>> release,
>> 2/ the note about Xilinx tools to Ubuntu users concerning gmake should
>> be in
>> bold, huge size, blinking fonts ;)  I spent a while being concerned about
>> licensing issues when the FPGA synthesis tool would not run. No
>> seriously, just
>> learning to read did the trick. As a side note, it all ran smoothly with
>> the
>> 14.7 release of ISE on a 32-bit x86 architecture. I believe there is a
>> minor
>> trivial error in the PATH to ISE in which xtclsh should not be included in
>> the PATH definition.
>>
>> Anyway, thanks for the tutorial, just need to now understand what I did,
>> but
>> at least the whole thing is running smoothly.
>>
>> Best wishes for the new year, JM
>>
>
> ___
> 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] [User Experience] Hangout Thursday

[Vanush Vaswani]

I just wanted to say, that I thought this is a great example of a FOSS
project site.

http://ardour.org/

For new users, the abilities of the project is made clear. The current
gnuradio content could be migrated to the 'Community' sub section.
One difference is that gnuradio is theoretically an API not
application software - but I still think the site serves as a good
example.


On Fri, Nov 15, 2013 at 6:11 AM, Martin Braun (CEL)
 wrote:
> On Thu, Nov 14, 2013 at 06:58:20PM +0100, Martin Braun (CEL) wrote:
>> The call has started, to join please head to #gnuradio on Freenode and
>> the G+ page.
>>
>> We'll be streaming live on YouTube, too.
>
> The recording is available at
> http://www.youtube.com/watch?v=7LN6M-8bJuU.
>
> 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

Re: [Discuss-gnuradio] BPSK receiver issue / message passing

[Vanush Vaswani]

Thanks for the reply. It seems to be an endian issue such that I can't
simply shift bits but must use a proper framer.

I have modified an existing AX.25 block such that I can now see my
frames over the air using debug prints but I am having difficulty
getting my data out from gnuradio. The AX.25 block, from gr-ec,
creates frames through several iterations of the work() fn using a
state machine and also has a message queue output (but hasn't actually
implemented the message passing). Once I have a verified frame, what
is the best way to get the data out?

I have tried this technique:

d_good_byte_cnt += frame_size-2; // don't count CRC
gr_message_sptr msg = gr_make_message(0, 0, 0, d_good_byte_cnt);
memcpy(msg->msg(), frame_buf, d_good_byte_cnt);
d_target_queue->insert_tail(msg);
msg.reset();

and then connect to a message source, and then a file sink. However,
the memcpy seems to cause my flowgraph to crash. Any tips?


On Wed, Nov 6, 2013 at 1:42 AM, Tom Rondeau  wrote:
> On Mon, Nov 4, 2013 at 10:25 AM, Vanush Vaswani  wrote:
>> Hi all,
>>
>> I am using GR 3.6.5.1 to receive BPSK modulated data from a third
>> party RF chip / microcontroller combination and am having a strange
>> experience. I am implementing a very simple protocol by constantly
>> transmitting 0x7E constantly and then ASCII data triggered by a serial
>> connection to the microcontroller, all at 9.6kbps
>>
>> With the  following configuration
>> FCDPP source sampling at 192KHz.
>> -> AGC
>>  -> Freq Xlate (bring near baseband)
>>  -> Costas loop (remove carrier)
>> -> RRC (48 taps, symbol rate = 9600)
>> -> PSK Demod (sps = 20 as 192/20 = 9.6kbps, everything else default)
>>
>> I can see my 0x7E bitstream "square wave" in a scope sink.
>> When I pack the bits and send it to a file sink, I can see my 0x7E's
>> and also ascii data that I've typed in to the microcontroller serial
>> port. However - this is rare. Most of the time, I see the bytes of
>> rotated flag - 0x3F, 0xFC, 0x3F etc. I thought this was ok, I can
>> simply rotate the whole file by x bits to remake all the flags as
>> 0x7E. But when I do this, my ascii text input is completely garbled,
>> with only a few letters showing up.
>>
>> Can anyone give me a hint as to what is going on? I don't think my
>> transmitter is the issue, as when I get my flag bytes in the output
>> file, I can see my data.
>>
>> vanush
>
> The PSK demod has the FLL, Costas loop, and RRC filter in it. That's
> what each of those bandwidth settings are for (frequency, phase, and
> timing). But also, going in at 20 sps is really high. You should put a
> channel filter in front that both removes any extra noise and
> downsamples (by a factor of 5 or 10 to get to 4 or 2 sps).
>
> Tom

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

[Discuss-gnuradio] BPSK receiver issue

[Vanush Vaswani]

Hi all,

I am using GR 3.6.5.1 to receive BPSK modulated data from a third
party RF chip / microcontroller combination and am having a strange
experience. I am implementing a very simple protocol by constantly
transmitting 0x7E constantly and then ASCII data triggered by a serial
connection to the microcontroller, all at 9.6kbps

With the  following configuration
FCDPP source sampling at 192KHz.
-> AGC
 -> Freq Xlate (bring near baseband)
 -> Costas loop (remove carrier)
-> RRC (48 taps, symbol rate = 9600)
-> PSK Demod (sps = 20 as 192/20 = 9.6kbps, everything else default)

I can see my 0x7E bitstream "square wave" in a scope sink.
When I pack the bits and send it to a file sink, I can see my 0x7E's
and also ascii data that I've typed in to the microcontroller serial
port. However - this is rare. Most of the time, I see the bytes of
rotated flag - 0x3F, 0xFC, 0x3F etc. I thought this was ok, I can
simply rotate the whole file by x bits to remake all the flags as
0x7E. But when I do this, my ascii text input is completely garbled,
with only a few letters showing up.

Can anyone give me a hint as to what is going on? I don't think my
transmitter is the issue, as when I get my flag bytes in the output
file, I can see my data.

vanush

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

Re: [Discuss-gnuradio] GnuRadio in particle accelerators

[Vanush Vaswani]

OT but has anyone used GNURadio for music production?

On Thu, Oct 24, 2013 at 10:54 PM, Aylons Hazzud  wrote:
> 2013/10/23 M Dammer :
>> I have no answer here. But talking about Gnuradio and nuclear physics I
>> want to add my idea to your question:
>> Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer
>> ? These spectrometers usually work with a multichannel analyzer that
>> measures the pulse height coming from the detector and then sorting the
>> heights into bins. This is similar to the histogram GUI element found in
>> GRC, but the counting is accumulative until a timer or manual
>> interaction stops it. The big difference between SDR use and nuclear
>> instrumentation is that while SDR mainly works with a constant stream of
>> data the latter mainly deals with transient pulses.
>
> Interesting.
>
> But, is GnuRadio needed for it? The pulse height coming from the
> detector is a pulsed high-frequency signal, or just a width-modulated
> square wave?
>
> ___
> 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

[Discuss-gnuradio] Error using Packet Decoder block in 3.7

[Vanush Vaswani]

The following error is thrown when trying to run dpsk_loopback.py in
gr digital examples.

  File "/usr/local/lib/python2.7/dist-packages/grc_gnuradio/blks2/packet.py",
line 243, in recv_pkt
msg = blocks.message_from_string(payload, 0, self._item_size_out,
AttributeError: 'module' object has no attribute 'message_from_string'

Any advice?

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

Re: [Discuss-gnuradio] How to use USRP to detect and collect weak satellite signals

[Vanush Vaswani]

http://en.wikipedia.org/wiki/SiRF


On Wed, Sep 4, 2013 at 11:14 PM, Sylvain Munaut <246...@gmail.com> wrote:

> On Wed, Sep 4, 2013 at 2:54 PM, Vanush Vaswani  wrote:
> > What is the difference between the receiver tech in something like a CSR
> > chip vs USRP?
>
> CSR chip ?
>
>
> Cheers,
>
> Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to use USRP to detect and collect weak satellite signals

[Vanush Vaswani]

What is the difference between the receiver tech in something like a CSR
chip vs USRP?


On Wed, Sep 4, 2013 at 9:25 PM, Ralph A. Schmid, dk5ras wrote:

> > I've actually seen it without de-spreading during a presentation
> recently. Of
> > course it had been received with a 25 m dish or so :)
>
> Yep, brute forced it should be possible :-) Not really the same like with
> UMTS or LTE...
>
> 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] Comparison of new USRP, HackRF and bladeRF

[Vanush Vaswani]

This is brilliant. I'm trying to decide between bladeRF and USRP B200. USRP
B200 is $895 AUD for for me, whereas bladeRF is $100 less. However, my
suspicion is that driver support is far better for USRP. So confused




On Fri, Aug 23, 2013 at 1:19 PM, Taylor Killian wrote:

> Hello,
>
> I've spent a lot of time researching and comparing the different Software
> Defined Radios that are available for purchase. This year, three new SDRs
> are being released from three different companies, the HackRF, bladeRF and
> the USRP B210 and B200. While doing research on the B200, very little
> information was available on the web, but I've managed to dig up a lot of
> information on it and post in the article, along with some high resolution
> photos.
>
> I think this article will be useful for anybody considering buying a new
> Software Defined Radio. There are definitely three great options out there.
> Hopefully having all the information about the three in the same place will
> be useful. Check out there article below:
>
>
> http://www.taylorkillian.com/2013/08/sdr-showdown-hackrf-vs-bladerf-vs-usrp.html
>
> Thanks,
> Taylor Killian
> University of Toledo, Electrical Engineering Student
>
> ___
> 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] Processing multiple signals off single source block

[Vanush Vaswani]

Mike, does this work with the Funcube Dongle Pro+?




On Thu, Aug 22, 2013 at 4:39 AM, Mike Jameson  wrote:

> Hi Luke,
>
> I've found using the FFT blocks are the most cpu efficient way to extract
> a channel from the whole 20MHz of the HackRF.  Have a look at my latest
> Scanoo release built in GRC which uses the 'Keep X in N' block to select
> the channel required.  There's also a spectrum sense mode which locks on to
> the strongest signal within the 20MHz bandwidth if it is not in the blocked
> frequency list:
>
> https://github.com/m0mik/scanoo
>
> Cheers,
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Email: m...@scanoo.com
> Web: http://scanoo.com
>
>
> On Wed, Aug 21, 2013 at 7:15 PM, Luke B  wrote:
>
>>  I am working on a processing multiple signals using a single source
>> block. The background is below, but I had a couple of high level questions:
>>
>>  - What is the best approach performance wise for selecting multiple
>> ~15khz channels from a 2mhz+ source block? Is it using a Xlating FIR
>> Filter with a low-pass? Is it more efficient to use a SIN Sig source &
>> Multiply Block with a low-pass FIR Filter? Is there a better way to extract
>> a filter?
>>
>>  - What is the best way to have different bunch of blocks processing each
>> signal run independently and not block each other? I want to do this as a
>> GR C++ program is there any way to run the signal source and chanelizersas 
>> one thread and then have the different processing chains run as separate
>> threads? Is there a way to put a queue or buffer inbetween blocks that
>> would allow for a chain of blocks to be separated between threads?
>>
>> Or am I better off doing the basic signal/channel processing for
>> everything in a single process and then writing the results to a file and
>> then having a process which goes through the files and does the more
>> intensive vocoder work in non-real time?
>>
>> Any pointers or examples of how to do threading with GR C++ code would be
>> really helpful. I am not sure of the best architectual approach.
>>
>>
>> Background:
>>  I have taken the gr-smartnet code and done a skeleton implementation in
>> C++. I want to process the digital trunking channel and then decode and
>> record the digital audio from all of the different talk groups. Since it is
>> trunked, channels will be randomly be turning on and off and talk groups
>> will be switching from channels. It would be good to have a separate thread
>> for the trunk decoding and the separate digital audio recorders. Ideally, I
>> would like to be able to do this over 8 or 10Mhz using my HackRF.
>>
>> My code, which is working enough to decode the trunking channel, is here:
>> https://github.com/robotastic/sdr
>>
>> Thanks!
>>
>>  - Luke
>>
>> ___
>> 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] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Hi,

yeah, makes sense to use OS functionality thats available.
One question - how does one pack the samples back into complex within
gnuradio (or grc)?
FYI, I am referring to OOT block gr-fcdproplus, not gr-fcd. The funcube
dongle pro+ has an improved quadrature sampling rate of 192 KHz.



On Sat, Aug 10, 2013 at 8:13 PM, Marcus Müller  wrote:

>  Hi again,
>
> I was a little surprised that your connection couldn't handle the 12.3
> Mbit/s for the complex 192ksam/s,
> so I had a look at the source code of the fcd_source; that basically wraps
> an audio source.
> Surprise was mine when I found out that there's no complex 192ksam/s at
> all... The audio device is set to
> deliver 96ksam/s of stereo, that gets converted to 96ksam/s of complex
> samples.
> Therefore, the data rate is only 6.144Mbit/s for your wifi link... Not
> very much.
> Anyway, what (due to that being the default data type in GR), the audio
> source inside the fcd_source converts
> the 16bit adc resolution of your dongle to 32bit floats; so, instead of
> streaming those using GR over your network,
> you can also just stream raw audio data from your beaglebone to your
> receiver computer, something like
> arecord --format={try something like S16_LE, U16_LE, see man arecord} -D
> beagleboardaudiodev --file-type=raw --channels=2 --disable-resample
> --disable-channels --disable-format |ncat host port
> and
> ncat -l port > rxfifo
> on the receiver.
> And then reading that file using a file source, converting the 16bit
> signed/unsigned ints to floats, packing them into complexes and using that
> for your receiver; note, however, that a lost packet is not tolerable in
> this case, you will end up with corrupt samples if lost bytes are not
> multiples of 4...
>
> To the TCP/UDP sources in GR: they do what they were designed for,
> dropping samples from an outside source makes sense if your flowgraph can't
> handle the load, since there is no such thing as the infinite buffer or the
> infinite acceptance of latency; not so much for your fifos. They start
> blocking when you ram+swap is used up...
>
> Greetings
> Marcus
>
>
> On 08/10/2013 03:15 AM, Vanush Vaswani wrote:
>
> Iain, thanks for that. Will be helpful in my gnuradio pursuits.
>
> I think the TCP blocks should be definitely be decoupled from GRC...
>
> With regards to my problem, I tried the ncat/fifo approach, and it works
> acceptably. Using TCP, I get a few overflows on the sender (beaglebone) as
> expected due to the nature of TCP. With UDP, I can stream with very few
> skips (and this is all over WiFi too). Thus, for my app, I may use a fifo +
> Twisted to get data out of gnuradio. I think the TCP/UDP blocks are a bit
> spartan in gnuradio.
>
> For the record, here are my commands
> sender: ncat -u 192.168.0.8 31337 < txfifo   (txfifo is a File
> sink directly connected to a FCDPP source)
> receiver: ncat -k -u -l 192.168.0.8 > rxfifo (rxfifo is a File
> source connected to a WBFM Receiver and then Audio sink)
>
>
>
>
> On Sat, Aug 10, 2013 at 8:15 AM, Marcus D. Leech wrote:
>
>>  On 08/09/2013 05:29 PM, Marcus Müller wrote:
>>
>> You're right, although grc_blks2 is in grc/grc_gnuradio, which, as far as
>> I would guess from here,
>> won't be built if you don't build GRC, which you usually don't when in a
>> headless environment.
>>
>> There's also no necessity to do the development side on the target
>> platform, if you're just targetting a headless environment.  Take the
>> generated
>>   Python, and run it on the target.
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>> ___
>> 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] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Iain, thanks for that. Will be helpful in my gnuradio pursuits.

I think the TCP blocks should be definitely be decoupled from GRC...

With regards to my problem, I tried the ncat/fifo approach, and it works
acceptably. Using TCP, I get a few overflows on the sender (beaglebone) as
expected due to the nature of TCP. With UDP, I can stream with very few
skips (and this is all over WiFi too). Thus, for my app, I may use a fifo +
Twisted to get data out of gnuradio. I think the TCP/UDP blocks are a bit
spartan in gnuradio.

For the record, here are my commands
sender: ncat -u 192.168.0.8 31337 < txfifo   (txfifo is a File sink
directly connected to a FCDPP source)
receiver: ncat -k -u -l 192.168.0.8 > rxfifo (rxfifo is a File
source connected to a WBFM Receiver and then Audio sink)




On Sat, Aug 10, 2013 at 8:15 AM, Marcus D. Leech  wrote:

> **
> On 08/09/2013 05:29 PM, Marcus Müller wrote:
>
> You're right, although grc_blks2 is in grc/grc_gnuradio, which, as far as
> I would guess from here,
> won't be built if you don't build GRC, which you usually don't when in a
> headless environment.
>
> There's also no necessity to do the development side on the target
> platform, if you're just targetting a headless environment.  Take the
> generated
>   Python, and run it on the target.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> 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] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Hi Marcus,
No... that didn't do it. In fact, connected UDP source to null sink and
still get console full of warnings.
I think something is wrong somewhere, maybe in network setup or network
stack of BBB.
If anyone has achieved something similar, (sample forwarding), do feel free
to post your grc files. :)

I would try TCP.. but it seems to be coupled with grc, but Beaglebone is
headless! Ack...



On Sat, Aug 10, 2013 at 3:41 AM, Marcus Müller  wrote:

>  Hi Vanush,
> remove the gui sink. It also limits the sample processing speed and thus
> is equally bad as throttle.
>
> Am 09.08.2013 19:33, schrieb Vanush Vaswani:
>
> Hi,
>
> It doesn't help, I still consistently drop samples.
>
> I tried increasing the buffer size in udp_source_impl.cc. I can record to
> .wav perfectly for about two minutes before the flow graph suddenly exits
> with (I'm assuming) a segfault.
>
> For reference, I have attached images of the sender and receiver. Surely,
> this sort of streaming has been done before? I am using a BeagleBone Black
> running Ubuntu 12.04 (which runs fine - no overflows). The correctness of
> the FM receiver is less of a concern than the dropped samples.
>
> Regards,
> Vanush
>
> On Sat, Aug 10, 2013 at 3:11 AM, Marcus Müller  wrote:
>
>>  Hi Vanush,
>>
>> ok. Throttle does not _do anything_ with the samples. It just slows down
>> the computational speed that they are processed with. Remove it, it breaks
>> your flowgraph.
>> As said before, the WARN:... warnings stem from your UDP source. Data
>> does not get processed fast enough; that's throttle's fault (before, the
>> audio sink was limiting
>> your sample processing speed, which is in its nature).
>> Your flowgraphs are _not_ running at the same rate; they _may_ process
>> samples at the same average rate (that's what throttle does, stop the
>> sample flow when it's faster
>> than specified), but throttle does not convert sample rates.
>> Refer to existing Receiver flowgraphs from the internet on how to do
>> things right, and please remember: 192kHz input MUST be downsampled for
>> audio usage.
>>
>> Have a nice day,
>> Marcus Müller
>>
>>   Ok, I still don't understand why I'm getting so many dropped packets.
>>
>> sender
>> FCDPP -> UDP Sink
>>
>> receiver
>> UDP Src -> _Throttle_ (at 192KHz) -> WBFM Receive -> Wav File Sink
>>
>> Note: no audio sinks.
>> I constantly get "WARN: Too much data; dropping packet."
>>
>> Wave file is full of skips, yet both flowgraphs are running at the same
>> rate?
>>
>>
>>   On Fri, Aug 9, 2013 at 10:37 AM, Iain Young, G7III wrote:
>>
>>>  On 09/08/13 00:22, Vanush Vaswani wrote:
>>>
>>>> Hi,
>>>>
>>>> If i add a rational resampler to match the audio rate before the UDP
>>>> sink, I can get a continuous output, but it's of terrible quality due to
>>>> the loss of information.
>>>>
>>>
>>>  You are always going to have to throw information away. You have 192k
>>> that you are trying to fit into human hearing, so you *must* filter
>>> and then down sample.
>>>
>>> How wide is your BPF/LPF ? Is it more than your soundcard can handle ?
>>>
>>>
>>>  How does the flowgraph work having a sample rate 'mismatch' when the
>>>> FCDPP block is in the same graph?!
>>>>
>>>
>>>  Your soundcard (probably) expects 44k1. The resampler takes care of
>>> this, but of course, 192k is not going to go into 44k1. You need to
>>> filter first.
>>>
>>>
>>>  Could you give me a hint in working around this issue?
>>>>
>>>
>>>  As I said before, google has plenty of examples of FM receivers with grc
>>> (Google for gnuradio FM receiver grc, I'm sure you'll find loads)
>>>
>>> Here are two working flowgraphs that start at 192k and 250k
>>> respectively:
>>>
>>> http://hal.g7iii.net/GRC/Examples/Simple_Multimode_RX.png
>>> http://hal.g7iii.net/GRC/Examples/GUI_TRX_JACK.<http://hal.g7iii.net/GRC/Examples/GUI_TRX_JACK.png>
>>>   They are actually a multimode receiver I wrote as an example for a
>>> friend, and a multimode transceiver for ham radio use, but they show
>>> the FM receive chain.
>>>
>>> With both, you'll note I have a variable BPF so I can listen to
>>> broadcast stations on MW/LW, and FM, SSB, or CW stations on the amateur
>>> radio bands.
>>>
>>> For pure FM you can drop the selector blocks, and just concentrate on
>>> the NBFM receiver chain
>>>
>>> Note if you need to be tuning with the FIR filter, you'll need to define
>>> filter taps. I used a simple LPF.
>>>
>>>
>>> Hope that helps
>>>
>>> Iain
>>>
>>
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Ok, I still don't understand why I'm getting so many dropped packets.

sender
FCDPP -> UDP Sink

receiver
UDP Src -> _Throttle_ (at 192KHz) -> WBFM Receive -> Wav File Sink

Note: no audio sinks.
I constantly get "WARN: Too much data; dropping packet."

Wave file is full of skips, yet both flowgraphs are running at the same
rate?


On Fri, Aug 9, 2013 at 10:37 AM, Iain Young, G7III  wrote:

> On 09/08/13 00:22, Vanush Vaswani wrote:
>
>> Hi,
>>
>> If i add a rational resampler to match the audio rate before the UDP
>> sink, I can get a continuous output, but it's of terrible quality due to
>> the loss of information.
>>
>
> You are always going to have to throw information away. You have 192k
> that you are trying to fit into human hearing, so you *must* filter
> and then down sample.
>
> How wide is your BPF/LPF ? Is it more than your soundcard can handle ?
>
>
>  How does the flowgraph work having a sample rate 'mismatch' when the
>> FCDPP block is in the same graph?!
>>
>
> Your soundcard (probably) expects 44k1. The resampler takes care of
> this, but of course, 192k is not going to go into 44k1. You need to
> filter first.
>
>
>  Could you give me a hint in working around this issue?
>>
>
> As I said before, google has plenty of examples of FM receivers with grc
> (Google for gnuradio FM receiver grc, I'm sure you'll find loads)
>
> Here are two working flowgraphs that start at 192k and 250k
> respectively:
>
> http://hal.g7iii.net/GRC/**Examples/Simple_Multimode_RX.**png<http://hal.g7iii.net/GRC/Examples/Simple_Multimode_RX.png>
> http://hal.g7iii.net/GRC/**Examples/GUI_TRX_JACK.png<http://hal.g7iii.net/GRC/Examples/GUI_TRX_JACK.png>
>
> They are actually a multimode receiver I wrote as an example for a
> friend, and a multimode transceiver for ham radio use, but they show
> the FM receive chain.
>
> With both, you'll note I have a variable BPF so I can listen to
> broadcast stations on MW/LW, and FM, SSB, or CW stations on the amateur
> radio bands.
>
> For pure FM you can drop the selector blocks, and just concentrate on
> the NBFM receiver chain
>
> Note if you need to be tuning with the FIR filter, you'll need to define
> filter taps. I used a simple LPF.
>
>
> Hope that helps
>
> Iain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Hi,

If i add a rational resampler to match the audio rate before the UDP sink, I 
can get a continuous output, but it's of terrible quality due to the loss of 
information. 

How does the flowgraph work having a sample rate 'mismatch' when the FCDPP 
block is in the same graph?! 

Could you give me a hint in working around this issue?

Sent from my iPhone

On 09/08/2013, at 5:01 AM, Marcus Müller  wrote:

> Hi Vanush,
> 
> as Iain pointed out, the sound card _enforces_ a low sample rate by being an 
> actual piece of hardware;
> therefore, 44.1ksamples/s "leave" your flowgraph at the audio sink, while you 
> feed it 192ksamples/s from the
> funcube. 
> A faster computer _might_ help, but first adjust the sampling rates (although 
> if your computer is really fast travelling away from you, the 192ks/s might 
> hit him with 44.1ks/s, but I guess if you get a computer that fast, it might 
> be the end of everything.)
> 
>  08.08.2013 20:18 Vanush Vaswani:
>> Ok,
>> 
>> would a faster computer help? I am running the receiver on a 2008 Macbook 
>> air, might be a bit slow for modern standards.
>> 
>> On Fri, Aug 9, 2013 at 4:13 AM, Marcus Müller  wrote:
>>> Hi,
>>> your warning points to the UDP source: Since your receiver can't process 
>>> all the samples that it gets
>>> via UDP, and the UDP source runs out of buffering capacity, it starts to 
>>> drop UDP packets.
>>> 
>>> There are two things that you must do:
>>> 1) The Samples for the audio sink _must_ be resampled to the right sound 
>>> card sampling rate,
>>> e.g. 44.1kHz, otherwise that card will see a highly frequency-shifted 
>>> version of the real signal
>>> 2) take care that the samples from the network get processed fast enough so 
>>> that there will be no dropping.
>>> 
>>> Best Regards
>>> Marcus
>>> 
>>> Am 08.08.2013 18:09, schrieb Iain Young, G7III:
>>> 
>>>> Different parts of the flow graph can have different sample rates.
>>>> 
>>>> You need to use the rational resampler so it's output matches what
>>>> your soundcard expects.
>>>> 
>>>> You may also need a complex to real somewhere. There are plenty of
>>>> examples for a FM receiver on the web.
>>>> 
>>>> 
>>>> Best Regards
>>>> 
>>>> Iain
>>>> 
>>>> On 08/08/13 16:56, Vanush Vaswani wrote:
>>>>> How can I set the sampling rate on both ends to be the same? FCDPP
>>>>> sampling rate is 192 KHz.
>>>>> 
>>>>> If I include an audio sink, is the rate of the flowgraph controlled by
>>>>> the sound card sampling rate?
>>>>> 
>>>>> Attached are my .grc files.
>>>>> 
>>>>> 
>>>>> On Thu, Aug 8, 2013 at 11:34 PM, Alexey Bazhin >>>> <mailto:b...@irc.msk.ru>> wrote:
>>>>> 
>>>>> Do you set sampling rate 192000 on both ends? Post your grc files.
>>>>> 
>>>>> On Thu, 8 Aug 2013 14:09:42 +1000
>>>>> Vanush Vaswani mailto:van...@gmail.com>> wrote:
>>>>> 
>>>>>  > Hi there,
>>>>>  >
>>>>>  > I'm trying to stream the FCDPP over UDP to a another computer
>>>>>  > The setup is as follows
>>>>>  >
>>>>>  > FCDPP Source -> UDP Sink
>>>>>  >
>>>>>  > For the receiver,
>>>>>  >
>>>>>  > UDP Source -> LPF -> Quadrature demod -> FM Deemph -> LPF -> Audio
>>>>>  > sink
>>>>>  >
>>>>>  > Unfortunately, when I run the flowgraph on the receiver end, I only
>>>>>  > hear a bunch of clicks.
>>>>>  > The console is full of messages "WARN: Too much data; dropping
>>>>>  > packet.". WX GUI FFT Sink and Waterfall seem to work, though with 
>>>>> the
>>>>>  > same messages.
>>>>>  >
>>>>>  > Any hints to rectify this issue?
>>>>> 
>>>>> 
>>>>> --
>>>>> Alexey Bazhin mailto:b...@irc.msk.ru>>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> 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] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Ok,

would a faster computer help? I am running the receiver on a 2008 Macbook
air, might be a bit slow for modern standards.

On Fri, Aug 9, 2013 at 4:13 AM, Marcus Müller  wrote:

> Hi,
> your warning points to the UDP source: Since your receiver can't process
> all the samples that it gets
> via UDP, and the UDP source runs out of buffering capacity, it starts to
> drop UDP packets.
>
> There are two things that you must do:
> 1) The Samples for the audio sink _must_ be resampled to the right sound
> card sampling rate,
> e.g. 44.1kHz, otherwise that card will see a highly frequency-shifted
> version of the real signal
> 2) take care that the samples from the network get processed fast enough
> so that there will be no dropping.
>
> Best Regards
> Marcus
>
> Am 08.08.2013 18:09, schrieb Iain Young, G7III:
>
>  Different parts of the flow graph can have different sample rates.
>>
>> You need to use the rational resampler so it's output matches what
>> your soundcard expects.
>>
>> You may also need a complex to real somewhere. There are plenty of
>> examples for a FM receiver on the web.
>>
>>
>> Best Regards
>>
>> Iain
>>
>> On 08/08/13 16:56, Vanush Vaswani wrote:
>>
>>> How can I set the sampling rate on both ends to be the same? FCDPP
>>> sampling rate is 192 KHz.
>>>
>>> If I include an audio sink, is the rate of the flowgraph controlled by
>>> the sound card sampling rate?
>>>
>>> Attached are my .grc files.
>>>
>>>
>>> On Thu, Aug 8, 2013 at 11:34 PM, Alexey Bazhin >> <mailto:b...@irc.msk.ru>> wrote:
>>>
>>> Do you set sampling rate 192000 on both ends? Post your grc files.
>>>
>>> On Thu, 8 Aug 2013 14:09:42 +1000
>>> Vanush Vaswani mailto:van...@gmail.com>> wrote:
>>>
>>>  > Hi there,
>>>  >
>>>  > I'm trying to stream the FCDPP over UDP to a another computer
>>>  > The setup is as follows
>>>  >
>>>  > FCDPP Source -> UDP Sink
>>>  >
>>>  > For the receiver,
>>>  >
>>>  > UDP Source -> LPF -> Quadrature demod -> FM Deemph -> LPF -> Audio
>>>  > sink
>>>  >
>>>  > Unfortunately, when I run the flowgraph on the receiver end, I
>>> only
>>>  > hear a bunch of clicks.
>>>  > The console is full of messages "WARN: Too much data; dropping
>>>  > packet.". WX GUI FFT Sink and Waterfall seem to work, though with
>>> the
>>>  > same messages.
>>>  >
>>>  > Any hints to rectify this issue?
>>>
>>>
>>> --
>>> Alexey Bazhin mailto:b...@irc.msk.ru>>
>>>
>>>
>>>
>>>
>>> __**_
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>>
>>>
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<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] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

So the receiver begins with a sample rate of 48 KHz? So how is it possible
to FM demodulation this case?

On Fri, Aug 9, 2013 at 2:09 AM, Iain Young, G7III  wrote:

> Different parts of the flow graph can have different sample rates.
>
> You need to use the rational resampler so it's output matches what
> your soundcard expects.
>
> You may also need a complex to real somewhere. There are plenty of
> examples for a FM receiver on the web.
>
>
> Best Regards
>
> Iain
>
>
> On 08/08/13 16:56, Vanush Vaswani wrote:
>
>> How can I set the sampling rate on both ends to be the same? FCDPP
>> sampling rate is 192 KHz.
>>
>> If I include an audio sink, is the rate of the flowgraph controlled by
>> the sound card sampling rate?
>>
>> Attached are my .grc files.
>>
>>
>> On Thu, Aug 8, 2013 at 11:34 PM, Alexey Bazhin > <mailto:b...@irc.msk.ru>> wrote:
>>
>> Do you set sampling rate 192000 on both ends? Post your grc files.
>>
>> On Thu, 8 Aug 2013 14:09:42 +1000
>> Vanush Vaswani mailto:van...@gmail.com>> wrote:
>>
>>  > Hi there,
>>  >
>>  > I'm trying to stream the FCDPP over UDP to a another computer
>>  > The setup is as follows
>>  >
>>  > FCDPP Source -> UDP Sink
>>  >
>>  > For the receiver,
>>  >
>>  > UDP Source -> LPF -> Quadrature demod -> FM Deemph -> LPF -> Audio
>>  > sink
>>  >
>>  > Unfortunately, when I run the flowgraph on the receiver end, I only
>>  > hear a bunch of clicks.
>>  > The console is full of messages "WARN: Too much data; dropping
>>  > packet.". WX GUI FFT Sink and Waterfall seem to work, though with
>> the
>>  > same messages.
>>  >
>>  > Any hints to rectify this issue?
>>
>>
>> --
>> Alexey Bazhin mailto:b...@irc.msk.ru>>
>>
>>
>>
>>
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<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] question about overruns with simple flowgraph

[Vanush Vaswani]

Has there been any effort in using PTP to solve the two-clock problem (like
Audinate's Dante)?

On Wed, Aug 7, 2013 at 11:15 AM, Marcus D. Leech  wrote:

> On 08/06/2013 09:07 PM, Stephen wrote:
>
>> I tend to use the fractional interpolator--you can get exact rate
>>> matching that way.  It doesn't seem that expensive, particularly when I
>>> use it at the
>>>"low speed" part of the graph near the audio subsystem.
>>>
>>>  I tried that and it worked. But it adds a small amount of hiss. I also
>> tried the fractional resampler. It added a lot of hiss and a high pitch
>> whine. The polyphase arbitrary resampler added a more hiss than the
>> fractional interpolator but less than the fractional resampler.
>>
>> stephen
>>
>>  If you're downsampling, you do need to make certain that the bandwidth
> of your incoming signal (regardless of its rate) is appropriate for
>   the final bandwidth after the resampler.
>
>
>
>
> --
> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

How can I set the sampling rate on both ends to be the same? FCDPP sampling
rate is 192 KHz.

If I include an audio sink, is the rate of the flowgraph controlled by the
sound card sampling rate?

Attached are my .grc files.


On Thu, Aug 8, 2013 at 11:34 PM, Alexey Bazhin  wrote:

> Do you set sampling rate 192000 on both ends? Post your grc files.
>
> On Thu, 8 Aug 2013 14:09:42 +1000
> Vanush Vaswani  wrote:
>
> > Hi there,
> >
> > I'm trying to stream the FCDPP over UDP to a another computer
> > The setup is as follows
> >
> > FCDPP Source -> UDP Sink
> >
> > For the receiver,
> >
> > UDP Source -> LPF -> Quadrature demod -> FM Deemph -> LPF -> Audio
> > sink
> >
> > Unfortunately, when I run the flowgraph on the receiver end, I only
> > hear a bunch of clicks.
> > The console is full of messages "WARN: Too much data; dropping
> > packet.". WX GUI FFT Sink and Waterfall seem to work, though with the
> > same messages.
> >
> > Any hints to rectify this issue?
>
>
> --
> Alexey Bazhin 
>


udp_rcv.grc
Description: Binary data


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

[Discuss-gnuradio] Streaming Funcube Dongle Pro+ over UDP

[Vanush Vaswani]

Hi there,

I'm trying to stream the FCDPP over UDP to a another computer
The setup is as follows

FCDPP Source -> UDP Sink

For the receiver,

UDP Source -> LPF -> Quadrature demod -> FM Deemph -> LPF -> Audio sink

Unfortunately, when I run the flowgraph on the receiver end, I only hear a
bunch of clicks.
The console is full of messages "WARN: Too much data; dropping packet.".
WX GUI FFT Sink and Waterfall seem to work, though with the same messages.

Any hints to rectify this issue?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A new SDR on Kickstarter

[Vanush Vaswani]

When can you ship to Australia?
We are interested in purchasing for university SATCOM project.

Regards,
Vanush

On Sun, Aug 4, 2013 at 4:57 AM, Michael Ossmann  wrote:

> The maximum output power varies by frequency.  See:
>
> https://github.com/mossmann/hackrf/wiki/Jawbreaker#transmit-power
>
>
> On Fri, Aug 02, 2013 at 08:06:49AM +0200, Ralph A. Schmid, dk5ras wrote:
> >
> > Do not expect more than a few mW, but MMICs are cheaply available, no
> > problem to boost it a bit :)
> >
> >
> >
> > Ralph.
> >
> >
> >
> >
> >
> > From: nyxxena...@gmail.com [mailto:nyxxena...@gmail.com] On Behalf Of
> James
> > Hall
> > Sent: Thursday, August 01, 2013 5:35 PM
> > To: Ralph A. Schmid, dk5ras
> > Subject: Re: [Discuss-gnuradio] A new SDR on Kickstarter
> >
> >
> >
> > I'm wondering what the power output is on this? I haven't seen it
> anywhere.
> > I wouldn't imagine it's very much. 100mw?
> >
> > On Thu, Aug 1, 2013 at 4:53 AM, Ralph A. Schmid, dk5ras  >
> > wrote:
> >
> > I love the 6 GHz capability, but I really miss full duplex, this locks
> out
> > stuff like OpenBTS or the open source LTE system everyone is hoping for
> :)
> > For the moment I will go with the BladeRF, also a small design, nice for
> > travel. Still I am tempted to order a hackrf :)
> >
> > Ralph.
> >
> >
> >
> > > -Original Message-
> > > From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> > > [mailto:discuss-gnuradio-bounces+ralph
> >  =schmid@gnu.org] On
> Behalf Of
> > > Michael Ossmann
> > > Sent: Wednesday, July 31, 2013 11:36 PM
> > > To: Farhad Abdolian
> > > Cc: discuss-gnuradio@gnu.org
> > > Subject: Re: [Discuss-gnuradio] A new SDR on Kickstarter
> > >
> > > Thanks, Farhad.  I designed HackRF for 20 MHz with 8 bit quadrature
> > samples
> > > because it is at the maximum rate that can be transferred over USB 2.0
> > (Hi-
> > > Speed).  It's enough bandwidth for most SDR applications I've seen.
>  What
> > > applications do you have in mind?
> > >
> > >
> > > On Wed, Jul 31, 2013 at 10:32:07PM +0200, Farhad Abdolian wrote:
> > > >
> > > > Hi Guys,
> > > > Just saw this project on Kickstarter.
> > > > http://www.kickstarter.com/projects/mossmann/hackrf-an-open-source-
> > > sdr
> > > > -platform
> > > >
> > > > It is an interesting low cost SDR with 20MHz bandwidth.
> > > >
> > > > It seems like SDR is becoming more popular every day and the number
> of
> > > > low cost SDR devices are on the rise.
> > > >
> > > > I am thinking about backing it up, but I am not sure of 20MHz is
> > > > enough for the applications I have in mind.
> > > >
> > > > What do you think?
> > > >
> > > > BR,
> > > > Farhad
> > >
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
>
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Streaming audio through internet

[Vanush Vaswani]

Hello,

I would like to stream demodulated audio through GNU Radio to the internet

The way I want to achieve this is follows.
1. Create virtual sound card available as audio sink, connect some source (e.g. 
sine wave)
2. Use VLC streamer to capture audio and stream device through RTSP

So far, I have install jack, changed my audio_module to jack and created a sine 
wave flowing to an audio_sink.

When I execute the flow graph, nothing happens. (Is this expected?)

How can I capture this audio using VLC?

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