[Discuss-gnuradio] Lock onto QPSK signal

Hi, does anyone know of any good tutorials that explain how to lock onto the clock of a QPSK signal and/or correlate? I know this is all very simple in GNUradio, but I hope someone knows of a website or, preferably, a video series that will explain this. If I have 10 different QPSK users,

[Discuss-gnuradio] Sample rate of file souce/sink

This is probably embarrassingly simple but I can't seem to find the answer anywhere. I just recorded a signal to a file sink with a sample rate of 100k. I go to use that file as a source with a throttle set to 100k and it seems to playback at approximately 1/10 the speed. When I step up the

Re: [Discuss-gnuradio] benchmark_tx and rx : too many FALSE packet

Dear Nathan, I know QAM is the fastest modulation because it can carry more bits per symbol. This is a reason why I use QAM modulation. As bits per symbol level is higher, bit error rates will be increased. I expected it returns feasible error rate. However, error rates were too high. So I

Re: [Discuss-gnuradio] GNU Radio Meetup this Tuesday in Reston, VA

Anyone meeting in the lobby to get the shuttle? Time? On Tue, Mar 15, 2016 at 3:33 PM, Tom Rondeau wrote: > Generally shuttle or carpooling. > > Tom > > Sent from my phone > > On Mar 15, 2016, at 6:21 PM, Stephen Harrison > wrote: > > How are

Re: [Discuss-gnuradio] GNU Radio Meetup this Tuesday in Reston, VA

How are people getting down there? Shuttle? On Sun, Mar 13, 2016 at 4:57 PM, Tom Rondeau wrote: > Once again, for anyone in area, we will be having a GNU Radio Meetup at > the American Tap Room in Reston Town center this Tuesday starting at 7:30. > While we're in town for

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

I know I had some problems with older versions of GNU Radio with Python block and message ports breaking my flowgraph. I don't know for sure if it's the same problem though. Try to install the latest GNU Radio in a new prefix, or you could re-code this blocks in C++ in an OOT module. Cheers,

[Discuss-gnuradio] SDRA-2016: Call for Papers, Call for Talks, Call for Posters, Call for Tutorials

Dear list(s), ** apologies for cross-posting ** Call for Papers / Talks / Posters / Tutorials > SDRA-2016 at Friedrichshafen < HAMRADIO Friedrichshafen Software Defined Radio Academy 2016 (SDRA-2016) Date: Saturday 25.06.2016 Conference Websites: * http://www.sdra-2016.de

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Hi Timothée, Thank you very much, I have built a python block as you suggested and then put it between the strobe and the USRP source, but it come up error like: File "/home/mint/Documents/test_sensor/scan/scan.py", line 154, in tb = scan() File

Re: [Discuss-gnuradio] benchmark_tx and rx : too many FALSE packet

There's been some subtle miscues in this thread. Let's start over from the fundamentals. First, think about what the flowgraph is. You must understand the transmit and receive chains to do meaningful work with GNU Radio flowgraphs. This is a rather old example of sending packetized data that

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

The easiest way would be to create a simple Python block between the strobe and the USRP source : ### class frequency_sweeper(gr.sync_block): def __init__(self, initial_freq=2.37e9, step=2e6): # only default arguments here gr.sync_block.__init__( self,

Re: [Discuss-gnuradio] Picking up RF cellular signals

Marcus, Thanks again. Very helpful as always. Of course those are 2 completely different approaches, but this one can also be useful to me. I'll start looking in to it right now. Thanks! 2016-03-15 18:02 GMT+02:00 Marcus Müller : > That is direction finding, not

Re: [Discuss-gnuradio] Picking up RF cellular signals

That is direction finding, not distance estimation based on signal power. Two totally different approaches. You'll need at least two antennas for direction estimation. Meny, you're an engineer, read up on the theory; it's actually fun to see these signal and geometric equations fall into place.

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Hi Timothée, Thank you for your advice. But if I want to change the center frequency from 2.37GHz-2.43GHz with each time stepping 2MHz, how can I realize it by” Message Strobe”? Many thanks, Yan From: Timothée COCAULT [mailto:timothee.coca...@gmail.com] Sent: 15 March 2016 15:44 To: Yan Huang

[Discuss-gnuradio] GSoC Proposal (was: CQ de VU3TTL/KD2KER)

Dear Parth, from the GNU Radio side of things, I can only stress what Martin Braun said on this mailing list on multiple occassions: Read the whole GNU Radio wiki Page on GSoC; get yourself familiar with GNU Radio (google for GNU Radio Guided Tutorials), match yourself to one of the proposed

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Hi Yan, You should only pass only one value in the second member. Try : pmt.cons(pmt.intern("freq"), pmt.to_pmt(2.4e9)) Cheers, Timothée. 2016-03-15 12:14 GMT+01:00 Yan Huang : > Hi Martin, > > Thank you, it works well. But I want to change the frequency >

[Discuss-gnuradio] CQ de VU3TTL/KD2KER

Hi Guys, I’m interested in participating in GSoC 2016 with GNU radio and Debian. I’ve looked at the page at the Debian ideas page . Its not very clear to me

Re: [Discuss-gnuradio] Picking up RF cellular signals

Thanks Ralph, But when i'm opening a bts station i have to register SIM numbers that could later on connect to my network, is there a way around that? i couldnt find any.. Meny 2016-03-15 16:26 GMT+02:00 Ralph A. Schmid, dk5ras : > The phones will register to your base

Re: [Discuss-gnuradio] Picking up RF cellular signals

The phones will register to your base station, when there is no infrastructure any more - this is a common scenario in a real disaster, the cell phone infrastructure will collapse quite soon. In this situation all surviving phones will search for a new signal, find your BTS and register. Then

Re: [Discuss-gnuradio] Picking up RF cellular signals

Thank you for your comments. Marcus, sorry for bugging you with this issue. I am well aware of the previous discussions with you, and have learned from them as well as from other people. however, when i come across something like this for example: https://www.youtube.com/watch?v=ZUqzdrB1o2U i keep

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Hi Martin, Thank you, it works well. But I want to change the frequency automatically, so I change the frequency to array like: pmt.cons(pmt.string_to_symbol("freq"),pmt.to_pmt(numpy.array([2.4e9,2.45e9],dtype=numpy.float32))) and I also import numpy in GNU Radio, but it comes up with error :

Re: [Discuss-gnuradio] Multiplexing and Demultiplexing

Frequency division multiplex is having a separate frequency band for RX and for TX. You could achieve that simply by using two filters. Time division multiplex is done by either transmitting or receiving at a predefined time; that's going to be a little harder, because it typically involves

Re: [Discuss-gnuradio] Multiplexing and Demultiplexing

Dear Marcus, Many thanks for fast reply I would like to create Time Division Multiplexing or Frequency Division Multiplexing. is there any block in GNU radio companion? or I have to create. On Tue, Mar 15, 2016 at 10:26 AM, Marcus Müller wrote: > Dear Diyar, > > could

Re: [Discuss-gnuradio] Question about output/input buffers

Hi, what you are trying to do will not work in GNURadio without heavy modification of the scheduler. The in/out buffers of the blocks are allocated by the scheduler as double-mapped FIFO buffers. Whenever your (general_)work() has produced some samples, it will inform the scheduler about the

Re: [Discuss-gnuradio] Multiplexing and Demultiplexing

Dear Diyar, could you please define more clearly with what you mean with that? Generally, it's a good idea to explain a bit more broadly what your goal is; questions that don't do that are often very hard to answer. GNU Radio is a framework for signal processing, so yes, probably it is possible.

Re: [Discuss-gnuradio] benchmark_tx and rx : too many FALSE packet

Hi, I missed that. Sorry :( I tried to this example on ofdm one. It shows more stable communication than narrowband one. However, false rate still occur about 75 % (most of packet be corrupted) I don't know why ! ADD) OFDM benchmark example is different with narrowband one. It use directly

[Discuss-gnuradio] GSoC 2016 Proposal - Speed Optimizations using Viterbi Decoders

___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio