|
| From: | Damindra Bandara |
| Subject: | Re: [Discuss-gnuradio] Frequency multiplexing at baseband -filters introduce 'DDDDDDDDDDD' |
| Date: | Tue, 6 Dec 2016 13:51:36 -0500 |
Send Discuss-gnuradio mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hiddenorg
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. ZeroMQ: Has anyone tried 4.2.0? (Martin Braun)
2. Re: rx_time tag after drop (Martin Braun)
3. Re: Add RFNoC FIFO (Martin Braun)
4. Frequency multiplexing at baseband -filters introduce
'DDDDDDDDDDD' (Damindra Bandara)
5. gr-ieee 802.11 and integration with linux stack
(wpa_supplicant) (sumitstop)
6. Re: PMT Oddities (Dave NotTelling)
7. Re: Frequency multiplexing at baseband -filters introduce
'DDDDDDDDDDD' (Marcus M?ller)
8. Re: Frequency multiplexing at baseband -filters introduce
'DDDDDDDDDDD' (Marcus D. Leech)
9. Re: Reg: gr-ieee 802.11 and wireshark settings for commercial
NIC (Bastian Bloessl)
10. Re: gr-ieee 802.11 and integration with linux stack
(wpa_supplicant) (Bastian Bloessl)
11. Re: gr-ieee 802.11 and integration with linux stack
(wpa_supplicant) (Manolis Surligas)
12. Re: gr-ieee 802.11 and integration with linux stack
(wpa_supplicant) (Bastian Bloessl)
13. OS X Sierra complete build (Gregory Ratcliff)
14. Re: OS X Sierra complete build (Michael Dickens)
15. Re: rx_time tag after drop (Meelis N?mm)
16. Max PMT Size (Dave NotTelling)
17. Re: Segfault with volk_32fc_32f_dot_prod_32fc_a_avx (devin kelly)
------------------------------------------------------------ ----------
Message: 1
Date: Mon, 5 Dec 2016 09:03:37 -0800
From: Martin Braun <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] ZeroMQ: Has anyone tried 4.2.0?
Message-ID: <802a712f-7060-0d94-40d5-address@hidden >
Content-Type: text/plain; charset=utf-8
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
------------------------------
Message: 2
Date: Mon, 5 Dec 2016 09:32:04 -0800
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] rx_time tag after drop
Message-ID: <a7243e85-5eed-5c8f-1b19-address@hidden >
Content-Type: text/plain; charset=windows-1252
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 <address@hidden
> <mailto:address@hidden>> 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 <address@hidden <mailto:address@hidden>
> > <mailto:address@hidden <mailto:address@hidden>>> 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
> <https://github.com/EttusResearch/uhd/tree/maint >
> > <https://github.com/EttusResearch/uhd/tree/maint
> <https://github.com/EttusResearch/uhd/tree/maint >>
> >
> > Thanks,
> > Derek
> >
> > On Thu, Dec 1, 2016 at 1:42 AM, Meelis N?mm <address@hidden <mailto:address@hidden>
> > <mailto:address@hidden <mailto:address@hidden>>>
> 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. There might be more places in the code that
> > mishandle the rx_time tags after drops. I understand that
> drops
> > should be avoided, but still I think it is crucial that
> they are
> > correctly handled.
> >
> >
> ------------------------------------------------------------ ---------
> >
> > Tag Debug:
> > Input Stream: 00
> > Offset: 0 Source: gr uhd usrp source1 Key: rx_time
> > Value: {1480518095 0 <tel:1480518095%200>.75052}
> > Offset: 0 Source: gr uhd usrp source1 Key: rx_rate
> > Value: 1e+07
> > Offset: 0 Source: gr uhd usrp source1 Key: rx_freq
> > Value: 1.56e+08
> >
> ------------------------------------------------------------ ----------
> >
> > D
> >
> ------------------------------------------------------------ ----------
> >
> > Tag Debug:
> > Input Stream: 00
> > Offset: 17461752 Source: gr uhd usrp source1 Key:
> rx_time
> > Value: {1480518097 0.497203}
> > Offset: 17461752 Source: gr uhd usrp source1 Key:
> rx_rate
> > Value: 1e+07
> > Offset: 17461752 Source: gr uhd usrp source1 Key:
> rx_freq
> > Value: 1.56e+08
> >
> ------------------------------------------------------------ ----------
> >
> > D
> >
> ------------------------------------------------------------ ----------
> >
> > Tag Debug:
> > Input Stream: 00
> > Offset: 17471916 Source: gr uhd usrp source1 Key:
> rx_time
> > Value: {1480518097 0.496695}
> > Offset: 17471916 Source: gr uhd usrp source1 Key:
> rx_rate
> > Value: 1e+07
> > Offset: 17471916 Source: gr uhd usrp source1 Key:
> rx_freq
> > Value: 1.56e+08
> >
> ------------------------------------------------------------ ----------
> >
> > D
> >
> ------------------------------------------------------------ ----------
> >
> > Tag Debug:
> > Input Stream: 00
> > Offset: 17476998 Source: gr uhd usrp source1 Key:
> rx_time
> > Value: {1480518097 0.498219}
> > Offset: 17476998 Source: gr uhd usrp source1 Key:
> rx_rate
> > Value: 1e+07
> > Offset: 17476998 Source: gr uhd usrp source1 Key:
> rx_freq
> > Value: 1.56e+08
> >
> ------------------------------------------------------------ ----------
> >
> >
> > With regards
> > Meelis
> >
> > [1]
> >
> http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx- time-tags-while-receiving- continuously-tt44492.html# a44515
> <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx- >time-tags-while-receiving- continuously-tt44492.html# a44515
> >
> <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx- time-tags-while-receiving- continuously-tt44492.html# a44515
> <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx- >>time-tags-while-receiving- continuously-tt44492.html# a44515
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden <mailto:address@hiddenorg >
> <mailto:address@hiddenorg <mailto:address@hiddenorg >>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss- >gnuradio
> > <https://lists.gnu.org/mailman/listinfo/discuss- gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss- >>gnuradio
> >
> >
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden <mailto:address@hiddenorg >
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss- >gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden <mailto:address@hiddenorg >
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss- >gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 3
Date: Mon, 5 Dec 2016 09:52:39 -0800
From: Martin Braun <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Add RFNoC FIFO
Message-ID: <cdb98e23-0711-017d-07bd-address@hidden >
Content-Type: text/plain; charset=windows-1252
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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 4
Date: Mon, 5 Dec 2016 15:25:09 -0500
From: Damindra Bandara <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Frequency multiplexing at baseband
-filters introduce 'DDDDDDDDDDD'
Message-ID:
<CANpceN_xb7JJzij6biF9OqV0fB61YmmTQawBs >address@hidden
Content-Type: text/plain; charset="utf-8"
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 'DDDDDD' 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161205/2c2c325b/ attachment.html
------------------------------
Message: 5
Date: Mon, 5 Dec 2016 13:10:17 -0700 (MST)
From: sumitstop <address@hiddenin >
To: address@hidden
Subject: [Discuss-gnuradio] gr-ieee 802.11 and integration with linux
stack (wpa_supplicant)
Message-ID: <address@hiddennabble.com >
Content-Type: text/plain; charset=us-ascii
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.
------------------------------
Message: 6
Date: Mon, 5 Dec 2016 16:56:14 -0500
From: Dave NotTelling <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] PMT Oddities
Message-ID:
<CAK6GVuPWvMQFw_3mdYmULEyaKbYaw1QbLAsbHH6bmw_ >address@hidden
Content-Type: text/plain; charset="utf-8"
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 <address@hidden>
wrote:
> Thanks for the explanation!
>
> On Tue, Nov 22, 2016 at 5:29 PM, Marcus M?ller <address@hidden>
> 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 <address@hidden>
>> 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 <address@hidden>
>>> 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
>>>> > address@hidden
>>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing address@hiddenorghttps://lists.gnu.org/ mailman/listinfo/discuss- gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161205/81d2620b/ attachment.html
------------------------------
Message: 7
Date: Tue, 6 Dec 2016 00:42:58 +0100
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Frequency multiplexing at baseband
-filters introduce 'DDDDDDDDDDD'
Message-ID: <6a55611d-bc18-93c6-b9a5-address@hidden >
Content-Type: text/plain; charset="windows-1252"
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
> 'DDDDDD' 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/473f5456/ attachment.html
------------------------------
Message: 8
Date: Mon, 05 Dec 2016 18:58:53 -0500
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Frequency multiplexing at baseband
-filters introduce 'DDDDDDDDDDD'
Message-ID: <address@hidden>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161205/23f61a02/ attachment.html
------------------------------
Message: 9
Date: Tue, 6 Dec 2016 04:58:14 +0100
From: Bastian Bloessl <address@hidden>
To: sumit kumar <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Reg: gr-ieee 802.11 and wireshark
settings for commercial NIC
Message-ID: <71111109-DCE6-40F3-9829-address@hidden >
Content-Type: text/plain; charset="utf-8"
Hi,
> On 5 Dec 2016, at 23:08, sumit kumar <address@hidden> 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 <phyname> set channel <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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/fef1db88/ attachment.html
------------------------------
Message: 10
Date: Tue, 6 Dec 2016 05:21:48 +0100
From: Bastian Bloessl <address@hidden>
To: sumitstop <address@hiddenin >
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] gr-ieee 802.11 and integration with
linux stack (wpa_supplicant)
Message-ID: <93295A4C-FA01-4B45-80B3-address@hidden >
Content-Type: text/plain; charset="utf-8"
Hi,
> On 5 Dec 2016, at 21:10, sumitstop <address@hiddenin > 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_ <https://wireless.wiki.kernel.hwsim org/en/users/drivers/mac80211_ >). Then the higher layer stuff like hostap and wpa_supplicant would just work out of the box.hwsim
Best,
Bastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/ccab2740/ attachment.html
------------------------------
Message: 11
Date: Tue, 6 Dec 2016 13:35:36 +0200
From: Manolis Surligas <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] gr-ieee 802.11 and integration with
linux stack (wpa_supplicant)
Message-ID: <641014fa-e1ef-6379-bccc-address@hidden >
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi all,
we have done it two years ago as part of my master thesis and it works
like a charm! The SDR IEEE 802.11 implementation can be configured as AP
using hostapd or adhoc via the network manager. We had some problems
making it work as a normal client however.
Our approach has a kernel module that provides an interface for
receiving and sending PDUs from/to SDR PHY. Internally, the kernel
module communicates with the mac80211 for passing around these PDUs.
On 12/06/2016 06:21 AM, Bastian Bloessl wrote:
> Hi,
>
>> On 5 Dec 2016, at 21:10, sumitstop <address@hiddenin
>> <mailto:address@hiddeniiit.ac.in >> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
/* Code is the Law */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/a6e75b15/ attachment.html
------------------------------
Message: 12
Date: Tue, 6 Dec 2016 12:47:09 +0100
From: Bastian Bloessl <address@hidden>
To: Manolis Surligas <address@hidden>, address@hidden
Subject: Re: [Discuss-gnuradio] gr-ieee 802.11 and integration with
linux stack (wpa_supplicant)
Message-ID: <a9865420-198a-f801-c459-address@hidden >
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
On 12/06/2016 12:35 PM, Manolis Surligas wrote:
> Hi all,
>
> we have done it two years ago as part of my master thesis and it works
> like a charm! The SDR IEEE 802.11 implementation can be configured as AP
> using hostapd or adhoc via the network manager. We had some problems
> making it work as a normal client however.
>
> Our approach has a kernel module that provides an interface for
> receiving and sending PDUs from/to SDR PHY. Internally, the kernel
> module communicates with the mac80211 for passing around these PDUs.
wow that sounds cool. Would it be possible to share the code? I would
love to give this a try.
Best,
Bastian
>
> On 12/06/2016 06:21 AM, Bastian Bloessl wrote:
>> Hi,
>>
>>> On 5 Dec 2016, at 21:10, sumitstop <address@hiddenin
>>> <mailto:address@hiddeniiit.ac.in >> 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
------------------------------
Message: 13
Date: Tue, 6 Dec 2016 07:08:53 -0500
From: Gregory Ratcliff <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] OS X Sierra complete build
Message-ID: <1E5F550F-D7E3-4E0A-8DAE-address@hidden >
Content-Type: text/plain; charset="utf-8"
Just following instructions here: http://gnuradio.org/redmine/projects/gnuradio/wiki/ <http://gnuradio.org/redmine/MacInstall projects/gnuradio/wiki/ > precisely for the first time with a new Mac.MacInstall
Xcode went well
XQuartz went well
Command line tools went well
sudo port install gnuradio
? lots of lines of success
Then end the end
---> Fetching archive for doxygen
---> Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from https://packages.macports.org/ doxygen
---> Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from http://sea.us.packages. macports.org/macports/ packages/doxygen
---> Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from http://mse.uk.packages. macports.org/sites/packages. macports.org/doxygen
---> Fetching distfiles for doxygen
---> Attempting to fetch doxygen-1.8.10.src.tar.gz from https://distfiles.macports.org/doxygen
---> Verifying checksums for doxygen
---> Extracting doxygen
---> Applying patches to doxygen
---> Configuring doxygen
---> Building doxygen
Error: org.macports.build for port doxygen returned: command execution failed
Has anyone else encountered oxygen build issues?
Thank you,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/82276f57/ attachment.html
------------------------------
Message: 14
Date: Tue, 6 Dec 2016 07:21:25 -0500
From: Michael Dickens <address@hidden>
To: Gregory Ratcliff <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] OS X Sierra complete build
Message-ID: <7FA2CBE0-6082-44ED-A970-address@hidden >
Content-Type: text/plain; charset="utf-8"
Hi Greg - what usually works is the following:
{{{
sudo port clean doxygen
sudo port install doxygen
sudo port clean gnuradio
sudo port install gnuradio
}}}
If that fails, email me off-list & I'll help debug. - MLD
> On Dec 6, 2016, at 7:08 AM, Gregory Ratcliff <address@hidden> wrote:
>
> Just following instructions here: http://gnuradio.org/redmine/projects/gnuradio/wiki/ precisely for the first time with a new Mac.MacInstall
>
> Xcode went well
> XQuartz went well
> Command line tools went well
> sudo port install gnuradio
> ? lots of lines of success
>
> Then end the end
>
> ---> Fetching archive for doxygen
> ---> Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from https://packages.macports.org/ doxygen
> ---> Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from http://sea.us.packages. macports.org/macports/ packages/doxygen
> ---> Attempting to fetch doxygen-1.8.10_2.darwin_16.x86_64.tbz2 from http://mse.uk.packages. macports.org/sites/packages. macports.org/doxygen
> ---> Fetching distfiles for doxygen
> ---> Attempting to fetch doxygen-1.8.10.src.tar.gz from https://distfiles.macports.org/doxygen
> ---> Verifying checksums for doxygen
> ---> Extracting doxygen
> ---> Applying patches to doxygen
> ---> Configuring doxygen
> ---> Building doxygen
> Error: org.macports.build for port doxygen returned: command execution failed
>
> Has anyone else encountered oxygen build issues?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/f1356e57/ attachment.html
------------------------------
Message: 15
Date: Tue, 6 Dec 2016 14:37:24 +0200
From: Meelis N?mm <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] rx_time tag after drop
Message-ID:
<CAEMOa89qXfy2eX8jRNOR_vYfP82hSOMG1T8Kge35wGz=qh_dDA@ mail.gmail.com >
Content-Type: text/plain; charset="utf-8"
>
> > 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?
I mean that in GnuRadio, in general, time is represented by a pair of
values, t_0 (absolute time of the first sample) and the sample number or
the Offset of the given sample i.e.
Offset: 0 Source: gr uhd usrp source1 Key: rx_time
Value: {1480518095 0.75052}
Offset: 17461752 Source: gr uhd usrp source1 Key: rx_time Value:
{1480518097 0.497203}
I will try to illustrate my previous question.
Lets assume that t_0 = 0.0. At first we receive 100 000 samples correctly.
Then a UDP package with 500 samples is dropped by the UHD driver. Now the
question is what will be the values in the inserted Tag:
a) Offset: 100 501 Key: rx_time Value: {100 501 / F_sample} (timestamp
taken from the received UDP package)
b) Offset: 100 001 Key: rx_time Value: {100 501 / F_sample} (timestamp
taken from the received UDP package)
In case of a) the original value pair t_0 + Offset gives the correct
absolute time, but in reality less samples than the Offset value were
received. In case of b) it does not, but the Offset reflects the actual
number of samples received.
Sorry for dragging this topic for so long.
Meelis
On Mon, Dec 5, 2016 at 7:32 PM, Martin Braun <address@hidden> wrote:
> 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 <address@hidden
> > <mailto:address@hidden>> 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 <
> address@hidden <mailto:address@hidden>
> > > <mailto:address@hidden <mailto:address@hidden>>>
> 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
> > <https://github.com/EttusResearch/uhd/tree/maint >
> > > <https://github.com/EttusResearch/uhd/tree/maint
> > <https://github.com/EttusResearch/uhd/tree/maint >>
> > >
> > > Thanks,
> > > Derek
> > >
> > > On Thu, Dec 1, 2016 at 1:42 AM, Meelis N?mm <
> address@hidden <mailto:address@hidden>
> > > <mailto:address@hidden <mailto:address@hidden>>>
> > 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. There might be more places in the code
> that
> > > mishandle the rx_time tags after drops. I understand that
> > drops
> > > should be avoided, but still I think it is crucial that
> > they are
> > > correctly handled.
> > >
> > >
> > ------------------------------------------------------------
> ---------
> > >
> > > Tag Debug:
> > > Input Stream: 00
> > > Offset: 0 Source: gr uhd usrp source1 Key: rx_time
> > > Value: {1480518095 0 <tel:1480518095%200>.75052}
> > > Offset: 0 Source: gr uhd usrp source1 Key: rx_rate
> > > Value: 1e+07
> > > Offset: 0 Source: gr uhd usrp source1 Key: rx_freq
> > > Value: 1.56e+08
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > > D
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > > Tag Debug:
> > > Input Stream: 00
> > > Offset: 17461752 Source: gr uhd usrp source1 Key:
> > rx_time
> > > Value: {1480518097 0.497203}
> > > Offset: 17461752 Source: gr uhd usrp source1 Key:
> > rx_rate
> > > Value: 1e+07
> > > Offset: 17461752 Source: gr uhd usrp source1 Key:
> > rx_freq
> > > Value: 1.56e+08
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > > D
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > > Tag Debug:
> > > Input Stream: 00
> > > Offset: 17471916 Source: gr uhd usrp source1 Key:
> > rx_time
> > > Value: {1480518097 0.496695}
> > > Offset: 17471916 Source: gr uhd usrp source1 Key:
> > rx_rate
> > > Value: 1e+07
> > > Offset: 17471916 Source: gr uhd usrp source1 Key:
> > rx_freq
> > > Value: 1.56e+08
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > > D
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > > Tag Debug:
> > > Input Stream: 00
> > > Offset: 17476998 Source: gr uhd usrp source1 Key:
> > rx_time
> > > Value: {1480518097 0.498219}
> > > Offset: 17476998 Source: gr uhd usrp source1 Key:
> > rx_rate
> > > Value: 1e+07
> > > Offset: 17476998 Source: gr uhd usrp source1 Key:
> > rx_freq
> > > Value: 1.56e+08
> > >
> > ------------------------------------------------------------
> ----------
> > >
> > >
> > > With regards
> > > Meelis
> > >
> > > [1]
> > >
> > http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx-
> time-tags-while-receiving-continuously-tt44492.html# a44515
> > <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx-
> time-tags-while-receiving-continuously-tt44492.html# a44515>
> > >
> > <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx-
> time-tags-while-receiving-continuously-tt44492.html# a44515
> > <http://gnuradio.4.n7.nabble.com/How-to-get-multipe-rx-
> time-tags-while-receiving-continuously-tt44492.html# a44515>>
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden <mailto:address@hiddenorg >
> > <mailto:address@hiddenorg <mailto:address@hiddenorg >>
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > <https://lists.gnu.org/mailman/listinfo/discuss- >gnuradio
> > > <https://lists.gnu.org/mailman/listinfo/discuss- gnuradio
> > <https://lists.gnu.org/mailman/listinfo/discuss- >>gnuradio
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden <mailto:address@hiddenorg >
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > <https://lists.gnu.org/mailman/listinfo/discuss- >gnuradio
> > >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden <mailto:address@hiddenorg >
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > <https://lists.gnu.org/mailman/listinfo/discuss- >gnuradio
> >
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/01a4f208/ attachment.html
------------------------------
Message: 16
Date: Tue, 6 Dec 2016 11:17:48 -0500
From: Dave NotTelling <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Max PMT Size
Message-ID:
<CAK6GVuPW5xfH4R96EBTtR61bUVB3address@hidden >gmail.com
Content-Type: text/plain; charset="utf-8"
I seem to remember asking this question once before and being told that the
only way to increase the max size of a PMT object is to set a define in a
header file before compilation. Is this size limit only applicable to the
PDU to Tagged Stream block? Can a PMT output to another PMT input be
whatever size it wants to be?
Also, is there a way to programmatically get the max possible buffer size?
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/962827a7/ attachment.html
------------------------------
Message: 17
Date: Tue, 6 Dec 2016 11:48:01 -0500
From: devin kelly <address@hidden>
To: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Segfault with
volk_32fc_32f_dot_prod_32fc_a_avx
Message-ID:
<CAANLyuahuZT-GyKaBJ3V+JWS-wE-address@hidden >gmail.com
Content-Type: text/plain; charset="utf-8"
OK, I tried a brand new GR/Volk install and still had the same problem. So
no problem with re-linking Volk to GR. Could this be an issue with Volk on
GCC 4.8.5? The newest GCC is 6.2 so 4.8.5 is pretty old, though the newest
for Red Hat 7. Is there any way to reconfigure volk to not use
volk_32fc_32f_dot_prod_32fc_a_avx?
Here's volk-config-info:
$ volk-config-info --all --prefix --cc --cflags --avail-machines --machine
--alignment --malloc
/local_disk/spectrum_challenge
cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software see the source for copying conditions. There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/usr/bin/cc::: -Wall
/usr/bin/c++::: -Wall
generic_orc:::GNU:::-g -Wall
sse2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2
sse3_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3
ssse3_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
sse4_a_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a
-mpopcnt
sse4_1_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1
sse4_2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt
avx_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt -mavx
avx2_64_mmx_orc:::GNU:::-g -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_ orc;sse4_a_64_mmx_orc;sse4_1_ 64_mmx_orc;sse4_2_64_mmx_orc; avx_64_mmx_orc;avx2_64_mmx_ orc;
generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_ orc;sse4_1_64_mmx_orc;sse4_2_ 64_mmx_orc;avx_64_mmx_orc; avx2_64_mmx_orc;
avx2_64_mmx_orc
Alignment in bytes: 32
Used malloc implementation: posix_memalign
Thanks again for any help,
Devin
On Fri, Dec 2, 2016 at 10:04 AM, Marcus M?ller <address@hidden>
wrote:
> Oh, that's pretty interesting! Well, no misconfiguration should segfault,
> so I'm a bit stumped at the moment.
>
> On 12/01/2016 06:14 PM, devin kelly wrote:
>
> Marcus,
>
> Thanks for taking the time. It is possible I re-installed a new version
> of VOLK. I'll try a fresh build and see what that gets me.
>
> I also should have mentioned that the filter works OK for a while then
> segfaults. A couple of packets always pass through the clock sync block
> I'm using before I get the segfault. Finally, the segfault occurs in the
> polyphase clock sync block, do you think I could have mis-configured the
> block in some way that will get me this error? I think the PF clock sync
> block is pretty popular so if there's a bug in that block that's causing
> this I'd be surprised.
>
> Devin
>
> On Thu, Dec 1, 2016 at 11:47 AM, Marcus M?ller <address@hidden>
> wrote:
>
>> Hi Devin,
>>
>> I don't think it's a kernel problem ? all your calculations happen in
>> userland, and the kernel has not much to say with respect to the
>> instructions used.
>>
>> The most common reason for this kind of misbehaviour is in fact a problem
>> with how the application (in this case, your GNU Radio application's block)
>> calls into the library function (in this case the VOLK dot product).
>>
>> Is it possible that for some reason, GNU Radio used a previous version of
>> VOLK when you linked it, and then the new version of VOLK was installed?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 12/01/2016 05:23 PM, devin kelly wrote:
>>
>> Hello,
>>
>> I'm having a problem with the above VOLK function segfaulting. I don't
>> think I'm passing any incorrect values to VOLK. My problem could be that
>> I'm on RHEL7 with (obviously) an older kernel:
>>
>> $ uname -a
>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
>> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> I'm on VOLK 1.3 and GR 3.7.10.1.
>>
>> it segfaults here:
>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/ vol
>> k_32fc_32f_dot_prod_32fc.h#L119
>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid. GR passes this
>> pointer to VOLK so maybe it's a GR problem?
>>
>> I've copied the output of a GDB session and my CPU info below.
>>
>> Thanks for any help,
>> Devin
>>
>>
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0 0x00007fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin. h:835
>> 835 return *(__m256 *)__P;
>> Missing separate debuginfos, use: debuginfo-install
>> python-2.7.5-48.el7.x86_64
>> (gdb) bt
>> #0 0x00007fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
>> (__P=0x7fea5c3014c0) at /usr/lib/gcc/x86_64-redhat-lin
>> ux/4.8.5/include/avxintrin.h:835
>> #1 0x00007fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
>> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_ 32f_
>> dot_prod_32fc.h:119
>> #2 0x00007fea6661d88f in gr::filter::kernel::fir_filter
>> _ccf::filter(std::complex<float> const*) () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1. so.0.0.0
>> #3 0x00007fea66c01d01 in gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
>> std::vector<int, std::allocator<int> >&, std::vector<void const*,
>> std::allocator<void const*> >&, std::vector<void*, std::allocator<void*>
>> >&) ()
>> at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.s
>> o.0.0.0
>> #4 0x00007fea7b73fe10 in gr::block_executor::run_one_iteration() () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1. so.0.0.0
>> #5 0x00007fea7b781120 in gr::tpb_thread_body::tpb_threa
>> d_body(boost::shared_ptr<gr::block>, int) () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1. so.0.0.0
>> #6 0x00007fea7b774821 in boost::detail::function::void_
>> function_obj_invoker0<gr::thread::thread_body_wrapper< gr::tpb_container>,
>> void>::invoke(boost::detail::function::function_buffer&) () at
>> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1. so.0.0.0
>> #7 0x00007fea7b725ef0 in boost::detail::thread_data<boost::function0<void>
>> >::run() () at /local_disk/gr_3.7.10.1/lib64/
>> libgnuradio-runtime-3.7.10.1.so.0.0.0
>> #8 0x00007fea7a22427a in thread_proxy () at
>> /lib64/libboost_thread-mt.so.1.53.0
>> #9 0x00007fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
>> #10 0x00007fea9571973d in clone () at /lib64/libc.so.6
>> (gdb) print __P
>> $1 = (const float *) 0x7fea5c3014c0
>> (gdb) print *__P
>> Cannot access memory at address 0x7fea5c3014c0
>> (gdb) print *(__m256 *)__P
>> Cannot access memory at address 0x7fea5c3014c0
>> (gdb) f 1
>> #1 volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160,
>> input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
>> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_ 32f_
>> dot_prod_32fc.h:119
>> 119 a0Val = _mm256_load_ps(aPtr);
>> (gdb) info locals
>> number = 0
>> sixteenthPoints = 2
>> res = {-1.30492652e+29, 0.0779444203}
>> realpt = 0x7fea57ffde50
>> imagpt = 0x7fea57ffde54
>> aPtr = 0x7fea5c3014c0
>> bPtr = 0x3671a00
>> a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127,
>> -0.869615495, -0.869560063, -0.887507021, -0.885902643}
>> a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977,
>> -0.0328192525, -0.0346645005, 0.376206338, 0.374125361}
>> a2Val = {0.711783648, 0.711464763, 0.931477308, 0.933318734, 1.01744843,
>> 1.01973152, 0.954917312, 0.955377996}
>> a3Val = {0.734342158, 0.732418418, 0.374049634, 0.371605545,
>> -0.0585254543, -0.0588675328, -0.461206883, -0.458686352}
>> b0Val = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
>> 0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293}
>> b1Val = {-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193,
>> 0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
>> b2Val = {0, 0, 0.22138992, 0.22138992, -0.0485430211, -0.0485430211,
>> -0.00614725193, -0.00614725193}
>> b3Val = {0.0158917159, 0.0158917159, -0.00727195293, -0.00727195293,
>> -0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694}
>> x0Val = {0.0023738991, -0.00534401694, 0.00242348039, 0.00727195293,
>> -0.0158917159, 0.00614725193, 0.0485430211, -0.22138992}
>> x1Val = {0, 0.22138992, -0.0485430211, -0.00614725193, 0.0158917159,
>> -0.00727195293, -0.00242348039, 0.00534401694}
>> x0loVal = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
>> -0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193}
>> x0hiVal = {0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293,
>> 0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
>> x1loVal = {0, 0, 0.22138992, 0.22138992, 0.0158917159, 0.0158917159,
>> -0.00727195293, -0.00727195293}
>> x1hiVal = {-0.0485430211, -0.0485430211, -0.00614725193, -0.00614725193,
>> -0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694}
>> c0Val = {-0.00155906542, -0.00156219525, 0.00406643841, 0.00407376606,
>> -0.00210749614, -0.0021073618, -0.00645390945, -0.0064422423}
>> c1Val = {0.0118262777, 0.011799735, -0.00269082887, -0.00269069499,
>> -0.00159314566, -0.00168271956, -0.0832882896, -0.082827583}
>> c2Val = {0, 0, 0.206219688, 0.206627354, -0.0493900217, -0.0495008491,
>> -0.00587011734, -0.00587294903}
>> c3Val = {0.0116699571, 0.0116393855, -0.00272007124, -0.00270229811,
>> 0.000141835291, 0.000142664314, -0.00246469746, -0.00245122775}
>> dotProdVal0 = {0, 0, 0, 0, 0, 0, 0, 0}
>> dotProdVal1 = {0, 0, 0, 0, 0, 0, 0, 0}
>> dotProdVal2 = {0, 0, 0, 0, 0, 0, 0, 0}
>> dotProdVal3 = {0, 0, 0, 0, 0, 0, 0, 0}
>> dotProductVector = {0.0218032673, 0.0217418969, 0.204074427, 0.204509094,
>> -0.0519821495, -0.0521854945, -0.0983558819, -0.097870864}
>> (gdb) print *aPtr
>> Cannot access memory at address 0x7fea5c3014c0
>>
>>
>>
>>
>> $ lscpu
>> Architecture: x86_64
>> CPU op-mode(s): 32-bit, 64-bit
>> Byte Order: Little Endian
>> CPU(s): 4
>> On-line CPU(s) list: 0-3
>> Thread(s) per core: 2
>> Core(s) per socket: 2
>> Socket(s): 1
>> NUMA node(s): 1
>> Vendor ID: GenuineIntel
>> CPU family: 6
>> Model: 61
>> Model name: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
>> Stepping: 4
>> CPU MHz: 2038.664
>> BogoMIPS: 5187.61
>> Virtualization: VT-x
>> L1d cache: 32K
>> L1i cache: 32K
>> L2 cache: 256K
>> L3 cache: 4096K
>> NUMA node0 CPU(s): 0-3
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing address@hiddenorghttps://lists.gnu.org/ mailman/listinfo/discuss- gnuradio
>>
>> _______________________________________________ Discuss-gnuradio mailing
>> list address@hidden https://lists.gnu.org/mailman/
>> listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing address@hiddenorghttps://lists.gnu.org/ mailman/listinfo/discuss- gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ >attachments/20161206/d8ce9307/ attachment.html
------------------------------
Subject: Digest Footer
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
End of Discuss-gnuradio Digest, Vol 169, Issue 6
************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |