[Discuss-gnuradio] Lock onto QPSK signal

[Henry Barton]

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, spreaded and on the same frequency, that 
would make CDMA. Assuming no manufacturing tolerance or frequency drift, all 
the clocks on the transmitters would be perfectly the same. What I’m trying to 
understand is:

1. No two separate transmitters can ever be perfectly in sync. Even if the 
clocks were 100% accurate, User 1 might start his transmitter at 10:00:00 AM 
while User 2 starts his at 10:00:00.250 AM. The signals would be a little out 
of sync with each other. How would I pick one out in DSP?
2. I’ve heard of “clock recovery”, which implies to me that you “look” at a 
signal to find its clock, but surely you must have at least a very close idea 
of the desired clock before you can begin, right? If you had 3 different CDMA 
signals  but different chip rates, they could probably coexist nicely, but how 
would you pick out the faster signal or the slower one? (see picture)

Please advise if my current understanding is erroneous. Thank you in advance.

Sent from Mail for Windows 10

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

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

[Jesse Reich]

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
throttle sample rate to 1M it seems to be closer to real-time. What am I
missing??

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

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

[SangHyuk Kim]

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 wondered "is this normal case or what is it I'm missing".

Recently I could reduce bit error rates of benchmark example (ofdm one).
In my case, the problem was sub-bandwidth. In OFDM, total bandwidth is
divided by # sub-carrier.
I changed related parameters(occupied_tones, fft_size) to small.

Now, I'm researching how transmit rate be maximized and how error rate be
minimized (I think it can be solved by maximizing sample rate)

Thank you for your advice.

2016-03-16 1:30 GMT+09:00 West, Nathan :

> 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 doesn't use
> error correction. There is a function that checks the CRC of packets. If a
> single bit is wrong the packet fails. (As a side note building
> packetized/bursty modems in the way these flowgraphs work is NOT
> recommended).
>
> Given this information, for the same SNR and channel what would you expect
> to happen to bit error rates (and therefor packet error rates) as you
> change modulations from GMSK, BPSK, etc to QAM?
>
> Finally, as I mentioned these flowgraphs are sort of deprecated. Maybe you
> can tell us what you're really going for and someone can suggest a better
> tool.
>
> Cheers,
> Nathan
>
> On Sun, Mar 13, 2016 at 4:22 AM, SangHyuk Kim 
> wrote:
>
>> Hi all.
>>
>> I'm using benchmark_tx(rx).py example
>>
>> I experimented variety modulation schemes and GMSK, BPSK, QPSK modulation
>> worked well
>>
>> However, when I used QAM modulation, most of received packet were
>> corrupted (FALSE)
>>
>> ENV)
>> both TX and RX uses USRP N210 with ANT500 and CBX 40MHz
>> distance between TX and RX is shorter than 3m
>>
>> TX)
>> ./benchmark_tx.py -f 1.5G -m qam -S 8 --tx-gain=30
>>
>> RX)
>> ./benchmark_rx.py -f 1.5G -m qam -S 8
>>
>> RESULTS ON RX)
>> ok = FALSE  pktno = 1  n_rcvd = 1  n_right = 0
>> ok = FALSE  pktno = 2  n_rcvd = 2  n_right = 0
>> ok = FALSE  pktno = 3  n_rcvd = 3  n_right = 0
>> ...
>> ok = TRUE  pktno = N  n_rcvd = N  n_right = 1
>> ...
>>
>> Is this normal case of qam modulation ?
>> How can I get more TRUE packet using QAM modulation ?
>>
>> Thanks.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Stephen Harrison]

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 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 WinnComm'16, you do not need to go to the
>> conference to come out and see us. This is an open event for anyone
>> interested in GNU Radio!
>>
>> Details here:
>> http://gnuradio.org/redmine/news/62
>>
>> Tom
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Stephen Harrison]

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 WinnComm'16, you do not need to go to the
> conference to come out and see us. This is an open event for anyone
> interested in GNU Radio!
>
> Details here:
> http://gnuradio.org/redmine/news/62
>
> Tom
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Timothée COCAULT]

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,
Timothée.

2016-03-15 18:58 GMT+01:00 Yan Huang :

