Re: [Discuss-gnuradio] Correlation Estimator Block

[Cinaed Simson]

Suppose someone asked you to implement your flow graph on a transmitter
and receiver separated by an air gap.

Where would you tap into the signal with the Correlation Estimator?

I would tap into the signal at the end of the receiver - at the virtual
source with the decoded signal - or the very end of the flow chart.

And you've already demonstrated the output of the flow graph is the same
as input, i.e., you can reliably transit and receive a BPSK signal.

Instead of trying to cram all these block into 1 flow graph, there's an
easier way.

Replace the entire flow graph with a Channel Model. Use a complex vector
equal to the sum of the data and preamble.  Feed the complex vector into
a complex Stream to Tagged Stream block and then feed the tagged stream
into the Channel Model. Place the Correlation Estimator on the other
side of the Channel Model and you have something that begins to look like

 /share/gnuradio/examples/digital/pack
/example_corr_est.grc

Use your Constellation Object to configure the Modulate Vector for BPSK.

And after you've work out all the details of the Correlation Estimator,
you can graph it back onto the original flow graph.

-- Cinaed


On 05/24/2017 10:32 AM, Mojtaba Mansour Abadi wrote:
> Hi Everyone,
> 
> 
> I am trying to benefit "Correlation Estimator" block to tag the preamble
> of the transmit bit sequence in a QPSK-based system
> 
> 
> The modulation is done as:
> Data + Preamble -> Constellation Modulator
> 
> 
> The way I am doing the demodulation is:
> AGC -> FLL Band-Edge -> Correlation Estimator -> Correlation Estimator
> -> Polyphase Clock Sync -> CMA Equaliser -> Costas Loop
> 
> The hard decoding is done as:
> Constellation Decoder -> Differential Decoder -> Map -> Unpacked to Packed
> 
> After I execute the flowgraph, for a few seconds everything works fine
> and I receive the correct sequences. However, after a while, the
> received bits are not correct and their pattern changes periodically.
> 
> When I bypass the "Correlation Estimator" block, everything works fine
> and I receive the correct data.
> 
> I am confused. Is the correlation block suppose to deteriorate the
> demodulation performance?
> 
> The flowgraph is attached to the email.
> 
> 
> -- 
> Regards,
> Mansour.
> 
> https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451
> 
> 
> ___
> 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] Correlation Estimator Block

[Mojtaba Mansour Abadi]

Hi Cinaed,

Thanks a lot for the complete reply. I appreciate it.

I will implement your suggestions and see what the output will be and let
you know.

Cheers.

On 25 May 2017 at 09:56, Cinaed Simson  wrote:

> Suppose someone asked you to implement your flow graph on a transmitter
> and receiver separated by an air gap.
>
> Where would you tap into the signal with the Correlation Estimator?
>
> I would tap into the signal at the end of the receiver - at the virtual
> source with the decoded signal - or the very end of the flow chart.
>
> And you've already demonstrated the output of the flow graph is the same
> as input, i.e., you can reliably transit and receive a BPSK signal.
>
> Instead of trying to cram all these block into 1 flow graph, there's an
> easier way.
>
> Replace the entire flow graph with a Channel Model. Use a complex vector
> equal to the sum of the data and preamble.  Feed the complex vector into
> a complex Stream to Tagged Stream block and then feed the tagged stream
> into the Channel Model. Place the Correlation Estimator on the other
> side of the Channel Model and you have something that begins to look like
>
>  /share/gnuradio/examples/digital/pack
> /example_corr_est.grc
>
> Use your Constellation Object to configure the Modulate Vector for BPSK.
>
> And after you've work out all the details of the Correlation Estimator,
> you can graph it back onto the original flow graph.
>
> -- Cinaed
>
>
> On 05/24/2017 10:32 AM, Mojtaba Mansour Abadi wrote:
> > Hi Everyone,
> >
> >
> > I am trying to benefit "Correlation Estimator" block to tag the preamble
> > of the transmit bit sequence in a QPSK-based system
> >
> >
> > The modulation is done as:
> > Data + Preamble -> Constellation Modulator
> >
> >
> > The way I am doing the demodulation is:
> > AGC -> FLL Band-Edge -> Correlation Estimator -> Correlation Estimator
> > -> Polyphase Clock Sync -> CMA Equaliser -> Costas Loop
> >
> > The hard decoding is done as:
> > Constellation Decoder -> Differential Decoder -> Map -> Unpacked to
> Packed
> >
> > After I execute the flowgraph, for a few seconds everything works fine
> > and I receive the correct sequences. However, after a while, the
> > received bits are not correct and their pattern changes periodically.
> >
> > When I bypass the "Correlation Estimator" block, everything works fine
> > and I receive the correct data.
> >
> > I am confused. Is the correlation block suppose to deteriorate the
> > demodulation performance?
> >
> > The flowgraph is attached to the email.
> >
> >
> > --
> > Regards,
> > Mansour.
> >
> > https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451
> >
> >
> > ___
> > 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,
Mansour.

https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] choosing hardware for demos, ham purposes

[Daniel Pocock]

On 19/05/17 01:49, q...@kd4e.com wrote:
> Has anyone actually used a LimeSDR for Ham RX/Tx yet?
> 
> I held-off buying one early due to the absence of even a bread-boarded
> proof-of-concept Ham RxTx, or even a VFO or single conversion Rx.
> 


This has also been discussed on the debian-hams list[1] with slightly
more detail but no definite solution.

If I used one I would be using it with a band pass filter for both RX
and TX.

Some other alternatives came up in that thread, has anybody tested any
of these?  It appears that some of them are self-contained, not using
something like GNU Radio on the PC, but if they can send the raw SDR
feed into GNU Radio (for RX at least) that would be interesting.


SunSDR QRP[2]
KX2[3]
KX3[4]
Mountain Topper[5]
WSPRlite[6] from Sotabeams


Regards,

Daniel


1. https://lists.debian.org/debian-hams/2017/05/msg7.html
2. https://eesdr.com/en/products-en/transceivers-en/sunsdr2qrp-en
3. http://www.elecraft.com/KX2/kx2.htm
4. http://www.elecraft.com/KX3/kx3.htm
5. http://www.lnrprecision.com/store/#!/MTR3B-Mountain-Topper/p/45010523
6. http://www.sotabeams.co.uk/wsprlite

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

[Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Qurat-Ul-Ann Akbar]

Hi,

I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to
work with higher sampling rate like 20 MHZ used in WiFi and that's why I
bought a new workstation with better processor. However, the module still
isn't working. The receiver isn't receiving anything at 20 MHZ if it's QAM
64 or BPSK . It works perfectly fine with 1 MHZ and receives all data from
the transmitter USRP. But at 20 MHZ it receives a few WiFi packets from
surrounding far off APs in the building but isn't receiving anything from
the USRP transmitter in the room. It doesn't work for 10 MHZ as well.

Can anyone tell me what could be the reason for that? I have tried changing
LO offset etc.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python block help

[Zach Morris]

Hello Marcus,

I realize this is a couple years later but I am attempting to do the same
type of arbitrary ratio block, where samples above a threshold are passed
and samples below that threshold are dropped. 

When I tried to subclass gr.block (as below, and in  this tutorial from 2014

 
) in an embedded Python block, GRC threw an error saying gr.block could not
be found. Does this method still work, or is there an updated method with
basic_block to implement arbitrary ratio blocks in Python?

Greetings from Menlo Park, CA,

Zach



Marcus Müller-3 wrote
> Hi Bob,
> 
> I think you've introduced the "j" variable to keep count of how many
> items you're going to produce, but then just tell the scheduler you've
> produced as many items as he offered you to do. Replace
> self.produce(0,len(out0))
> by
> self.produce(0,j).
> Also, you consume ninput_items every for loop iteration, so
> ninput_items^2 per work run. That's not right; do it only once, after
> the loop.
> 
> Greetings,
> 
> Marcus
> 
> On 12/24/2014 12:21 PM, bob wole wrote:
>> Hi list,
>>
>> I am writing a custom python block that should take complex input,
>> check magnitude of incoming samples and if the magnitude is greater
>> than a threshold value, the block should pass that sample otherwise
>> the block just drop the samples. As this is an arbitrary ratio block I
>> derived it from gr.block and set_auto_consume(False).
>>
>> However I get intermittent zeros in output stream of my custom block.
>> Below is the code
>>
>> from gnuradio import gr
>> import gnuradio.extras
>> import math
>> import numpy as np
>>
>>
>> class sdr_pass_valid(gr.block):
>> """
>> """
>> def __init__(self,threshold):
>> gr.block.__init__(
>> self,
>> name = "VALID",
>> in_sig = [np.complex64],
>> out_sig = [np.complex64],
>> )
>> self.set_auto_consume(False)
>>
>> self.threshold =  threshold
>> def forecast (self,noutput_items,ninput_items_required):
>> for i in range(len(ninput_items_required)):
>> ninput_items_required[i] = noutput_items
>>
>> def work(self, input_items, output_items):
>>
>> in0 = input_items[0][:len(output_items[0])]
>> out0= output_items[0]
>> nread = self.nitems_read(0) #number of items read on port 0
>> ninput_items = len(in0)
>> j=0
>> for i in range(0,ninput_items):
>> if np.absolute(in0[i]) >= self.threshold :
>> out0[j] = in0[i]
>> j = j + 1
>> self.consume(0,ninput_items)
>> self.produce(0,len(out0))
>> return 0
>>
>>
>> --
>> Bob
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> 

> Discuss-gnuradio@

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

> Discuss-gnuradio@

> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Python-block-help-tp51706p64046.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Diez Victor]

The problem could be the transmission of data via ethernet port.
Are you working under virtualized OS conditions? These could be the origin of 
your problem, virtualized ethernet ports don’t reach enough high data rates.
Another possibility could be that your ethernet adapter isn’t a gigabyte 
ethernet adapter.
Finally, if you work with Matlab/Simulink, you can have the same problem. In 
this case I recommend you to change to GNU-Radio and its flowchart interface, 
GRC.



De: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+vdiez=ikerlan...@gnu.org] 
En nombre de Qurat-Ul-Ann Akbar
Enviado el: jueves, 25 de mayo de 2017 17:44
Para: GNURadio Discussion List
Asunto: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling 
rates

Hi,

I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to work 
with higher sampling rate like 20 MHZ used in WiFi and that's why I bought a 
new workstation with better processor. However, the module still isn't working. 
The receiver isn't receiving anything at 20 MHZ if it's QAM 64 or BPSK . It 
works perfectly fine with 1 MHZ and receives all data from the transmitter 
USRP. But at 20 MHZ it receives a few WiFi packets from surrounding far off APs 
in the building but isn't receiving anything from the USRP transmitter in the 
room. It doesn't work for 10 MHZ as well.

Can anyone tell me what could be the reason for that? I have tried changing LO 
offset etc.


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

Re: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Qurat-Ul-Ann Akbar]

Hi Victor,

I am using GNU Radio flow graph and it's actually IEEE 802.11 modules
wifi-tx for sending data. Also I am not using virtualized environment and
my ethernet port is 1Gbps.

On May 25, 2017 11:11 AM, "Diez Victor"  wrote:

> The problem could be the transmission of data via ethernet port.
>
> Are you working under virtualized OS conditions? These could be the origin
> of your problem, virtualized ethernet ports don’t reach enough high data
> rates.
>
> Another possibility could be that your ethernet adapter isn’t a gigabyte
> ethernet adapter.
>
> Finally, if you work with Matlab/Simulink, you can have the same problem.
> In this case I recommend you to change to GNU-Radio and its flowchart
> interface, GRC.
>
>
>
>
>
>
>
> *De:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+vdiez=
> ikerlan...@gnu.org] *En nombre de *Qurat-Ul-Ann Akbar
> *Enviado el:* jueves, 25 de mayo de 2017 17:44
> *Para:* GNURadio Discussion List
> *Asunto:* [Discuss-gnuradio] IEEE 802.11 receiver not working for high
> sampling rates
>
>
>
> Hi,
>
>
>
> I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to
> work with higher sampling rate like 20 MHZ used in WiFi and that's why I
> bought a new workstation with better processor. However, the module still
> isn't working. The receiver isn't receiving anything at 20 MHZ if it's QAM
> 64 or BPSK . It works perfectly fine with 1 MHZ and receives all data from
> the transmitter USRP. But at 20 MHZ it receives a few WiFi packets from
> surrounding far off APs in the building but isn't receiving anything from
> the USRP transmitter in the room. It doesn't work for 10 MHZ as well.
>
>
>
> Can anyone tell me what could be the reason for that? I have tried
> changing LO offset etc.
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Uher, Jason J.]

