Re: [Discuss-gnuradio] gr-ieee 802.11 and integration with linux stack (wpa_supplicant)

[Bastian Bloessl]

Hi,

> On 5 Dec 2016, at 21:10, sumitstop  wrote:
> 
> Has anyone tried integration of gr-ieee 802.11 with Linux stack
> (wpa_supplicant)? 
> 


I guess no, but since it doesn’t have a standard compliant MAC layer that might 
be of limited benefit.

If you really want to look into integrating it in Linux, I would implement it 
as virtual WiFi device, similar to hwsim 
(https://wireless.wiki.kernel.org/en/users/drivers/mac80211_hwsim 
). Then the 
higher layer stuff like hostap and wpa_supplicant would just work out of the 
box.

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

Re: [Discuss-gnuradio] Reg: gr-ieee 802.11 and wireshark settings for commercial NIC

[Bastian Bloessl]

Hi,

> On 5 Dec 2016, at 23:08, sumit kumar  wrote:
> I  mean the wireshark dint detect transmission from gr-ieee 802.11 
> transmitter also apart from my custom build transmitter(openairinterface).  
> 


So AFAIS, this are two problems.

- Your custom transmitter is received by gr-ieee802-11, but not by you WiFi 
card. I guess that’s a configuration issue (see my previous reply).

- gr-ieee802-11 is not received by gr-ieee802-11. 
Please make sure to
- reset the flow graphs to their initial state (no parameters changed). Clone 
the repository again, for example.
- try to change the gain
- double-check which TX port is used and if an antenna is connected to that 
port.


Best,
Bastian



> 
> 
> 
> 
> I think you should make sure to
> - tune to the correct frequency/channel
> 
> Currently I have put this filter in wireshark wlan_radio.frequency ==
> 2432 and using gr-ieee 802.11 tx tuned to the same.
> 
> You will have to configure the card using something like
> 
> iw phy  set channel 
> 
> The filter doesn't tune the card to the correct frequency.
> This is also not helping though ! :-/  
> 
> 
> 
> - make sure that the network manager doesn't interfere
> 
> How to do this ?
> 
> sudo service network-manager stop
> 
> or edit /etc/NetworkManager/NetworkManager.conf
> I did this, but it stopped my wifi signals. I mean the wifi icon was gone.  
> 
> 
> Best,
> Bastian
> 
> 
> Regards
> 
> -- 
> Sumit Kumar
> 
> 

--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/

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

Re: [Discuss-gnuradio] Frequency multiplexing at baseband -filters introduce 'DDDDDDDDDDD'

[Marcus D. Leech]

On 12/05/2016 06:42 PM, Marcus Müller wrote:


Dear Damindra,

a "D" means that your computer was so busy, the operating system 
wasn't able to handle network data sufficiently fast, and in effect, 
network packets were dropped even before they reached UHD.


This means that your filter is too compute-intense for your PC. Either 
get a faster PC, or decrease the order of your filter. Overly sharp 
filters are a common mistake.


Best regards,

Marcus


Also, for regularly-spaced channels, using a PFB channelizer or PFB 
synthesis block may be significantly more efficient for what Damindra is

  trying to do.


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

Re: [Discuss-gnuradio] Frequency multiplexing at baseband -filters introduce 'DDDDDDDDDDD'

[Marcus Müller]

Dear Damindra,

a "D" means that your computer was so busy, the operating system wasn't
able to handle network data sufficiently fast, and in effect, network
packets were dropped even before they reached UHD.

This means that your filter is too compute-intense for your PC. Either
get a faster PC, or decrease the order of your filter. Overly sharp
filters are a common mistake.

Best regards,

Marcus

