Re: Taylor detector

It's possible to simulate a Tayloe detector in gnuradio. Probably this would involve stream demux block, filters, negate and sum. Ie. there's no "capacitor" block. You will need to think in terms of functions. On Sat, Aug 13, 2022, 20:57 david vanhorn wrote: > Because in GR I can generate

Re: Low sample rate hardware

For low budget modify the low pass filter of a sound card. On Wed, Feb 9, 2022, 15:27 vitt...@pm.me wrote: > Good evening everybody > I'm looking for a sampling device, GNURADIO compatible, with low sample > rate ( max 50 KHz ) AND frequency response down to 1 Hz, so sound cards > aren't the

Re: VOLK C++ core

I like the idea. It will make it difficult to use volk with other language's FFI though. --Albin On Tue, Dec 21, 2021, 12:27 Marcus Müller wrote: > Hi Johannes, > > I, for one, like it :) Especially since I honestly find void > volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny

Re: Does complex conjugate invert IQ ?

This might be of interest. https://www.dsprelated.com/showarticle/51.php --Albin On Mon, Dec 13, 2021, 16:45 Cyrille Morin wrote: > Hi, > > You could use a "Complex to Float" to separate the I and Q components, > followed by a "Float to Complex", inverting the re and im inputs. > > > Le

Re: GNU Radio on Raspberry Pi 4?

ot been released yes as it has > the pi4 has a more recent GPU. > Or am I completely wrong? > > > 73 > kristoff - ON1ARF > > > On 17/12/2020 1:22 p.m., Albin Stigö wrote: > > I suspect a lot of the graphics could run perfectly fine if they took > > advantage of the

Re: GNU Radio on Raspberry Pi 4?

; making use of a legacy mode that it still supports. > > Best regards, > Marcus > > On 17.12.20 10:53, Albin Stigö wrote: > > 64bit mode is most likely better because in addition to being 64bit it > > enables additional cpu features (certain new instructions and more SIMD >

Re: GNU Radio on Raspberry Pi 4?

64bit mode is most likely better because in addition to being 64bit it enables additional cpu features (certain new instructions and more SIMD NEON registers) On Thu, Dec 17, 2020, 10:36 jean-michel.fri...@femto-st.fr < jean-michel.fri...@femto-st.fr> wrote: > The benchmark on volk/64 bit kernel

Re: GNU Radio on Raspberry Pi 4?

And remember to run volk_profile On Thu, Dec 17, 2020, 08:03 Albin Stigö wrote: > Dan, > > I can't comment on your particular flowgraph but I can tell you that you > will get a significant speed-up if you build volk and GNURadio from source > (and maybe fftw) as this enable

Re: GNU Radio on Raspberry Pi 4?

Dan, I can't comment on your particular flowgraph but I can tell you that you will get a significant speed-up if you build volk and GNURadio from source (and maybe fftw) as this enables all sorts off optimizations not in the ppa for compatability reasons. If you decide to go down this route I

Re: GPIO lines on RPi4

> lost is still > not yet understood). Will have a look at this new Python Snippet feature. > > Thanks, JM > > -- > JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, > 25000 Besancon, France > > June 22, 2020 2:05 PM, "Albin Stigö" wrote:

Re: GPIO lines on RPi4

It might be difficult to control GPIO with precise timing on raspberry pi depending on what you want to do... A few hundred khz might be ok though. libgpiod is the new better Linux GPIO API. --Albin On Mon, Jun 22, 2020, 13:25 Marcus Müller wrote: > It gets even better: > > We've launched a

Re: Multithreading in GR blocks

An alternative is to use none blocking IO and use poll or select in your worker thread and use another fd created with pipe(2) to signal that you are done... Or a timer fd like Sylvain suggests. Not sure if boost has some portability wrapping for this? --Albin On Mon, Apr 13, 2020, 19:59 Sylvain

Re: Slack alternatives

+1 On Tue, Feb 4, 2020, 17:26 Sylvain Munaut <246...@gmail.com> wrote: > Hi > > > as you might know, Slack has become a very frequently used tool for > communication in the project. > > Tbh, I never understood the hype around Slack (not the form of > communication but the specific software). It

Re: Generating CW-morse signals with a straight key