> 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 "/home/mint/Documents/test_sensor/scan/scan.py", line 123, in
> __init__
>
> self.msg_connect((self.blocks_message_strobe_0, 'strobe'),
> (self.freq_sweeper_frequency_sweeper_0, 'in'))
>
>  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> line 60, in wrapped
>
> func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
> dstport)
>
>  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
> line 132, in msg_connect
>
> self.primitive_msg_connect(*args)
>
>  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
> 4472, in primitive_msg_connect
>
> return _runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
>
> RuntimeError: invalid msg port in connect() or disconnect()
>
>
>
>  File "   The GNU Radio version is GNU Radio Companion
> v3.7.6.1-65-g500517ac, do you know where is the problem?
>
>
>
>  Many thanks,
>
> Yan
>
>
>
> *From:* Timothée COCAULT [mailto:timothee.coca...@gmail.com]
> *Sent:* 15 March 2016 16:24
>
> *To:* Yan Huang
> *Cc:* Martin Braun; discuss-gnuradio@gnu.org
> *Subject:* 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,
>
> name='Frequency sweeper',
>
> in_sig=[],
>
> out_sig=[]
>
> )
>
> self.message_port_register_in(pmt.intern('clock'))
>
> self.set_msg_handler(pmt.intern('clock'), self.handler)
>
> self.message_port_register_out(pmt.intern('sync'))
>
> self.freq = initial_freq
>
> self.step = step
>
>
>
> def handler(self, pdu):
>
> self.message_port_pub(pmt.intern('sync'),
> pmt.cons(pmt.intern("freq"), pmt.to_pmt(self.freq)))
>
> self.freq += self.step
>
>
>
> ###
>
>
>
> Cheers,
>
> Timothée.
>
>
>
> 2016-03-15 16:52 GMT+01:00 Yan Huang :
>
> 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
> *Cc:* Martin Braun; discuss-gnuradio@gnu.org
>
>
> *Subject:* 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
> 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 :
>
> thread[thread-per-block[10]: ]:
> pmt_to_double: wrong_type : #[2.4e+09 2.4487e+09]
>
> Thanks,
>
> Yan
>
>
> -Original Message-
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org [mailto:
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of
> Martin Braun
> Sent: 15 March 2016 00:43
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
> Yan,
>
> simply convert "freq" and your frequency to a PMT before passing into
> cons().
>
> Cheers,
> Martin
>
> On 03/14/2016 03:44 PM, Yan Huang wrote:
> > Hi Martin,
> >
> > Thank you for your kind reply. But I'm still comfused that I already
> have to input in pmt::cons("freq",2.4e9), cause in the manual it said:
> >
> > pmt::cons(KEY, VALUE): This format is useful for commands that take a
> single value. Think of KEY and VALUE as the argument name and value,
> respectively. For the case of the QT GUI Frequency Sink, KEY would be
> "freq" and VALUE would be the new center frequency in Hz.
> >
> > Could you please give me an exmaple about it?
> >
> > Thank you a 

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

[Markus Heller]

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
  * http://www.hamradio-friedrichshafen.de

SDRA-2016 invites radio amateurs and researchers from acadaemia and
industry to submit papers for oral and poster presentations on recent
research that addresses theoretical aspects, algorithms, applications,
hardware and software architectures for applied Software Defined Radio
systems and resources and other aspects of SDR, as well as survey and
discussion papers. The invitation particularly addresses open source
research and projects. We also particularly invite specialists giving
introductory talks and tutorials on SDR technologies.


SDRA Topics:
  * Advances in GNURadio related projects and research
  * Algorithms, applications, architectures in SDR systems
  * Real Time signal processing
  * Innovative applications using modern ADC/DAC environments

Submission Information
How to submit: Please send an abstract of approximately 250 words to:

sdra-2...@darc.de

Please include the following information:

  * Paper title
  * Author's name (and callsign). Names and callsigns of all authors
if multiple authors.
  * Author's affiliation
  * Country
  * Email address of the main author

All accepted papers will be published. Publication details will be
available at a later point of time.

We ask authors to keep a limit of 6 pages. If there is a reason why the
paper should be longer, please contact us.

We also solicit Posters and Demo papers: Poster/Demo papers describe a
small focused result, a negative result, or a late-breaking result, or a
description of a system that can be demonstrated on-site at the
conference.

Papers should be formatted using the IEEE A4 templates:
http://www.ieee.org/conferences_events/conferences/publishing/templates.html


Organization
  * Prof. Dr. Michael Hartje, DK5HH
  * Markus Heller, M.A., DL8RDS
  * Klaus Kaiser, DB3TK
  * Ulrich Neumann, DF4QC
Senior Programme Committee
  * Prof. Dr. Michael Hartje, HS Bremen, DK5HH
  * Prof. Dr. Michael Niemetz, OTH Regensburg, DG2RAM
  * Prof. Dr. Michael Mächtel, HTWG Konstanz, DL2SBS
Important Dates:
  * Abstract Submission: 17.04.2016
  * Acceptance Notification: 16.05.2016
  * Presentation Slides: 25.06.2016
  * Paper Presentation: 27.06.2016
  * Paper Submission: 11.07.2016

Contact
For enquiries and paper submission details please do not hesitate to
contact us:

Email: sdra-2...@darc.de Tel.: +49.89.420956305-0

***
br
markus
dl8rds


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

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

[Yan Huang]

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 "/home/mint/Documents/test_sensor/scan/scan.py", line 123, in __init__
self.msg_connect((self.blocks_message_strobe_0, 'strobe'), 
(self.freq_sweeper_frequency_sweeper_0, 'in'))
 File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 
60, in wrapped
func(self, src.to_basic_block(), srcport, dst.to_basic_block(), dstport)
 File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 
132, in msg_connect
self.primitive_msg_connect(*args)
 File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 4472, in primitive_msg_connect
return _runtime_swig.top_block_sptr_primitive_msg_connect(self, *args)
RuntimeError: invalid msg port in connect() or disconnect()

 File "   The GNU Radio version is GNU Radio Companion v3.7.6.1-65-g500517ac, 
do you know where is the problem?

 Many thanks,
Yan

From: Timothée COCAULT [mailto:timothee.coca...@gmail.com]
Sent: 15 March 2016 16:24
To: Yan Huang
Cc: Martin Braun; discuss-gnuradio@gnu.org
Subject: 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,
name='Frequency sweeper',
in_sig=[],
out_sig=[]
)
self.message_port_register_in(pmt.intern('clock'))
self.set_msg_handler(pmt.intern('clock'), self.handler)
self.message_port_register_out(pmt.intern('sync'))
self.freq = initial_freq
self.step = step

def handler(self, pdu):
self.message_port_pub(pmt.intern('sync'), pmt.cons(pmt.intern("freq"), 
pmt.to_pmt(self.freq)))
self.freq += self.step

###

Cheers,
Timothée.

2016-03-15 16:52 GMT+01:00 Yan Huang 
>:
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
Cc: Martin Braun; discuss-gnuradio@gnu.org

Subject: 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 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 :

thread[thread-per-block[10]: ]: pmt_to_double: 
wrong_type : #[2.4e+09 2.4487e+09]

Thanks,

Yan

-Original Message-
From: 
discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
 
[mailto:discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org]
 On Behalf Of Martin Braun
Sent: 15 March 2016 00:43
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Yan,

simply convert "freq" and your frequency to a PMT before passing into cons().

Cheers,
Martin