On 05.12.2016 21:25, Damindra Bandara wrote:
> Hi,
>
> I am trying to send multiple baseband signals combined using USRP
> N210. To do that I multiplied the baseband signals by a proper sine
> wave and added them before transmission. At the receiver I try to
> filter the signals using bandpass filters, then multiply using the
> same sinewave and extract the signal. The problem I am facing is that
> as soon as I add a filter the USRP started to give a sequence of
> 'DD' s.  Could somebody please help me to understand what is going
> on.
>
> If the method I am trying to get the frequency multiplexing at the
> baseband is wrong could you please give me some instructions to do
> baseband channel multiplexing. I appreciate if you could give me any help.
>
> Thank you,
> Damindra
>
> -- 
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
> ___
> 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] PMT Oddities

[Dave NotTelling]

Marcus & Martin:

 I tried the dict_keys() method of checking, but even that can fail.
Here is an example:

[code]

import pmt

d = pmt.make_dict()
d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))

a = pmt.cons(d, pmt.make_u8vector(10, 10))

print pmt.dict_keys(a)

[/code]

You end up with: ((c . c))

The dict_keys() method will bomb if there are no elements in the dictionary:

print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10)))


On Tue, Nov 22, 2016 at 5:55 PM, Dave NotTelling 
wrote:

> Thanks for the explanation!
>
> On Tue, Nov 22, 2016 at 5:29 PM, Marcus Müller 
> wrote:
>
>> That's a long story. Essentially, a list is a pair of the first element
>> and a pair of a second element and a pair of the third element and a pair
>> of …
>>
>> Cheers,
>> Marcus
>>
>> On 22.11.2016 23:18, Dave NotTelling wrote:
>>
>> I ask because it feels like a bug.  Things like ((a . b), (c . d), (e .
>> f)) are definitely not pairs (assuming a pair is 2 elements) and (in my
>> opinion) should not return true for pmt.is_pair().
>>
>> On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling 
>> wrote:
>>
>>> Martin,
>>>
>>>  Was that done on purpose?
>>>
>>>  Thank you for the link!  I hadn't thought about checking that way.
>>>
>>> Thanks!
>>>
>>> -Dave
>>>
>>> On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
>>> wrote:
>>>
 Dave,

 pairs pass is_dict(), which is possibly the root cause here. See also:
 https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b2
 6617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494

 Cheers,
 M

 On 11/22/2016 01:47 PM, Dave NotTelling wrote:
 > I noticed today that the is_dict and is_pair checks are not appearing
 to
 > work properly.  Here is an example that shows the issue:
 >
 > [code]
 >
 > #!/usr/bin/python
 >
 > import pmt
 >
 > def print_pmt(dictVar):
 > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
 > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
 dictVar)
 >
 > print 'DICT'
 >
 > d = pmt.make_dict()
 > print_pmt(d)
 >
 > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
 > print_pmt(d)
 >
 > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
 > print_pmt(d)
 >
 > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
 > print_pmt(d)
 >
 > print '\nCONS'
 >
 > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
 > print_pmt(p)
 >
 > [/code]
 >
 > Run that and you'll see what I consider strange behavior.  The values
 of
 > is_pair and is_dict to not match what is expected.  Is that by design?
 > If so, why?
 >
 > ((a . b)) is not a pair...  It's a single element dictionary
 > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
 > created that way
 > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
 >
 > (() . #[]) don't dictionaries have to be nested?
 >
 >
 > 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

>>>
>>>
>>
>>
>> ___
>> 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] gr-ieee 802.11 and integration with linux stack (wpa_supplicant)

[sumitstop]

Hello,

Has anyone tried integration of gr-ieee 802.11 with Linux stack
(wpa_supplicant)? 

Regards

Sumit 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-ieee-802-11-and-integration-with-linux-stack-wpa-supplicant-tp62184.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] Frequency multiplexing at baseband -filters introduce 'DDDDDDDDDDD'

[Damindra Bandara]

Hi,

I am trying to send multiple baseband signals combined using USRP N210. To
do that I multiplied the baseband signals by a proper sine wave and added
them before transmission. At the receiver I try to filter the signals using
bandpass filters, then multiply using the same sinewave and extract the
signal. The problem I am facing is that as soon as I add a filter the USRP
started to give a sequence of 'DD' s.  Could somebody please help me to
understand what is going on.

If the method I am trying to get the frequency multiplexing at the baseband
is wrong could you please give me some instructions to do baseband channel
multiplexing. I appreciate if you could give me any help.

Thank you,
Damindra

-- 
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Add RFNoC FIFO

[Martin Braun]

To change the blocks, you need to edit rfnoc_ce_auto_inst_x310.v twice:
You need to change NUM_CE (at the top), and then the actual block list.

For FIFOs, you can go to the bottom and use the generate for loop to add
more FIFOs.

You can use make.py to autogenerate this file (in
usrp3/tools/scripts/make.py).

Cheers,
Martin

On 12/04/2016 05:55 PM, Vishwesh Rege wrote:
> Hi,
> 
> I want to add the FIFO block in usrp3_rfnoc/lib/fifo to USRP along with
> the addsub module in usrp3_rfnoc/lib/hls folder.
> 
> I'm running make X310_RFNOC_HLS_HG from usrp3_rfnoc/top/x300 directory
> and then flashing the generated image in build/.
> 
> However, the FIFO isn't included in the image for some reason. Only the
> following RFNoC blocks are actually flashed:
> | | | * DmaFIFO_0
> | | | * Radio_0
> | | | * Radio_1
> | | | * AddSub_0
> | | | * FIR_0
> | | | * FFT_0
> | | | * Window_0
> | | | * NullSrcSink_0
> | | | * SigGen_0
> | | | * MovingAverage_0
> | | | * VectorIIR_0
> | | | * KeepOneInN_0
> | | | * fosphor_0
> 
> The Makefile usrp3_rfnoc/top/x300/Makefile.x300.inc already includes
> FIFO_SRCS in DESIGN_SRCS
> 
> Do I need to make any changes to include the FIFO?
> 
> Any help is appreciated.
> 
> 
> 
> ___
> 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] rx_time tag after drop

[Martin Braun]

On 12/05/2016 04:24 AM, Meelis Nõmm wrote:
> Now to what Martin told
> 
> > 3. I would expect that the offset is incremented by the number of
> > dropped samples. So that the combination of t_0 and offset still
> > provides valid current sample time. The difference between the sum of
> > noutput_items and offset will give the number of dropped samples?
> 
> If you have two tags, and in between, N samples, the number of dropped
> samples is (t_1 - t_0) * f_s - N.
> 
> By " N samples ", do you mean Offset_{t_1} - Offset_{t_0} (the offset
> difference between 2 tags)?   

The offset difference dictates how many samples there *should* be (if
nothing was dropped). Subtract the number of samples you actually
received from that, and you have the number of dropped samples.

> I guess this leads to the core question. What does the offset show?
> 1. sample number related to the GnuRadio stream or
> 2. sample number related to the USRP stream?

There is no offset. The tag is the absolute time of the sample
(rx_time). Ore are we speaking about different things?

Cheers,
Martin