General raspberry pi advise: GNURadio is quite slow on raspberry pi if not built from source as this will use the best compiler flags. The apt version is backwards compatible and hence slower. Also volk needs to be built from source. Then you need to run volk_profile to use the best available

Re: Generating CW-morse signals with a straight key

I did extensive experimentation with this and it's tricky to get the timing good enough with GPIO. Like Gorkem says mic/line is a good option. You can connect an oscillator and just send a tone in, filter this and then just send it as "SSB" as a pure tone in SSB is just a carrier. You can also

Re: AM demodulation

Hi Barry, Some thoughts: You have a large DC spike at the center, try using the frequency xlating fir filter to tune an offset frequency. Why don't you decimate at the channel filter? Try observing the signal at various points using the frequency sink. Good luck, Albin SM6WJM On Sat, Oct 26,

Re: [Discuss-gnuradio] Create a general block using a GRC 'misc Python block'

Nice! I like the way you generate morse code using the repeat block! I don't see that the keying is filtered in any way which will lead to clicks... some kind of symbol filter would be nice! You can use the rotator block to generate a complex tone to send morse code with an SDR transmitter.

Re: [Discuss-gnuradio] [GSoC19] Final results announced!

That's great news! On Wed, Sep 4, 2019, 11:08 Wunsch, Felix (CEL) wrote: > ​Hi all, > > > today, the final results for this year's Google Summer of Code were > announced. We are happy to say that both students that worked for GNU Radio > during the summer successfully completed GSoC!

[Discuss-gnuradio] set_min_noutput_items has no effect?

Hi, Regarding coding blocks in C++: Like the subject says, set_min_noutput_items seems to have no effect? set_output_multiple has the intended effect and works as a workaround though... I'm I doing something wrong? --Albin ___ Discuss-gnuradio

Re: [Discuss-gnuradio] ffast-math

acarsdec runs over 400% faster. > > > On Sun, Sep 1, 2019, 07:11 Albin Stigö wrote: >> >> Anyone has experience with the real world impact of using gcc -ffast-math >> with SDR in general, and GNURadio/Volk in particular? >> >> >> --Albin SM6WJM >>

Re: [Discuss-gnuradio] ffast-math

regards, > Marcus > > On Mon, 2019-09-02 at 16:52 +0200, Albin Stigö wrote: > > ffast-math disables signed zero by design I think... > > > > I'm particularly interested in problems of numeric stability and loss of > > dynamic range. > > > > > &g

Re: [Discuss-gnuradio] ffast-math

gt; > Cheers > Johannes > > Am 01.09.19 um 16:10 schrieb Albin Stigö: > > Anyone has experience with the real world impact of using gcc > > -ffast-math with SDR in general, and GNURadio/Volk in particular? > > > > > > --Albin SM6WJM > > > &g

[Discuss-gnuradio] ffast-math

Anyone has experience with the real world impact of using gcc -ffast-math with SDR in general, and GNURadio/Volk in particular? --Albin SM6WJM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Maximum input items consumed on each input stream

Laura et al, consume_each <= ninput_items. If you need a larger buffer than you consume you can abuse the scheduler slightly by set_relative_rate(1, some_min_input_items), this is done in the stream to vector blocks for example. I do this in a visualization sink where I need to produce FFTs with

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

You could implement your flowgraph in python and then use some python library for rpc and write a thin layer between... You can also implement a flowgraph in C++. I'm currently playing around with RPC over DBUS (only control, no data) for an application I'm writing in C++. --Albin On Fri,

[Discuss-gnuradio] ARM optimization update

Hi, ARM support is now pretty much done for libvolk. I'm just waiting to sign the Contributor licence agreement before I start sending pull requests. There has been some (legimite) concern that my branch is a total mess, but don't worry, I will refactor so there will be one pull request / kernel,

[Discuss-gnuradio] Request for comment: FFT optimizations

Hi, There's a lot of memcpy/memmove going on in the FFT kernel which I suspect degrades performance quite a bit... This is partly because some platforms requires buffers to be aligned for SIMD to work and partly because DC is not normally centered (which is normally what you would like to see in

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

-05-31 at 11:45 +0200, Albin Stigö wrote: > > > two's complement being the standard way of > > > dealing with numbers > > > > Signed numbers at least... > > > > Signed Q values are (at least in all cases I've seen) stored in two's > > complement form

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

