Re: [Discuss-gnuradio] FSK Burst emission

Take a look at gr-eventstream and gr-*burst. On 03/28/2018 04:14 AM, samuel verdon wrote: Hello everyone, Builind a FSK tansiever, I would like to send burst data. All the fec and data maniupation are made with custom block working with message. After formating everything, I  convert my

[Discuss-gnuradio] FSK Burst emission

Hello everyone, Builind a FSK tansiever, I would like to send burst data. All the fec and data maniupation are made with custom block working with message. After formating everything, I convert my data to Stream with « PDU to tagged Stream » block and send it to «GFSK mod » block. This last

Re: [Discuss-gnuradio] FSK Burst emission

Have a look at this burst fsk modem too https://oshearesearch.com/index.php/2015/05/31/building-a-burst-fsk-modem-in-gnu-radio-with-message-lambda-blocks-and-eventstream/ On 28 March 2018 at 10:57, Jeff Long wrote: > Take a look at gr-eventstream and gr-*burst. > > > On

Re: [Discuss-gnuradio] FSK Burst emission

Thank you for the answer. I forgot to say that my graph is connected to hardware (bladerf or limesdr) via osmocom block. This one give me the error that there is not enough data. Is it possible to do with hardware attached to gnuradio? All examples are without hardware and don’t have the clock

Re: [Discuss-gnuradio] Meaning of header_payload_demux0 - Parser returned #f

Hi Alex - If you want to share your GRC file with me (privately) and/or the list, we'll see what we can figure out. Guessing it's an OFDM sync issue, since GR's OFDM implementation is for async messages, and those are on a message by message basis. - MLD On Tue, Mar 27, 2018, at 8:50 PM, Roberts,

Re: [Discuss-gnuradio] FSK Burst emission

Hi Samuel, On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote: > I forgot to say that my graph is connected to hardware (bladerf or limesdr) > via osmocom block. This one give me the error that there is not enough data. Jeff's mail recommending gr-eventstream was on-spot. Best regards,

Re: [Discuss-gnuradio] Dropping samples "D" when CPU at 60%

Dear Bakshi, On Tue, 2018-03-27 at 18:00 +, Bakshi, Arjun wrote: > > After writing a cpp block for detecting the trigger and piping some samples, > the cpu utilization jumped up to +90% on all cores, and I can now support > 6.25MSps x 3 streams. This nicely demonstrates that CPU

Re: [Discuss-gnuradio] Dropping samples "D" when CPU at 60%

Regarding your flow graphs: energy_det: ### Moving average == Your Decimating FIR is really just a moving average. Try that block; it uses far less operations per sample. Delay-Divide This is a very nonlinear operation: >Divide

Re: [Discuss-gnuradio] spectrum monitoring / very wide band scanning

so, 60 steps in 3 Minutes… sounds absolutely doable with the Ettus B200 (you asked about UHD drivers, so I presume you mean USRPs – the RTL dongle has nothing to do with UHD) and the usrp_spectrum_sense.py script that comes with GNU Radio. Even if I do not endorse the architecture of that script,

Re: [Discuss-gnuradio] FSK Burst emission

Speaking of gr-eventstream, Marcus: is there any intent to pull that or something like it into core in this new Gnuradio world? On Wed, Mar 28, 2018 at 3:22 PM Müller, Marcus (CEL) wrote: > Hi Samuel, > On Wed, 2018-03-28 at 14:54 +0200, samuel verdon wrote: > > I forgot to say

Re: [Discuss-gnuradio] spectrum monitoring / very wide band scanning

Thanks Marcus, indeed I'm using B200's for this project. X300's are slightly over my budget unfortunately... but I'm also interested in doing the same with RTL dongles. You mention 450ms for tuning a B200 - that seems rather longish? Cheers - Balt On 29 March 2018 at 06:04, Müller, Marcus (CEL)

[Discuss-gnuradio] gnuradio.org feeds broken

The two feeds linked at https://gnuradio.org/rss-feed/ both return a HTTP 403 error. I think this has been going on for some time. (I couldn't find an address more suitable for reporting problems with the gnuradio.org web site; sorry to bother everyone else.)

[Discuss-gnuradio] build error at uhd::time_spec_t::get_system_time()

Hello Michael! Thanks for your reply. Yes, indeed: I would have to "distclean" the build directory. But then, using cmake to re-build is kind of drifting away from the original pybombs problem. It is more or less reverting back to what I call "the good old way" (i.e. ./configure && make && make

Re: [Discuss-gnuradio] Dropping samples "D" when CPU at 60%

Hi Marcus, Thanks for looking into the block. You're right that it's a block from trial and error, and the moving average block is what I wanted. I don't think that I'll observe a long fade effect in my setup (indoor + <10MSps sampling rate + mostly line of sight. Most multi-path components

[Discuss-gnuradio] [GSoC18] Applications are being reviewed

Hi all! The application period is over and we are now reviewing the proposals. And already a big thank you to all students who have submitted an application! The acceptance notifications will go out on April 23. We're really looking forward to working with you! Cheers, Felix