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

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

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

he cut the code? On Wed, Sep 24, 2014 at 5:53 AM, Jeff Long willco...@gmail.com 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

Re: [Discuss-gnuradio] Where is the modulation in Modulation_utils

modulation_utils is a registry for modulations implemented in other modules. A grep in the same directory as modulation_utils turns up bpsk.py, cpm.py, gfsk.py, gmsk.py, psk.py, qam.py, qpsk.py. On 09/24/2014 04:26 PM, Medhat Hamdy wrote: Hi all, I am really confused. I opened the

Re: [Discuss-gnuradio] possible bug in tag-srcid processing

It looks like you're doing it right. The example gr-blocks/examples/vector_source_with_tags.grc does the same thing, and also fails to report srcid correctly. Walked through the process in Python and it works fine. In [57]: h = pmt.to_pmt('hello') In [58]: type(h) Out[58]:

Re: [Discuss-gnuradio] Bypass work function

Bob, Saw this the other day, but there isn't a lot to go on here. If block2 is your own, you can make it do the bypass. You can also use some of the logic blocks and a multiplier depending on what you're doing. There isn't really a concept of on-the-fly switching in GNU Radio. - Jeff On

Re: [Discuss-gnuradio] SNR Peak AMplitude and Noise Floor Calculation

Ankit, First, calibration is outside the scope (so to speak) of GNU Radio and USRPs, so absolute measurements are going to require test equipment. But, you can determine SNR and the peak amplitude above the noise floor for some simple signals by viewing them on uhd_fft or a similar program.

Re: [Discuss-gnuradio] Bypass work function

Try using a threshold off the mag squared and feed that into a multiplier after block2 (with appropriate type adapters). As long as block2 doesn't have a huge delay or do rate changes, this should work. - Jeff On 09/29/2014 10:23 AM, bob wole wrote: Hi thanks for your comment. block2 is the

Re: [Discuss-gnuradio] How to import in Gnu Radio IQ.wav files recorder with SDR#?

Make sure you have a throttle block between the source and the FFT, set to the rate at which you captured the wav. Also, there is a Wav File Source under Audio. The plain File Source will also work (usually WAV is 16-bit signed, 2 chan), but will have a little noise at the beginning (the wav

Re: [Discuss-gnuradio] New to Gnuradio, couple of questions

Gerry, It will probably take a bunch of experimentation to find something that works. Since you're probably interested in the very beginning of the signal, you'll need to do power detection in parallel with a delayed version of the signal so you trigger in time. Look up some of the following

Re: [Discuss-gnuradio] How to import in Gnu Radio IQ.wav files recorder with SDR#?

: The IQ.wav file is indeed 16-bit signed, 2 channels, but it has sample rate=192000 (FCDpro+) I want to get the Complex output (Audio output is always Float). My setup is: fileSource - Throttle --wx fft sink. Still get nothing Thanassis 2014-09-29 23:31 GMT+03:00 Jeff Long willco...@gmail.com

Re: [Discuss-gnuradio] top block edge list

Ryan, You can print the edge list using print tb.edge_list() BUT, it's not populated until after tb.start(). You can either wait until after tb.start(), or you can use print tb.dot_graph() before tb.start(). It's meant to be input to dot (graphviz) but it's human readable. dotty

Re: [Discuss-gnuradio] possible bug in tag-srcid processing

On 10/01/2014 10:47 AM, Tom Rondeau wrote: On Thu, Sep 25, 2014 at 11:17 PM, Jeff Long willco...@gmail.com mailto:willco...@gmail.com wrote: It looks like you're doing it right. The example gr-blocks/examples/vector___source_with_tags.grc does the same thing, and also fails

Re: [Discuss-gnuradio] Bypass work function

. In the above scenario CMA taps change due to presence of noise, because it tries to equalize noise as well. Thanks for your comment. -- Bob On Mon, Sep 29, 2014 at 7:19 PM, Jeff Long willco...@gmail.com mailto:willco...@gmail.com wrote: Try using a threshold off the mag squared and feed

Re: [Discuss-gnuradio] BPSK Transmitter

Abhinav, If you're referring to the difference in file size, it's 4096 bytes, which probably just means there was a little data left in a buffer that didn't get pushed through when the flowgraph was done. A FIR may also eat some number of samples (not sure about this). If you're referring

Re: [Discuss-gnuradio] Difference between QT/WX

They're both implemented in C++, and both wrapped in Python. New feature work, however, is aimed at the QT-based blocks in GNU Radio, so you won't see as many WX blocks or features. - Jeff On 10/03/2014 04:32 PM, Isen I-Chun Chao wrote: I think it just an alternative of UI, one is based on

Re: [Discuss-gnuradio] TVRX2 and GRC

Dan, If you execute the various sudo sysctl ... lines shown in the warnings, does it work any better? You can make these permanent. man sysctl.conf - Jeff On 10/03/2014 05:23 PM, Daniel Marlow wrote: Hello, We have a new TVRX2, which we are using with a N200 USRP. The N200 has a

Re: [Discuss-gnuradio] BPSK Transmitter

Abhinav, This doesn't matter for a real world problem. You could add zeros to the end of your input if you need a certain number of samples out. Please keep replies on the list. - Jeff On 10/04/2014 02:14 AM, Abhinav Jadon wrote: Jeff , If i dont use the filter , then how do i demodulate

Re: [Discuss-gnuradio] Gnuradio DCS Module

Martin, Some ideas inline ... hope some of this is useful. On 10/07/2014 03:30 PM, Martin Holst Swende wrote: Hi list, I am pretty new to Gnuradio / SDR, experimenting with a HackRF. As a startup experiment, I wanted to communicate with simple handheld radio devices (toy radios). These radios

Re: [Discuss-gnuradio] Gnuradio DCS Module

On 10/07/2014 07:16 PM, Jeff Long wrote: Martin, Some ideas inline ... hope some of this is useful. On 10/07/2014 03:30 PM, Martin Holst Swende wrote: Hi list, I am pretty new to Gnuradio / SDR, experimenting with a HackRF. As a startup experiment, I wanted to communicate with simple

Re: [Discuss-gnuradio] Delay block controlled by input

If you're comparing real time (system clock) to your sample stream, you'll get jitter, not drift, using a throttle. Throttle maintains a sample rate over time, but operates on blocks, and also is running under a non-realtime operating system. If you're talking about drift between the clock on

Re: [Discuss-gnuradio] Packet Encoder-Decoder

Hi Thanasis, 1. The flow you showed could not have worked because Packet Decoder takes unpacked bytes. The graph should be: File Source - Encoder - Packed-to-Unpacked - Decoder - File Sink 2. The payload length defaults to 512 if you leave it at 0, so a short file won't fill a packet.

Re: [Discuss-gnuradio] Sub-classing a block defined in an _impl class

The good part is the separation of the API from the implementation. The not so good thing is that the implementations themselves often contain all the logic, usually because they are fairly simple. So, your choices are to subclass or copy/edit the implementation files. [Just saw Sylvain's not

Re: [Discuss-gnuradio] A BERT Block with Offset Compensation

Hi Dan, On 10/12/2014 03:48 AM, Dan CaJacob wrote: I am working on a GR block that will test two incoming bit streams (one a reference and one a received result) for equality and return the estimated BER. Blocks already exist that do this, but they assume the streams are aligned. My block

Re: [Discuss-gnuradio] Source Block - Flow Control

Use a throttle block immediately after your source block, setting the vector size to match your source. - Jeff On 10/14/2014 04:34 PM, David Halls wrote: Dear All, I am wondering how to add some flow control to a source block, so that it doesn’t fire out items so quickly. Later stages of my

Re: [Discuss-gnuradio] Source Block - Flow Control

Should have mentioned ... set the throttle rate just slightly higher than what the chain would consume at steady state when all the buffers are filled and the USRP is transmitting. How well this works depends on what the rest of the chain looks like. - Jeff On 10/14/2014 05:52 PM, Jeff Long

Re: [Discuss-gnuradio] Source Block - Flow Control

of the database during the initial transient (which I don't recommend), you should do that within your source block. Matt On Tue, Oct 14, 2014 at 10:56 AM, Jeff Long willco...@gmail.com mailto:willco...@gmail.com wrote: Should have mentioned ... set the throttle rate just slightly higher

Re: [Discuss-gnuradio] Import block

Fernando, Set the PYTHONPATH environment variable to include the location of the file you want to import, then re-run gnuradio-companion (or the generated Python file). In bash: export PYTHONPATH=$PYTHONPATH:/some/other/directory Then you can put 'import psk' in an Import block. - Jeff On

Re: [Discuss-gnuradio] Import block

On 10/20/2014 03:42 PM, Jeff Long wrote: Fernando, Set the PYTHONPATH environment variable to include the location of the file you want to import, then re-run gnuradio-companion (or the generated Python file). In bash: export PYTHONPATH=$PYTHONPATH:/some/other/directory Then you can put

Re: [Discuss-gnuradio] Memory allocation issue

Ron, See if you can set kernel.shmmax to something higher. You can check the current value with sysctl kernel.shmmax See sysctl(8). Jeff On 10/21/2014 04:12 PM, Ron Economos wrote: I'm writing a block that requires a large amount of data to be processed in one iteration of the work

Re: [Discuss-gnuradio] What does Feedback mean in the issue tracker?

On 10/24/2014 09:02 PM, Kevin Reid wrote: What does it mean in the GNU Radio issue tracker for an issue to have the status Feedback? Usually Feedback does mean waiting for user feedback. But in this case, I think it means hmm, have to think about that. Both reports have the same underlying

Re: [Discuss-gnuradio] Filter in rational resampler

On 10/27/2014 04:40 PM, Andy Walls wrote: On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org wrote: Message: 5 Date: Wed, 30 Jul 2014 18:42:14 +0200 From: Daniele Nicolodi dani...@grinta.net To: GNURadio discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Filter in rational

Re: [Discuss-gnuradio] Filter in rational resampler

On Oct 27, 2014 6:36 PM, Jeff Long willco...@gmail.com wrote: On 10/27/2014 04:40 PM, Andy Walls wrote: On Thu, 2014-07-31 at 12:01 -0400, discuss-gnuradio-requ...@gnu.org wrote: Message: 5 Date: Wed, 30 Jul 2014 18:42:14 +0200 From: Daniele Nicolodi dani...@grinta.net To: GNURadio

Re: [Discuss-gnuradio] Filter in rational resampler

On 10/28/2014 07:47 AM, Andy Walls wrote: From: Jeff Long Subject: Re: [Discuss-gnuradio] Filter in rational resampler Date: Tue, 28 Oct 2014 04:31:30 -0400 On Oct 27, 2014 6:36 PM, Jeff Long address@hidden wrote: On 10/27/2014 04:40 PM, Andy Walls wrote: On Thu, 2014-07-31 at 12:01 -0400

Re: [Discuss-gnuradio] All ist klar, Herr Kommisar

On 10/30/2014 03:04 PM, Ryan Marlow wrote: I've seen this comment for a while now in flowgraph.cc and most of the time chose to ignore it. Today I saw it and decided to do a quick google search to see what I could find. https://www.youtube.com/watch?v=6GmkjnL4EYw What??? Why??? Funny easter egg

Re: [Discuss-gnuradio] Software Compatibility among USRP2, N and X Series

Jiayi, Generally, the UHD driver hides the difference, so the Ettus products are interchangeable. There aren't too many projects that are specific to model, unless you're looking at FPGA mods. But there are some differences (or there wouldn't be separate products) having to do with frequency

Re: [Discuss-gnuradio] GRC, Recording chunks of spectrum triggered on input signal level

On 11/12/2014 02:54 PM, Staffan Bruce wrote: Hello, Being limited in my programming skills, I would very much like to do the following in Gnuradio Companion: * Sample an input stream (from RTL-SDR) * Generate a trigger signal based on the input stream * If a trigger criterion is met, save/sink

[Discuss-gnuradio] [PATCH] Tagged sink and UHD source tags

Tagged file sink is not compatible with UHD source. Tag name and type disagree. diff --git a/gnuradio-core/src/lib/io/gr_tagged_file_sink.cc b/gnuradio-core/src index d698927..b8e9fb7 100644 --- a/gnuradio-core/src/lib/io/gr_tagged_file_sink.cc +++

[Discuss-gnuradio] USRP2 firmware build

Trying out the firmware build ... - had to comment out apps/rx_only_v2.c, line 104 (static volatile bool link_is_up = false) to avoid multiple definitions ... does not appear to be used in this file and is declared static - build exceeds size of flatmem (0x8000) ... bumped to 0xa000 and

[Discuss-gnuradio] Re: USRP2 firmware build

Also, mb-gcc had trouble with -Wl,-T$(LINKER_SCRIPT). Had to add another comma: -Wl,-T,$(LINKER_SCRIPT) Jeff Long wrote: Trying out the firmware build ... - had to comment out apps/rx_only_v2.c, line 104 (static volatile bool link_is_up = false) to avoid multiple definitions ... does

Re: [Discuss-gnuradio] USRP2 firmware build

txrx.bin from 26028 to 25484 bytes. The function __udivdi3 is 1836 bytes long, and is only used in print_uint64, which is used only in printf_fxpt_freq. That might be something to get rid of. Eric Blossom wrote: On Fri, Oct 03, 2008 at 01:58:02PM -0400, Jeff Long wrote: Trying out the firmware

Re: [Discuss-gnuradio] USRP2 firmware build

Right now __moddi3, __umoddi3, __divdi3 and __udivdi3 contain inlined versions of __udivmoddi4. Un-inlining them should save about 5KB in the worst case, 4KB typical. I'm working on it. (These routines implement signed and unsigned 64-bit divides and mods. We use these in dealing with our

Re: [Discuss-gnuradio] pipe data from GRC through shell command (like gr-pipe in 3.6) ?

Mark, The File Descriptor Source/Sink work with stdin/stdout. On 12/16/2014 12:03 PM, M Dammer wrote: I want to pipe data from GRC through a command running in the linux shell. I found gr-pipe on github, but it seems to be for 3.6 only. Until now I have used file sinks / sources and FIFOs, but

Re: [Discuss-gnuradio] b210 overflows and huge usb buffer

On 01/11/2015 10:38 PM, Marcus D. Leech wrote: On 01/11/2015 10:26 PM, Juha Vierinen wrote: Hi, Now that the b210 timing issue now solved (thanks to Ian and Balint!), I'm trying to get samples to disk at about 50 MHz. I have more than I've streamed through programs like mbuffer before, to

Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC

/sec. Take a look at the Bluetooth physical layer spec for more info. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.com mailto:willco...@gmail.com wrote: On 01/10/2015 02:46 PM, vaibhav kulkarni wrote: Hi All, I am searching for an implementation

Re: [Discuss-gnuradio] OOK modulation naming

had a constant symbol rate. I would expect 011101001 in NRZI to look like: _-_--___- Mike On Thu, Apr 02, 2015 at 03:23:57PM -0400, Jeff Long wrote: Hey Mike, I think that NRZI. - Jeff On 04/02/2015 02:36 PM, John Ackermann N8UR wrote: Why not make the ratio 1:3 and then you could call

Re: [Discuss-gnuradio] OOK modulation naming

Hey Mike, I think that NRZI. - Jeff On 04/02/2015 02:36 PM, John Ackermann N8UR wrote: Why not make the ratio 1:3 and then you could call it Morse PWM. :-) On 4/2/2015 2:16 PM, Michael Ossmann wrote: A friend recently showed me an OOK modulation that I had never seen before, and I'm

Re: [Discuss-gnuradio] Multipath Fading

On 04/25/2015 07:36 AM, Ritvik Pandey wrote: Regarding my last post i want to bring it to your notice that i have to implement a multipath fading channel emulator so can you tell me how can i do that? On Sat, Apr 25, 2015 at 5:03 PM, Ritvik Pandey pandey.rit...@gmail.com

Re: [Discuss-gnuradio] SDR/USRP devices

Hi Pedro, Buy a RTL dongle, since they're almost free. If it doesn't do what you want, then you'll know more about what you want. Jeff On 08/17/2015 03:09 PM, Marcus Müller wrote: the features are not important for me now Then you can literally buy a rock. It has pretty bad reception, and

Re: [Discuss-gnuradio] Dealing with `divide 0` or `Inf` in GNU Radio C++ code.

Jeon, You can add an appropriate constant before the divide and compensate for it afterward. The exact math will depend on the values coming out of the correlators. Jeff On 08/19/2015 06:50 AM, Jeon wrote: Let's think about the following auto/cross correlator:

Re: [Discuss-gnuradio] Dealing with `divide 0` or `Inf` in GNU Radio C++ code.

(That should be moving averages, not correlators). Also, subtracting instead of dividing might do what you want. Jeff On 08/19/2015 07:25 AM, Jeff Long wrote: Jeon, You can add an appropriate constant before the divide and compensate for it afterward. The exact math will depend on the values

Re: [Discuss-gnuradio] Implementing a FIR Filter

Rich, hilbert_fc.cc and filter_delay_fc both use kernel::fir_filter in a relatively easy to understand way. Jeff On 08/18/2015 04:26 PM, Richard Bell wrote: Hi all, Would someone please recommend a good starting point in C++ source code that demonstrates how one uses the

Re: [Discuss-gnuradio] FFT Scaling

On 08/12/2015 05:39 PM, West, Nathan wrote: On Wed, Aug 12, 2015 at 12:31 PM, West, Nathan n...@ostatemail.okstate.edu mailto:n...@ostatemail.okstate.edu wrote: On Wed, Aug 12, 2015 at 10:51 AM, Gerome Jan L geromejanlla...@gmail.com mailto:geromejanlla...@gmail.com wrote:

Re: [Discuss-gnuradio] ALC662 audio card causes underruns and overruns

Make sure you're using 'plughw:' for the audio device so the driver does resampling (check ALSA docs). Without looking at the flowgraph, I'd guess this is a clock domain problem and your new computer (and audio card) clocks are somehow different than your old ones. On 08/28/2015 04:40 AM,

Re: [Discuss-gnuradio] Throttle block form wav files

You can't have a throttle block inline with an audio source. Did you try putting the throttle between the file source and the selector? (I haven't actually tried this) - Jeff On 09/03/2015 10:22 AM, Murray Thomson wrote: Hi, I'm using a flow graph with no GUI to demodulate a signal. I have

Re: [Discuss-gnuradio] ssb - question

/image/ukpcqqu39/ And after all that, I can see there a lot more peaks. So should I filter them ? What with that second peak near LSB Peak ?! Greatings, thank you in advice Przemek Lewandowski 2015-09-08 18:32 GMT+02:00 Jeff Long <willco...@gmail.com <mailto:willco...@gmail.com>>:

Re: [Discuss-gnuradio] [USRP] tracking the transmission/receiving process

As an example, look for issue_stream_command() in uhd/host/lib/usrp/cores/rx_dsp_core_200.cpp There are separate files to control the various "cores" in the FPGA logic. And, there are multiple versions of things for different boxes, transports, etc. It starts makes sense if you read through a

Re: [Discuss-gnuradio] Possible typos in a GRCon15 presentation?

Hi Jeon, Here's a long-winded answer. You're correct, but I wanted to make sure the terminology was clear. Tag offsets in add_item_tag() are absolute, relative to the beginning of the sample stream, not relative to input or output buffers. But it's probably safer to think in terms of

Re: [Discuss-gnuradio] ssb - question

Your first problem is that you're using a 32k sample rate with a 20k sin/cos. This will actually come out as a 12k sin/cos, due to aliasing. Try the same thing again with a 48k sample rate and see what happens. Either bandpass filtering or a Hilbert transform can be used to create SSB. Not

Re: [Discuss-gnuradio] Demodulating CPFSK with Viterbi algorithm using gr-trellis

Hi Sean, Don't really know much about this but I played around with the FSM code a little. Outputs would read the same as the state transitions: if in state 0 and a 0 is received, output A, else output B Using the fsms generation routines, I got a different shape FSM than yours (higher

Re: [Discuss-gnuradio] Scheduler and Tags - HELP!

Do you have a forecast() function defined in your block? If not, the scheduler will call it with however many items it has available at the time. Tags would be propagated by stream_to_vector at the same time it copies items to its output buffer. Your block would need to specify the

Re: [Discuss-gnuradio] Scheduler and Tags - HELP!

nces+david.halls=toshiba-trel....@gnu.org> on behalf of Jeff Long <willco...@gmail.com> Sent: 10 September 2015 16:46 To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] Scheduler and Tags - HELP! Do you have a forecast() function defined in

Re: [Discuss-gnuradio] Analyze data from Time Sink

Baudline is good, and you can also make up your own tools using GNU Radio, ipython/numpy/matplotlib, pyqtgraph, etc. - Jeff On 09/12/2015 02:22 PM, Przemek Lewandowski wrote: Thank you, I will check it. 2015-09-12 20:17 GMT+02:00 Kevin McQuiggin >:

Re: [Discuss-gnuradio] USRP sampling rate

Note that I kept everything in terms of "real" samples when talking about sampling rates. Also, I should have made clearer the difference between rates on receive and transmit. Transmit was not addressed. For transmit, you know the clock, so you can use a sample rate of >2B for real or >1B

Re: [Discuss-gnuradio] New module : error: expression cannot be used as a function d_fft_len(sync_symbol1.size())

The statement is fine. If you post more info, for example the file containing this statement, someone should be able to figure out why it doesn't work in context. - Jeff On 09/11/2015 05:59 AM, monika bansal wrote: hii I am making a new module using gr_modtool. i am getting an * error:

Re: [Discuss-gnuradio] Python 2.x or 3.x, C++11 or 14 or what?

GNU Radio uses Python 2.x for now, and C++ pre-11 (2007?). - Jeff On 09/11/2015 09:46 AM, Ali The GREAT! wrote: Hi everyone, I am a newbie in GNU Radio and trying to delve into it! I have decided on starting Python and C++ but I don't know which versions I should concentrate on! I searched a

Re: [Discuss-gnuradio] New module : error: expression cannot be used as a function d_fft_len(sync_symbol1.size())

dule named "gr-Channel_Estimation" and added a block named "ofdm_chanest_MMSE_vcvc". I am attaching these files as well. Thanks. On Fri, Sep 11, 2015 at 3:38 PM, Jeff Long <willco...@gmail.com <mailto:willco...@gmail.com>> wrote: The statement is fine. I

Re: [Discuss-gnuradio] Scheduler and Tags - HELP!

On 09/10/2015 02:09 PM, Jeff Long wrote: I think I found the problem, but not sure what to do about it. The block executor's tag propagation rounds "properly" when calculating offsets on a rate changing block. The result for stream_to_vector would be that the first half of the tags end

Re: [Discuss-gnuradio] To store input data

You can limit the number of samples using Head. To see the results, add File Sinks wherever you want to save samples, and use an external program to view, or use something like the QT Vector Sync in the flowgraph if it works for your case. If you are saving to a file, you do not need a

Re: [Discuss-gnuradio] Hackrf Source/Sink Combo

A GR block is not intended to be both a source and a sink, though you could probably force something. Even if you could, gr-osmosdr sits between GR and HackRF, and also separates source and sink. You could rework the gr-osmosdr hackrf support to provide a hardware manager below the source and

[Discuss-gnuradio] SDRplay rewrite w/RSP2

I picked up a SDRplay RSP2 recently, and the gr-osmosdr support needed some work. Here's a rewrite that works with RSP2 and has other improvements. When the RSP1A comes in, I'll finish support for that. No plans to pick up a RSP1, but someone can see if this works if interested. This was

Re: [Discuss-gnuradio] Fedora 27: gr-osmosdr problems

Your ldd says you're missing something: libboost_system.so.1.60.0 => not found Since all the other boost versions are 1.64.0, something got linked wrong. That would cause the error you're seeing. Most likely, there are stray boost libraries in the build path that are getting picked

Re: [Discuss-gnuradio] Audio File transmission using Qpsk modulation

A USRP doesn't work at 15k S/s, and your audio sink probably doesn't work at 120k. On the TX side you have 2 different blocking sinks (audio and USRP) which can mess things up. Not sure about the rest of it. It seems like there might be some filtering and oversampling missing. On 05/10/2018

Re: [Discuss-gnuradio] Bug in gnuradio-runtime block swig

Agree. Added issue https://github.com/gnuradio/gnuradio/issues/1757 On 05/01/2018 01:56 PM, Jessica Iwamoto wrote: Hi all, We found a bug in gnuradio-runtime/swig/block.i that prevented the set_output_multiple method from being accessed from python in a c++ block. The function declaration is

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

-1 to one branch and output-2 to another branch for further steps of processing and it worked flawlessly. I monitored nitems_written(0) and nitems_written(1), and they were always same. Let me know your views on this. On 30/04/2018 04:23, Jeff Long wrote: You are looking for the number

Re: [Discuss-gnuradio] Fundamental question on Sampling rate

Correct, you need at least 50 MS/s complex (I+Q) which is 100 MS/s or 400 MB/s from an I/O point of view. GNU Radio blocks can be used for real time decoding. Depending on what kind of "decoding" you want to do, the processor may not be able to keep up. On 04/26/2018 04:05 AM, mehtap özkan

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

is lock-up ? Similar to dual_channel short sync if I make a new block i .e dual channel long sync, will it force this block to produce same number of outputs on two output ports ? I am attaching the grc file for reference. Regards Sumit On 29/04/2018 15:49, Jeff Long wrote: I don't know the 8

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

I don't know the 802.11 code, but if the 2 sync_long blocks produce different amounts of output, eventually the "add" block will lock up. On 04/29/2018 09:30 AM, Sumit Kumar wrote: "In essence, you have to make sure that all branches start the synchronization process if one branch detects a

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

eneral_work, that they won't output the same number of bytes."* Regards Sumit On 29/04/2018 18:17, Jeff Long wrote: If you can get the ctrlport monitor/profiling code working (I can't at the moment), you can watch the buffers fill. Or, you could have the sync_long blocks print