On 03/14/2016 03:44 PM, Yan Huang wrote:
> Hi Martin,
>
> Thank you for your kind reply. But I'm still comfused that I already have to 
> input in pmt::cons("freq",2.4e9), cause in the manual it said:
>
> pmt::cons(KEY, VALUE): This format is useful for commands that take a single 
> value. Think of KEY and VALUE as the argument name and value, respectively. 
> For the case of the QT GUI Frequency Sink, KEY would be "freq" and VALUE 
> would be the new center frequency in Hz.
>
> Could you please give me an exmaple about it?
>
> Thank you a lot,
>
> Yan
> 
> From: 
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
> [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org]
>  on behalf
> of Martin Braun [martin.br...@ettus.com]
> Sent: 14 March 2016 17:18
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in 

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

[West, Nathan]

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 doesn't use
error correction. There is a function that checks the CRC of packets. If a
single bit is wrong the packet fails. (As a side note building
packetized/bursty modems in the way these flowgraphs work is NOT
recommended).

Given this information, for the same SNR and channel what would you expect
to happen to bit error rates (and therefor packet error rates) as you
change modulations from GMSK, BPSK, etc to QAM?

Finally, as I mentioned these flowgraphs are sort of deprecated. Maybe you
can tell us what you're really going for and someone can suggest a better
tool.

Cheers,
Nathan

On Sun, Mar 13, 2016 at 4:22 AM, SangHyuk Kim  wrote:

> Hi all.
>
> I'm using benchmark_tx(rx).py example
>
> I experimented variety modulation schemes and GMSK, BPSK, QPSK modulation
> worked well
>
> However, when I used QAM modulation, most of received packet were
> corrupted (FALSE)
>
> ENV)
> both TX and RX uses USRP N210 with ANT500 and CBX 40MHz
> distance between TX and RX is shorter than 3m
>
> TX)
> ./benchmark_tx.py -f 1.5G -m qam -S 8 --tx-gain=30
>
> RX)
> ./benchmark_rx.py -f 1.5G -m qam -S 8
>
> RESULTS ON RX)
> ok = FALSE  pktno = 1  n_rcvd = 1  n_right = 0
> ok = FALSE  pktno = 2  n_rcvd = 2  n_right = 0
> ok = FALSE  pktno = 3  n_rcvd = 3  n_right = 0
> ...
> ok = TRUE  pktno = N  n_rcvd = N  n_right = 1
> ...
>
> Is this normal case of qam modulation ?
> How can I get more TRUE packet using QAM modulation ?
>
> Thanks.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Timothée COCAULT]

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,
name='Frequency sweeper',
in_sig=[],
out_sig=[]
)
self.message_port_register_in(pmt.intern('clock'))
self.set_msg_handler(pmt.intern('clock'), self.handler)
self.message_port_register_out(pmt.intern('sync'))
self.freq = initial_freq
self.step = step

def handler(self, pdu):
self.message_port_pub(pmt.intern('sync'),
pmt.cons(pmt.intern("freq"), pmt.to_pmt(self.freq)))
self.freq += self.step

###

Cheers,
Timothée.

2016-03-15 16:52 GMT+01:00 Yan Huang :