eal with, > and then implement the rest of fixed point arithmetic with that. > Is that sensible? > > Best regards, > Marcus > On Fri, 2019-05-31 at 11:34 +0200, Albin Stigö wrote: > > What about naming these functions... any ideas? Here are some > > suggestions of the to

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

What about naming these functions... any ideas? Here are some suggestions of the top of my head: volk_32i_convert_32f volk_q1.32_convert_32f volk_q1_32_convert_32f --Albin On Fri, May 31, 2019 at 10:30 AM Albin Stigö wrote: > > Thanks for the feedback Marcus! > > Pretty much a

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

> (Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion > instructions.) > > Best regards, > Marcus > > On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote: > > Hi, > > > > Volk has functions for converting between int and float by casting

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

Hi, Volk has functions for converting between int and float by casting and multiplying with a scalar. I'd like to purpose functions for the special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this is a very common use case and might be available to an optimization. Certain CPUs

Re: [Discuss-gnuradio] ARM optimizations update

me snarky comments. > > On Thu, 30 May 2019 16:20:44 +0200 > Albin Stigö wrote: > > > I've finished ARM NEON SIMD optimization for 44 kernels which means > > only 23 kernels (not often used) are now missing a NEON > > implementation. > > I've checked on your pr

[Discuss-gnuradio] ARM optimizations update

Hi, I've finished ARM NEON SIMD optimization for 44 kernels which means only 23 kernels (not often used) are now missing a NEON implementation. All of the kernels so far are written using compiler intrinsics which means they will compile on both arm 32 and 64 bit. I've experimented with aarch64

Re: [Discuss-gnuradio] Messaging Passing on a Budget

I like to use the socketpair(2) syscall for this, if you don't really need a message broker. --Albin On Wed, May 29, 2019, 21:26 Brad Hein wrote: > Packaging the json string as a vector of u8 integers worked like a charm, > thank you for the suggestion! > > Python code: >

Re: [Discuss-gnuradio] Tutorial question

You can also program a flowgraph in c++ but it's not so simple. On Fri, May 24, 2019, 14:19 Michael Dickens wrote: > Hi Hans - GR Companion generates a Python script that you can run directly > from the commandline. You can set the name in the config box (upper left) > in the GRC flowgraph

Re: [Discuss-gnuradio] VOLK, gnuradio does not compile

Yes! It's only complicated to keep it as an internal submodule! On Wed, May 22, 2019 at 2:11 PM Philip Balister wrote: > > Or use > > -DENABLE_INTERNAL_VOLK=OFF > > when you run cmake. > > Volk living in and out of the source tree is painful. Time to toss it > out and let it stand alone! Makes

Re: [Discuss-gnuradio] UART block in GNU RADIO?

You mean a block where you input bytes, and the block adds start bit, stop bit and parity bit(s)? Albin On Mon, May 13, 2019, 23:04 mehtap özkan wrote: > Well, I would gladly pay for a c++ block. Anyone interested? > > 13 May 2019 Pzt 23:40 tarihinde Müller, Marcus (CEL) > şunu yazdı: > >> I

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

: > On 05/09/2019 02:54 PM, Albin Stigö wrote: > > Every instance of a block is an instance of the c++ class but like Nick > says all your variables are static and not member variables. Those need to > be declared in the header. Your two block instances are referring to the > same va

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

Every instance of a block is an instance of the c++ class but like Nick says all your variables are static and not member variables. Those need to be declared in the header. Your two block instances are referring to the same variables and that's why things get messed up. "A tour of C++" by Bjarne

Re: [Discuss-gnuradio] RPi Filesystem Image

: > On 05/08/2019 01:15 PM, Albin Stigö wrote: > > An official gnuradio raspberry pi image or PPA would be really neat! > > > > Raspbian comes with an older version of gnuradio not properly optimized. > > > My understanding Raspbina was bult for the orginal armv6 Pi. T

Re: [Discuss-gnuradio] RPi Filesystem Image