Re: [Discuss-gnuradio] Two more potential tag propagation improvements

How much error would be produced by having the executor determine rr_in_offset and rr_out_offset by assuming the current rate holds over the current window of data? offset = (new_tag.offset - rr_in_offset) * mp_rrate + rr_out_offset + one_half; This would not require an API change. You

Re: [Discuss-gnuradio] OFDM channel tap questions

s[i-carr_offset] = sym[i] / d_ref_sym[i-carr_offset]; } } On 01/10/2018 06:19 PM, Jeff Long wrote: Noise has some bias and structure when measured over a short period. You can see this on a FFT display, where larger transforms give you a smoother noise floor. You'll notice that the t

Re: [Discuss-gnuradio] OFDM channel tap questions

Noise has some bias and structure when measured over a short period. You can see this on a FFT display, where larger transforms give you a smoother noise floor. You'll notice that the taps change randomly with every packet as the estimator adjusts to the noise. On 01/10/2018 04:59 PM, Edwin

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

The forecast function is supposed to guarantee that there is enough input, but it might be rounding down in some cases. Could you try adding the "+1" to the last line and see if that changes anything? void pfb_clock_sync_ccf_impl::forecast(int noutput_items,

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Ah, good. I didn't think it needed another +1 but couldn't think of any other overflow. On Sun, Jan 21, 2018 at 7:33 AM, Jeff Long <willco...@gmail.com> wrote: > The forecast function is supposed to guarantee that there is enough input, > but it might be rounding down in some case

Re: [Discuss-gnuradio] Segfault in Polyphase clock sync block

Added issue https://github.com/gnuradio/gnuradio/issues/1554 On Sun, Jan 21, 2018 at 7:38 AM, Jeff Long <willco...@gmail.com> wrote: > Ah, good. I didn't think it needed another +1 but couldn't think of any > other overflow. > > On Sun, Jan 21, 2018 at 7:33 AM, Jeff Long &l

Re: [Discuss-gnuradio] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

This sounds like a memory corruption error of some sort. Try printing the values after calling the volk function and see if they have been changed. On Tue, Jan 23, 2018 at 2:22 AM, Gilad Beeri (ApolloShield) < gi...@apolloshield.com> wrote: > Hi, > I have the following function: > > float

Re: [Discuss-gnuradio] GRC: Bus connections updated while the property win is still open?

You could try removing the bus_structure_source from the GRC file to see if it's somewhere in that logic. On Tue, Jan 23, 2018 at 5:37 AM, Müller, Marcus (CEL) wrote: > Hello everyone, > > I'm currently debugging a strange spinlooping issue in GRC, which > happened just while I

Re: [Discuss-gnuradio] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

The generic VOLK implementation (probably not the one being called) can't do this, but the vectorized version (which is probably being called) does things in groups of 4. Can you try making 996 the highest and see if it wrongly reports 999? ___

Re: [Discuss-gnuradio] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

t 995 to (1,1), argmax returns 992 (?!) > When I set 992 to (1,1), argmax returns 992. > When I set 991, argmax returns 888. > When I set sample #2, argmax returns 0. > > So the pattern seems to be: > Return the first index of the quartet that contains the biggest sample. >

Re: [Discuss-gnuradio] VOLK: What Could Make volk_32fc_index_max_16u() Go Wrong?

I added issue https://github.com/gnuradio/volk/issues/139 (on VOLK, not GNU Radio). On Tue, Jan 23, 2018 at 8:30 AM, Jeff Long <willco...@gmail.com> wrote: > OK, we're going to need someone who speaks VOLKan to fix this one, but at > least we know it's not a memory corruption problem

[Discuss-gnuradio] SDRPlay in gr-osmosdr

Here is a PyBOMBS recipe file that pulls gr-osmosdr from my sdrplay2 branch. If anyone would like to try out this support with a PyBOMBS build, this would be the easiest way. Best to build everything from scratch, but you can remove the src/gr-osmosdr directory, do a pybombs fetch/rebuild if

Re: [Discuss-gnuradio] Is there a way to know whether more input data will become available?

Sure, either way will work, but if you don't need any special behavior, call set_history() and let the default forecast() in block.cc: void block::forecast(int noutput_items, gr_vector_int _items_required) { unsigned ninputs = ninput_items_required.size (); for(unsigned i = 0; i <

Re: [Discuss-gnuradio] OOT Module Not Working Properly

Noise amplitude is 1.0, so you are generating a lot of noise. The following two lines in your block are not right. 'c' is computed but not used. 'i' is the original value, not the log. Not sure about the scaling factor (1024). #converts 1024 values stored in in1 to dB and stores them in c c

Re: [Discuss-gnuradio] USRP N210, sometimes, cannot receive packets

the USRPs to a PC > (Personal Computer) through a switch. At the USRPs, there is no GPSDO. I > run the USRPs in one flowgraph and from a PC. Hopefully, the attached GRC > file will make it clear about my program. > > Thank you so much for your time. > > Kirianto > > >

Re: [Discuss-gnuradio] USRP N210, sometimes, cannot receive packets

the packets. > > Thanks again for your feedbacks. > > Kirianto > > > On 25 January 2018 at 11:51, Jeff Long <willco...@gmail.com> wrote: > >> How are the clocks in the N210s synced? What rates are you using? What >> symptoms are you seeing that tell you the sin

Re: [Discuss-gnuradio] USRP N210, sometimes, cannot receive packets

How are the clocks in the N210s synced? What rates are you using? What symptoms are you seeing that tell you the sinks are not receiving packets? On Thu, Jan 25, 2018 at 5:34 AM, Kurniawan Dwi Irianto < kdwiiria...@gmail.com> wrote: > Hallo guys, > > I have a configuration using

Re: [Discuss-gnuradio] OFDM channel tap questions

Ah, normalization was the secret. The phase offset is there because the subcarriers frequencies each look like a phasor that keeps moving (at a rate relative to its offset). You want to predict what the phase will be at the next symbol. On 01/12/2018 01:59 PM, edwin wrote: Hi Jeff, I just

Re: [Discuss-gnuradio] OFDM channel tap questions

I have to agree with you, and I don't understand what's going on. It looks like the magnitude of the taps should be 1.0, even if there's a phase offset. On 01/11/2018 03:53 PM, edwin wrote: Hi Jeff, Thanks for the reply. What you said about the noise makes sense. However, even if I turn the

Re: [Discuss-gnuradio] How to extract part of a vector in GNURadio Companion?

Flowgraphs aren't procedural, so you can't say "run, then extract". But you can build a flowgraph in GRC, import/run it from a small Python program, and then extract a slice of the vector. On 01/30/2018 10:44 AM, kokosz wrote: Dear all, Is there any way to extract just some part of a vector

Re: [Discuss-gnuradio] How to extract part of a vector in GNURadio Companion?

AM, Jeff Long wrote: Flowgraphs aren't procedural, so you can't say "run, then extract". But you can build a flowgraph in GRC, import/run it from a small Python program, and then extract a slice of the vector. On 01/30/2018 10:44 AM, kokosz wrote: Dear all, Is there any way to extract

Re: [Discuss-gnuradio] Import Error running companion after upgrade to Fedora 27

Import errors can happen for a variety of reasons, even if the packages are still in the right place. A common reason is that libraries provided by rpms, and that gnuradio depends on, have changed. Since Boost has changed to version 1.64 in Fedora 27, you'll have to rebuild gnuradio. On

  1   2   3   4   5   6   >