This might be a silly question, but are your gain settings correct?

These two facts make me think you may be saturating the receiver and not 
experience sample flow issues:

1)  You’re not seeing under/overflows on the output (I assume, or you 
probably would have mentioned it)

2)  You *are* seeing correctly demoded packets, just from far away

Are you able to turn debug on and check that the packets are being received in 
the linear area of the PA and ADC?



From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jason.uher=jhuapl@gnu.org] On Behalf Of 
Diez Victor
Sent: Thursday, May 25, 2017 12:12 PM
To: Qurat-Ul-Ann Akbar; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] IEEE 802.11 receiver not working for high 
sampling rates

The problem could be the transmission of data via ethernet port.
Are you working under virtualized OS conditions? These could be the origin of 
your problem, virtualized ethernet ports don’t reach enough high data rates.
Another possibility could be that your ethernet adapter isn’t a gigabyte 
ethernet adapter.
Finally, if you work with Matlab/Simulink, you can have the same problem. In 
this case I recommend you to change to GNU-Radio and its flowchart interface, 
GRC.



De: Discuss-gnuradio [mailto:discuss-gnuradio-bounces+vdiez=ikerlan...@gnu.org] 
En nombre de Qurat-Ul-Ann Akbar
Enviado el: jueves, 25 de mayo de 2017 17:44
Para: GNURadio Discussion List
Asunto: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling 
rates

Hi,

I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to work 
with higher sampling rate like 20 MHZ used in WiFi and that's why I bought a 
new workstation with better processor. However, the module still isn't working. 
The receiver isn't receiving anything at 20 MHZ if it's QAM 64 or BPSK . It 
works perfectly fine with 1 MHZ and receives all data from the transmitter 
USRP. But at 20 MHZ it receives a few WiFi packets from surrounding far off APs 
in the building but isn't receiving anything from the USRP transmitter in the 
room. It doesn't work for 10 MHZ as well.

Can anyone tell me what could be the reason for that? I have tried changing LO 
offset etc.


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

[Discuss-gnuradio] "LED" GUI widget?

[John Ackermann N8UR]

I'd like to have an indicator in the GUI (just a small circle is fine) 
light up when a Power Squelch block opens -- basically, an "in use" signal.