> 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
> *Cc:* Martin Braun; discuss-gnuradio@gnu.org
>
> *Subject:* 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
> 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 :
>
> thread[thread-per-block[10]: ]:
> pmt_to_double: wrong_type : #[2.4e+09 2.4487e+09]
>
> Thanks,
>
> Yan
>
>
> -Original Message-
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org [mailto:
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of
> Martin Braun
> Sent: 15 March 2016 00:43
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
> Yan,
>
> simply convert "freq" and your frequency to a PMT before passing into
> cons().
>
> Cheers,
> Martin
>
> On 03/14/2016 03:44 PM, Yan Huang wrote:
> > Hi Martin,
> >
> > Thank you for your kind reply. But I'm still comfused that I already
> have to input in pmt::cons("freq",2.4e9), cause in the manual it said:
> >
> > pmt::cons(KEY, VALUE): This format is useful for commands that take a
> single value. Think of KEY and VALUE as the argument name and value,
> respectively. For the case of the QT GUI Frequency Sink, KEY would be
> "freq" and VALUE would be the new center frequency in Hz.
> >
> > Could you please give me an exmaple about it?
> >
> > Thank you a lot,
> >
> > Yan
> > 
> > From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
> > [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf
> > of Martin Braun [martin.br...@ettus.com]
> > Sent: 14 March 2016 17:18
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> > automatically
> >
> > Yan,
> >
> > check the PMT manuals. cons() takes 2 PMTs as input.
> >
> >
> > Cheers,
> > Martin
> >
> > On 03/14/2016 09:09 AM, Yan Huang wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I want to change the frequency in "USRP source" automatically, for
> >> example 2.37GHz-2.43GHz with each time stepping 2MHz.
> >>
> >>
> >>
> >> 1. As you know, the USRP source has an input message port, so I want
> >> to connect it to a "Message strobe" to control the frequency change.
> >> But  after I see [1][2], I write PMT type commands  in "Message PMT"
> >> in "Message Strobe" as:
> >>
> >> pmt::cons("freq",2.4e9)
> >>
> >> it comes up error "invalid syntax(,line 1)", so I don't know
> >> how to further stepping the frequency.
> >>
> >> 2. If I use the "Message Strobe" to define frequency, what can I put
> >> in the "frequency" in "USRP source" block? Put it as 0?
> >>
> >>
> >>
> >> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
> >>
> >> [2]
> >> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_co
> >> mmands
> >>
> >>
> >>
> >> Many thanks ,
> >>
> >>
> >>
> >> Yan
> >>
> >>
> >>
> >>
> >>
> >> This message and any attachment are intended solely for the addressee
> >> and may contain confidential information. If you have received this
> >> message in error, please send it back to me, and immediately delete it.
> >>
> >> Please do not use, copy or disclose the information contained in this
> >> message or in any attachment.  Any views or opinions expressed by the
> >> author of this email do not 

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

[Meny Sidar]

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 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.
>
> In this case, Walter Kaminsky (who made that device from the video) holds
> a granted patent [1] on this specific device, and as a skimming of the
> abstract of that patent shows, direction finding is done by phase
> comparison. You'll find more details in the patent and if you look up
> direction finding in the literature/the internet.
> Direction finding through phase difference isn't such a complex concept
> mathematically, but non-trivial to implement in hardware (which is why
> Walter was granted a patent on a device that implements a rather well-known
> application); but if you have phase-coherent receivers, also not impossibly
> hard to build such a system with GNU Radio. It all boils down to writing a
> direction estimator. There's a *lot* of approaches and algorithms out
> there, but I'd recommend you start with something intuitive – maybe finding
> the relative phase of a received signal by estimating the phases of
> signals, and based on these phase relationship estimate the angle of the
> wavefront relative to your antenna array.
>
> Best regards,
> Marcus
>
> [1] http://www.google.de/patents/US6239747
>
>
> On 03/15/2016 03:17 PM, Meny Sidar wrote:
>
> 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 thinking that there is some kind of heat signature in the spectrum
> that the cellular produces (please correct me if im wrong)
> how else can you explain this works?
>
> I know my approch is not ideal, and i'm not ruling out opening a bts base
> station,
> but i cant find a way to make phones register to my station automatically..
>
> thanks again for your comments guys,
> really appreciate it.
>
> Meny
>
> 2016-03-15 4:11 GMT+02:00 Nikos Balkanas :
>
>> Indeed, there is phone locator protocol, and a service offered as by some
>> companies. They work through provider contracts. The problem is that you
>> have to know the phone number beforehand and the carrier. Not very useful
>> in a disaster case :(
>>
>> BR,
>> Nikos
>>
>> On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller <
>> marcus.muel...@ettus.com> wrote:
>>
>>> True, at least unless you send them something they have to react to.
>>> Which the phone will only do if you're the infrastructure, and usually
>>> implies you authenticate as such[2]. Which will hence most likely only work
>>> if the cellular providers cooperate with you.
>>>
>>> ​[...snip...]​
>>>
>>>
>>>
>>> On 03/14/2016 03:54 PM, Meny Sidar wrote:
>>>
>>> Hi guys,
>>>
>>> I am currently working on a project for my university, where i'm trying
>>> to locate cellular phones using SDR (USRP B210).
>>> The idea of the project is to be able to find survivors/victims in
>>> disaster areas, such as earthquakes, by assuming they have their cellular
>>> on them.
>>>
>>> What i did so far, is a program that calculates and outputs in a loop
>>> the power transmitted from a cellular phone from it's uplink channel. that
>>> can tell me my distance to it.
>>> problem is, that cellular phones are usually in idle mode and not
>>> transmitting at all.
>>> So it works, but only if the phone is currently transmitting to the
>>> network (phone call, internet, etc..)
>>>
>>> I'm trying to find a solution for this,
>>> There has to be a way of knowing that some kind of RF
>>> transmitter/receiver is near me...
>>> If anyone can shed some light on this subject, what can i do or if i
>>> need to go in another way, i'll be very grateful!
>>> right now i'm stuck.
>>>
>>> Thanks a lot,
>>> Meny
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
___
Discuss-gnuradio mailing list

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

[Marcus Müller]

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.

In this case, Walter Kaminsky (who made that device from the video)
holds a granted patent [1] on this specific device, and as a skimming of
the abstract of that patent shows, direction finding is done by phase
comparison. You'll find more details in the patent and if you look up
direction finding in the literature/the internet.
Direction finding through phase difference isn't such a complex concept
mathematically, but non-trivial to implement in hardware (which is why
Walter was granted a patent on a device that implements a rather
well-known application); but if you have phase-coherent receivers, also
not impossibly hard to build such a system with GNU Radio. It all boils
down to writing a direction estimator. There's a *lot* of approaches and
algorithms out there, but I'd recommend you start with something
intuitive – maybe finding the relative phase of a received signal by
estimating the phases of signals, and based on these phase relationship
estimate the angle of the wavefront relative to your antenna array.

Best regards,
Marcus

[1] http://www.google.de/patents/US6239747

On 03/15/2016 03:17 PM, Meny Sidar wrote:
> 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 thinking that there is some kind of heat signature in the
> spectrum that the cellular produces (please correct me if im wrong)
> how else can you explain this works?
>
> I know my approch is not ideal, and i'm not ruling out opening a bts
> base station,
> but i cant find a way to make phones register to my station
> automatically..
>
> thanks again for your comments guys,
> really appreciate it.
>
> Meny
>
> 2016-03-15 4:11 GMT+02:00 Nikos Balkanas  >:
>
> Indeed, there is phone locator protocol, and a service offered as
> by some companies. They work through provider contracts. The
> problem is that you have to know the phone number beforehand and
> the carrier. Not very useful in a disaster case :(
>
> BR,
> Nikos
>
> On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller
> > wrote:
>
> True, at least unless you send them something they have to
> react to. Which the phone will only do if you're the
> infrastructure, and usually implies you authenticate as
> such[2]. Which will hence most likely only work if the
> cellular providers cooperate with you.
>
>> ​[...snip...]​
>>
>>
>>
>> On 03/14/2016 03:54 PM, Meny Sidar wrote:
>> Hi guys,
>>
>> I am currently working on a project for my university, where
>> i'm trying to locate cellular phones using SDR (USRP B210).
>> The idea of the project is to be able to find
>> survivors/victims in disaster areas, such as earthquakes, by
>> assuming they have their cellular on them.
>>
>> What i did so far, is a program that calculates and outputs
>> in a loop the power transmitted from a cellular phone from
>> it's uplink channel. that can tell me my distance to it.
>> problem is, that cellular phones are usually in idle mode and
>> not transmitting at all. 
>> So it works, but only if the phone is currently transmitting
>> to the network (phone call, internet, etc..)
>>
>> I'm trying to find a solution for this,
>> There has to be a way of knowing that some kind of RF
>> transmitter/receiver is near me...
>> If anyone can shed some light on this subject, what can i do
>> or if i need to go in another way, i'll be very grateful! 
>> right now i'm stuck.
>>
>> Thanks a lot,
>> Meny
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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

[Yan Huang]

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
Cc: Martin Braun; discuss-gnuradio@gnu.org
Subject: 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 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 :

thread[thread-per-block[10]: ]: pmt_to_double: 
wrong_type : #[2.4e+09 2.4487e+09]

Thanks,

Yan

-Original Message-
From: 
discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
 
[mailto:discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org]
 On Behalf Of Martin Braun
Sent: 15 March 2016 00:43
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Yan,

simply convert "freq" and your frequency to a PMT before passing into cons().

Cheers,
Martin

On 03/14/2016 03:44 PM, Yan Huang wrote:
> Hi Martin,
>
> Thank you for your kind reply. But I'm still comfused that I already have to 
> input in pmt::cons("freq",2.4e9), cause in the manual it said:
>
> pmt::cons(KEY, VALUE): This format is useful for commands that take a single 
> value. Think of KEY and VALUE as the argument name and value, respectively. 
> For the case of the QT GUI Frequency Sink, KEY would be "freq" and VALUE 
> would be the new center frequency in Hz.
>
> Could you please give me an exmaple about it?
>
> Thank you a lot,
>
> Yan
> 
> From: 
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
> [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org]
>  on behalf
> of Martin Braun [martin.br...@ettus.com]
> Sent: 14 March 2016 17:18
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
> Yan,
>
> check the PMT manuals. cons() takes 2 PMTs as input.
>
>
> Cheers,
> Martin
>
> On 03/14/2016 09:09 AM, Yan Huang wrote:
>> Hi all,
>>
>>
>>
>> I want to change the frequency in "USRP source" automatically, for
>> example 2.37GHz-2.43GHz with each time stepping 2MHz.
>>
>>
>>
>> 1. As you know, the USRP source has an input message port, so I want
>> to connect it to a "Message strobe" to control the frequency change.
>> But  after I see [1][2], I write PMT type commands  in "Message PMT"
>> in "Message Strobe" as:
>>
>> pmt::cons("freq",2.4e9)
>>
>> it comes up error "invalid syntax(,line 1)", so I don't know
>> how to further stepping the frequency.
>>
>> 2. If I use the "Message Strobe" to define frequency, what can I put
>> in the "frequency" in "USRP source" block? Put it as 0?
>>
>>
>>
>> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
>>
>> [2]
>> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_co
>> mmands
>>
>>
>>
>> Many thanks ,
>>
>>
>>
>> Yan
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>>
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> This message and any attachment are intended solely for 

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

[Marcus Müller]

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
topics from the wiki, write an excellent proposal and also be visible in
the community, e.g. by having pull requests (documentation can *always*
be improved), or an out-of-tree module that does something unique. Show
that you're both able to build something great within the GNU Radio
ecosystem and are willing to participate in the community process!

Best regards,
Marcus

On 03/15/2016 03:02 PM, Parth Sane wrote:
> 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 what tasks can be done as a part of GSoC
> 2016. I’m good at Java,C++,have used a fair bit of git and I do have
> ham radio licenses across USA and India. I’m a newbie at python, but I
> can manage it. So please do reply so as to help with project proposal
> ideas!
> Regards,
> Parth Sane
> VU3TTL/KD2KER
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

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

[Timothée COCAULT]

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
> 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 :
>
> thread[thread-per-block[10]: ]:
> pmt_to_double: wrong_type : #[2.4e+09 2.4487e+09]
>
> Thanks,
>
> Yan
>
> -Original Message-
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org [mailto:
> discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of
> Martin Braun
> Sent: 15 March 2016 00:43
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> automatically
>
> Yan,
>
> simply convert "freq" and your frequency to a PMT before passing into
> cons().
>
> Cheers,
> Martin
>
> On 03/14/2016 03:44 PM, Yan Huang wrote:
> > Hi Martin,
> >
> > Thank you for your kind reply. But I'm still comfused that I already
> have to input in pmt::cons("freq",2.4e9), cause in the manual it said:
> >
> > pmt::cons(KEY, VALUE): This format is useful for commands that take a
> single value. Think of KEY and VALUE as the argument name and value,
> respectively. For the case of the QT GUI Frequency Sink, KEY would be
> "freq" and VALUE would be the new center frequency in Hz.
> >
> > Could you please give me an exmaple about it?
> >
> > Thank you a lot,
> >
> > Yan
> > 
> > From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org
> > [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf
> > of Martin Braun [martin.br...@ettus.com]
> > Sent: 14 March 2016 17:18
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Change frequency in USRP source
> > automatically
> >
> > Yan,
> >
> > check the PMT manuals. cons() takes 2 PMTs as input.
> >
> >
> > Cheers,
> > Martin
> >
> > On 03/14/2016 09:09 AM, Yan Huang wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I want to change the frequency in "USRP source" automatically, for
> >> example 2.37GHz-2.43GHz with each time stepping 2MHz.
> >>
> >>
> >>
> >> 1. As you know, the USRP source has an input message port, so I want
> >> to connect it to a "Message strobe" to control the frequency change.
> >> But  after I see [1][2], I write PMT type commands  in "Message PMT"
> >> in "Message Strobe" as:
> >>
> >> pmt::cons("freq",2.4e9)
> >>
> >> it comes up error "invalid syntax(,line 1)", so I don't know
> >> how to further stepping the frequency.
> >>
> >> 2. If I use the "Message Strobe" to define frequency, what can I put
> >> in the "frequency" in "USRP source" block? Put it as 0?
> >>
> >>
> >>
> >> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
> >>
> >> [2]
> >> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_co
> >> mmands
> >>
> >>
> >>
> >> Many thanks ,
> >>
> >>
> >>
> >> Yan
> >>
> >>
> >>
> >>
> >>
> >> This message and any attachment are intended solely for the addressee
> >> and may contain confidential information. If you have received this
> >> message in error, please send it back to me, and immediately delete it.
> >>
> >> Please do not use, copy or disclose the information contained in this
> >> message or in any attachment.  Any views or opinions expressed by the
> >> author of this email do not necessarily reflect the views of the
> >> University of Nottingham.
> >>
> >> This message has been checked for viruses but the contents of an
> >> attachment may still contain software viruses which could damage your
> >> computer system, you are advised to perform your own checks. Email
> >> communications with the University of Nottingham may be monitored as
> >> permitted by UK legislation.
> >>
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> >
> > This message and any attachment are intended solely for the addressee
> > and may contain confidential information. If you have received this
> > message in error, please send it back to me, and immediately delete it.
> >
> > Please do not use, copy or disclose the information contained in this
> > message or in any attachment.  Any views or opinions expressed by the
> > author of this email do not necessarily reflect the views of the
> > University of Nottingham.
> >
> > This message has been checked for viruses but the contents of an
> > attachment may still contain software viruses 

[Discuss-gnuradio] CQ de VU3TTL/KD2KER

[Parth Sane]

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 what tasks can be done as a part of GSoC 2016. I’m 
good at Java,C++,have used a fair bit of git and I do have ham radio licenses 
across USA and India. I’m a newbie at python, but I can manage it. So please do 
reply so as to help with project proposal ideas!
Regards,
Parth Sane
VU3TTL/KD2KER


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Meny Sidar]

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 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 you can find out the TA values and try locating then.
>
>
>
> In fact exactly this is done when people get lost out in the woods, or in
> the mountains - putting a GSM cell on board a helicopter...
>
>
> Ralph.
>
>
>
> *From:* discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:
> discuss-gnuradio-bounces+ralph=schmid@gnu.org] *On Behalf Of *Meny
> Sidar
> *Sent:* Tuesday, March 15, 2016 3:18 PM
> *To:* Nikos Balkanas
> *Cc:* discuss-gnuradio@gnu.org; Marcus Müller
> *Subject:* 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 thinking that there is some kind of heat signature in the spectrum
> that the cellular produces (please correct me if im wrong)
>
> how else can you explain this works?
>
>
>
> I know my approch is not ideal, and i'm not ruling out opening a bts base
> station,
>
> but i cant find a way to make phones register to my station automatically..
>
>
>
> thanks again for your comments guys,
>
> really appreciate it.
>
>
>
> Meny
>
>
>
> 2016-03-15 4:11 GMT+02:00 Nikos Balkanas :
>
> Indeed, there is phone locator protocol, and a service offered as by some
> companies. They work through provider contracts. The problem is that you
> have to know the phone number beforehand and the carrier. Not very useful
> in a disaster case :(
>
>
>
> BR,
>
> Nikos
>
>
>
> On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller 
> wrote:
>
> True, at least unless you send them something they have to react to.
> Which the phone will only do if you're the infrastructure, and usually
> implies you authenticate as such[2]. Which will hence most likely only work
> if the cellular providers cooperate with you.
>
>
> ​[...snip...]​
>
>
>
> On 03/14/2016 03:54 PM, Meny Sidar wrote:
>
> Hi guys,
>
>
>
> I am currently working on a project for my university, where i'm trying to
> locate cellular phones using SDR (USRP B210).
>
> The idea of the project is to be able to find survivors/victims in
> disaster areas, such as earthquakes, by assuming they have their cellular
> on them.
>
>
>
> What i did so far, is a program that calculates and outputs in a loop the
> power transmitted from a cellular phone from it's uplink channel. that can
> tell me my distance to it.
>
> problem is, that cellular phones are usually in idle mode and not
> transmitting at all.
>
> So it works, but only if the phone is currently transmitting to the
> network (phone call, internet, etc..)
>
>
>
> I'm trying to find a solution for this,
>
> There has to be a way of knowing that some kind of RF transmitter/receiver
> is near me...
>
> If anyone can shed some light on this subject, what can i do or if i need
> to go in another way, i'll be very grateful!
>
> right now i'm stuck.
>
>
>
> Thanks a lot,
>
> Meny
>
>
>
> ___
>
> Discuss-gnuradio mailing list
>
> Discuss-gnuradio@gnu.org
>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Ralph A. Schmid, dk5ras]

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 you can find out 
the TA values and try locating then. 

 

In fact exactly this is done when people get lost out in the woods, or in the 
mountains - putting a GSM cell on board a helicopter...


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Meny 
Sidar
Sent: Tuesday, March 15, 2016 3:18 PM
To: Nikos Balkanas
Cc: discuss-gnuradio@gnu.org; Marcus Müller
Subject: 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 thinking that there is some kind of heat signature in the spectrum that 
the cellular produces (please correct me if im wrong)

how else can you explain this works?

 

I know my approch is not ideal, and i'm not ruling out opening a bts base 
station,

but i cant find a way to make phones register to my station automatically..

 

thanks again for your comments guys,

really appreciate it.

 

Meny

 

2016-03-15 4:11 GMT+02:00 Nikos Balkanas  >:

Indeed, there is phone locator protocol, and a service offered as by some 
companies. They work through provider contracts. The problem is that you have 
to know the phone number beforehand and the carrier. Not very useful in a 
disaster case :(

 

BR,

Nikos

 

On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller  > wrote:

True, at least unless you send them something they have to react to. Which 
the phone will only do if you're the infrastructure, and usually implies you 
authenticate as such[2]. Which will hence most likely only work if the cellular 
providers cooperate with you.




​[...snip...]​





On 03/14/2016 03:54 PM, Meny Sidar wrote:

Hi guys,

 

I am currently working on a project for my university, where i'm trying to 
locate cellular phones using SDR (USRP B210).

The idea of the project is to be able to find survivors/victims in disaster 
areas, such as earthquakes, by assuming they have their cellular on them.

 

What i did so far, is a program that calculates and outputs in a loop the power 
transmitted from a cellular phone from it's uplink channel. that can tell me my 
distance to it.

problem is, that cellular phones are usually in idle mode and not transmitting 
at all. 

So it works, but only if the phone is currently transmitting to the network 
(phone call, internet, etc..)

 

I'm trying to find a solution for this,

There has to be a way of knowing that some kind of RF transmitter/receiver is 
near me...

If anyone can shed some light on this subject, what can i do or if i need to go 
in another way, i'll be very grateful! 

right now i'm stuck.

 

Thanks a lot,

Meny

 

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

 


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

 


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

 

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

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

[Meny Sidar]

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 thinking that there is some kind of heat signature in the spectrum
that the cellular produces (please correct me if im wrong)
how else can you explain this works?

I know my approch is not ideal, and i'm not ruling out opening a bts base
station,
but i cant find a way to make phones register to my station automatically..

thanks again for your comments guys,
really appreciate it.

Meny

2016-03-15 4:11 GMT+02:00 Nikos Balkanas :

> Indeed, there is phone locator protocol, and a service offered as by some
> companies. They work through provider contracts. The problem is that you
> have to know the phone number beforehand and the carrier. Not very useful
> in a disaster case :(
>
> BR,
> Nikos
>
> On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller 
> wrote:
>
>> True, at least unless you send them something they have to react to.
>> Which the phone will only do if you're the infrastructure, and usually
>> implies you authenticate as such[2]. Which will hence most likely only work
>> if the cellular providers cooperate with you.
>>
>> ​[...snip...]​
>>
>>
>>
>> On 03/14/2016 03:54 PM, Meny Sidar wrote:
>>
>> Hi guys,
>>
>> I am currently working on a project for my university, where i'm trying
>> to locate cellular phones using SDR (USRP B210).
>> The idea of the project is to be able to find survivors/victims in
>> disaster areas, such as earthquakes, by assuming they have their cellular
>> on them.
>>
>> What i did so far, is a program that calculates and outputs in a loop the
>> power transmitted from a cellular phone from it's uplink channel. that can
>> tell me my distance to it.
>> problem is, that cellular phones are usually in idle mode and not
>> transmitting at all.
>> So it works, but only if the phone is currently transmitting to the
>> network (phone call, internet, etc..)
>>
>> I'm trying to find a solution for this,
>> There has to be a way of knowing that some kind of RF
>> transmitter/receiver is near me...
>> If anyone can shed some light on this subject, what can i do or if i need
>> to go in another way, i'll be very grateful!
>> right now i'm stuck.
>>
>> Thanks a lot,
>> Meny
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Yan Huang]

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 :

thread[thread-per-block[10]: ]: pmt_to_double: 
wrong_type : #[2.4e+09 2.4487e+09]

Thanks,

Yan

-Original Message-
From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org 
[mailto:discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of 
Martin Braun
Sent: 15 March 2016 00:43
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Yan,

simply convert "freq" and your frequency to a PMT before passing into cons().

Cheers,
Martin

On 03/14/2016 03:44 PM, Yan Huang wrote:
> Hi Martin,
> 
> Thank you for your kind reply. But I'm still comfused that I already have to 
> input in pmt::cons("freq",2.4e9), cause in the manual it said:
> 
> pmt::cons(KEY, VALUE): This format is useful for commands that take a single 
> value. Think of KEY and VALUE as the argument name and value, respectively. 
> For the case of the QT GUI Frequency Sink, KEY would be "freq" and VALUE 
> would be the new center frequency in Hz. 
> 
> Could you please give me an exmaple about it?
> 
> Thank you a lot,
> 
> Yan
> 
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org 
> [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf 
> of Martin Braun [martin.br...@ettus.com]
> Sent: 14 March 2016 17:18
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source 
> automatically
> 
> Yan,
> 
> check the PMT manuals. cons() takes 2 PMTs as input.
> 
> 
> Cheers,
> Martin
> 
> On 03/14/2016 09:09 AM, Yan Huang wrote:
>> Hi all,
>>
>>
>>
>> I want to change the frequency in "USRP source" automatically, for 
>> example 2.37GHz-2.43GHz with each time stepping 2MHz.
>>
>>
>>
>> 1. As you know, the USRP source has an input message port, so I want 
>> to connect it to a "Message strobe" to control the frequency change. 
>> But  after I see [1][2], I write PMT type commands  in "Message PMT" 
>> in "Message Strobe" as:
>>
>> pmt::cons("freq",2.4e9)
>>
>> it comes up error "invalid syntax(,line 1)", so I don't know 
>> how to further stepping the frequency.
>>
>> 2. If I use the "Message Strobe" to define frequency, what can I put 
>> in the "frequency" in "USRP source" block? Put it as 0?
>>
>>
>>
>> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
>>
>> [2]
>> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_co
>> mmands
>>
>>
>>
>> Many thanks ,
>>
>>
>>
>> Yan
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee 
>> and may contain confidential information. If you have received this 
>> message in error, please send it back to me, and immediately delete it.
>>
>> Please do not use, copy or disclose the information contained in this 
>> message or in any attachment.  Any views or opinions expressed by the 
>> author of this email do not necessarily reflect the views of the 
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an 
>> attachment may still contain software viruses which could damage your 
>> computer system, you are advised to perform your own checks. Email 
>> communications with the University of Nottingham may be monitored as 
>> permitted by UK legislation.
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> This message and any attachment are intended solely for the addressee 
> and may contain confidential information. If you have received this 
> message in error, please send it back to me, and immediately delete it.
> 
> Please do not use, copy or disclose the information contained in this 
> message or in any attachment.  Any views or opinions expressed by the 
> author of this email do not necessarily reflect the views of the 
> University of Nottingham.
> 
> This message has been checked for viruses but the contents of an 
> attachment may still contain software viruses which could damage your 
> computer system, you are advised to perform your own checks. Email 
> communications with the University of Nottingham may be monitored as 
> permitted by UK legislation.
> 


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




This message and any attachment are intended solely for the addressee
and may contain 

Re: [Discuss-gnuradio] Multiplexing and Demultiplexing

[Marcus Müller]

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 switching your hardware from RX to TX mode, but sure,
it's possible, and has been done.

However, the logic that manages where/when to TX and RX is higher level
and will need to be defined by you, who knows the application you want
to build.

Best regards,
Marcus

On 15.03.2016 12:08, Diyar Muhammed wrote:
> 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 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.
> For many kinds of multiplexing, there's even already blocks that
> do the core of the job.
>
> Best regards,
> Marcus
>
>
> On 14.03.2016 20:14, Diyar Muhammed wrote:
>> Dear All,
>> Is there any way to do multiplexing and demultiplexing in GNU
>> radio software?
>> -- 
>> Regards,
>> Diyar Muhammed
>> Ministry of Higher Education and Scientific Research
>> Duty: Network Administration and Design
>> Website:  www.mhe-krg.or g
>> Cell Phone: 009647504690060
>> Office Phone:   00964662554683
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> -- 
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org 
> Cell Phone: 009647504690060
> Office Phone:   00964662554683

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

Re: [Discuss-gnuradio] Multiplexing and Demultiplexing

[Diyar Muhammed]

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 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.
> For many kinds of multiplexing, there's even already blocks that do the
> core of the job.
>
> Best regards,
> Marcus
>
>
> On 14.03.2016 20:14, Diyar Muhammed wrote:
>
> Dear All,
> Is there any way to do multiplexing and demultiplexing in GNU radio
> software?
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:   www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Jan Krämer]

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 exact amount of samples, let's say N, via the produced() call.
The scheduler will then advance the write pointer for that output buffer by
N-(history-1) entries. GNURadios scheduler is essentially a stream based
scheduler. While tagged streams provided a good approach to packet based
communication schemes, I think even then you could not guaranty that for a
packet at address 0 with the length N, the next packet will be placed in
the output buffer at address 0+N and so on.

One other way you could archieve your task (if I understood it correctly),
to strip away the preamble before the FFT when you detect a packet and then
preload the fft->input() with that preamble. Inside the FFT block you would
have to detect the beginning of the packet again and then copy that packet
to the fft input buffer beginning at fft->input()[length_of_preamble].
All this would require you to write custom blocks and in the end I am not
sure if copying the preamble would be really the tightest bottleneck you
could find in your flowgraph.

hope that clarified some things.
Cheers,
Jan

2016-03-15 1:08 GMT+01:00 Gonzalo Arcos :

> Anyone? Is there a way to keep the buffer array for subsequent executions
> of work() ?
>
> Also, ive searched everywhere for the meaning of the return value of the
> work function. The documentation explains the function and its parameters,
> but not what the return value is for.
>
> 2016-03-13 16:11 GMT-03:00 Gonzalo Arcos :
>
>> So basically i tried assigning the sync words only in the first call to
>> work() and the result was that only the first packet was transmitted
>> successfully, so either gnuradio scheduler is erasing all the output buffer
>> before the call to the work function, or the output buffer is a new
>> allocation and has nothing to do with the output buffer of the previous
>> call to work.
>>
>> In any case, is there a way i can make that gnuradio just allocs that
>> buffer once and does not change the values of it, so i can be sure that in
>> successive calls to work the buffer retains the values written by previous
>> calls to work, if none of the consumer blocks changes their input buffer?
>>
>> Thanks in advantage.
>>
>> 2016-03-13 14:44 GMT-03:00 Gonzalo Arcos :
>>
>>> Do output buffers of a block are always allocated in the same address
>>> throughout the same execution of the flowgraph? I need to know this because
>>> it would allow me to do some optimization.
>>>
>>>
>>> For example:
>>>
>>> Suppose i have the OFDM Carrier Allocator Block connected to the IFFT
>>> block.
>>>
>>> On every execution of work() the carrier allocator copies the synch
>>> words to the beggining of the output buffer. However, i know that my synch
>>> words will always remain the same throughout the entire execution of the
>>> flowgraph. Additionally, the fft should not change anything in its input
>>> buffer, which is ofdm carrier allocator's output buffer.
>>>
>>> So basically, i only need to copy that information once, on the first
>>> run, since then that data will remain in the buffer.
>>>
>>> This happens ONLY if the ofdm carrier allocator output buffer is not
>>> freed/alloc'ed by the gnuradio scheduler more than once per execution of
>>> the flowgraph.
>>>
>>> Can somebody confirm this?
>>>
>>> Thanks
>>>
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multiplexing and Demultiplexing

[Marcus Müller]

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.
For many kinds of multiplexing, there's even already blocks that do the
core of the job.

Best regards,
Marcus

On 14.03.2016 20:14, Diyar Muhammed wrote:
> Dear All,
> Is there any way to do multiplexing and demultiplexing in GNU radio
> software?
> -- 
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.or g
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

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

[SangHyuk Kim]

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 bandwidth parameter rather instead of bits rate, samples
per symbol, bits per symbol
It is because of purpose of use


2016-03-15 11:14 GMT+09:00 Nikos Balkanas :

> Hi,
>
> Nope, as i told you, my x300 has only rx tuners :(
>
> BR
> Nikos
>
> On Tue, Mar 15, 2016 at 4:13 AM, SangHyuk Kim 
> wrote:
>
>> Hi,
>>
>> Sorry I'm late for reply
>>
>> Did you use two device (Tx,Rx) at a time ?
>>
>> I expect like these messages on Rx machine
>>
>> ok = FALSE  pktno = 1  n_rcvd = 1  n_right = 0
>> ok = FALSE  pktno = 2  n_rcvd = 2  n_right = 0
>> ok = FALSE  pktno = 3  n_rcvd = 3  n_right = 0
>> ...
>> ok = TRUE  pktno = N  n_rcvd = N  n_right = 1
>> ...
>>
>> I think you tested only RX test, right ?
>>
>> Thanks Nikos
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Joshua Lilly]

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