Re: [Discuss-gnuradio] GPS Time

Hi Jawad, I believe that setting the USRP Sink block's setting to: Clock: O\B GPSDO Sync: Unknown PPS is all that's needed but I do not have the hardware in front of me to verify this at the moment. I hope someone will chime in with confirmation or the correct settings, but I will check this

Re: [Discuss-gnuradio] GPS Time

Thanks Derek, I will try that when I get a chance. I didn't try setting the "Sync" parameter to "Unknown PPS" but was guessing it might have something to do with that. I will give it shot on Monday. Regards, Jawad 2016-01-08 20:07 GMT+01:00 Derek Kozel : > Hi Jawad, > >

Re: [Discuss-gnuradio] use of CCSDS 27 encoder-decoder blocks

thanks tom for your reply. as you told me to use fec api blocks i tried to use fec encoder and decoder blocks but still my output is not same as input. may be i am missing something while i am using these blocks. i have attached the image and .grc file of my flowgraph. Hitesh On Mon, Jan 4, 2016

[Discuss-gnuradio] Gnuradio 802.11g

Hi Is there any fully working implementation for the 802.11g protocol in gnuradio capable of working as an access point? I was wondering if there exist one with the MAc layer fully developed, since i've only seen simplyfied MAC layers, or is there a software/hardware limitation. Thanks in

Re: [Discuss-gnuradio] GPS Time

Hello Derek, Thanks for your answer. Unfortunately, this is the method I was referring to when I was talking about setting the time manually in a python interpreter (the only difference is that I was using the functions from gr-uhd that translate to the method you mentioned). Is there a way of

Re: [Discuss-gnuradio] Asynchronous source with zeros in between

Thanks, Tim! I tried to install gr-eventstream with the last GR version and had problems with cmake. I only had success after using the same cmake parameters I used building GR. Nevertheless, I made a drop-in replacement of my block with ES Source and I was unable to mimic the previous behavior.

[Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

Hi, Does anybody know how a signal must look to trigger a 5 GHz WLAN for a frequency change? I intend testing this feature by transmitting a radar-like signal with gnuradio, but for this I should know how this detection works, how such a signal does look :) Ralph.

Re: [Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

I managed to find an old document that details the output from the driver and the pulses I generated. I tried it with 2 different pulse characteristics : - Pulse width of 15 μs and PRF equal to 1000 Hz - Pulse width of 15 μs and PRF equal to 3000 Hz Image below details the second signal (PRF =

Re: [Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

you can start to detect the delta time of the pulses, but please also consider the usual staggering of about 8% in Delta t. interval times are definitely not constant in order to allow to distinguish between second time round signals that fall into the next pulse period, i.e. which come from

[Discuss-gnuradio] Segmentation fault (core dumped)

Hello! I unfortunately ended up reloading gnuradio and now I'm getting a "Segmentation fault (core dumped)" My system is Ubuntu 14.04LTS/64bit machine and I originally used pybombs before I messed things up and did an uninstall gnuradio with Synaptic. I then reloaded using the install guide

Re: [Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

Hi Ralph, hm; depends, I think. So, there's two things: If you're referring to a channel switch announcement, that can be part of a management frame [1]. But I think it can also be part of a beacon frame. Or a probe response frame. Luckily, 802.11 is not confusing the least. Blind guess is that

Re: [Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

Hi Ralph, I did this 2 and half years ago and I basically followed the directions in pages 60-61 of the ETSI document linked by Marcus to generate the signals. By watching the channel on which the WiFi card was operating, I generated the signal at the right frequency and I could see the card

Re: [Discuss-gnuradio] Update to GR 3.7.7.9?

Hello John, For Network Mode to work with the E310 the version of UHD installed on the host computer must match exactly the version installed on the E310 and be compiled with the network mode enabled. GNU Radio, when built from source, will use the version of UHD installed on your system already

Re: [Discuss-gnuradio] GPS Time

Hello Jawad, The UHD 3.9 release changed the default GPSDO behavior. UHD does not automatically synchronize device time to GPS time on initialization because it's not reliable during device start-up. I'm not 100% sure about GNU Radio's handling of these changes so will have to check before

Re: [Discuss-gnuradio] Segmentation fault (core dumped)

Is it this issue: http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#My-application-segfaults-immediately-It-used-to-work-and-I-didnt-change-it-What-the ? M On 01/09/2016 02:26 AM, shortwaved...@comcast.net wrote: > Hello! > > I unfortunately ended up reloading gnuradio and now I'm getting

Re: [Discuss-gnuradio] Fwd: Asynchronous source with zeros in between

Francisco, looks like you have a bugfix there. Can you submit a pull request? M On 01/08/2016 02:27 PM, Francisco Albani wrote: > Line nº 40 has an unnecesary call to "max". It should be: > > n_consumed = min(n_ready, n_demanded) > > > > -- Forwarded message -- >

Re: [Discuss-gnuradio] Update to GR 3.7.7.9?

Hello, everyone. After much assistance from Neel Pandeya and Marcus Leech at Ettus some months back I got my USRP E310 working in the remote mode with GRC 3.7.7.1/Ubuntu 14.04 LTS on the local platform. Haven't discovered any bugs or segfaults using this setup. Should I update to the latest

[Discuss-gnuradio] Fwd: Asynchronous source with zeros in between

Line nº 40 has an unnecesary call to "max". It should be: n_consumed = min(n_ready, n_demanded) -- Forwarded message -- From: Francisco Albani Date: 2016-01-07 20:24 GMT-03:00 Subject: Re: [Discuss-gnuradio] Asynchronous source with zeros in

[Discuss-gnuradio] GPS Time

Hi all, Yesterday, I decided to update from GNU Radio 3.7.7.1 + UHD 3.8.4 to GNU Radio 3.7.9 + UHD 3.9.1. I used pybombs and everything went well, my OOT modules compile and my blocks run just like they used to. My issue comes from the time that is set on the USRP. It seems like the time on the

Re: [Discuss-gnuradio] Asynchronous source with zeros in between

You may want to look at gr-eventstream source block, this is exactly what it is intended to do, precisely timed if desired On Mon, Nov 30, 2015, 2:38 PM Francisco Albani wrote: > Hi to all. > > (this email subject may be inaccurate) > > I need a block with the

Re: [Discuss-gnuradio] Moving Average Block

Whoops, just noticed I didn't reply to all when I answered so my message and Pedro's response were not forwarded to the mailing list : Le jeu. 7 janv. 2016 à 20:28, Pedro Gabriel Adami < pedrogabriel.ad...@gmail.com> a écrit : Dear, Timothée, Thank you so much. I am doing some tests and I've