Is there a Qt widget that can do that, and is there a way to probe the 
Power Squelch for its state?  (I'd like to do this within GRC if possible.)


Thanks,
John

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

Re: [Discuss-gnuradio] How to write data periodically in file sink

[Paul I.]

Take a look at "Tagged file sink" block.


2017-05-25 4:35 GMT+03:00 Deepak Gautam :

>
> On Thu, May 25, 2017 at 10:34 AM Deepak Gautam  wrote:
>
>> Dear  Gilad, paul,luca
>>
>>
>> Thank you for the kind response. Yes, i need the high accuracy and i
>> think i should go with "issue_stream_cmd" method. Before i start working in
>> this method, my concern is whether i can write the different burst in
>> separate file. My main conern is written file size. Because i have to
>> record data for few minutes With my sampling rate of 25msps. I got problem
>> of overflow when i write in normal hard disk. So i am writing data in RAM
>> disk by which i dont get overflow. Due to size limitation of the Ram disk,
>> i will not be able to write all data in one file. If i write in different
>> file, i can move previous files back to hard disk and proceed. If there is
>> a way of writing in a file for 3/4 minutes with 25msps without overflow , i
>> dont need burst reception also. I appreciate your opinion
>>
>> Best regards,
>> Deepak
>>
>>
>>
>> On Sun, May 21, 2017 at 6:24 PM Paul I.  wrote:
>>
>>> You need to use USRP "issue_stream_cmd" method (mode:
>>> STREAM_MODE_NUM_SAMPS_AND_DONE). It's allow to receive burst of data by
>>> USRP timer.
>>> If you work in GRC:
>>> 1) Disable streaming autostart for "UHD source"
>>> 2) Create your own block which will periodically issue stream commands
>>> (yes, you need to pass USRP pointer to it)
>>> a) For stream command set "num_samples" =  sample_rate * 1 sec
>>> b) Read the USRP timer value, add some time offset to it and use this
>>> value as timestamp for the first stream command
>>> c) Increment timestamp after every stream command
>>> ...
>>> 3) Profit!
>>>
>>> 2017-05-20 10:09 GMT+03:00 Gilad Beeri (ApolloShield) <
>>> gi...@apolloshield.com>:
>>>
 If you need accuracy, I think the asynchronous nature of your method
 might problematic (will appreciate input from GR devs).
 Maybe try a different approach - write the samples to a memory buffer,
 then read from the buffer the exact # of samples you want to write to a
 file.

 On Fri, May 19, 2017 at 5:02 PM Deepak Gautam 
 wrote:

> Dear luca,
>
> I had already tried with controlling flow graph dynamically using
> start(), stop(), lock(), unlock() function. Here i have the part of code i
> had used.
>
> tb=top_block_cls()
> count=1
> tb.start()
> while (count<5):
> time.sleep(1.0)   #data is recorded in the file
> tb.lock()
> tb.disconnect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0,
> 0))   #disconnect source and block
> tb.blocks_file_sink_0= blocks.file_sink(gr.sizeof_gr_complex*1,
> filename,False)  # create new file sink to write
> tb.connect((tb.uhd_usrp_source_0,0),(tb.blocks_file_sink_0, 0))
>  #connect source with new file
> count=count+1
> time.sleep(2.0)   #wait
> tb.unlock()
> tb.stop()
>
>
> This program should write the data for 1 second in the file, wait for
> 2 second and again write for 1 second to another file and so on for 5 4
> times. I expect the total data written in the file to be same. But total
> number of samples recorded in the files are different. for my sampling 
> rate
> of 25MSps, it should record 25MS per file, but it is around 22Mega sample
> with different number of data in different file.  So it is difficult to
> reproduce the accurate signal from received data . My application requires
> very good phase coherence. So i am wondering whether there is something to
> do to solve in this method or i have to think of another idea.
>
>
> Best Regards,
> Deepak
>
>
>
> On Mon, May 15, 2017 at 9:02 PM Moritz Luca Schmid <
> luca.moritz.sch...@gmail.com> wrote:
>
>> Hey Deepak,
>>
>> my first idea is to reconfigure the flowgraph. You could connect and
>> disconnect your source for the time, you want to write data in your file
>> sink and the time you don't want to.
>>
>> You can find infos about the flowgraphs operations here
>> .
>>
>>
>> Best
>>
>> Luca
>>
>>
>>
>> On 15.05.2017 13:53, Deepak Gautam wrote:
>>
>> Currently i am working in the USRP using GNU Radio for my masters
>> work. In my transmitter side, i send data continuously from file source
>> followed by UHD Sink at the rate of 25 MSPS. In receiver side, I want to
>> write the data in every two/three seconds after receiving from receiver
>> USRP. Meaning, write data for 1 sec (25M samples), then dont write for 
>> next
>> 2 second and again write for 1 sec and so on. Is there any suggestion for
>> this purpose. I look forward for the resposne
>>
>>
>> Best Regards,
>> Deepak
>>
>>
>> _

Re: [Discuss-gnuradio] Python block help

[Marcus Müller]

Hi Zach,

not sure the Python interface supports general blocks (ie. blocks where
the number of output items is not a multiple of the input items), I hope
someone else can comment; I'd recommend implementing this as a C++
block; the "Guided Tutorials" on http://tutorials.gnuradio.org should
prepare you to do that.