An official gnuradio raspberry pi image or PPA would be really neat! Raspbian comes with an older version of gnuradio not properly optimized. --Albin On Wed, May 8, 2019, 18:46 Philip Balister wrote: > On 05/08/2019 12:09 PM, Ben Hilburn wrote: > > Hi Glen - > > > > We’ve put our event

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

I've tried out. I'll dust one off and see if I can make it work in this > application. > > > > On Wed, May 8, 2019 at 4:15 AM Albin Stigö wrote: >> >> Hi Brad, >> >> Just some random ideas... What you are trying to do is very doable. Ive seen >> a lot

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

Hi Brad, Just some random ideas... What you are trying to do is very doable. Ive seen a lot of people do it for VLF reception... Usually along with some kind of FET amplifier before the mic... The frequency xlating FIR filter doesn't have great performance on the rbpi at the moment. The

[Discuss-gnuradio] libvolk NEON support progress update

Hi, Just a quick progress update. I have completed NEON support for 34 out of 74 libvolk kernels that were missing NEON implementations. Average speedup is around 4x depending on kernel, not very surprising since NEON SIMD vector size for float32 is 4... Biggest surprise was

Re: [Discuss-gnuradio] Towards NEON completeness in libvolk

Sorry about the twitter url, here's the link to the issue: https://github.com/TujaSDR/volk/tree/tuja On Wed, May 1, 2019, 19:12 Albin Stigö wrote: > Hi, > > Just a quick update. Good progress today towards NEON SIMD completeness in > libvolk. Saw a

[Discuss-gnuradio] Towards NEON completeness in libvolk

Hi, Just a quick update. Good progress today towards NEON SIMD completeness in libvolk. Saw a 14x speedup in volk_32fc_s32fc_x2_rotator_32fc on RaspberryPi 3b. Follow my progress here https://t.co/l3SHgeWSqK --Albin, SM6WJM ___ Discuss-gnuradio

Re: [Discuss-gnuradio] Half band decimator/interpolator

he classical case of "half your tap memory by only storing one half of > your symmetrical FIR" performs worse than just working with the full > (half redundant) tap vector, simply because doing so avoids nonlinear > memory access patterns. > > Best regards, > Marcus > > On Tue

Re: [Discuss-gnuradio] Half band decimator/interpolator

eady have blocks – yay! > > Best regards, > Marcus > > On Tue, 2019-04-23 at 17:45 +0200, Albin Stigö wrote: > > Just checking before I write one, is there a half band > decimator/interpolator in gnuradio I haven't been able to find... > > > > Optimized like th

[Discuss-gnuradio] Half band decimator/interpolator

Just checking before I write one, is there a half band decimator/interpolator in gnuradio I haven't been able to find... Optimized like this: http://liquidsdr.org/doc/resamp2/ Or is there an even better option for interpolation by 2? --Albin ___

Re: [Discuss-gnuradio] forum to learn more about signal-processing and SDR ?

This book is a very good starting point: http://www.dspguide.com dsp.stackexchange.com is a good place for questions. Good luck. Albin SM6WJM On Sat, Mar 16, 2019, 22:20 Kristoff wrote: > Hi, > > > One of the reasons I am currently using GNU Radio is to learn more about > signal-processing

Re: [Discuss-gnuradio] Moving my antenna

Loss will be proportional to the length of coax, type of coax, impedenace match and frequency. Higher frequency, higher loss. For example at 10MHz the loss in in 100m RG58 would be around 3.7dB, at 1000MHz 48dB, a factor 27000 difference. It's normally best practice to put the

Re: [Discuss-gnuradio] How's volk doing?

ner, we can determine the validity of each commit / PR. You can > note in any specific PR that it depends on some other PR; that's totally OK & > we'll work with them to get things going. > > Anyway that's my $0.02 worth on the matter. Thanks again for heading down > this path! - MLD >

[Discuss-gnuradio] How's volk doing?

Maybe some of you have noticed that I've been working on getting volk 1.4 and gnuradio 3.8 to compile and cross compile for ARM with clang (specifically clang 7 but seems to work down to at least 3.8). I'm happy to say that it's working pretty well now! Volk with neon support works and most of

[Discuss-gnuradio] GNURadio on ARM and rbpi3 in particular with clang7

