Re: [Discuss-gnuradio] Issue with the Message API in Python

2019-05-24 Thread CEL
arcus, > > > > Aha! I saw hints of this in the documentation but couldn't fully connect > > the dots. > > > > Would this be the start() function of top_block, or the block in question? > > How would the syntax look like then? > > > > Regard

Re: [Discuss-gnuradio] Issue with the Message API in Python

2019-05-24 Thread CEL
he block in question? > > How would the syntax look like then? > > > > Regards > > > > Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) : > > > Hi Sebastian, > > > > > > classic one! > > > > > > You send the mess

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

2019-05-25 Thread CEL
تابة ما يلي بواسطة ‪Müller, > Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬ > > Dear Moon Light, > > > > Please stay on the mailing list. > > The guided tutorials *are* a course through GNU Radio. > > If you need an introduction to digital communications and DSP, >

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

2019-05-25 Thread CEL
Best regards, Marcus On Sat, 2019-05-25 at 15:07 +0300, Moon Light wrote: > Dear Mr > Ok, I will. > > > > ‫في السبت، 25 مايو 2019 في 2:30 م تمت كتابة ما يلي بواسطة ‪Müller, > Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬ > > Dear Moon light, > > > > Plea

Re: [Discuss-gnuradio] Issue with the Message API in Python

2019-05-26 Thread CEL
On Sun, 2019-05-26 at 14:45 +0200, Sebastian Sahlin wrote: > Hi again, > > Thanks for the info and for being patient Marcus. I suppose as a > general rule you need to be able to interpret C++ documentation if > you're going the Python route in GR? > > Regards > &g

Re: [Discuss-gnuradio] Need help with gr-eventstream

2019-05-27 Thread CEL
I'm sure Team Platypus is awesome and will do the FOSS thing and contribute that block to gr-eventstream? On Sun, 2019-05-26 at 15:46 -0600, U L wrote: > Team Platypus ran into this precise problem at the DARPA Hackfest. The only > solution was to code it up ourselves. It's non-trivial, but not

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread CEL
Hi Sebastian, I must admit that I don't remember whether the TSB block base was correctly wrapped for Python (darn it, first I write something, and then you find a glaring counterexample); in fact, there's not a single test case for that in the main GNU Radio tree, which probably means "no". Best

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread CEL
e with the tagged stream > block is to apply tags at an interval on a packet; the values are taken from > an array that I want to iterate over. However, since the work function has no > "memory" I am unsure how to solve iterating over the array. > > Den tis 28 m

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread CEL
since then I'd be able to iterate over the entire packet in one work > function call. > > Den tis 28 maj 2019 kl 16:22 skrev Müller, Marcus (CEL) : > > But that block doesn't have to be a Tagged Stream Block itself, right? > > On Tue, 2019-05-28 at 16:1

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

2019-05-28 Thread CEL
t; GNURadio.. is it within my power to define the exact number of samples that > should be available on the next call to the work function of e.g. a sync > block? > > Den tis 28 maj 2019 kl 16:28 skrev Müller, Marcus (CEL) : > > But you're free to do that in any block you des

Re: [Discuss-gnuradio] complaints about missing volk.h

2019-05-28 Thread CEL
Seems you didn't quite install things into a place CMake looks into by default; quite possibly, there will be needs to tell CMake about /usr/local/include/volk (which is what I guess is the default installation prefix if you build from source manually). Anyway, this wouldn't have helped you! Pleas

Re: [Discuss-gnuradio] [EXT] Re: complaints about missing volk.h

2019-05-28 Thread CEL
. > > What should be my next step? > > Thanks, > > Aaron > > > -Original Message- > From: Müller, Marcus (CEL) > Sent: Tuesday, May 28, 2019 1:41 PM > To: Chesir, Aaron M. ; discuss-gnuradio@gnu.org > Subject: [EXT] Re: [Discuss-gnuradio] complain

Re: [Discuss-gnuradio] [EXT] Re: complaints about missing volk.h

2019-05-29 Thread CEL
would GRC and the QT GUI be disabled? > > Thanks for your help, > > Aaron > > > -Original Message- > From: Discuss-gnuradio > On Behalf Of Chesir, Aaron M. > Sent: Wednesday, May 29, 2019 9:11 AM > To: Müller, Marcus (CEL) > Cc: discuss-gn

Re: [Discuss-gnuradio] GTK related segmentation fault when running GRC

2019-05-30 Thread CEL
Hi Jason, that backtrace didn't quite tell me anything, but then I googled the library in which the segfault happens (gtk3-nocsd). The github page to that library literally describes it as "A hack to disable gtk+ 3 client side decoration"; the readme says it's automatically being preloaded into th

Re: [Discuss-gnuradio] GTK related segmentation fault when running GRC

2019-05-31 Thread CEL
-05-30 at 16:42 -0600, Jason Fritz, PhD wrote: > That appears to have done the trick! Thank you! > > If it happens again, I'll follow up, but hopefully you won't see any > responses on this topic. > > Jason > > On 5/30/2019 2:45 PM, Müller, Marcus (CEL) wrote: &

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

2019-05-31 Thread CEL
Hi Albin, I'd love this, especially if we end up with a kernel that we can use to build decimating FIR filters that inherently convert to higher-bitwidth int or floating point. I think this could be super useful in hardware flow graphs, where one would get integer numbers from hardware anyway; i

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

2019-05-31 Thread CEL
; > > > A CIC decimator/interpolator might also be interesting, although I'm > > not sure if there's already an implementation. > > > > > > --Albin > > > > On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL) > > wrote: > > > > >

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

2019-05-31 Thread CEL
fairly good: > https://en.wikipedia.org/wiki/Q_(number_format) > > > --Albin > > On Fri, May 31, 2019 at 11:40 AM Müller, Marcus (CEL) wrote: > > > > Hm, wait, realizing something: > > Q1.31 differs from what a x86 CPU can reasonably deal with in that it

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

2019-06-04 Thread CEL
he > signal. PLease someone guide. > > > With Best Regards, > Maitry Raval, > > - Original Message - > From: "Maitry Raval" > To: "Marcus Müller, CEL" > Cc: "discuss-gnuradio" > Sent: Monday, 3 June, 2019 10:14:11 > Subj

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

2019-06-04 Thread CEL
h 48k sample rate and 8 bits per sample, my recorded > wavfile shows a very low amplitude signal, the screenshot is attached, please > check. > > > With Best Regards, > Maitry Raval, > > > ----- Original Message - > From: "Marcus Müller, CEL" > To:

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

2019-06-04 Thread CEL
Maitry Raval, > > > - Original Message - > From: "Marcus Müller, CEL" > To: "maitry raval" > Cc: "discuss-gnuradio" > Sent: Tuesday, 4 June, 2019 08:56:22 > Subject: Re: query regarding wav file recording through wav file sink block

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

2019-06-05 Thread CEL
> - Original Message - > From: "Marcus Müller, CEL" > To: "maitry raval" > Cc: "discuss-gnuradio" > Sent: Tuesday, 4 June, 2019 13:01:55 > Subject: Re: query regarding wav file recording through wav file sink > block > > Ok, there&#

Re: [Discuss-gnuradio] Request for comment: FFT optimizations

2019-06-06 Thread CEL
Hi Albin, no, it's not been discussed on the list, as far as my memory reaches. We're talking about gr:fft:fft_vcc, right? Because that output memory shifting only happens when you set shift = 1 in the constructor. I don't have any hard feelings about whether to shift the output or perform an exp

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

2019-06-06 Thread CEL
mitted signal, record > it in txt file and remove noise as well resample it to 48k in order > to save that downcoverted signal to wav file sink. > > With Best Regards, > Maitry Raval, > > - Original Message - > From: "Marcus Müller, CEL" > To: &qu

Re: [Discuss-gnuradio] Request for comment: FFT optimizations

2019-06-07 Thread CEL
ocumentation I could find is [0] and this seems like some > Intel > wrapper that is not part of FFTW?! > > Cheers > Johannes > > [0] > http://sep.stanford.edu/sep/claudio/Research/Prst_ExpRefl/ShtPSPI/intel/mkl/10.0.3.020/interfaces/fftw3xf/wrappers/fftwf_execute_dft.c &g

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

2019-06-07 Thread CEL
es are *interpreted* by the reading software. GNU Radio maps -1 to +1 to the full scale of the wav file's sample format. Other software might do something else. Best regards, Marcus > With Best Regards, > Maitry Raval, > > > - Original Message - > From: "Mar

Re: [Discuss-gnuradio] Determining distance from OFDM signals

2019-06-07 Thread CEL
Well, you can go ahead and at least to a degree enforce a known relative phase between transmitter and receiver, but yeah, without extensive external synchronization effort (e.g. GPSDOs – hi there, u- blox :) ), the receiver phase is random relative to the transmitter's phase. So, the distance can'