Best regards,

Marcus


On 25.05.2017 18:08, Zach Morris wrote:
> Hello Marcus,
>
> I realize this is a couple years later but I am attempting to do the same
> type of arbitrary ratio block, where samples above a threshold are passed
> and samples below that threshold are dropped. 
>
> When I tried to subclass gr.block (as below, and in  this tutorial from 2014
> 
>  
> ) in an embedded Python block, GRC threw an error saying gr.block could not
> be found. Does this method still work, or is there an updated method with
> basic_block to implement arbitrary ratio blocks in Python?
>
> Greetings from Menlo Park, CA,
>
> Zach
>
>
>
> Marcus Müller-3 wrote
>> Hi Bob,
>>
>> I think you've introduced the "j" variable to keep count of how many
>> items you're going to produce, but then just tell the scheduler you've
>> produced as many items as he offered you to do. Replace
>> self.produce(0,len(out0))
>> by
>> self.produce(0,j).
>> Also, you consume ninput_items every for loop iteration, so
>> ninput_items^2 per work run. That's not right; do it only once, after
>> the loop.
>>
>> Greetings,
>>
>> Marcus
>>
>> On 12/24/2014 12:21 PM, bob wole wrote:
>>> Hi list,
>>>
>>> I am writing a custom python block that should take complex input,
>>> check magnitude of incoming samples and if the magnitude is greater
>>> than a threshold value, the block should pass that sample otherwise
>>> the block just drop the samples. As this is an arbitrary ratio block I
>>> derived it from gr.block and set_auto_consume(False).
>>>
>>> However I get intermittent zeros in output stream of my custom block.
>>> Below is the code
>>>
>>> from gnuradio import gr
>>> import gnuradio.extras
>>> import math
>>> import numpy as np
>>>
>>>
>>> class sdr_pass_valid(gr.block):
>>> """
>>> """
>>> def __init__(self,threshold):
>>> gr.block.__init__(
>>> self,
>>> name = "VALID",
>>> in_sig = [np.complex64],
>>> out_sig = [np.complex64],
>>> )
>>> self.set_auto_consume(False)
>>>
>>> self.threshold =  threshold
>>> def forecast (self,noutput_items,ninput_items_required):
>>> for i in range(len(ninput_items_required)):
>>> ninput_items_required[i] = noutput_items
>>>
>>> def work(self, input_items, output_items):
>>>
>>> in0 = input_items[0][:len(output_items[0])]
>>> out0= output_items[0]
>>> nread = self.nitems_read(0) #number of items read on port 0
>>> ninput_items = len(in0)
>>> j=0
>>> for i in range(0,ninput_items):
>>> if np.absolute(in0[i]) >= self.threshold :
>>> out0[j] = in0[i]
>>> j = j + 1
>>> self.consume(0,ninput_items)
>>> self.produce(0,len(out0))
>>> return 0
>>>
>>>
>>> --
>>> Bob
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>>
>> Discuss-gnuradio@
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/Python-block-help-tp51706p64046.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] IEEE 802.11 receiver not working for high sampling rates

[Marcus Müller]

Hi,

well, the next step here would pretty clearly be going through the flow
graph and finding out where things don't work – you'd typically start
with something like a frequency or waterfall plot directly at the
receiver, and then look for packet errors, and so on. Use a Qt time sink
to look for clipping or too weak signals.

As we're not sitting in your lab, this might actually be pretty hard to
do remotely; that's the thing about debugging: you basically have to do
it till until you're experienced enough. We can only suggest things from
afar, but I think in the other threads we've been discussing the most
likely things already...

Best regards,

Marcus


