Thank you; that is what I wanted to know. On Wed, Jun 7, 2017 at 9:00 AM, <discuss-gnuradio-requ...@gnu.org> wrote:
> Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > 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 > discuss-gnuradio-requ...@gnu.org > > You can reach the person managing the list at > discuss-gnuradio-ow...@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > > 1. Re: [GSoC 17] DAB: updates of the week (Benny Alexandar) > 2. Re: [GSoC 17] DAB: updates of the week (Marcus M?ller) > 3. ninput_items_required=1024 (G Reina) > 4. Re: ninput_items_required=1024 (G Reina) > 5. Re: [GSoC 17] DAB: updates of the week (John Ackermann N8UR) > 6. Re: why can't use iwconfig when I run the gr-ieee802-11 > (Bastian Bloessl) > 7. Re: [GSoC 17] DAB: updates of the week (John Ackermann N8UR) > 8. symbol already exists: cannot reuse! runtime error > (Eugene Grayver) > 9. Re: why can't use iwconfig when I run the gr-ieee802-11 > (zhan siyu) > 10. 1,024 in - 3 out (G Reina) > 11. Re: why can't use iwconfig when I run the gr-ieee802-11 > (Bastian Bloessl) > 12. Handling more than 3 output streams (Vipin Sharma) > 13. Re: Handling more than 3 output streams (Moritz Luca Schmid) > 14. Re: Rational Resampler no output. (Anon Lister) > 15. USRP sink clock rate (???) > 16. Re: USRP sink clock rate (Derek Kozel) > 17. Measure the Distance to another 802.11 device (Florian Adamsky) > 18. Re: why can't use iwconfig when I run the gr-ieee802-11 > (zhan siyu) > 19. Re: Measure the Distance to another 802.11 device (Marcus M?ller) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 6 Jun 2017 16:02:32 +0000 > From: Benny Alexandar <ben.a...@outlook.com> > To: Moritz Luca Schmid <luca.moritz.sch...@gmail.com>, "GNURadio > Discussion List" <discuss-gnuradio@gnu.org> > Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > Message-ID: > <HK2PR02MB13304001D3CCC4F3834584E08BCB0@HK2PR02MB1330. > apcprd02.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi Luca, > > > Nice to see your progress so far. Once you have the > DAB receiver audio listening in place, I would > suggest to have an audio synchronization for continuous > playback without any buffer overflow or under-runs. > > DAB+ audio super frame length is 120ms according to DAB+ > standard (ETSI TS 102 563). Each audio super frame is > carried in five consecutive logical DAB frames. > Which means 120ms of audio is mapped to 5 DAB frames. > > If I add a timestamp at the receiver when the first DAB frame > sample arrives, I can check the max latency when it comes to > audio renderer, I mean after buffering to adjust the variable > decoding time of compressed audio. > > t_D = t_A - t_B , > where, > t_A = time at audio out > t_B = time at input baseband sample. > t_D = maximum system delay. > > The difficulty is to estimate the slow clock drift correctly > and separate it from the short-time channel/decoding jitter. > > Add a delay to buffer audio at audio out, say D, which is larger > than max system delay. Whenever the audio reaches audio out, check the > delay to separate the clock drift. > > drift = t_D - D > > Please let me know if you need any more details. > > -ben > > > > > > > > > > > > > ________________________________ > From: Discuss-gnuradio <discuss-gnuradio-bounces+ben.alex= > outlook....@gnu.org> on behalf of Moritz Luca Schmid < > luca.moritz.sch...@gmail.com> > Sent: Friday, May 26, 2017 6:19:31 PM > To: GNURadio Discussion List > Subject: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > > > Hi everyone, > > I just published my latest updates of my DAB project in a new blog post< > https://dabtransceiver.wordpress.com/>. > > This week, I created a source block for the Fast Information Channel and > started to build a reception chain for the Main Service Channel (where the > audio data is transmitted). > > Read more about it in my post. > > > Cheers > > Luca > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170606/bcd8ed3c/attachment.html> > > ------------------------------ > > Message: 2 > Date: Tue, 6 Jun 2017 19:10:06 +0200 > From: Marcus M?ller <marcus.muel...@ettus.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > Message-ID: <520a2557-1506-5fd3-305a-23e4207ea...@ettus.com> > Content-Type: text/plain; charset="windows-1252" > > Hi ben, > > > I love this topic of how to match hardware clocks just as much as you > do, but I personally think that solving the two-clock problem between an > SDR receiver and an audio device might be just a tiny bit out of scope > of a GSoC project on a broadcast standard implementation. Also, it's not > part of the milestones / deliverables that Luca set in cooperation with > the community, and a considerable effort, so I don't think I'd advise > Luca to do that; > however, I'd really like to see this happening in another context. Maybe > we can help /you/ get that working, preferably with an analog audio > modulation first? Also, haven't we been talking about this extensively > before? I don't see how the fact that your PC simply can't, with > sufficient accuracy, measure what you call t_A for this approach to work > without much higher-level tracking has changed. But that's a discussion > that we really shouldn't be having (again) within the context of an > unrelated GSoC project. > > > background: in digital mod, you have to recover the TX sample clock, > anyway, and then this problem boils down to matching the studio's audio > sample rate to your soundcard's sample rate. > > Studio equipment typically has rather good oscillators (I think: better > than 10ppm offset), and even the cheapest USB codec from Texas > Instruments advises you to use a <=25ppm oscillator. That leads to a > total worst-case rate offset of 35 ppm; with an 48 kHz sample clock, > that's an offset of about 0.6 Hz, or one sample every 1.68 s. Thus, meh, > assume your ALSA does 1024-sample periods, it'd take some half hour for > a single frame to go missing or accumulate. And that's not even when you > get an issue. It's just the first point that you'd actually be able to > count things worthy of being sent to the audio driver not being the > number that would be correct. > > > In analog audio modulation, you don't get the benefit of anything that > inherently transports the transmitter's sampling clock, and thus, your > SDR's frequency error can't be corrected. > > > Best regards, > > Marcus > > > On 06.06.2017 18:02, Benny Alexandar wrote: > > > > Hi Luca, > > > > > > Nice to see your progress so far. Once you have the > > DAB receiver audio listening in place, I would > > suggest to have an audio synchronization for continuous > > playback without any buffer overflow or under-runs. > > > > DAB+ audio super frame length is 120ms according to DAB+ > > standard (ETSI TS 102 563). Each audio super frame is > > carried in five consecutive logical DAB frames. > > Which means 120ms of audio is mapped to 5 DAB frames. > > > > If I add a timestamp at the receiver when the first DAB frame > > sample arrives, I can check the max latency when it comes to > > audio renderer, I mean after buffering to adjust the variable > > decoding time of compressed audio. > > > > t_D = t_A - t_B , > > where, > > t_A = time at audio out > > t_B = time at input baseband sample. > > t_D = maximum system delay. > > > > The difficulty is to estimate the slow clock drift correctly > > and separate it from the short-time channel/decoding jitter. > > > > Add a delay to buffer audio at audio out, say D, which is larger > > than max system delay. Whenever the audio reaches audio out, check the > > delay to separate the clock drift. > > > > drift = t_D - D > > > > Please let me know if you need any more details. > > > > -ben > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > *From:* Discuss-gnuradio > > <discuss-gnuradio-bounces+ben.alex=outlook....@gnu.org> on behalf of > > Moritz Luca Schmid <luca.moritz.sch...@gmail.com> > > *Sent:* Friday, May 26, 2017 6:19:31 PM > > *To:* GNURadio Discussion List > > *Subject:* [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > > > > > > Hi everyone, > > > > I just published my latest updates of my DAB project in a new blog > > post <https://dabtransceiver.wordpress.com/>. > > > > This week, I created a source block for the Fast Information Channel > > and started to build a reception chain for the Main Service Channel > > (where the audio data is transmitted). > > > > Read more about it in my post. > > > > > > Cheers > > > > Luca > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > 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/20170606/204476a8/attachment.html> > > ------------------------------ > > Message: 3 > Date: Tue, 6 Jun 2017 11:12:08 -0700 > From: G Reina <gre...@eng.ucsd.edu> > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] ninput_items_required=1024 > Message-ID: > <CAEBTegSZB3cj0f-UL+ncQRxh3Y_hQ=oAWiQ=JpqVPQQe_Sn-3g@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > I'm creating a Python block that calculates a custom FFT. I need to ensure > that I get at least 1024 data points for every input to the block. > > >From my reading, it looks like I should just be able to do this with the > forecast() function in the Python block. So I've done this: > > class blk(gr.sync_block): # other base classes are basic_block, > > decim_block, interp_block > > > > def __init__(self, bandWidthMHz=100.0): # only default arguments > here > > """arguments to this function show up as parameters in GRC""" > > gr.sync_block.__init__( > > self, > > name='test', # will show up in GRC > > in_sig=[np.complex64], > > out_sig=[np.float32] > > ) > > # if an attribute with the same name as a parameter is found, > > # a callback is registered (properties work, too). > > self.bandWidthMHz = bandWidthMHz > > self.MM = 0 > > > > def forecast(self, noutput_items, ninput_items_required=1024): > > ninput_items_required[0] = 1024 > > > > def work(self, input_items, output_items): > > if (np.shape(input_items[0])[0] < 1024): > > print(np.shape(input_items[0])) > > output_items[0] = [3.5, -1, 0, 1] > > return len(output_items[0]) > > > > According to the docs, if I set ninput_items_required[0] = 1024, then > forecast should prevent the work from being done until I have at least 1024 > input values. > > Nevertheless, the print statement I have in the work function is showing > that the program gets to the work even when the input_items[0] is much less > (e.g. 24, 102, 960) than 1024. > > Can anyone point me in the right direction? Can I just have the work > function skip execution if len(input_items[0]) < 1024? Or, will that drop > data? > > Thanks for your help. > -Tony > > p.s. I'm just doing this in a Python block from the GRC. So this is not a > custom OOT module. Does that matter? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170606/e0ee6b42/attachment.html> > > ------------------------------ > > Message: 4 > Date: Tue, 6 Jun 2017 11:30:29 -0700 > From: G Reina <gre...@eng.ucsd.edu> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] ninput_items_required=1024 > Message-ID: > <CAEBTegSNRJFGC+FXydNXrS37HnRGyWmFe3tkb=nzPk7m > wo2...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I may have just answered it. I change the sync_block to a basic_block and > it seems to be working. > > -Tony > > > On Tue, Jun 6, 2017 at 11:12 AM, G Reina <gre...@eng.ucsd.edu> wrote: > > > I'm creating a Python block that calculates a custom FFT. I need to > ensure > > that I get at least 1024 data points for every input to the block. > > > > From my reading, it looks like I should just be able to do this with the > > forecast() function in the Python block. So I've done this: > > > > class blk(gr.sync_block): # other base classes are basic_block, > >> decim_block, interp_block > >> > >> def __init__(self, bandWidthMHz=100.0): # only default arguments > here > >> """arguments to this function show up as parameters in GRC""" > >> gr.sync_block.__init__( > >> self, > >> name='test', # will show up in GRC > >> in_sig=[np.complex64], > >> out_sig=[np.float32] > >> ) > >> # if an attribute with the same name as a parameter is found, > >> # a callback is registered (properties work, too). > >> self.bandWidthMHz = bandWidthMHz > >> self.MM = 0 > >> > >> def forecast(self, noutput_items, ninput_items_required=1024): > >> ninput_items_required[0] = 1024 > >> > >> def work(self, input_items, output_items): > >> if (np.shape(input_items[0])[0] < 1024): > >> print(np.shape(input_items[0])) > >> output_items[0] = [3.5, -1, 0, 1] > >> return len(output_items[0]) > >> > > > > According to the docs, if I set ninput_items_required[0] = 1024, then > > forecast should prevent the work from being done until I have at least > 1024 > > input values. > > > > Nevertheless, the print statement I have in the work function is showing > > that the program gets to the work even when the input_items[0] is much > less > > (e.g. 24, 102, 960) than 1024. > > > > Can anyone point me in the right direction? Can I just have the work > > function skip execution if len(input_items[0]) < 1024? Or, will that drop > > data? > > > > Thanks for your help. > > -Tony > > > > p.s. I'm just doing this in a Python block from the GRC. So this is not a > > custom OOT module. Does that matter? > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170606/e2235296/attachment.html> > > ------------------------------ > > Message: 5 > Date: Tue, 6 Jun 2017 15:46:53 -0400 > From: John Ackermann N8UR <j...@febo.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > Message-ID: <b44389c8-9b9f-f2b3-07ab-18438dee9...@febo.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I don't have a view whether an audio synchronizer (is that the right > term?) is appropriate for GSoC, but it's a problem that's biting me > right now. I'm doing a multi-channel nbfm receiver with a polyphase > channelizer that feeds a bunch of power squelch/nbfm demod blocks, with > the audio streams added together, rationally resampled to theoretically > 48kHz, and then fed to an audio sink. > > With this setup, I seem to have two choices: (a) I can tell the audio > sink to block, in which case I get nice clean audio but latency of about > 5 seconds, or (b) I can say not to block, in which case I get much less > latency but also many aU underruns and audio that's very choppy. > > I wonder if I am suffering from rounding or truncation errors that's > causing the demod rate to not be quite what it should be. > > It seems that there would be use for a block that provides a combination > of buffering and a loop to measure input and consumption rates and steer > a rational resampler to correct for mismatch. I have no idea whether > that would be easy, hard, or infeasible to implement. > > (If you're interested in the app, the current under-development version > is at > https://github.com/TAPR/N8UR_GnuRadio/blob/master/multi_fm/nbfm_27ch.grc) > > John > ---- > > > On 06/06/2017 01:10 PM, Marcus M?ller wrote: > > Hi ben, > > > > > > I love this topic of how to match hardware clocks just as much as you > > do, but I personally think that solving the two-clock problem between an > > SDR receiver and an audio device might be just a tiny bit out of scope > > of a GSoC project on a broadcast standard implementation. Also, it's not > > part of the milestones / deliverables that Luca set in cooperation with > > the community, and a considerable effort, so I don't think I'd advise > > Luca to do that; > > however, I'd really like to see this happening in another context. Maybe > > we can help /you/ get that working, preferably with an analog audio > > modulation first? Also, haven't we been talking about this extensively > > before? I don't see how the fact that your PC simply can't, with > > sufficient accuracy, measure what you call t_A for this approach to work > > without much higher-level tracking has changed. But that's a discussion > > that we really shouldn't be having (again) within the context of an > > unrelated GSoC project. > > > > > > background: in digital mod, you have to recover the TX sample clock, > > anyway, and then this problem boils down to matching the studio's audio > > sample rate to your soundcard's sample rate. > > > > Studio equipment typically has rather good oscillators (I think: better > > than 10ppm offset), and even the cheapest USB codec from Texas > > Instruments advises you to use a <=25ppm oscillator. That leads to a > > total worst-case rate offset of 35 ppm; with an 48 kHz sample clock, > > that's an offset of about 0.6 Hz, or one sample every 1.68 s. Thus, meh, > > assume your ALSA does 1024-sample periods, it'd take some half hour for > > a single frame to go missing or accumulate. And that's not even when you > > get an issue. It's just the first point that you'd actually be able to > > count things worthy of being sent to the audio driver not being the > > number that would be correct. > > > > > > In analog audio modulation, you don't get the benefit of anything that > > inherently transports the transmitter's sampling clock, and thus, your > > SDR's frequency error can't be corrected. > > > > > > Best regards, > > > > Marcus > > > > > > On 06.06.2017 18:02, Benny Alexandar wrote: > >> > >> Hi Luca, > >> > >> > >> Nice to see your progress so far. Once you have the > >> DAB receiver audio listening in place, I would > >> suggest to have an audio synchronization for continuous > >> playback without any buffer overflow or under-runs. > >> > >> DAB+ audio super frame length is 120ms according to DAB+ > >> standard (ETSI TS 102 563). Each audio super frame is > >> carried in five consecutive logical DAB frames. > >> Which means 120ms of audio is mapped to 5 DAB frames. > >> > >> If I add a timestamp at the receiver when the first DAB frame > >> sample arrives, I can check the max latency when it comes to > >> audio renderer, I mean after buffering to adjust the variable > >> decoding time of compressed audio. > >> > >> t_D = t_A - t_B , > >> where, > >> t_A = time at audio out > >> t_B = time at input baseband sample. > >> t_D = maximum system delay. > >> > >> The difficulty is to estimate the slow clock drift correctly > >> and separate it from the short-time channel/decoding jitter. > >> > >> Add a delay to buffer audio at audio out, say D, which is larger > >> than max system delay. Whenever the audio reaches audio out, check the > >> delay to separate the clock drift. > >> > >> drift = t_D - D > >> > >> Please let me know if you need any more details. > >> > >> -ben > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ------------------------------------------------------------ > ------------ > >> *From:* Discuss-gnuradio > >> <discuss-gnuradio-bounces+ben.alex=outlook....@gnu.org> on behalf of > >> Moritz Luca Schmid <luca.moritz.sch...@gmail.com> > >> *Sent:* Friday, May 26, 2017 6:19:31 PM > >> *To:* GNURadio Discussion List > >> *Subject:* [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > >> > >> > >> Hi everyone, > >> > >> I just published my latest updates of my DAB project in a new blog > >> post <https://dabtransceiver.wordpress.com/>. > >> > >> This week, I created a source block for the Fast Information Channel > >> and started to build a reception chain for the Main Service Channel > >> (where the audio data is transmitted). > >> > >> Read more about it in my post. > >> > >> > >> Cheers > >> > >> Luca > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 6 Jun 2017 21:23:05 +0100 > From: Bastian Bloessl <m...@bastibl.net> > To: zhan siyu <zhansyu...@gmail.com>, discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the > gr-ieee802-11 > Message-ID: <d76f1dcb-4431-0849-7c6a-5c1a01d05...@bastibl.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > > On 06/06/2017 03:55 PM, zhan siyu wrote: > > Hi all, > > > > I just found I can't use the iwconfig tap0 rate 20M to setup the > > bandwidth of the tap0. The error message is : > > > > Error for wireless request "Set Bit Rate" (8B20) : > > SET failed on device tap0 ; Operation not supported. > > > > But in their video , it can be set in this way. May I know how to solve > it ? > > The WiFi transceiver is attached to the tun/tap interface, which is a > virtual Ethernet device. This device doesn't support WiFi-specific > configuration through iwconfig. > > If you wanted this level of integration, you would have to write a > kernel module that attaches the transceiver to a virtual WiFi card. > > Some group already did that, but they didn't release the source code. > > Best, > Bastian > > > > ------------------------------ > > Message: 7 > Date: Tue, 6 Jun 2017 17:17:50 -0400 > From: John Ackermann N8UR <j...@febo.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > Message-ID: <44ed7cf1-9584-88e7-e5ee-6e084e62f...@febo.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Benny -- > > As I mentioned in another message, I'm struggling with the RF-audio > interface now. Do you have any example code for your suggestion that I > might play with (in my mind, the idea would be an "audio synchronizer" > block that would take input at the nominal audio rate and output at the > actual rate, correcting for clock error to keep the stream flowing > smoothly). > > If a prototype exists, I'd be happy to plug it into my current app to > see what happens. > > John > ---- > > On 06/06/2017 12:02 PM, Benny Alexandar wrote: > > Hi Luca, > > > > > > Nice to see your progress so far. Once you have the > > DAB receiver audio listening in place, I would > > suggest to have an audio synchronization for continuous > > playback without any buffer overflow or under-runs. > > > > DAB+ audio super frame length is 120ms according to DAB+ > > standard (ETSI TS 102 563). Each audio super frame is > > carried in five consecutive logical DAB frames. > > Which means 120ms of audio is mapped to 5 DAB frames. > > > > If I add a timestamp at the receiver when the first DAB frame > > sample arrives, I can check the max latency when it comes to > > audio renderer, I mean after buffering to adjust the variable > > decoding time of compressed audio. > > > > t_D = t_A - t_B , > > where, > > t_A = time at audio out > > t_B = time at input baseband sample. > > t_D = maximum system delay. > > > > The difficulty is to estimate the slow clock drift correctly > > and separate it from the short-time channel/decoding jitter. > > > > Add a delay to buffer audio at audio out, say D, which is larger > > than max system delay. Whenever the audio reaches audio out, check the > > delay to separate the clock drift. > > > > drift = t_D - D > > > > Please let me know if you need any more details. > > > > -ben > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > *From:* Discuss-gnuradio > > <discuss-gnuradio-bounces+ben.alex=outlook....@gnu.org> on behalf of > > Moritz Luca Schmid <luca.moritz.sch...@gmail.com> > > *Sent:* Friday, May 26, 2017 6:19:31 PM > > *To:* GNURadio Discussion List > > *Subject:* [Discuss-gnuradio] [GSoC 17] DAB: updates of the week > > > > > > Hi everyone, > > > > I just published my latest updates of my DAB project in a new blog post > > <https://dabtransceiver.wordpress.com/>. > > > > This week, I created a source block for the Fast Information Channel and > > started to build a reception chain for the Main Service Channel (where > > the audio data is transmitted). > > > > Read more about it in my post. > > > > > > Cheers > > > > Luca > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ------------------------------ > > Message: 8 > Date: Wed, 7 Jun 2017 01:08:21 +0000 > From: Eugene Grayver <eugene.gray...@aero.org> > To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> > Subject: [Discuss-gnuradio] symbol already exists: cannot reuse! > runtime error > Message-ID: > <BY2PR09MB0965C99ADD1D91A859FA5C49ECC80@BY2PR09MB0965. > namprd09.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > I have a rather complicated GR application. I create (Python, w/out grc) > multiple top_blocks, each containing dozens of blocks. To make things even > more complicated, the flowgraphs are created in stages - using runtime > reconfiguration to add more blocks. > > Everything works fine until I reach some critical size (apparently). Then > I get an error: 'symbol already exists cannot reuse' It has something to > do with registering a block name in 'block_registry::register_ > symbolic_name' > > I experience this error with both versions 3.7.9.2 and 3.7.11. > > I am at a loss on how to debug this problem. Reviewing the code seems OK > - the thread locks look good. I have no idea how a block with the same > name can show up twice. Is this due to multiple top_block instances? Due > to runtime reconfig? > > Ideas? > > _______________________ > Eugene Grayver, Ph.D. > Aerospace Corp., Sr. Eng. Spec. > Tel: 310.336.1274 > ________________________ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170607/33bf626b/attachment.html> > > ------------------------------ > > Message: 9 > Date: Wed, 7 Jun 2017 10:04:40 +0800 > From: zhan siyu <zhansyu...@gmail.com> > To: Bastian Bloessl <m...@bastibl.net> > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the > gr-ieee802-11 > Message-ID: > <CAGNex4jsMd9WZkn7p4Fe-gPwxow1T2N+-4iU5gV+AyM3nkWpQw@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks. I just wonder why. Because I meet some performance problem. I > thought it maybe caused by my misconfiguration of the gr-ieee802-11 code. > Now, it seems not. > > However, theoretically, as my current sample rate is 10M and BPSK. So the > coding rate should be 10M/2 = 5M b/s. The throughtput should be around 5M/8 > = 625K B/s. Assuming the 12% head cost, so the data throughput should be > 625 * 88 % = 550K B/s. But as my experiment shows, the throughput is only > 150K B/s. > > I'm new to the communication. Is my calculation right ? If it were right, > then what might cause the gap? > > One more question, I didn't run the volk_profile. Does it matter? > > Best regards. > > Siyu > > > 2017-06-07 4:23 GMT+08:00 Bastian Bloessl <m...@bastibl.net>: > > > Hi, > > > > On 06/06/2017 03:55 PM, zhan siyu wrote: > > > >> Hi all, > >> > >> I just found I can't use the iwconfig tap0 rate 20M to setup the > >> bandwidth of the tap0. The error message is : > >> > >> Error for wireless request "Set Bit Rate" (8B20) : > >> SET failed on device tap0 ; Operation not supported. > >> > >> But in their video , it can be set in this way. May I know how to solve > >> it ? > >> > > > > The WiFi transceiver is attached to the tun/tap interface, which is a > > virtual Ethernet device. This device doesn't support WiFi-specific > > configuration through iwconfig. > > > > If you wanted this level of integration, you would have to write a kernel > > module that attaches the transceiver to a virtual WiFi card. > > > > Some group already did that, but they didn't release the source code. > > > > Best, > > Bastian > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170607/2083e1f0/attachment.html> > > ------------------------------ > > Message: 10 > Date: Tue, 6 Jun 2017 21:08:34 -0700 > From: G Reina <gre...@eng.ucsd.edu> > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] 1,024 in - 3 out > Message-ID: > <CAEBTegT92t3fUc_eotaBtK5ScGvNWSJp=xQBkr630tmnE > hg...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I'm trying to implement a Python block that will take a signal (complex64 > array of 1,024 values) and return a float32 array that includes the max, > min, and mean of the norm for the complex values. > > So something with an input array of 1,024 complex elements and an output > array of 3 float elements. From my reading so far, I think I can use an > embedded basic Python block: > > class blk(gr.basic_block): # other base classes are basic_block, > > decim_block, interp_block > > """Embedded Python Block example""" > > > > def __init__(self, example_param=1.0): # only default arguments here > > """arguments to this function show up as parameters in GRC""" > > gr.basic_block.__init__( > > self, > > name='Embedded Python Block', # will show up in GRC > > in_sig=[np.complex64], > > out_sig=[np.float32] > > ) > > # if an attribute with the same name as a parameter is found, > > # a callback is registered (properties work, too). > > self.example_param = example_param > > > > def forecast(self, noutput_items, ninput_items_required=1024): > > for i in range(len(ninput_items_required)): > > ninput_items_required[i] = 1024 > > > > def general_work(self, input_items, output_items): > > > > output_items[0] = np.zeros(3) > > output_items[0][:] = [np.min(np.abs(input_items[0])), > > np.max(np.abs(input_items[0])), np.mean(np.abs(input_items[0]))] > > > > print('{}: {}'.format(len(input_items[0]), output_items[0])) > > > > return len(output_items[0]) > > > > This code runs. The print statement shows me that the data is getting in > (8,191 elements) and that it is correctly calculating the output_items[0] > vector. However, when I try to hook up the output of the block to a GRC > number sink or time scope, I don't see anything at all. So it doesn't seem > to be passing anything back for another block to use. > > Is there a better way for me to do this? My intention is to turn this > simple block into a more complicated block that finds open channels from a > complex spectrum. So I'd be taking a 1,024 complex input and returning an > output with the open center frequency, bandwidth, and probability of being > unoccupied. Maybe the block can just pass messages back instead of an array > of values?? > > Thanks. > -Tony > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170606/3c5cbdf5/attachment.html> > > ------------------------------ > > Message: 11 > Date: Wed, 7 Jun 2017 07:02:31 +0100 > From: Bastian Bloessl <m...@bastibl.net> > To: zhan siyu <zhansyu...@gmail.com> > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the > gr-ieee802-11 > Message-ID: <9eff9bd8-e09f-3b9f-8180-605d15b1c...@bastibl.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > > On 06/07/2017 03:04 AM, zhan siyu wrote: > > Thanks. I just wonder why. Because I meet some performance problem. I > > thought it maybe caused by my misconfiguration of the gr-ieee802-11 > > code. Now, it seems not. > > I'm a bit confused why the fact that the transceiver is not configured > through iwconfig ruled out any configuration issues, but great that all > seems to be set up now. > > > > > However, theoretically, as my current sample rate is 10M and BPSK. So > > the coding rate should be 10M/2 = 5M b/s. The throughtput should be > > around 5M/8 = 625K B/s. Assuming the 12% head cost, so the data > > throughput should be 625 * 88 % = 550K B/s. But as my experiment shows, > > the throughput is only 150K B/s. > > > > I'm new to the communication. Is my calculation right ? > > BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet has to be > subtracted, i.e. the actual maximum rate depends on the frame size. > > > > If it were > > right, then what might cause the gap? > > Since you don't explain what you are doing, this is very hard to tell. > You would reach this theoretical throughput only if you send frames > back-to-back (which probably only works if you pregenerate the sample > stream). But also a WiFi card will insert inter-frame space, so that the > actual throughput will not match the theoretical maximum physical layer > throughput. > > Best, > Bastian > > > > > > One more question, I didn't run the volk_profile. Does it matter? > > > > Best regards. > > > > Siyu > > > > > > 2017-06-07 4:23 GMT+08:00 Bastian Bloessl <m...@bastibl.net > > <mailto:m...@bastibl.net>>: > > > > Hi, > > > > On 06/06/2017 03:55 PM, zhan siyu wrote: > > > > Hi all, > > > > I just found I can't use the iwconfig tap0 rate 20M to setup the > > bandwidth of the tap0. The error message is : > > > > Error for wireless request "Set Bit Rate" (8B20) : > > SET failed on device tap0 ; Operation not supported. > > > > But in their video , it can be set in this way. May I know how > > to solve it ? > > > > > > The WiFi transceiver is attached to the tun/tap interface, which is > > a virtual Ethernet device. This device doesn't support WiFi-specific > > configuration through iwconfig. > > > > If you wanted this level of integration, you would have to write a > > kernel module that attaches the transceiver to a virtual WiFi card. > > > > Some group already did that, but they didn't release the source code. > > > > Best, > > Bastian > > > > > > -- > Dipl.-Inform. Bastian Bloessl > CONNECT Center > Trinity College Dublin > > GitHub/Twitter: @bastibl > https://www.bastibl.net/ > > > > ------------------------------ > > Message: 12 > Date: Tue, 6 Jun 2017 23:57:24 -0700 > From: Vipin Sharma <vipinsha...@photonpace.com> > To: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: [Discuss-gnuradio] Handling more than 3 output streams > Message-ID: > <CAJQb1zusxLXxMJ0J4Ff3jy+9ctGZFLvOVNBhY0c=0MK8hMovOg@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I have a custom block for which I am trying to define the io signature in > the *impl.cc file correctly. The problem is that the custom block has more > than 3 output streams. I tried make5 but got a compile error saying make5 > is not a member. After researching more, I found out that I need to use > makev instead. But I am not sure how and where to initialize the vector int > array type and then pass that variable as the third argument to the makev > function below. Here is the block of code below. For example, where do I > initialize the sizeOfInputStream vector-int array type? > > /* > * The private constructor > */ > Nulling_cc_impl::Nulling_cc_impl(int PBoostFactor, char TapSize, int > FrameSize, gr_complex *InitialTapsDb[2]) > : gr::block("Nulling_cc", > gr::io_signature::makev(5, 5, &sizeOfInputStream), > gr::io_signature::make4(4, 4, TapSize*sizeof(gr_complex), > TapSize*sizeof(gr_complex), sizeof(bool), TapSize*sizeof(gr_complex))) > {} > > Vipin > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170606/d0bd85e7/attachment.html> > > ------------------------------ > > Message: 13 > Date: Wed, 7 Jun 2017 09:19:47 +0200 > From: Moritz Luca Schmid <luca.moritz.sch...@gmail.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Handling more than 3 output streams > Message-ID: <cb16f123-9f29-5fb2-6a6a-13ced087f...@gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Vipin, > > you can find detailed information about the methods makeX to create an > i/o signature in the doxygen documentation > <https://gnuradio.org/doc/doxygen/classgr_1_1io__signature.html# > a99e0f9e8de8e7ce16ed92d9f2655e66c>. > > If you have multiple input streams with the same size, you don't have to > specify the size of each stream separately but you can simply define > their size in the last input item once (e.g. for make3 the the argument > sizeof_stream_item3: "specify the size of the items in the third and > subsequent streams"). If this is not the case and you have to define the > size for each stream separately or you have at least more than 3 > different stream sizes, you choose makev. > > You can initialize the vector sizeof_stream_items just before your > constructor. See /gr-digital constellation_receiver_cb_impl > <https://github.com/fengzhe29888/gnuradio-old/blob/master/gr-digital/lib/ > constellation_receiver_cb_impl.cc>/as > an example for that. > > > Best > > Luca > > > On 07.06.2017 08:57, Vipin Sharma wrote: > > I have a custom block for which I am trying to define the io signature > > in the *impl.cc file correctly. The problem is that the custom block > > has more than 3 output streams. I tried make5 but got a compile error > > saying make5 is not a member. After researching more, I found out that > > I need to use makev instead. But I am not sure how and where to > > initialize the vector int array type and then pass that variable as > > the third argument to the makev function below. Here is the block of > > code below. For example, where do I initialize the sizeOfInputStream > > vector-int array type? > > > > /* > > * The private constructor > > */ > > Nulling_cc_impl::Nulling_cc_impl(int PBoostFactor, char TapSize, > > int FrameSize, gr_complex *InitialTapsDb[2]) > > : gr::block("Nulling_cc", > > gr::io_signature::makev(5, 5, &sizeOfInputStream), > > gr::io_signature::make4(4, 4, > > TapSize*sizeof(gr_complex), TapSize*sizeof(gr_complex), sizeof(bool), > > TapSize*sizeof(gr_complex))) > > {} > > > > Vipin > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > 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/20170607/8383410e/attachment.html> > > ------------------------------ > > Message: 14 > Date: Wed, 7 Jun 2017 04:26:58 -0400 > From: Anon Lister <listera...@gmail.com> > To: Marcus M?ller <marcus.muel...@ettus.com> > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Rational Resampler no output. > Message-ID: > <CAMp204QG9ttezukNHogskabUr6hVj69pS5OXqDmw5DDVY-C1KQ@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > I have an AMD system with the same chip running Ubuntu 16.xx. I can > probably try to duplicate this weekend, if Cor doesn't get to it, as > another data point. > > On Jun 5, 2017 3:14 PM, "Marcus M?ller" <marcus.muel...@ettus.com> wrote: > > Hi Cor, > > Excuse the language, but faaaark. Ok, looks like we have a bug in low_pass. > Or in GCC. Or SWIG (which does the python-wrapping of the code in > firdes.cc). yay. > > So, let's narrow this down: on intel and amd64, same number of taps, right? > > Then: If I asked you to use GDB to verify the C++ low_pass function in > gr::filter::firdes::low_pass actually returned the right float values, > would you feel that, with a few hints, be able to do that? > > Best regards, > > Marcus > > On 01.06.2017 07:20, Cor Legemaat wrote: > > Hi: > > filter.firdes.low_pass get called with: > * fractional_bw = 0.4 > * trans_width = 0.1 > * mid_transition_band = 0.45 > * interpolation = 24 > > But return: (nan, <788 times nan>) > > Regards: > Cor > > On Tue, 2017-05-30 at 00:06 +0200, Marcus M?ller wrote: > > Hi Cor, > > * When using 1 as "taps" there is output. > > Aha!! > So, here's the thing: something might be going wrong in the python > code that sets up the taps automatically if you don't set them > explicitly. > Maybe you can figure out where things go wrong; the interesting part > (maybe add some `print`s here?) from [1]: > > # If we don't have user-provided taps, reduce the interp and > # decim values by the GCD (if there is one) and then define > # the taps from these new values. > if taps is None: > interpolation = interpolation // d > decimation = decimation // d > taps = design_filter(interpolation, decimation, > fractional_bw) > > and > > > def design_filter(interpolation, decimation, fractional_bw): > """ > Given the interpolation rate, decimation rate and a fractional > bandwidth, > design a set of taps. > > Args: > interpolation: interpolation factor (integer > 0) > decimation: decimation factor (integer > 0) > fractional_bw: fractional bandwidth in (0, 0.5) 0.4 works > well. (float) > Returns: > : sequence of numbers > """ > > if fractional_bw >= 0.5 or fractional_bw <= 0: > raise ValueError, "Invalid fractional_bandwidth, must be in > (0, 0.5)" > > beta = 7.0 > halfband = 0.5 > rate = float(interpolation)/float(decimation) > if(rate >= 1.0): > trans_width = halfband - fractional_bw > mid_transition_band = halfband - trans_width/2.0 > else: > trans_width = rate*(halfband - fractional_bw) > mid_transition_band = rate*halfband - trans_width/2.0 > > taps = filter.firdes.low_pass(interpolation, > # gain > interpolation, > # Fs > mid_transition_band, > # trans mid point > trans_width, > # transition width > filter.firdes.WIN_KAISER, > beta) > # beta > > return taps > > > > Best regards, > Marcus > > [1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python > /filter/rational_resampler.py > > On 29.05.2017 19:01, Cor Legemaat wrote: > > Hi: > > * The only warning is about the thread priority but that's on > both. > * Type "Complex->Complex (Complex Taps)" > * When using 1 as "taps" there is output. > > I can open it in Nemiver if I know where to put the break point... > > Regards: > Cor > > On Mon, 2017-05-29 at 11:36 +0200, Marcus M?ller wrote: > > Hi Cor, > that's kind of surprising?. My first bet is that your AMD system > is > missing some dependency that the intel system has, so that > something > goes wrong during build. But then again, you shouldn't be seeing > the > rational resampler block at all in that case. Let's head straight > to > debugging: > * Do you get any warning/console output during the execution of > that > flow graph? > * Which is the input/output type (float or complex, orange or > blue > connector in GRC, if using that) > * If in GRC: when explicitly using [1,] as "taps", do you get > output? > Best regards, > Marcus > > ? "wat?!" > > On 29.05.2017 06:35, Cor Legemaat wrote: > > Hi: > > I have 2 different hardware setup's with funtoo/gentoo and > gnuradio > installed. On the Intel system the "Rational Resampler" is > working > correctly but on the AMD system there is no output. This is on > a > flow > graph for an basic wide band fm receiver based on the USPR > 10min fm > receiver tutorial. > > AMD system: > * AMD FX(tm)-8150 Eight-Core Processor > * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3 > sse4_1 sse4_2 sse4a ssse3 xop" > > Intel system: > * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz > * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 > sse4_1 > sse4_2 > ssse3" > > Tried with different versions of GNURadio and gcc but the same > symptoms, both systems is compiled with CFLAGS="-march=native > -O2 > -pipe". At the moment it is gcc:6.3.0 and net- > wireless/gnuradio- > 3.7.11:0/3.7.11 USE="alsa analog atsc audio channels digital > doc > dtv > examples fec filter grc noaa pager performance-counters > portaudio > qt4 > uhd utils vocoder wavelet wxwidgets zeromq -fcd -jack -log -oss > -sdl {- > test} -trellis" PYTHON_TARGETS="python2_7" > > Where do I start to search? > > Regards: > Cor > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/ > mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/ > mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170607/c94fd215/attachment.html> > > ------------------------------ > > Message: 15 > Date: Wed, 7 Jun 2017 17:37:20 +0900 > From: ??? <d...@radarnspace.kr> > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] USRP sink clock rate > Message-ID: <gab5937bb407b...@radarnspace.kr> > Content-Type: text/plain; charset="utf-8" > > Hi all > > > > I'm using Ettus Research USRP device with GRC > > And I have one question > > <The "sampling rate" is the rate at which samples are passed > between the host commuter and the USRP> > <The "master_clock_rate" is the rate at which samples are > passed between FPGA and the RF front end> > > > > Is there anybody who can explain me why the clock rate on UHD:USRP sink > block > > have only 4 choice? (200, 18432, 120, 3072MHz) > > > > > > Regards > > Kim taeyeong > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170607/b4bea426/attachment.html> > > ------------------------------ > > Message: 16 > Date: Wed, 7 Jun 2017 10:29:32 +0100 > From: Derek Kozel <derek.ko...@ettus.com> > To: ??? <d...@radarnspace.kr> > Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> > Subject: Re: [Discuss-gnuradio] USRP sink clock rate > Message-ID: > <CAA+K=tuzn7L9C=v0-bMioRuVh-3PSaEr8NSE9pK=HEeXQ7dLdg@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Kim, > > The first two rates (200e6 and 184.32e6) are for the X310 which only > supports those two ADC sampling rates. The third rate (120e6) is no longer > supported, I'll get that removed. 30.72e6 is for the AD9361/AD9364 based > USRPs (B2x0, E310). > > The field is a text field so you can enter any value you want. However for > most applications it is best to initialize the device with the master clock > rate set in the device arguments. You can supply a string such as > "master_clock_rate=61.44e6" into the Device Arguments field in the sink > block. If you have a source block using the same USRP the Device Arguments > and Device Address fields must be identical between these blocks. > > Regards, > Derek > > > On Wed, Jun 7, 2017 at 9:37 AM, ??? <d...@radarnspace.kr> wrote: > > > Hi all > > > > > > > > I'm using Ettus Research USRP device with GRC. > > > > And I have one question. > > > > <The "sampling rate" is the rate at which samples are passed between > the > > host commuter and the USRP.> > > <The "master_clock_rate" is the rate at which samples are passed > between > > FPGA and the RF front end.> > > > > > > > > Is there anybody who can explain me why the clock rate on UHD:USRP sink > > block > > > > have only 4 choice? (200, 184.32, 120, 30.72MHz) > > > > > > > > > > > > Regards > > > > Kim taeyeong > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > 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/20170607/54022dae/attachment.html> > > ------------------------------ > > Message: 17 > Date: Wed, 07 Jun 2017 14:58:37 +0200 > From: Florian Adamsky <fa-gnura...@haktar.org> > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Measure the Distance to another 802.11 > device > Message-ID: <87o9u0hs3m....@haktar.org> > Content-Type: text/plain > > Hi all, > > in one of our projects we need to measure the distance between two > 802.11 devices as accurately as possible. Our idea is to use the > round-trip time (RTT). To avoid any delay from the operation system and > from the network stack, our idea is to measure the arrival time of the > acknowledgment control frame. Means, we take a timestamp when device A > sent a small data frame to device B; when B has received the frame, it > replies with an acknowledgment control frame and when A has received it > we will take another timestamp. Of course we would repeat that n-times > to avoid outliers. > > We bought a HackRF and tried to get the examples from gr-ieee802-11 > running. After some minor problems (dc offset) we were able to receive > 802.11 frames. However, we are not able to send any 802.11 packets, > because the hackrf driver does not support burst transmission with > tagged streams. One reader of this mailing list suggested to give > soapysdr a try. We did that as well, but again without success. Here we > didn't see any "UUUUU" in the debug console but we were still not able > to see any packets with another wireless card in monitor mode. > > Now we begin to think if the HackRF is the right device to get the job > done. Is the HackRF maybe the wrong device and we need to get a better > one? If yes, which one would you suggest? Or do you think there is > better approach to solve our problem like modifying one of the open > firmware for wireless cards? > > Thanks in advance. > > Cheers! > -- > Dr. Florian Adamsky > http://florian.adamsky.it/ > > > > ------------------------------ > > Message: 18 > Date: Wed, 7 Jun 2017 21:32:11 +0800 > From: zhan siyu <zhansyu...@gmail.com> > To: Bastian Bloessl <m...@bastibl.net> > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the > gr-ieee802-11 > Message-ID: > <CAGNex4ieGY+yyC7X96q3KMrO5+FOBgg_fVLZ=frXGP27DunQkA@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thanks for your reply. Let me explain what I 'm doing. > > I have two B210s connected with two computers. I want to measure the > throughput between the two computers over the usrp connection over > gr-ieee802-11. But no matter how hard I try, like tuning the parameters and > turning off my own wifi card and AP, I can only get 150K B/s, which should > be around 300K B/s if my theoretical calculation is right. There are no > underrun or overrun errors. The throughput measurement tool I'm using is > iperf, which is an application to measure the end to end throughput. > > Could you give me some hints? > > Best regards. > > Siyu > > 2017-06-07 14:02 GMT+08:00 Bastian Bloessl <m...@bastibl.net>: > > > Hi, > > > > On 06/07/2017 03:04 AM, zhan siyu wrote: > > > >> Thanks. I just wonder why. Because I meet some performance problem. I > >> thought it maybe caused by my misconfiguration of the gr-ieee802-11 > code. > >> Now, it seems not. > >> > > > > I'm a bit confused why the fact that the transceiver is not configured > > through iwconfig ruled out any configuration issues, but great that all > > seems to be set up now. > > > > > >> However, theoretically, as my current sample rate is 10M and BPSK. So > >> the coding rate should be 10M/2 = 5M b/s. The throughtput should be > around > >> 5M/8 = 625K B/s. Assuming the 12% head cost, so the data throughput > should > >> be 625 * 88 % = 550K B/s. But as my experiment shows, the throughput is > >> only 150K B/s. > >> > >> I'm new to the communication. Is my calculation right ? > >> > > > > BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet has to be > > subtracted, i.e. the actual maximum rate depends on the frame size. > > > > > > If it were right, then what might cause the gap? > >> > > > > Since you don't explain what you are doing, this is very hard to tell. > You > > would reach this theoretical throughput only if you send frames > > back-to-back (which probably only works if you pregenerate the sample > > stream). But also a WiFi card will insert inter-frame space, so that the > > actual throughput will not match the theoretical maximum physical layer > > throughput. > > > > Best, > > Bastian > > > > > > > >> One more question, I didn't run the volk_profile. Does it matter? > >> > >> Best regards. > >> > >> Siyu > >> > >> > >> 2017-06-07 4:23 GMT+08:00 Bastian Bloessl <m...@bastibl.net <mailto: > >> m...@bastibl.net>>: > >> > >> Hi, > >> > >> On 06/06/2017 03:55 PM, zhan siyu wrote: > >> > >> Hi all, > >> > >> I just found I can't use the iwconfig tap0 rate 20M to setup the > >> bandwidth of the tap0. The error message is : > >> > >> Error for wireless request "Set Bit Rate" (8B20) : > >> SET failed on device tap0 ; Operation not supported. > >> > >> But in their video , it can be set in this way. May I know how > >> to solve it ? > >> > >> > >> The WiFi transceiver is attached to the tun/tap interface, which is > >> a virtual Ethernet device. This device doesn't support WiFi-specific > >> configuration through iwconfig. > >> > >> If you wanted this level of integration, you would have to write a > >> kernel module that attaches the transceiver to a virtual WiFi card. > >> > >> Some group already did that, but they didn't release the source > code. > >> > >> Best, > >> Bastian > >> > >> > >> > > -- > > Dipl.-Inform. Bastian Bloessl > > CONNECT Center > > Trinity College Dublin > > > > GitHub/Twitter: @bastibl > > https://www.bastibl.net/ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/ > attachments/20170607/099e661c/attachment.html> > > ------------------------------ > > Message: 19 > Date: Wed, 7 Jun 2017 17:36:34 +0200 > From: Marcus M?ller <marcus.muel...@ettus.com> > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Measure the Distance to another 802.11 > device > Message-ID: <d593a29c-c303-f7ec-21d3-96b5e9f7d...@ettus.com> > Content-Type: text/plain; charset=windows-1252 > > Hi Florian, > > that's an interesting approach! > > > On 06/07/2017 02:58 PM, Florian Adamsky wrote: > > Hi all, > > > > in one of our projects we need to measure the distance between two > > 802.11 devices as accurately as possible. Our idea is to use the > > round-trip time (RTT). To avoid any delay from the operation system and > > from the network stack, our idea is to measure the arrival time of the > > acknowledgment control frame. Means, we take a timestamp when device A > > sent a small data frame to device B; when B has received the frame, it > > replies with an acknowledgment control frame and when A has received it > > we will take another timestamp. Of course we would repeat that n-times > > to avoid outliers. > Your observation, that Wifi chipsets typically delegate most of what is > necessary to be a working Wifi device to the operating system. Highly > timing-sensitive things, however, are typically handled by the chip > firmware itself. > If I remember correctly, there's some degree of adjustability in that > firmware, at least in Atheros chipsets; [1] might be an interesting talk > for you. > > > > We bought a HackRF and tried to get the examples from gr-ieee802-11 > > running. After some minor problems (dc offset) we were able to receive > > 802.11 frames. However, we are not able to send any 802.11 packets, > > because the hackrf driver does not support burst transmission with > > tagged streams. One reader of this mailing list suggested to give > > soapysdr a try. We did that as well, but again without success. Here we > > didn't see any "UUUUU" in the debug console but we were still not able > > to see any packets with another wireless card in monitor mode. > Another takeaway from [1] that in usual operation, the hardware doesn't > even hand over packets that don't make the checksum test ? maybe it'd be > interesting to disable that filtering. > > Best regards, > Marcus > > [1] > https://www.irongeek.com/i.php?page=videos/defcon- > wireless-village-2014/20-inside-the-atheros-wifi-chipset-adrian-chadd > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ------------------------------ > > End of Discuss-gnuradio Digest, Vol 176, Issue 7 > ************************************************ >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