Merry Christmas everyone, In between the festivities I've been pretty busy trying to compile, and cross compile, GNURadio and volk for ARM with clang 7. Here is a rough guide on how to do it. https://github.com/TujaSDR/gnuradio-rbpi3 Found some issues in the process and have submitted bug

[Discuss-gnuradio] Libvolk license compatability

There is the MIT neon-math library which includes a lot of the functions missing NEON versions in volk. My understanding of GPL v3 and MIT is that it's ok to include MIT code in GPL code as long as you retain the license text? https://code.google.com/archive/p/math-neon/ --Albin

Re: [Discuss-gnuradio] libvolk development

:25 PM Philip Balister wrote: > > On 12/21/2018 03:01 AM, Albin Stigö wrote: > > Hi GNURadio/libvolk friends, > > > > I've started filling in the gaps in the in the libvold SIMD matrix > > http://libvolk.org/platforms.html, for NEON. > > > > Just don't want

[Discuss-gnuradio] libvolk development

Hi GNURadio/libvolk friends, I've started filling in the gaps in the in the libvold SIMD matrix http://libvolk.org/platforms.html, for NEON. Just don't want to step on someone's toes, is anyone else working on this, NEON specifically. --Albin ___

[Discuss-gnuradio] Lock/unlock?

Does calling lock/unlock on a top block call the stop method on connected blocks? And does it flush/empty buffers? --Albin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Half duplex flowgraph

Hi GNURadio folks, I'm hacking on a small half duplex (classic ptt) transceiver application using GNUradio as backend and I'm looking for the best way for switching between two flowgraphs? Is it necessary to lock()-reconfigure-runlock() or is there some clever way of having two separate

Re: [Discuss-gnuradio] UDP sink that respects PDU? SOCK_SEQPACKET?

> Great, now I'll have to check the actual state of SOCK_SEQPACKET on > Linux on an international flight. SCTP is the greatest thing before sliced bread that never really happened... it works on the Internet but A LOT of consumer routers doesn't support it. Probably should have mentioned I

[Discuss-gnuradio] UDP sink that respects PDU? SOCK_SEQPACKET?

Hi GNURadio friends, Is there a UDP sink that respects PDUs, ie that is based on tagged_stream_block? Is there a sink that uses SOCK_SEQPACKET? --Albin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] [GSoC18] gr-modtool overhaul: Blog updates

Swapnil, This sounds really great! I'm excited to see what you come up with! Albin On Sat, May 12, 2018, 15:49 swapnil negi wrote: > Hi everyone, > I have updated the blog for the Week 0 > updates and the tasks for week 1. Here >

Re: [Discuss-gnuradio] RTP block / Opus vocoder

Hi Adrian, UDP and RTP adds a lot of overhead to a codec like Codec2 and doesn't make any sense at all unless you wan't to route your packets over an IP WAN like the internet. Then it makes a lot of sense. I imagine the only use case for an RTP/Codec2 or RTP/Opus block is streaming audio from a

Re: [Discuss-gnuradio] RTP block / Opus vocoder

tributed GSE work that can be found in > Wireshark and in GNU Radio, so working with GSE streams can be easier. > > -Michelle W5NYV > > "Potestatem obscuri lateris nescis." > > > On Wed, May 9, 2018 at 9:54 AM, Albin Stigö <albin.st...@gmail.com> wrote: &

Re: [Discuss-gnuradio] RTP block / Opus vocoder

P stream, decompress the audio to > raw audio samples, and send them via UDP to your flow graph) > > That would alleviate the need to have all this in a block, and test it > yourself. > > Best regards, > Marcus > > On Wed, 2018-05-09 at 12:30 +0200, Albin Stigö wrote: >

Re: [Discuss-gnuradio] I miss the TCP server and client blocks!

You haven't looked writing an RTP block by any chance? Thinking about writing one... Albin On Wed, May 9, 2018, 16:24 Michael Piscopo wrote: > I felt the same way so I rewrote the TCP blocks in C++/boost with thread > offloading a while back. The package should be in

Re: [Discuss-gnuradio] RTP block / Opus vocoder

is just a suggestion. It can send RTP containing Opus. > > Ron > > On 05/09/2018 01:10 AM, Albin Stigö wrote: > > Well RTP provides important functionality when streaming over the > > internet. Especially time stamping and sequence numbering which allows > > to reassembl

Re: [Discuss-gnuradio] RTP block / Opus vocoder

-Albin On Wed, May 9, 2018 at 9:35 AM, Ron Economos <w...@comcast.net> wrote: > RTP runs over UDP. Why would you need a block? Just let VLC do all the dirty > work. > > Ron > > > On 05/08/2018 11:59 PM, Albin Stigö wrote: >> >> Hi all, >> >

[Discuss-gnuradio] RTP block / Opus vocoder

Hi all, Is there an RTP (real time protocol) streaming block? I know about the UDP block but I want RTP/RTCP. If not I will start writing one... Just don't want to start a new project if there already is one. Also, what happened to Opus in the gr-vocoder? Thinking about writing an opus block as

Re: [Discuss-gnuradio] Help decoding Bell 202

For anyone working with APRS Stephen (wa8lmf) has put together a downloadable cd image with a lot of test data. Not in quadrature, but that's maybe something Hilbert can take care of. http://wa8lmf.net/TNCtest/ # Get it with wget. $ wget http://www.argentdata.com/files/tnc_test_cd_ver1.0.zip #

Re: [Discuss-gnuradio] Help decoding Bell 202

, and a 1 is encoded as no change in tone. You are probably looking for the change in bit rather than the actual bits, that could explain why your data is a bit off. There's a good summary here: http://n1vg.net/packet/ --Albin On Mon, Dec 28, 2015 at 10:54 AM, Albin Stigö <albin.st...@gmai

Re: [Discuss-gnuradio] VFO tuning knobs

Lots of people are building their own with a microcontroller and some kind of rotary encoder. One super easy way is to use the teensy arudino clone (or similar) since they already have libraries for USB HID so you can make your scroll wheel act like a mouse scroll wheel. Rotary encoders exist in

[Discuss-gnuradio] gnuradio-companion development

Hi, Is there a separate list for gnuradio-companion development? I'm interested in taking part... --Albin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion development

will definitely provide some motivation :-) --Albin On Thu, Jul 30, 2015 at 8:31 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 30, 2015 at 1:21 PM, Albin Stigö albin.st...@gmail.com wrote: Hi Seth, I'm fairly new to gnuradio but I've spent the last couple of weeks digging through the code

Re: [Discuss-gnuradio] gnuradio-companion development

on for the current version, and Hopefully we are going to start ramping up on the qt port again soon. -- Seth Sent from my iPhone On Jul 30, 2015, at 11:11 AM, Albin Stigö albin.st...@gmail.com wrote: Hi, Is there a separate list for gnuradio-companion development? I'm interested in taking

Re: [Discuss-gnuradio] gnuradio and android

It would definitely be a great thing is GRC was slightly more language agnostic! On Thu, Jul 30, 2015 at 6:21 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 23, 2015 at 4:06 PM, Volker Schroer dl1...@gmx.de wrote: Tom, thank you for your comments. I agree to your objection that

Re: [Discuss-gnuradio] Mac gui

concern you in that case. Still, Sylvain's answer on the licensing issue should be correct. Cheers, Jan 2015-07-15 13:47 GMT+02:00 Albin Stigö albin.st...@gmail.com: Hi Marcus, Thanks for your reply. This is just hacking for fun and I plan to put any code I produce on github so im

Re: [Discuss-gnuradio] Mac gui

to get, modify and distribute the source code for the GPL program). Best regards, Marcus On 15.07.2015 12:43, Albin Stigö wrote: Hi, I'm pretty new to gnuradio so please bear with me if I have missed something. I finally managed to get everything up and running on my macbook pro

Re: [Discuss-gnuradio] Mac gui

into the gnuradio runtime code as I can see I really need a deeper understanding of it. --A On Wed, Jul 15, 2015 at 1:47 PM, Albin Stigö albin.st...@gmail.com wrote: Hi Marcus, Thanks for your reply. This is just hacking for fun and I plan to put any code I produce on github so im not really

[Discuss-gnuradio] Mac gui

Hi, I'm pretty new to gnuradio so please bear with me if I have missed something. I finally managed to get everything up and running on my macbook pro yesterday (with funcube dongle pro+) and experimented with building an out of tree block. I'm interested in writing some instrumentation blocks