Re: [Discuss-gnuradio] Determining distance from OFDM signals

2019-06-08 Thread CEL
Hi Qasim, a) it's so nice to see you drop in here from time to time :) b) that's true! But reality is even better; the back and forth exchange isn't strictly necessary. c) I finally find the time to write down what I wanted to write. ## First, agreeing with you: One can basically emulate the pri

Re: [Discuss-gnuradio] RTTY receiver

2019-06-11 Thread CEL
Yeah, char signedness is compiler-dependent (and can be configured with -f[un]signed-char in GCC). Neither C nor C++ specify a "default" signedness in the standard. So, if you want to do arithmetic on chars, you need to specify which data type you'd want – signed char or unsigned char. That's wha

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

2019-06-11 Thread CEL
There's the function probes. Using that is almost always a sign of bad design; what do you want to achieve that way? Best regards, Marcus On Sun, 2019-06-09 at 19:23 -0500, Daniel Andres Palacios wrote: > > Hi everyone > it is there a way to get and store in a variable the output of gr- > inspe

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

2019-06-11 Thread CEL
output is a vector of tuples with center > frequency an band width. I want to know the length of the vector without > using the debug block. And store the data for further processing. > > On Tue, Jun 11, 2019, 02:22 Müller, Marcus (CEL) wrote: > > There's the function pr

Re: [Discuss-gnuradio] names to use for ubuntu package manager to get install GNURadio

2019-06-11 Thread CEL
Hi, a full agreement from my side: especially when using Ubuntu 19.04, you get a pretty recent GNU Radio. If you want to talk to your hackRF, you need gr-osmosdr, too, so sudo apt install gnuradio gr-osmosdr and the thing is set up. Best regards, Marcus On Tue, 2019-06-11 at 10:18 -0400, Micha

Re: [Discuss-gnuradio] Output files in the VITA 49 format

2019-06-11 Thread CEL
Hi Sara, stock GNU Radio indeed doesn't include any VITA49 I/O capabilities. I'm not aware of any GNU Radio out-of-tree module that you could use to gain that. I know that Josh Blum wrote a VITA49 serializer for GREX, but that's not compatible with GNU Radio. It might serve you as inspiration fo

Re: [Discuss-gnuradio] Gnuradio life cycle

2019-06-11 Thread CEL
Hi Daniel, no, that's not right. In your program, whatever that is, if it wants to use GNU Radio: You set up a bunch of blocks – to even instantiate them, their constructors must return – and then tell the GNU Radio top_block to connect them. After you've done with that, you tell the top_block

Re: [Discuss-gnuradio] Live fm detection gr-inspector

2019-06-11 Thread CEL
Hi Daniel, please remember to be specific when asking a question: "best way" is a bit ambiguous, and "I'm not getting a good result" definitely is insufficient for us to help you make things work better. What doesn't work sufficiently well? What happens instead? Best regards, Marcus On Tue, 201

Re: [Discuss-gnuradio] RTTY receiver

2019-06-12 Thread CEL
Hi Barry, On Wed, 2019-06-12 at 06:59 -0400, ba...@dcsmail.net wrote: > Hi Kyeong, > > 1) In lib/radioteletype/baudot_encode_bb.h I tried replacing "static > const char" with "static const signed char", but it caused complications > in radioteletype/baudot_encode_bb.cc, so I took an alternate a

Re: [Discuss-gnuradio] Serial to parallel conversion

2019-06-12 Thread CEL
You want a vector to stream (not to "stream*s*") block. The reality is that what OFDM block diagrams typically show as "parallel to serial" block is usually not actually there in software or hardware architecture. Authors just put these in there to say "hey, look, we consider these consecutive dat

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

2019-06-12 Thread CEL
; > Thanks > > > > On Tue, Jun 11, 2019 at 7:59 AM Müller, Marcus (CEL) > > wrote: > > > But the debug block does exactly what you need: store the data and thus > > > allow for analysis. Why don't you want to use it? Sounds like the right > > >

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

2019-06-12 Thread CEL
ific enough > > On Tue, Jun 11, 2019 at 12:27 PM Daniel Andres Palacios > wrote: > > Ok. Thank you. > > I managed to get the messages from the debug block. Now, I have to deal > > with types conversation. > > > > Thanks > > > > On Tue, Jun 11

Re: [Discuss-gnuradio] RTTY receiver

2019-06-13 Thread CEL
On Wed, 2019-06-12 at 16:26 -0400, Barry Duggan wrote: > Hi Marcus, > > I wasn't careful in getting the filenames right, but the intent and the > execution were there :) > > If you look at bitglue/gr-radioteletype/lib/baudot_encode_bb_impl.h, the > tables have a '-1' to indicate characters whic

Re: [Discuss-gnuradio] Live fm detection gr-inspector

2019-06-14 Thread CEL
d > > > > around with the Rx gain of the USRP? > > > > > > > > Best, > > > > > > > > Sebastian Müller > > > > gse...@gmail.com > > > > PGP ID DC2AA3EE > > > > > > > > Am 13. Juni 2019 um

Re: [Discuss-gnuradio] [EXT] Re: Python3 or still Python 2.7?

2019-06-18 Thread CEL
Aaron, while I think the windows port is cool as hell, there's really not much irritation with respect to dependencies on Linux distros. Just use your modern Linux distribution's tool (apt, dnf, pacman…) to install the gnuradio package. Don't manually install any dependencies. Done. If you really

Re: [Discuss-gnuradio] [EXT] Re: Python3 or still Python 2.7?

2019-06-18 Thread CEL
Hi Marc, haven't tried that myself, but generally, CMake should be able to generate a MSVC19 project for the GNU Radio source code. The whole point of what Geof does is that he actually *does* a build, contributes a lot of fixes and improvements back, and to do that, assembles and if necessary bui

Re: [Discuss-gnuradio] Python3 or still Python 2.7?

2019-06-18 Thread CEL
Authorative answer: GNU Radio <=3.7.* : Python2 GNU Radio 3.8.* (yet unreleased) : Python2 & Python3, through a lot of hard work on our side GNU Radio >= 3.9 (unreleased): Python3 Best regards, Marcus On Mon, 2019-06-17 at 14:49 +, Chesir, Aaron M. wrote: > Will GNUradio migrate to Python3.X

Re: [Discuss-gnuradio] Divide frequency by a constant

2019-06-19 Thread CEL
Hi Barry, I don't know whether I'm following your intent, but I assume you have a Variable in GRC called "frequency_a", at say value 99 and you want to have a signal source block that you want to run at frequency 9? In that case, you can literally put frequency_a / 11.0 in that frequency field

Re: [Discuss-gnuradio] Divide frequency by a constant

2019-06-20 Thread CEL
Ah, I think I see where you're going :) So, here, we're really talking about digital clock division! That is, a counter :) While that'd be totally possible to piece together (counting edges, then emitting an edge every N input edges), it's not how DSP works: the things you handle *are* already wit

Re: [Discuss-gnuradio] Divide frequency by a constant

2019-06-20 Thread CEL
Hi Barry, On Thu, 2019-06-20 at 09:27 -0400, Barry Duggan wrote: > Marcus, > > Thank you for that. So now I have three questions: > 1) Does it matter if one uses [brackets] or (parentheses) to enclose a > vector? It appears not. That's Python syntax; [] means Python list (a mutable sequence of

Re: [Discuss-gnuradio] Divide frequency by a constant

2019-06-20 Thread CEL
ha! That's easier than I think you think it is :) So, you have some hardware to actually transmit. Let's, for the time being, assume we're doing an acoustocoupler using your soundcard. That's cool, because a) you very likely have that and b) it's easy to observe :D So, you use GNU Radio's Audio S

Re: [Discuss-gnuradio] Divide frequency by a constant

2019-06-20 Thread CEL
Hi Barry, on my way to bed, so really quick: On Thu, 2019-06-20 at 17:48 -0400, Barry Duggan wrote: > Marcus, > > OK, so that works. Now I have more questions! > > 1) Since the vector source has a repeat option, why use the Repeat > block? Does it still need a 'vector to stream' function? The

[Discuss-gnuradio] [job posting] Looking for Researchers: Robust Communications (goal: PhD / Dr.-Ing.) @ CEL / KIT

2019-06-21 Thread CEL
Dear Mailing List, advertising something here is a bit out of style for me, but considering this is really the right crowd, and CEL has really been the right place for PhDs in the communications field in the past: We're looking for people to employ; help us do interesting science and de

Re: [Discuss-gnuradio] Combining blocks

2019-06-24 Thread CEL
Hi Tom, that's **exactly** what hierarchical blocks are for. Make a new flow graph. Set the flow graph type to "Hier Block" (instead of "Qt Gui") in the "Options" block, and __give it a good "Dd" and "Title"__. You should probably also define a descriptive "Category Name", e.g. "[Resamplers]" if

Re: [Discuss-gnuradio] Difference in Spectrum Analysis between Wx and Qt?

2019-06-24 Thread CEL
Hi Martijn, Can you please use a file sink to record the signal, so that you can verify that it's different when visualized with Qt and Wx? Because: there might be a scaling difference between Qt and Wx GUI, but the math should really be the same inside. I'd hence assume that there's really a dif

Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio

2019-06-25 Thread CEL
Hi Erik, so, GNU Radio *itself* is purely host-based software; in other words, you'd be processing 100s of MHz on the poor Zynq's ARM (will not even remotely happen). What you'd need is to do the signal processing in the FPGA, for the most significant part. After you've selected your channel and

Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio

2019-06-27 Thread CEL
case > running gnuradio on the Zync board would be a dead end solution that cannot > be accelerated easily, and no appropriate approach for the given task. > > Best regards, > Erik > > > Von: Müller, Marcus (CEL) > Gesendet: D

Re: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

2019-06-27 Thread CEL
You **Really** have steep pricing ideas :) Anyway, https://osmocom.org/projects/osmo-fl2k/wiki On Thu, 2019-06-27 at 05:32 -0400, cliff palmer wrote: > Thanks for both suggestions. Both recommended solutions are great hardware, > but at those prices I may as well buy another HackRF One. > > On

Re: [Discuss-gnuradio] USB Audio Adapter as audio source

2019-07-03 Thread CEL
Hey Barry, what I usually do is run "arecord -L" and pick one of the listed things. Best regards, Marcus On Wed, 2019-07-03 at 21:48 -0400, Barry Duggan wrote: > I am trying to use a C-Media USB Audio Device as the audio source in > my > flow graph. So far, I have not had any success with the de

Re: [Discuss-gnuradio] fractional resampler weird behavior?

2019-07-03 Thread CEL
Uh, yeah. That thing always confuses me, too. The "resampling ratio" is the inverse of what you'd expect, i.e. to interpolate by 10, set it to 0.1. Note that for extreme resampling ratios (r << 1 or r >> 1), it might make sense to split the resampling between a rational resampler and this MMSE re

Re: [Discuss-gnuradio] Problem with GNU Radio v.3.6.5

2019-07-07 Thread CEL
You didn't properly install your GNU Radio or one of its dependencies, or you've installed incompatible versions of the same software, or something of the like. You should do a clean install on a clean system. Since the 3.6 branch has long outlived its community support, I can only wish you the

Re: [Discuss-gnuradio] Installing GNURadio on Centos 7

2019-07-07 Thread CEL
Dear George, getting the slightly dated GNU Radio 3.7.11 + matching gr-osmosdr + matching rtl-sdr on a clean-slate CentOS is literally three lines of command line (as root) yum install epel-release yum check-update yum install gr-osmosdr That will give you a fully functioning GNU Radio and RTL-

Re: [Discuss-gnuradio] JIT integration and undefined symbol

2019-07-10 Thread CEL
Hi Ron, wasn't aware of that. I *think* we shouldn't be doing that. Optimizing flags can't be set per submodule, but only for the whole build. Would you agree we need to "centralize" that in some way? Best regards, Marcus On Tue, 2019-07-09 at 07:36 -0700, Ron Economos wrote: > This is just a gu

Re: [Discuss-gnuradio] Clarification

2019-07-12 Thread CEL
Dear Moon Light, as I said before for other blocks: > Dear Moon Light, > > there's no such course. Get yourself familiar with GNU Radio; the usage > of these blocks should be relatively self-explanatory and illustrated > by the examples with GNU Radio. Feel free to ask specific questions > relat

Re: [Discuss-gnuradio] How should I ignore certain block and add g++ compile options in compiling GNU Radio blocks ?

2019-07-13 Thread CEL
You can remove the block that you don't want to be compiled from the lib/CMakeLists.txt . Generally, as a good development practice, try to use git branches for different features, with the "master" branch always being your "main" branch into which you only merge working features :) Best regards,

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

2019-07-15 Thread CEL
So, first of all: never use "Throttle" in a flow graph with hardware. In fact, GRC will *scream* at you that you shouldn't be doing that! Then: I can't claim to have any knowledge of the limeSDR driver, but unless that driver specifically allows you to start the TX and RX streaming at the exac

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