> In case of 1. offset knows nothing of dropped samples and in case of 2.
> it takes them into account.
> 
> Things are starting to clear up
> Meelis
> 
> 
> 
> On Sat, Dec 3, 2016 at 2:05 AM, Martin Braun  > wrote:
> 
> On 12/02/2016 05:08 AM, Meelis Nõmm wrote:
> > Since dropped samples never enter GNU Radio the behavior is correct.
> >
> > I see, before I thought the samples are dropped inside the Gnuradio
> > framework.
> >
> > That raises a few questions for me that are unclear
> > 1. Does the UHD driver drop a full UDP package?
> 
> When you see a D, UHD didn't actually drop the packet itself. It's
> telling you that it didn't get a packet it was expecting. And yes, it's
> always full packets that get lost this way.
> 
> > 2. After a drop (D), does the UHD source (PC side) take the rx_time from
> > the next UDP package and that is inserted to the tag?
> 
> Yes.
> 
> > 3. I would expect that the offset is incremented by the number of
> > dropped samples. So that the combination of t_0 and offset still
> > provides valid current sample time. The difference between the sum of
> > noutput_items and offset will give the number of dropped samples?
> 
> If you have two tags, and in between, N samples, the number of dropped
> samples is (t_1 - t_0) * f_s - N.
> 
> Cheers,
> Martin
> 
> > Can't tell the exact UHD version, as my colleague is out of office
> > today. But we used N210, during that example test we did not change the
> > sample rate during runtime.
> >
> > Can tell more on Monday,
> > Meelis
> >
> > On Thu, Dec 1, 2016 at 10:05 PM, Derek Kozel  
> > >> wrote:
> >
> > Hello Meelis,
> >
> > My understanding is that the offset is the index of the sample
> > within GNU Radio which the tag is attached to. Since dropped samples
> > never enter GNU Radio the behavior is correct. The rx_time is one of
> > the few tags where this behavior is potentially confusing since the
> > rx_time is a concept based entirely outside of the host computer. It
> > is possible to calculate the number of dropped samples using the
> > rx_time tags and the total number of samples correctly received
> > between the tags, as long as the rx_time tags are correct.
> >
> > What version of UHD are you running? What USRP are you connected to?
> > Are you setting or changing the sample rate after starting the
> > flowgraph? Would you be able to try using the latest UHD maint code?
> > https://github.com/EttusResearch/uhd/tree/maint
> 
> >  >
> >
> > Thanks,
> > Derek
> >
> > On Thu, Dec 1, 2016 at 1:42 AM, Meelis Nõmm  
> > >>
> wrote:
> >
> > Hello everyone
> >
> > We have been wondering about rx_time tags after drop. In
> [1] it
> > is stated that "Then, if a dropped
> > packet or overflow are detected, it sends a new rx_time tag."
> >
> > The tag debugger output is shown below.
> > Initially we thought that in the tag the time and the
> offset are
> > bound together. Instead seems that this is true only for the
> > first tag. Meaning, the offset is always bound to the initial
> > rx_time, as one can 

[Discuss-gnuradio] ZeroMQ: Has anyone tried 4.2.0?

[Martin Braun]

I'm wondering if it's safe to update the gr-recipes recipe for ZeroMQ to
4.2.0 -- that way we can point it to a git tag instead of a tarball,
which plays nicer with git caches etc.

If anyone's given this a spin, please let me know! Thanks!

Cheers,
Martin

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

Re: [Discuss-gnuradio] Building simulation of basic turbo code

[AzieRis]

Hello again,

so i made some steps into Gnu Radio Companion by examples you suggested in
previous post. However i still could not find information or did not
understand documentation properly. I'm gonna link my project in here to let
know what am I talking about.
Turbocoding.grc
  
fsm1.fsm   
I'm not sure why am I getting errors at my PCCC encoder:
Check "(isinstance(eval(""" $o_fsm_args """[1:-1], locals(),globals()), str)
and open($o_fsm_args).close()) or True" did not evaluate.
Check "(isinstance(eval(""" $i_fsm_args """[1:-1], locals(),globals()), str)
and open($i_fsm_args).close()) or True " did not evaluate.
Also i would like to ask if pccc encoder produces 3 bits out of one - 1
systematic,1 is the output by fsm and 3rd output is the interleaved fsm
output - or each fsm produces 2 outputs so i need to use such fsm that is
not going to produce systematic output. 
The rest of the project should be right, at least if think so ;) -
turbocoding with bpsk modulation 
In later stage I'm gonna be modifying: iterations, block interleaver length,
noise value to make charts of BER performance.

Thanks in forward for every response to this post.
Regards,
Adrian




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Building-simulation-of-basic-turbo-code-tp61978p62179.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] rx_time tag after drop

[Meelis Nõmm]

To answer Derek's question that output was generated using
UHD_003.011.000.git-95-g811444b1

We have a feeling that the development machine has some network issues, as
it also keeps giving UHD connection failures after fast application
restart.

> > 2. After a drop (D), does the UHD source (PC side) take the rx_time from
> > the next UDP package and that is inserted to the tag?
>
> Yes.
>
This could also explain why the rx_time tags are messed up, given the UDP
packages "arrive" in the wrong order.

Now to what Martin told

> > 3. I would expect that the offset is incremented by the number of
> > dropped samples. So that the combination of t_0 and offset still
> > provides valid current sample time. The difference between the sum of
> > noutput_items and offset will give the number of dropped samples?
>
> If you have two tags, and in between, N samples, the number of dropped
> samples is (t_1 - t_0) * f_s - N.
>
By " N samples ", do you mean Offset_{t_1} - Offset_{t_0} (the offset
difference between 2 tags)?

I guess this leads to the core question. What does the offset show?
1. sample number related to the GnuRadio stream or
2. sample number related to the USRP stream?

In case of 1. offset knows nothing of dropped samples and in case of 2. it
takes them into account.

Things are starting to clear up
Meelis



On Sat, Dec 3, 2016 at 2:05 AM, Martin Braun  wrote:

> On 12/02/2016 05:08 AM, Meelis Nõmm wrote:
> > Since dropped samples never enter GNU Radio the behavior is correct.
> >
> > I see, before I thought the samples are dropped inside the Gnuradio
> > framework.
> >
> > That raises a few questions for me that are unclear
> > 1. Does the UHD driver drop a full UDP package?
>
> When you see a D, UHD didn't actually drop the packet itself. It's
> telling you that it didn't get a packet it was expecting. And yes, it's
> always full packets that get lost this way.
>
> > 2. After a drop (D), does the UHD source (PC side) take the rx_time from
> > the next UDP package and that is inserted to the tag?
>
> Yes.
>
> > 3. I would expect that the offset is incremented by the number of
> > dropped samples. So that the combination of t_0 and offset still
> > provides valid current sample time. The difference between the sum of
> > noutput_items and offset will give the number of dropped samples?
>
> If you have two tags, and in between, N samples, the number of dropped
> samples is (t_1 - t_0) * f_s - N.
>
> Cheers,
> Martin
>
> > Can't tell the exact UHD version, as my colleague is out of office
> > today. But we used N210, during that example test we did not change the
> > sample rate during runtime.
> >
> > Can tell more on Monday,
> > Meelis
> >
> > On Thu, Dec 1, 2016 at 10:05 PM, Derek Kozel  > > wrote:
> >
> > Hello Meelis,
> >
> > My understanding is that the offset is the index of the sample
> > within GNU Radio which the tag is attached to. Since dropped samples
> > never enter GNU Radio the behavior is correct. The rx_time is one of
> > the few tags where this behavior is potentially confusing since the
> > rx_time is a concept based entirely outside of the host computer. It
> > is possible to calculate the number of dropped samples using the
> > rx_time tags and the total number of samples correctly received
> > between the tags, as long as the rx_time tags are correct.
> >
> > What version of UHD are you running? What USRP are you connected to?
> > Are you setting or changing the sample rate after starting the
> > flowgraph? Would you be able to try using the latest UHD maint code?
> > https://github.com/EttusResearch/uhd/tree/maint
> > 
> >
> > Thanks,
> > Derek
> >
> > On Thu, Dec 1, 2016 at 1:42 AM, Meelis Nõmm  > > wrote:
> >
> > Hello everyone
> >
> > We have been wondering about rx_time tags after drop. In [1] it
> > is stated that "Then, if a dropped
> > packet or overflow are detected, it sends a new rx_time tag."
> >
> > The tag debugger output is shown below.
> > Initially we thought that in the tag the time and the offset are
> > bound together. Instead seems that this is true only for the
> > first tag. Meaning, the offset is always bound to the initial
> > rx_time, as one can see from the example printout. Both the
> > offset and the time increase (sampling rate is 10e6).
> >
> > Actually, now that I look at them the rx_time values are messed
> > up, they are not even monotonically increasing (the timestamp in
> > the second tag is "newer" than in the third). So what does the
> > rx_time in the tag after drop represent?
> >
> > In any case, isn't this a bit counter intuitive? I know we fell
> > for it at first.