On 25.05.2017 17:43, Qurat-Ul-Ann Akbar wrote:
> Hi,
>
> I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able
> to work with higher sampling rate like 20 MHZ used in WiFi and that's
> why I bought a new workstation with better processor. However, the
> module still isn't working. The receiver isn't receiving anything at
> 20 MHZ if it's QAM 64 or BPSK . It works perfectly fine with 1 MHZ and
> receives all data from the transmitter USRP. But at 20 MHZ it receives
> a few WiFi packets from surrounding far off APs in the building but
> isn't receiving anything from the USRP transmitter in the room. It
> doesn't work for 10 MHZ as well. 
>
> Can anyone tell me what could be the reason for that? I have tried
> changing LO offset etc. 
>
>
>
>
> ___
> 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] Fwd: IEEE802.11 transceiver - problems sending data

[Cristian Rodríguez]

2017-05-19 7:04 GMT-05:00 Bastian Bloessl :

> Hi,
>
> > On 19. May 2017, at 12:09, Cristian Rodríguez <
> cristian.rodriguez...@gmail.com> wrote:
> >
> >  You will have to also add the corresponding entry in reverse direction.
> It’s not in the script since I always used the WiFi card of another PC.
>
> > I did that as follows:
> >
> > sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp4s0
>
> So you just set up one ARP entry.
>
>
> >
> > Then use Wireshark to monitor GNU Radio (that’s what you might do at the
> moment) and also the WiFi card. This might help to understand what frames
> are actually sent, if they are OK (MAC, IP, BSS) and if they are
> successfully received by the WiFi card and the SDR.
> > If i do a ping from the interface tap0 to 192.168.123.2 (IP of my wifi
> card) it doesn't work. The signal is going out of the USRP but the Wifi
> Card of the computer is not taking it.
> >
> > ping -I tap0 192.168.123.2
> >
> > If i do a ping from the interface wlp4s0 to 192.168.123.1 (IP of USRP
> B210) it doesn't work. The signal is NOT going out of the Wifi card (i
> verifed that through wireshark).
> >
> > ping -I wlp4s0 192.168.123.1
>
> As I said, you will have to actually look at the frame (BSS, MAC, IP, …)
> and see if the fields are OK. Also put the receiver in monitor mode to
> check if the packet is actually received. It’s a configuration issue and
> you will have to find out where in the network stack it gets dropped.
>

I've tried to solve the trouble the whole week. I don't think my computer
is able to support the communication between its Wifi card and the USRP
B210. When i do a Ping from the USRP to the wifi card (in monitor mode),
and it receives the ping, it stops working and in the terminal which is
executing the app nic.sh appear *ether type: IP. *In the wireshark file for
the side of Tx, it clearly have stoped working. I've tried to solve it, but
i don't think is a configuration problem.

On the other side, i got a computer and i'm try to communicate to it. When
i configure Monitor mode i can get packages.

What interface Mode do you think i should use? Ad-hoc or managed?

I've tried both but for me it doesn't work.

I've checked the frame and it looks as supposed. It shows the MAC of the PC
which is receiving, the MAC associated to the USRP and the common flags.

I think it is a problem in the configuration file in the PC which is
receiving.
In that PC i'm doing the next:

Turn off the interface:
sudo ifconfig wlp2s0 down
Set the mode
sudo iwconfig wlp2s0 mode monitor/managed
Turn on the interface:
sudo ifconfig wlp2s0 up
Set in the channel that USRP is going to send
sudo iw dev wlp2s0 set freq 2472
Assign an IP in the network, the USRP is .1
sudo ifconfig wlp2s0 192.168.123.2
Modify the kernel's IPv4 network
sudo route add -net 192.168.123.0/24 wlp2s0
Set a static route
sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp2s0

All the commands work, i checked with iwconfig, ifconfig, route, arp -a

*arp -a*
? (192.168.123.1) at 12:34:56:78:90:ab [ether] PERM on wlp2s0

*route*
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
192.168.123.0   *   255.255.255.0   U 0  00
wlp2s0

*ifconfig*
wlp2s0Link encap:Ethernet  HWaddr e0:ca:94:68:06:a7
  inet addr:192.168.123.2  Bcast:192.168.123.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1

*iwconfig*
wlp2s0IEEE 802.11  ESSID:off/any
  Mode:Managed  Frequency:2.462 GHz  Access Point: Not-Associated
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:on

Then i don't catch the problem.

*Finally, May you share to me the configuration file that you used when you
configure your PC in these experiments?*

Really, thanks a lot for your time.

Best regards,

Cristian



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

Re: [Discuss-gnuradio] IEEE802.11 transceiver - problems sending data

[Cristian Rodríguez]

2017-05-19 7:04 GMT-05:00 Bastian Bloessl :

> Hi,
>
> > On 19. May 2017, at 12:09, Cristian Rodríguez <
> cristian.rodriguez...@gmail.com> wrote:
> >
> >  You will have to also add the corresponding entry in reverse direction.
> It’s not in the script since I always used the WiFi card of another PC.
>
> > I did that as follows:
> >
> > sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp4s0
>
> So you just set up one ARP entry.
>
>
> >
> > Then use Wireshark to monitor GNU Radio (that’s what you might do at the
> moment) and also the WiFi card. This might help to understand what frames
> are actually sent, if they are OK (MAC, IP, BSS) and if they are
> successfully received by the WiFi card and the SDR.
> > If i do a ping from the interface tap0 to 192.168.123.2 (IP of my wifi
> card) it doesn't work. The signal is going out of the USRP but the Wifi
> Card of the computer is not taking it.
> >
> > ping -I tap0 192.168.123.2
> >
> > If i do a ping from the interface wlp4s0 to 192.168.123.1 (IP of USRP
> B210) it doesn't work. The signal is NOT going out of the Wifi card (i
> verifed that through wireshark).
> >
> > ping -I wlp4s0 192.168.123.1
>
> As I said, you will have to actually look at the frame (BSS, MAC, IP, …)
> and see if the fields are OK. Also put the receiver in monitor mode to
> check if the packet is actually received. It’s a configuration issue and
> you will have to find out where in the network stack it gets dropped.
>
> I've tried to solve the trouble the whole week. I don't think my computer
is able to support the communication between its Wifi card and the USRP
B210. When i do a Ping from the USRP to the wifi card (in monitor mode),
and it receives the ping, it stops working and in the terminal which is
executing the app nic.sh appear *ether type: IP. *In the wireshark file for
the side of Tx, it clearly have stoped working. I've tried to solve it, but
i don't think is a configuration problem.

On the other side, i got a computer and i'm try to communicate to it. When
i configure Monitor mode i can get packages.

What interface Mode do you think i should use? Ad-hoc or managed?

I've tried both but for me it doesn't work.

I've checked the frame and it looks as supposed. It shows the MAC of the PC
which is receiving, the MAC associated to the USRP and the common flags.

I think it is a problem in the configuration file in the PC which is
receiving.
In that PC i'm doing the next:

Turn off the interface:
sudo ifconfig wlp2s0 down
Set the mode
sudo iwconfig wlp2s0 mode monitor/managed
Turn on the interface:
sudo ifconfig wlp2s0 up
Set in the channel that USRP is going to send
sudo iw dev wlp2s0 set freq 2472
Assign an IP in the network, the USRP is .1
sudo ifconfig wlp2s0 192.168.123.2
Modify the kernel's IPv4 network
sudo route add -net 192.168.123.0/24 wlp2s0
Set a static route
sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp2s0

All the commands work, i checked with iwconfig, ifconfig, route, arp -a

*arp -a*
? (192.168.123.1) at 12:34:56:78:90:ab [ether] PERM on wlp2s0

*route*
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
192.168.123.0   *   255.255.255.0   U 0  00
wlp2s0

*ifconfig*
wlp2s0Link encap:Ethernet  HWaddr e0:ca:94:68:06:a7
  inet addr:192.168.123.2  Bcast:192.168.123.255  Mask:255.255.255.0
  UP BROADCAST MULTICAST  MTU:1500  Metric:1

*iwconfig*
wlp2s0IEEE 802.11  ESSID:off/any
  Mode:Managed  Frequency:2.462 GHz  Access Point: Not-Associated
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Power Management:on

Then i don't catch the problem.

*Finally, May you share to me the configuration file that you used when you
configure your PC in these experiments?*

Really, thanks a lot for your time.

Best regards,

Cristian



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