2019-07-15 Thread CEL
Also, without knowing, I'm almost certain that 64kS/s is not a possible sampling rate for the device. You really might want to read the console output very closely! On Mon, 2019-07-15 at 14:56 +, Müller, Marcus (CEL) wrote: > So, first of all: > > never use "Throttle&qu

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

2019-07-15 Thread CEL
Oh, and why are you doing an equalizer and a timing recovery on the *transmit* side!? On Mon, 2019-07-15 at 15:04 +, Müller, Marcus (CEL) wrote: > Also, without knowing, I'm almost certain that 64kS/s is not a possible > sampling rate for the device. You really might want to read

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

2019-07-15 Thread CEL
orial, hence that modulation scheme contains > equalizer and timing recovery on the transmit side. Shouldn't I use it? > please correct me if I am wrong. > > Sincerely, > Atiqur > > On Mon, Jul 15, 2019 at 5:05 PM Müller, Marcus (CEL) wrote: > > Oh, and why

Re: [Discuss-gnuradio] Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.

2019-07-15 Thread CEL
uld easily find out > my sampling rate for this particular SDR. I know it is silly please don't > mind. I am just a beginner of DSP and SDR communication systems. > > Sincerely, > Atiqur > > On Mon, Jul 15, 2019 at 5:48 PM Müller, Marcus (CEL) wrote: > > Dear At

Re: [Discuss-gnuradio] Question about GNU Radio Companion - Calling an external function from a QT GUI Push Button

2019-07-15 Thread CEL
Really quick: * write a Python class that has a function that takes an argument, and calls the external function you want * write a GRC block definition (GNU Radio 3.7: XML file, GNU Radio 3.8: YAML), wrapping that class * in that, define a property that has a callback; use the function you've def

[Discuss-gnuradio] Let's wrap this up! (was: Re: Delay determination between Tx and Rx signal for limesdr mini with help of gnu radio.)

2019-07-16 Thread CEL
Hi Atiqur, On Tue, 2019-07-16 at 12:02 +0200, Md. Atiqur Rahman wrote: > I really need to know that SPS(samples per symbol) like 16,32,64 so on for > qpsk scheme, possible to take? Uh-oh! You're confusing things. Samples per Symbol is a property of your pulse shaper, not of your constellation.

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread CEL
Hi Simona, * think about what you're *actually* transmitting in bandpass when you have a constant baseband * A USRP still can't be used at a sampling rate of 32 kS/s and will most definitely complain about that. Use a higher rate. Best regards, Marcus On Tue, 2019-07-16 at 17:05 +0100, Simona Si

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread CEL
Watch out! What do you get at the *output* of your SDR device when you transmit a constant complex baseband signal, mixed to a carrier frequency? How does that differ from transmitting a complex baseband sinusoid mixed to a carrier frequency? On Tue, 2019-07-16 at 18:32 +0200, sumit kumar wrote: >

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread CEL
gt; Simona > > Il giorno mar 16 lug 2019 alle ore 17:20 Müller, Marcus (CEL) > ha scritto: > > Hi Simona, > > > > * think about what you're *actually* transmitting in bandpass when you > > have a constant baseband > > * A USRP still can't be used at

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread CEL
at calibration is not so easy but I hope that. > Could you help me to understand what happened with a constant complex > baseband signal? > I am beginner in this field. > Thank you for your time. > > Best Regards, > > Simona > > Il giorno mar 16 lug 2019 all

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread CEL
d. > Best Regards, > > Simona > > Il giorno mar 16 lug 2019 alle ore 18:25 Müller, Marcus (CEL) > ha scritto: > > Well, there's leakage / DC blocking filters in most mixers, so yes. > > > > But the solution is simple (and hardware-supported transparen

Re: [Discuss-gnuradio] GNURadio File meta Sink performance.

2019-07-17 Thread CEL
That might very well be the case: 20 MS/s of 32bit float complex would amount to 1.280 Gb/s writing speed. Best regards, Marcus On Wed, 2019-07-17 at 10:35 +0530, SG wrote: > Hi all, > > I have been trying to capture data as well as meta data in file meta > sink in GNURadio. When I run my gr-

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-17 Thread CEL
e attached, 130K). > The flow graph is attached. > Do you have any suggestions? > Thank you in advance. > > Simona > > Il giorno mar 16 lug 2019 alle ore 18:59 Müller, Marcus (CEL) > ha scritto: > > That phase is not any more or less random than that of your local

Re: [Discuss-gnuradio] Using PyBOMBS to install gnuradio

2019-07-18 Thread CEL
Hi Barry, which OS / Linux Distro (I presume) are you using on your Pi? Best regards, Marcus On Wed, 2019-07-17 at 22:09 -0400, Barry Duggan wrote: > Hi, > > Today I tried to install gnuradio in my Raspberry Pi. I encountered the > following problems: > > A. In https://github.com/gnuradio/gn

Re: [Discuss-gnuradio] GNURadio File meta Sink performance.

2019-07-18 Thread CEL
The problem is not the metadata, the problems is the sheer amount of samples. Best regards, Marcus On Thu, 2019-07-18 at 13:18 +0530, SG wrote: > Hi, > > Thanks for your reply. > > Now that since metadata can't be saved to a file, how can we keep track > of timestamp of the received packets? I

Re: [Discuss-gnuradio] GNURadio File meta Sink performance.

2019-07-18 Thread CEL
ks and Regards > > SG > > On 18/07/19 2:34 PM, Müller, Marcus (CEL) wrote: > > The problem is not the metadata, the problems is the sheer amount of > > samples. > > > > Best regards, > > Marcus > > On Thu, 2019-07-18 at 13:18 +0530, SG wrote: > >

Re: [Discuss-gnuradio] Build GR 3.8 from source

2019-07-21 Thread CEL
Hi Andi, not quite sure where you're taking this. Neither cpuid.h not intrin.h are reasons for failure here. Also, it's almost certain you wouldn't want to download a compiler- specific include file from gihtub and put it somewhere! Please don't recommend something like that: We've (and I persona

Re: [Discuss-gnuradio] Build GR 3.8 from source

2019-07-21 Thread CEL
s not sure what the problem was but I see that CMake cannot find > the proper header files. Neither did I State in my email that header > files compile. Where did you come up with that? > > On Sun, Jul 21, 2019, 5:39 AM Müller, Marcus (CEL) > wrote: > > Hi Andi, > > >

Re: [Discuss-gnuradio] pybombs gnuradio install and sudo

2019-07-22 Thread CEL
Your sudo call resets the environment, and that includes things like PYTHONPATH, PATH and LD_LIBRARY_PATH. You need to add the right options to sudo. I'll carefully point out that the code in tuntap_pdu isn't really safe by any means. You generally should probably avoid running GNU Radio as root.

Re: [Discuss-gnuradio] Metadata file

2019-07-23 Thread CEL
Hello! Can you elaborate what you mean with "some information"? Best regards, Marcus On Tue, 2019-07-23 at 11:23 +0300, sarandis. Doulgeris wrote: > Hello everyone. I am to make system where at some point i want to save some > information about a signal in the memory. I read some things about th

Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor

2019-07-23 Thread CEL
Hi Alex, to get this straight: on your monitoring output, you get one item of output per item of input? (an input item being a vector, and a monitoring output item being a number) Then, everything is well: The thing is still a sync block, just one where not all output item sizes are identical, an

Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor

2019-07-24 Thread CEL
Marcus, > > > > I think what you said makes sense. I was initially thinking I would have a > > synchronous block with a message port output, but if I can keep it as > > simple as a sync block with two outputs just with different sizes, then > > that is where I

Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor

2019-07-24 Thread CEL
DTV, you may take a look at our OOT module gr-isdbt > (https://github.com/git-artes/gr-isdbt) which includes modifications to the > RS (and the viterbi) decoder to outputs the BER (but is easily modifiable to > output the number of errors). > best > Federico > > El mié., 24 ju

Re: [Discuss-gnuradio] DSP Block with internal variable output / monitor

2019-07-24 Thread CEL
nect > return _runtime_swig.top_block_sptr_primitive_connect(self, *args) > ValueError: port number 1 exceeds max of 0 > > I connected the nerrors_corrected output (type int) to a qt number sink. If I > make the output optional and don't connect to it, I don't get the error

Re: [Discuss-gnuradio] Question about metadata filesink

2019-07-25 Thread CEL
Also, I'd recommend not to rely on TCP sink/source, it's python-only and it is indeed quite fiddly – the constructors can deadlock each other. On Wed, 2019-07-10 at 17:51 -0400, Marcus D. Leech wrote: > On 07/10/2019 02:54 PM, Ellie White wrote: > > Hello! > > > > I am working on a radio astronomy

Re: [Discuss-gnuradio] Units of data saved by filesink

2019-07-25 Thread CEL
Arbitrary counts, relative to what your Device and the attached DSP you or the device are doing considers full scale. Best regards, Marcus On Thu, 2019-07-25 at 13:09 -0400, Ellie White wrote: > Hi all, > > Hope you are doing well! I have been working on a flowgraph (attached) that > will allow

Re: [Discuss-gnuradio] Question about metadata filesink

2019-07-25 Thread CEL
s why some kind of socket connection is needed. Also -- if > > you don't mind me asking, what does it mean that the constructors deadlock > > each other? How does this affect the data I am collecting? If you know of > > any blocks or methods that are more reliable,

Re: [Discuss-gnuradio] Units of data saved by filesink

2019-07-25 Thread CEL
On Thu, 2019-07-25 at 13:24 -0400, Ellie White wrote: > Hi Marcus, > > Good to know. So how would you recommend I should convert these values to, > say, watts? I described exactly that in my other email. > (I guess perhaps it would be watts squared due to the mag to mag squared > block). No.

Re: [Discuss-gnuradio] Units of data saved by filesink

2019-07-28 Thread CEL
Hi Ellie, which version of Redhat? What QT functionality are you missing? Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/disc

[Discuss-gnuradio] [GRCon] Price Progression Reminder: The price of tickets increases to USD 850 on 2019-08-01

2019-07-29 Thread CEL
On this splendid Monday afternoon, let me remind you that prices increase on the first of August. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.or

Re: [Discuss-gnuradio] memory leak with basic block

2019-07-30 Thread CEL
Hi Francesco, interesting! Can you tell us how that memory leak manifests, maybe even whether you can pinpoint the reason? Best regards, Marcus On Tue, 2019-07-30 at 11:24 +, Francesco Costa wrote: > Hi, > we are designing a block that receives multiple streams of bursts of data and > prod

Re: [Discuss-gnuradio] 3.8.0.0-rc2 build from source on macOS

2019-08-08 Thread CEL
Hi Emmanuel, my Apple experience limits itself to using an iPod in the summer 2010 or so, but I hope I can still be of help. First of all: Which path are you taking to build stuff? > - What is the proper/best/recommended UI framework to use? > >* Default build uses GTK, but it seems there i

Re: [Discuss-gnuradio] smith chart on GNU radio

2019-08-08 Thread CEL
You've not install gr-smithchart successfully into the directory your python looks into. On Thu, 2019-08-08 at 15:07 +0100, Simona Sibio wrote: > Hi Nate, > > Thank you, unfortunately I have the following error when I execute "python > ./example_smith.py": > Traceback (most recent call last): >

Re: [Discuss-gnuradio] Remotely controlling a GNURadio flowgraph via LAN

2019-08-09 Thread CEL
Hi Alex, we do have two approaches for that 1. the XMLRPC thing, which is a python-world block that basically would allow you to do the same you can do with e.g. a Qt GUI Range slider (i.e. change Python variables at runtime) 2. Ctrlport and the thrift backend, the latter of which is notoriously

Re: [Discuss-gnuradio] 802.11a capture with HackRF - Why am I not receiving signals anymore?

2019-08-12 Thread CEL
I'd recommend looking at the spectrum you receive. Also, how does receiving a 20 MHz wide channel with a HackRF work? Wasn't the maximum bandwidth of that lower? On Mon, 2019-08-12 at 15:10 -0400, Eamon Heaney wrote: > Last week, I was able to capture wifi packets in the 2.4 GHz band > (using a mo

Re: [Discuss-gnuradio] 802.11a capture with HackRF - Why am I not receiving signals anymore?

2019-08-12 Thread CEL
ney wrote: > Do you mean with a spectrum analyzer? Forgive me if that's a dumb > question, I'm a bit new to this. > > The max bandwidth of the HackRF One is 20MHz, so I should be able to > receive data. > > On Mon, Aug 12, 2019 at 3:13 PM Müller, Marcus (CEL) >

Re: [Discuss-gnuradio] Message passing: boost::bind() not executing

2019-08-20 Thread CEL
Hi! So, Occam's Razor first: Is it certain that gate_impl's general_work is really called regularly? Because: the message passing code here looks really good, and thus my first guess is that of the code which you sensibly omitted here, the rest of the general_work() somehow leads to the thing not

<    1   2   3   4   5   6   7   8   9   10   >