[Discuss-gnuradio] WiMAX scanner
Hello, I am interested in WiMAX technology (802.16e). In my research I am dealing with algorithms for admission control in Matlab. Typically these algorithms are located “within base station” – although they are not standardized by any organization. In simulations it is simple to “deploy them” as they are located inside BTS source code. As regards verification and validation of such algorithms I am currently using well known simulator which is ns2 – i.e. well known to the research community. It is clear however that “simulations vs reality” is not always very close…. That is why I am interested in collecting data from real network in a vendor agnostic way (in general from any network i.e. build upon BTSes delivered by any vendor) – it means that I would like to “observe” traffic intensity/duration/etc directly from the radio. I am using PureWave 6600 at university premises. The input data for the algorithms I am interested in is the wireless connection characteristics e.g.: connection requests, time of connection, type of traffic, connection close, etc. Unfortunately to my knowledge there is no one-fits-all (or virtually any) solution to communicate with inside components of a BTS in an automated manner (i.e. from within a software program that is learning for best policy etc). That is why I have started to think about using USRP (or its brother from NI / or any other SDR) to play a role of passive probe for WiMAX wireless signalling. I have seen that there is a “wimax scanner” project but it seems unfinished (or would it actually be operational in the area I mention?). Please let me know: 1. Is it possible to use “wimax scanner” with USRP right away (i.e. without much effort spent on programming)? 2. Is wimax scanner full featured solution? (i.e. what can I do with it) 3. What statistics I could capture with it? 4. What limitations does it has? 5. Are there any plans for continuing its development? 6. Do you know if there is already happening an approach to develop complete WiMAX stack as there is for GSM – OpenBTS…? Thank you for the assessment of my question or any hints. Best, Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scaling down IFFT values
Also I tried manually scaling down the output array in fft_vcc_fftw:work function. That has no effect no IFFT output! -- View this message in context: http://gnuradio.4.n7.nabble.com/Scaling-down-IFFT-values-tp50833p50968.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scaling down IFFT values
Did you mean something like: self.connect(self._pkt_input, 0), self.scale, (self.preambles,0)) ? That's not working as it's giving itemsize mismatch error! -- View this message in context: http://gnuradio.4.n7.nabble.com/Scaling-down-IFFT-values-tp50833p50967.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] iir_filter does not work with specified feedback taps?
Hi All, Any guys who ever used IIR filters? I got problems as below: I want the IIR filter works as: y[n] = 1.8*x[n] + 0.8*y[n-1] Then I set the feed forward taps as [1.8], feeback taps as [0.8], just like self.iir_filter_xxx_0 = filter.iir_filter_ffd(([1.8]), ([0.8]), True) But my testing result show that the feedback taps are not involved in computing at all, thus my output turns to y[n] = 1.8*x[n] I don't know anything wrong happened to my usage... Need help. Thanks -- Alex, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-qtgui Waterfall Time Axis
I have some large spectrum records and I would like to use GR for analysis in a a sort of "off-line" mode. I want to visualize the data using the spectrogram and then identify subsets of interesting features (e.g. WiFi Packets in 2.4 GHz) by frequency and time coordinates. Essentially, I want to know what index in the file certain features correspond with so I can save them as separate files. To this end, I've found gr_spectrogram_plot very handy, but it doesn't quite do what I want because the y-axis which displays time isn't showing up correctly. My y-axis is always 0.0, and the cursor highlight also reads 0.0 (although the frequency is correct). However, the qt spectrogram appears to have correct time information when I make a simple file source -> qt spectrogram sink. I'd like to fix this issue so I've been pouring over the code in gr-qtgui. I don't have much experience with QWT or Python GUIs in general. From what I can tell, there are methods for frequency axis and intensity scaling, but not time. Is this true or am I missing something in the API? The historyExtent parameter in the WaterfallData constructor appears to get hardcoded to 200 in WaterfallDisplayPlot.cc (gr-qtgui/lib). It would also be nice to toggle between the time and sample number. I'm happy to do the work to implement this. Could someone point me in the right direction here? Thanks! PWG ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
>> ##
>> # Variables
>> ##
>> self.tx_gain = tx_gain = 15
>> self.samp_rate = samp_rate = 20
>> self.f_center = f_center = 1.47e9
>> self.device = device = "type=usrp2"
>>
>> ##
>> # Blocks
>> ##
>> self.usrp_sink = uhd.usrp_sink(
>> device_addr=device,
>> stream_args=uhd.stream_args(
>> cpu_format="fc32",
>> length_tag_name="packet_len",
>> channels=range(1),
>> ),
>> )
>> self.usrp_sink.set_samp_rate(samp_rate)
>> self.usrp_sink.set_center_freq(f_center, 0)
>> self.usrp_sink.set_gain(tx_gain, 0)
>> self.usrp_sink.set_antenna("TX/RX", 0)
>> self.blocks_vector_source_x_0 =
>> blocks.vector_source_c((1,)*5, False, 1, [])
>> self.blocks_stream_to_tagged_stream_0 =
>> blocks.stream_to_tagged_stream(gr.sizeof_gr_complex, 1, 5,
>> "packet_len")
>>
>> ##
>> # Connections
>> ##
>> self.connect((self.blocks_vector_source_x_0, 0),
>> (self.blocks_stream_to_tagged_stream_0, 0))
>> self.connect((self.blocks_stream_to_tagged_stream_0, 0),
>> (self.usrp_sink, 0))
> It's not working either... I can still observe the carrier at the receiver.
>> - You'll know if your USRP hasn't acknowledged tx_eob if you see 'U's
>> between bursts.
> I am getting exactly one "U". Both for the code in my previous post as
> well as for the above one. It really seems like the USRP is not
> recognizing the stream tags.
>
There are a few things to consider with this flowgraph (as posted):
1) Your vector source is set to /not/ repeat. After your flowgraph
terminates, is that when you observe the LO still running?
2) You're essentially sending a very short rectangular pulse modulated
onto a carrier, which in the frequency domain would look like a sinc function
centered at the carrier. Is this what you want, or are you just experimenting
with the burst interface?
3) Is there a reason your burst pulses need to contain so few samples?
Could you provide some information about what you're trying to do in your end
application?
Sean
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Marcus Müller
Sent: Tuesday, October 21, 2014 1:41 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB
and EOB
Sean,
interesting point.
Frederik,
How does your carrier look when you send bursts of >500 samples?
Greetings,
Marcus
On 21.10.2014 19:29, Nowlan, Sean wrote:
> I'm concerned that the problem
Frederik is observing has to do with the very short burst he is
sending, something like 5 samples. I suspect this requires 1 call
each to work and tag_work per 5 sample burst, which seems like an
awful lot of context switching and overhead.
>
> -Original Message-
> From: Marcus Müller [mailto:mar...@hostalia.de]
> Sent: Tuesday, October 21, 2014 1:24 PM
> To: Nowlan, Sean;
discuss-gnuradio@gnu.org; Martin Braun
> Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC
by inserting SOB and EOB
>
Hi Sean,
aaah good catch! Yes, that's right; sob is safe.
Cheers,
Marcus
On 21.10.2014 19:19, Nowlan, Sean wrote:
> From Marcus:
>> ... and that (wut) might be a bug, because it implies that, if the
>> stream has both a time tag and a sob tag, the question whether the tx
>> metadata has a time tag depends on in which order these tags are
>> sorted on the the tag storage multimap. Which might be random,
>> because tags are sorted only by tag offset.
>> @Martin: is there a reason that this is explicitely set to false
>> here, or can one just fix this by deleting a line?
> This appears to be handled correctly. Given the same tag offset, the
> order of tx_time vs. tx_sob tags should not matter. If tx_time is
> found first, it sets found_time_tag=true and
> _metadata.has_time_spec=true (lines 652 & 653). Then
> _metadata.has_time_spec is overwritten in the tx_sob check (line
> 665) with 'false', but is set back to 'true' in line 743 due to
> found_time_tag being true.
> if (found_time_tag) { _metadata.has_time_spec = true; }
> If instead tx_sob is found first and tx_time second, then the time
> spec will also be set in line 743. So the question is whether setting
> _metadata.has_time_spec=false is really necessar
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Sean,
interesting point.
Frederik,
How does your carrier look when you send bursts of >500 samples?
Greetings,
Marcus
On 21.10.2014 19:29, Nowlan, Sean wrote:
> I'm concerned that the problem Frederik is observing has to do with the very
> short burst he is
sending, something like 5 samples. I suspect this requires 1 call each
to work and tag_work per 5 sample burst, which seems like an awful lot
of context switching and overhead.
>
> -Original Message-
> From: Marcus Müller [mailto:mar...@hostalia.de]
> Sent: Tuesday, October 21, 2014 1:24 PM
> To: Nowlan, Sean; discuss-gnuradio@gnu.org; Martin Braun
> Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by
inserting SOB and EOB
>
> Hi Sean,
>
> aaah good catch! Yes, that's right; sob is safe.
>
> Cheers,
> Marcus
>
>
>
> On 21.10.2014 19:19, Nowlan, Sean wrote:
> > From Marcus:
> >> ... and that (wut) might be a bug, because it implies that, if the
> >> stream has both a time tag and a sob tag, the question whether the tx
> >> metadata has a time tag depends on in which order these tags are
> >> sorted on the the tag storage multimap. Which might be random,
> >> because tags are sorted only by tag offset.
> >> @Martin: is there a reason that this is explicitely set to false
> >> here, or can one just fix this by deleting a line?
>
> > This appears to be handled correctly. Given the same tag offset, the
> > order of tx_time vs. tx_sob tags should not matter. If tx_time is
> > found first, it sets found_time_tag=true and
> > _metadata.has_time_spec=true (lines 652 & 653). Then
> > _metadata.has_time_spec is overwritten in the tx_sob check (line
> > 665) with 'false', but is set back to 'true' in line 743 due to
> > found_time_tag being true.
>
> > if (found_time_tag) { _metadata.has_time_spec = true; }
>
> > If instead tx_sob is found first and tx_time second, then the time
> > spec will also be set in line 743. So the question is whether setting
> > _metadata.has_time_spec=false is really necessary. I'd say it's worth
> > keeping in case the user doesn't always want to use tx_time stamps.
> > The user may want to schedule some bursts but force others to transmit
> > as soon as possible while still using the ATR functionality of the
> > USRP.
>
> > I know all this logic can be hard to follow, but it has to handle so
> > many different cases and possibly span many calls to work and
> > tag_work.
>
> > From Frederik:
> >> Unfortunately, even with the newest version the USRP is still
> >> transmitting its carrier over the air. I tried both with the Message
> >> Burst Source as well as with the Stream to Tagged Stream Block
> >> combined with setting a Length Tag name in the USRP Sink.
> >> With the Tag Debug Block I see tx_sob+tx_eob and the Length Tag,
> >> respectively. They all seem to be at the right place and have the
> >> right value.
> >>
> >> The Length Tag should arrive properly at the Sink. I checked by
> >> changing the tag's name at the Stream to Tagged Stream Block to
> >> something stupid and finally got an "tG" printed out.
>
> > It should be mentioned that there are two burst tag interfaces that
> > cannot be mixed. if a Length Tag Name is specified to the constructor,
> > all tx_sob and tx_eob tags will be ignored in tag_work to ensure the
> > interfaces are mutually exclusive. If no Length Tag Name is specified,
> > then tag_work will search for tx_sob/tx_eob tags and won't look for
> > length tags.
>
> > Sean
>
> > On 21.10.2014 15:53, Frederik Wing wrote:
> >> Hi Marcus,
> > I cannot believe that there is no solution to it since the
> > "tags_demo" application shows that it is indeed possible.
> > :-/
> >>> that makes the two of us! I didn't get that when using tags_demo,
> >>> you're not seeing the carrier that you use tags_demo; as far as I
> >>> understood, your application does exactly the same, sending bursts
> >>> with sob/eob tags?
> >>
> >> That's right. tags_demo works perfectly. No carrier in between the
> >> bursts. The flow graph I posted before sends exactly one burst with
> >> SOB and EOB tags. The only difference to tags_demo I could recognize
> >> so far is that I don't assign time stamps to the samples. But this
> >> shouldn't be a problem, should it?
> >>
> >> Frederik
> >>
> >>
> >> ___ Discuss-gnuradio
> >> mailing list Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory allocation issue
Hi Ron, Yes, that seems to be linux kernel default: $>cd /usr/src/kernels/3.14.19* $>grep -REo '^[[:space:]]*#define[[:space:]]+SHMMAX[[:space:]]+0x[0-9a-f]+' include/uapi/linux/shm.h:#define SHMMAX 0x200 $>echo $((0x200)) 33554432 Cheers, Marcus PS: help, I'm being helped captive in a bad-regex factory. They feed us mail addresses! On 21.10.2014 18:36, Ron Economos wrote: > Marcus and Jeff, > > Works great. Thanks guys. BTW, the default on my Ubuntu 13.10 system > was 33,554,432 bytes. > > best regards, > Ron > > On 10/21/2014 09:19 AM, Marcus Müller wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi Ron, >> yep, that can be, within kernel-caused and total memory boundaries be >> configured to your heart's delight: >> >> echo $(( 1024 * 1024 * 1024 )) > /proc/sys/kernel/shmmax >> >> to set the maximum size shared mem buffer to 1GB. >> >> Greetings, >> Marcus >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
I'm concerned that the problem Frederik is observing has to do with the very
short burst he is sending, something like 5 samples. I suspect this requires 1
call each to work and tag_work per 5 sample burst, which seems like an awful
lot of context switching and overhead.
-Original Message-
From: Marcus Müller [mailto:mar...@hostalia.de]
Sent: Tuesday, October 21, 2014 1:24 PM
To: Nowlan, Sean; discuss-gnuradio@gnu.org; Martin Braun
Subject: Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB
and EOB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Sean,
aaah good catch! Yes, that's right; sob is safe.
Cheers,
Marcus
On 21.10.2014 19:19, Nowlan, Sean wrote:
> From Marcus:
>> ... and that (wut) might be a bug, because it implies that, if the
>> stream has both a time tag and a sob tag, the question whether the tx
>> metadata has a time tag depends on in which order these tags are
>> sorted on the the tag storage multimap. Which might be random,
>> because tags are sorted only by tag offset.
>> @Martin: is there a reason that this is explicitely set to false
>> here, or can one just fix this by deleting a line?
>
> This appears to be handled correctly. Given the same tag offset, the
> order of tx_time vs. tx_sob tags should not matter. If tx_time is
> found first, it sets found_time_tag=true and
> _metadata.has_time_spec=true (lines 652 & 653). Then
> _metadata.has_time_spec is overwritten in the tx_sob check (line
> 665) with 'false', but is set back to 'true' in line 743 due to
> found_time_tag being true.
>
> if (found_time_tag) { _metadata.has_time_spec = true; }
>
> If instead tx_sob is found first and tx_time second, then the time
> spec will also be set in line 743. So the question is whether setting
> _metadata.has_time_spec=false is really necessary. I'd say it's worth
> keeping in case the user doesn't always want to use tx_time stamps.
> The user may want to schedule some bursts but force others to transmit
> as soon as possible while still using the ATR functionality of the
> USRP.
>
> I know all this logic can be hard to follow, but it has to handle so
> many different cases and possibly span many calls to work and
> tag_work.
>
> From Frederik:
>> Unfortunately, even with the newest version the USRP is still
>> transmitting its carrier over the air. I tried both with the Message
>> Burst Source as well as with the Stream to Tagged Stream Block
>> combined with setting a Length Tag name in the USRP Sink.
>> With the Tag Debug Block I see tx_sob+tx_eob and the Length Tag,
>> respectively. They all seem to be at the right place and have the
>> right value.
>>
>> The Length Tag should arrive properly at the Sink. I checked by
>> changing the tag's name at the Stream to Tagged Stream Block to
>> something stupid and finally got an "tG" printed out.
>
> It should be mentioned that there are two burst tag interfaces that
> cannot be mixed. if a Length Tag Name is specified to the constructor,
> all tx_sob and tx_eob tags will be ignored in tag_work to ensure the
> interfaces are mutually exclusive. If no Length Tag Name is specified,
> then tag_work will search for tx_sob/tx_eob tags and won't look for
> length tags.
>
> Sean
>
> On 21.10.2014 15:53, Frederik Wing wrote:
>> Hi Marcus,
> I cannot believe that there is no solution to it since the
> "tags_demo" application shows that it is indeed possible.
> :-/
>>> that makes the two of us! I didn't get that when using tags_demo,
>>> you're not seeing the carrier that you use tags_demo; as far as I
>>> understood, your application does exactly the same, sending bursts
>>> with sob/eob tags?
>>
>> That's right. tags_demo works perfectly. No carrier in between the
>> bursts. The flow graph I posted before sends exactly one burst with
>> SOB and EOB tags. The only difference to tags_demo I could recognize
>> so far is that I don't assign time stamps to the samples. But this
>> shouldn't be a problem, should it?
>>
>> Frederik
>>
>>
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> -BEGIN PGP SIGNATURE- Version: GnuPG v1
>
> iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
> Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
> pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
> MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
> G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
> L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
> =V3EN -END PGP SIGNATURE-
>
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURparAAoJEAFxB7BbsDrLiT8H/0qUJ6qkMEgWdp
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Sean,
aaah good catch! Yes, that's right; sob is safe.
Cheers,
Marcus
On 21.10.2014 19:19, Nowlan, Sean wrote:
> From Marcus:
>> ... and that (wut) might be a bug, because it implies that, if
>> the stream has both a time tag and a sob tag, the question
>> whether the tx metadata has a time tag depends on in which order
>> these tags are sorted on the the tag storage multimap. Which
>> might be random, because tags are sorted only by tag offset.
>> @Martin: is there a reason that this is explicitely set to false
>> here, or can one just fix this by deleting a line?
>
> This appears to be handled correctly. Given the same tag offset,
> the order of tx_time vs. tx_sob tags should not matter. If tx_time
> is found first, it sets found_time_tag=true and
> _metadata.has_time_spec=true (lines 652 & 653). Then
> _metadata.has_time_spec is overwritten in the tx_sob check (line
> 665) with 'false', but is set back to 'true' in line 743 due to
> found_time_tag being true.
>
> if (found_time_tag) { _metadata.has_time_spec = true; }
>
> If instead tx_sob is found first and tx_time second, then the time
> spec will also be set in line 743. So the question is whether
> setting _metadata.has_time_spec=false is really necessary. I'd say
> it's worth keeping in case the user doesn't always want to use
> tx_time stamps. The user may want to schedule some bursts but force
> others to transmit as soon as possible while still using the ATR
> functionality of the USRP.
>
> I know all this logic can be hard to follow, but it has to handle
> so many different cases and possibly span many calls to work and
> tag_work.
>
> From Frederik:
>> Unfortunately, even with the newest version the USRP is still
>> transmitting its carrier over the air. I tried both with the
>> Message Burst Source as well as with the Stream to Tagged Stream
>> Block combined with setting a Length Tag name in the USRP Sink.
>> With the Tag Debug Block I see tx_sob+tx_eob and the Length Tag,
>> respectively. They all seem to be at the right place and have the
>> right value.
>>
>> The Length Tag should arrive properly at the Sink. I checked by
>> changing the tag's name at the Stream to Tagged Stream Block to
>> something stupid and finally got an "tG" printed out.
>
> It should be mentioned that there are two burst tag interfaces that
> cannot be mixed. if a Length Tag Name is specified to the
> constructor, all tx_sob and tx_eob tags will be ignored in tag_work
> to ensure the interfaces are mutually exclusive. If no Length Tag
> Name is specified, then tag_work will search for tx_sob/tx_eob tags
> and won't look for length tags.
>
> Sean
>
> On 21.10.2014 15:53, Frederik Wing wrote:
>> Hi Marcus,
> I cannot believe that there is no solution to it since the
> "tags_demo" application shows that it is indeed possible.
> :-/
>>> that makes the two of us! I didn't get that when using
>>> tags_demo, you're not seeing the carrier that you use
>>> tags_demo; as far as I understood, your application does
>>> exactly the same, sending bursts with sob/eob tags?
>>
>> That's right. tags_demo works perfectly. No carrier in between
>> the bursts. The flow graph I posted before sends exactly one
>> burst with SOB and EOB tags. The only difference to tags_demo I
>> could recognize so far is that I don't assign time stamps to the
>> samples. But this shouldn't be a problem, should it?
>>
>> Frederik
>>
>>
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> -BEGIN PGP SIGNATURE- Version: GnuPG v1
>
> iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
> Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
> pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
> MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
> G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
> L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
> =V3EN -END PGP SIGNATURE-
>
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURparAAoJEAFxB7BbsDrLiT8H/0qUJ6qkMEgWdp7q1eKTr3Bm
hq4P6pIAXxXkmIRWVy+pn2uZ2zunvv0/2e/NcE4RMppuxTlT8HvjeKb0aKDMIxE2
spVqN/nuue5JSRAbQJIvI69jJytGgqzxvjY2EyWHSZPKtXB3Hc5a/PoMGY3EZb45
hZ+mYN0z6JpUhRlozinTkkRI3D/P38dubx5YXTSbzCthEt2BMMInS+FEpiH42KrI
rKP7ywwqL0O6TFvFMlOqn9hNzJKP+PFvoJQbuH3zJSItIeRbyIth6QwERNh8Pg0H
3U19h6Y7ejnh+G8UOSOdxnlsoLHzwloYEvUb1cvBbhKeyDd4Dng8DwPa+Q6T0qo=
=vsQm
-END PGP SIGNATURE-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
>From Marcus:
> ... and that (wut) might be a bug, because it implies that, if the stream has
> both a time tag and a sob tag, the
> question whether the tx metadata has a time tag depends on in which order
> these tags are sorted on the the
> tag storage multimap. Which might be random, because tags are sorted only by
> tag offset.
> @Martin: is there a reason that this is explicitely set to false here, or can
> one just fix this by deleting a line?
This appears to be handled correctly. Given the same tag offset, the order of
tx_time vs. tx_sob tags should not matter. If tx_time is found first, it sets
found_time_tag=true and _metadata.has_time_spec=true (lines 652 & 653). Then
_metadata.has_time_spec is overwritten in the tx_sob check (line 665) with
'false', but is set back to 'true' in line 743 due to found_time_tag being
true.
if (found_time_tag) {
_metadata.has_time_spec = true;
}
If instead tx_sob is found first and tx_time second, then the time spec will
also be set in line 743. So the question is whether setting
_metadata.has_time_spec=false is really necessary. I'd say it's worth keeping
in case the user doesn't always want to use tx_time stamps. The user may want
to schedule some bursts but force others to transmit as soon as possible while
still using the ATR functionality of the USRP.
I know all this logic can be hard to follow, but it has to handle so many
different cases and possibly span many calls to work and tag_work.
>From Frederik:
> Unfortunately, even with the newest version the USRP is still transmitting
> its carrier over the air. I tried both with
> the Message Burst Source as well as with the Stream to Tagged Stream Block
> combined with setting a Length Tag
> name in the USRP Sink. With the Tag Debug Block I see tx_sob+tx_eob and the
> Length Tag, respectively. They all
> seem to be at the right place and have the right value.
>
> The Length Tag should arrive properly at the Sink. I checked by changing the
> tag's name at the Stream to Tagged
> Stream Block to something stupid and finally got an "tG" printed out.
It should be mentioned that there are two burst tag interfaces that cannot be
mixed. if a Length Tag Name is specified to the constructor, all tx_sob and
tx_eob tags will be ignored in tag_work to ensure the interfaces are mutually
exclusive. If no Length Tag Name is specified, then tag_work will search for
tx_sob/tx_eob tags and won't look for length tags.
Sean
On 21.10.2014 15:53, Frederik Wing wrote:
> Hi Marcus,
I cannot believe that there is no solution to it since the
"tags_demo" application shows that it is indeed possible.
:-/
>> that makes the two of us! I didn't get that when using tags_demo,
>> you're not seeing the carrier that you use tags_demo; as far as I
>> understood, your application does exactly the same, sending bursts
>> with sob/eob tags?
>
> That's right. tags_demo works perfectly. No carrier in between the
> bursts. The flow graph I posted before sends exactly one burst with
> SOB and EOB tags. The only difference to tags_demo I could recognize
> so far is that I don't assign time stamps to the samples.
> But this shouldn't be a problem, should it?
>
> Frederik
>
>
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
=V3EN
-END PGP SIGNATURE-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio 3.7.5.1 and live DVD released
GNU Radio release 3.7.5.1 is now available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.7.5.1.tar.gz GNU Radio Live DVD for 3.7.5.1: http://gnuradio.org/releases/gnuradio/iso/ubuntu-14.04.1-desktop-amd64-gnuradio.torrent MD5 sums: bfd2116b344a949aacc3d7e2eff07642 gnuradio-3.7.5.1.tar.gz 0c22ccd6f66c1aeeb7b54072077b53f2 ubuntu-14.04.1-desktop-amd64-gnuradio.torrent This is a bug-fix only maintenance release for GNU Radio 3.7.5. For fixes and updates to the live DVD, please see: http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD h2. Contributors: Andy Walls Bastian Bloessl Doug Geiger Johnathan Corgan Martin Braun Michael Dickens Sebastian Koslowski Tom Rondeau Volker Schroer Changelog: http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_5_1 -- Johnathan Corgan, Corgan Labs SDR/DSP Training and Consulting Services http://corganlabs.com <> signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory allocation issue
Marcus and Jeff, Works great. Thanks guys. BTW, the default on my Ubuntu 13.10 system was 33,554,432 bytes. best regards, Ron On 10/21/2014 09:19 AM, Marcus Müller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ron, yep, that can be, within kernel-caused and total memory boundaries be configured to your heart's delight: echo $(( 1024 * 1024 * 1024 )) > /proc/sys/kernel/shmmax to set the maximum size shared mem buffer to 1GB. Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory allocation issue
Ron, See if you can set kernel.shmmax to something higher. You can check the current value with sysctl kernel.shmmax See sysctl(8). Jeff On 10/21/2014 04:12 PM, Ron Economos wrote: I'm writing a block that requires a large amount of data to be processed in one iteration of the work function. If I call set_output_multiple() with 8100 * 130 = 1053000 items (of gr_complex), I get the following error: gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::buffer::allocate_buffer: failed to allocate buffer of size 16456 KB gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::buffer::allocate_buffer: failed to allocate buffer of size 16456 KB terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc I realize that 16 Megabytes is a little large, but not astronomical. The set_output_multiple() function does work fine with 8100 * 129 = 1044900 items (of gr_complex). Is this some hard limitation in the shared memory library, or can it be overridden somehow? best regards, Ron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory allocation issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ron, yep, that can be, within kernel-caused and total memory boundaries be configured to your heart's delight: echo $(( 1024 * 1024 * 1024 )) > /proc/sys/kernel/shmmax to set the maximum size shared mem buffer to 1GB. Greetings, Marcus On 21.10.2014 18:12, Ron Economos wrote: > I'm writing a block that requires a large amount of data to be > processed in one iteration of the work function. If I call > set_output_multiple() with 8100 * 130 = 1053000 items (of > gr_complex), I get the following error: > > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::buffer::allocate_buffer: failed to allocate buffer of size > 16456 KB gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument > gr::buffer::allocate_buffer: failed to allocate buffer of size > 16456 KB terminate called after throwing an instance of > 'std::bad_alloc' what(): std::bad_alloc > > > I realize that 16 Megabytes is a little large, but not > astronomical. The set_output_multiple() function does work fine > with 8100 * 129 = 1044900 items (of gr_complex). > > Is this some hard limitation in the shared memory library, or can > it be overridden somehow? > > best regards, Ron > > ___ Discuss-gnuradio > mailing list Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJURoevAAoJEAFxB7BbsDrLZxQH/0L9Eq9YAeSCdkwKcxDtp58l 6kuHH+HZYHodOTxJBqlKG123Avnqr0nzCc13GAOXvRiq8ooVHrsyEOfGQooCzF8o yqlTNQzdxN86blnaW3Gb0BaDfIIvKWF5Q/DJHLagTsLMvKfcYRj7ke7wEge+tflJ YmAhcSUNqhxKyScbCkOShQMsdZcCgeirV0kkFkk2rqdMmdtSOTy7Cs/WMM0UCeP5 zzIuBstRac/7Sax+SY88OF9IUHzlspKzY/MpqDk+RxcHWcA+u+EXBsgO3oSVjRl+ grakLDtJBn5o95YLeRuxdSxHmRDiD6Uvuy/8MLoB78vcMWZi8S70k8SekQU8bAY= =h8wJ -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Memory allocation issue
I'm writing a block that requires a large amount of data to be processed in one iteration of the work function. If I call set_output_multiple() with 8100 * 130 = 1053000 items (of gr_complex), I get the following error: gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::buffer::allocate_buffer: failed to allocate buffer of size 16456 KB gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::buffer::allocate_buffer: failed to allocate buffer of size 16456 KB terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc I realize that 16 Megabytes is a little large, but not astronomical. The set_output_multiple() function does work fine with 8100 * 129 = 1044900 items (of gr_complex). Is this some hard limitation in the shared memory library, or can it be overridden somehow? best regards, Ron ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio in Python Tutorial - installing python block without C++
Hi all, I've been going through the tutorials with a fresh install of GNURadio (Version 3.7.2.1) through Ubuntu's package manager (Ubuntu 14.04) and I've run into a few issues when attempting to install a python block (without any C++, as indicated in the tutorial: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_Python#Installing-Python-Blocks). I think I resolved the first issue below, but any pointers for resolving the second error would be greatly appreciated: 1-) Running cmake threw an error "CMAKE error: cannot determine link language for target "gnuradio-tutorial" -As mentioned in the "bug" report #522, I was able to eliminate the error by removing the lib folder and commenting out the line "add_subdirectory(lib)" from CMakeLists.txt 2-) Running make now gives the error when attempting to link the tutorial module: Linking CXX shared module _tutorial_swig.so /usr/bin/ld: cannot find -lgnuradio-tutorial collect2: error: ld returned 1 exit status -Is there something else that needs to be edited before running cmake since there isn't any C++ code? Thanks in advance, -Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gd question.
The corresponding lines look something like [1] (while iterating over
the tags in the current set of items):
BOOST_FOREACH(const tag_t &my_tag, _tags) {
...
else if(pmt::is_null(_length_tag_key)
&& pmt::equal(key, SOB_KEY)) {
if (my_tag.offset != samp0_count) {
max_count = my_tag_count;
break;
}
// Bursty tx will not use time specs, unless a tx_time tag is also
given.
_metadata.has_time_spec = false; //(wut)
_metadata.start_of_burst = pmt::to_bool(value);
}
... and that (wut) might be a bug, because it implies that, if the
stream has both a time tag and a sob tag, the question whether the tx
metadata has a time tag depends on in which order these tags are
sorted on the the tag storage multimap. Which might be random, because
tags are sorted only by tag offset.
@Martin: is there a reason that this is explicitely set to false here,
or can one just fix this by deleting a line?
Cheers,
Marcus
[1]
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_sink_impl.cc#L659
On 21.10.2014 15:53, Frederik Wing wrote:
> Hi Marcus,
I cannot believe that there is no solution to it since the
"tags_demo" application shows that it is indeed possible.
:-/
>> that makes the two of us! I didn't get that when using tags_demo,
>> you're not seeing the carrier that you use tags_demo; as far as I
>> understood, your application does exactly the same, sending
>> bursts with sob/eob tags?
>
> That's right. tags_demo works perfectly. No carrier in between the
> bursts. The flow graph I posted before sends exactly one burst with
> SOB and EOB tags. The only difference to tags_demo I could
> recognize so far is that I don't assign time stamps to the samples.
> But this shouldn't be a problem, should it?
>
> Frederik
>
>
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJURnbzAAoJEAFxB7BbsDrL2nEIAJnutUguHZy3qb0delF4EEoZ
Wh+ikhML4LpzX76omgESTBzCIL+yeSzpwyF4+xFMs/laONrFoSYjKrIPicOUC85K
pKbddIT1eYC4ulDLViEAK7G+f3h8d6fj8NvVlBOYflyz/z8kfT5Ow2P7vT2osPbi
MrY9to3MQVGHriakq6mzf5cUe/F54YmscikEofrZXZj2EqwknULehS0Q0tm/Ms0L
G+OamkGyPdsyxn8vmR2yMOScHSKxWF0yINYzf+jLJ4ypmbYUmn+99lsDZoyF9bJ3
L93I6IaRgUReawdYjvfSmDMOL1n0t1zyp9GBgBTly4JtfD2Rcvfn8al6FSzOZv8=
=V3EN
-END PGP SIGNATURE-
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
On 10/21/2014 03:53 PM, Frederik Wing wrote: > Hi Marcus, I cannot believe that there is no solution to it since the "tags_demo" application shows that it is indeed possible. :-/ >> that makes the two of us! I didn't get that when using tags_demo, you're >> not seeing the carrier that you use tags_demo; as far as I understood, >> your application does exactly the same, sending bursts with sob/eob tags? > > That's right. tags_demo works perfectly. No carrier in between the bursts. > The flow graph I posted before sends exactly one burst with SOB and EOB > tags. The only difference to tags_demo I could recognize so far is that > I don't assign time stamps to the samples. But this shouldn't be a > problem, should it? Hm, it might. Give it a shot -- there might be some interaction between the way GNU Radio handles the time spec and what UHD expects. To reiterate on an earlier part of this thread, if you only see a single 'U', then GNU Radio/UHD *are* respecting the eob/sob tags, albeit in a slightly buggy way (there should be no U). If the tags weren't respected, you'd see lots and lots of U's between bursts. Although this might also be related to the time stamps. Cheers, M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Hi Marcus, >> > I cannot believe that there is no solution to it since the "tags_demo" >> > application shows that it is indeed possible. :-/ > that makes the two of us! I didn't get that when using tags_demo, you're > not seeing the carrier that you use tags_demo; as far as I understood, > your application does exactly the same, sending bursts with sob/eob tags? That's right. tags_demo works perfectly. No carrier in between the bursts. The flow graph I posted before sends exactly one burst with SOB and EOB tags. The only difference to tags_demo I could recognize so far is that I don't assign time stamps to the samples. But this shouldn't be a problem, should it? Frederik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for simple ra
Hi Will, The subversion server is still up and your relevant code is at https://www.cgran.org/svn/projects/simple_ra Archive.org has a nice cache of CGRAN also: https://web.archive.org/web/20140702091149/https://cgran.org/wiki/simple_ra - George On Mon, Oct 20, 2014 at 6:20 PM, Will Caruana wrote: > I am looking to download the program simple_ra to make a radio telescope > for my small town of Wilbraham MA. Please let me know if you can either > send me the files or up load them to https://github.com > > Thank you, > > Will Caruana > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Hi Frederik, On 21.10.2014 14:56, Frederik Wing wrote: > > I cannot believe that there is no solution to it since the "tags_demo" > application shows that it is indeed possible. :-/ that makes the two of us! I didn't get that when using tags_demo, you're not seeing the carrier that you use tags_demo; as far as I understood, your application does exactly the same, sending bursts with sob/eob tags? Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
- You're using an ancient UHD version. Is there a reason you can't use a newer one? >>>I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the >>>packet sources. There is no newer version available. And I don't >>>like to >>>compile myself unless it is absolutely necessary. >>Consider it outdated. Ubuntu's packet sources are most of the time >>horribly out of pace compared to GNU Radio's development process. >>For UHD it's the same. Note that Ettus ships its own Ubuntu packages >>for UHD*and* GNU Radio, so you can get a non-ancient version of both >>without even compiling it. >>By the way: GNU Radio is a software radio developer's framework. You >>can do great things with it without touching a compiler, but at many >>points it becomes helpful when one can write his own C++ block, so >>you definitely need to lose your fear of compilers if you want to use >>GNU Radio to its fullest potential:) > >After some hours of compiling time I could finally update GNU Radio to >version 3.7.6 and UHD to 003.008. > >>>I don't think it's because of an outdated version of UHD as the >>>"tags_demo" application is working perfectly with my current version. >>... Well, my old tube radio also still works;) > >Unfortunately, even with the newest version the USRP is still >transmitting its carrier over the air. I tried both with the Message >Burst Source as well as with the Stream to Tagged Stream Block >combined with setting a Length Tag name in the USRP Sink. With the Tag >Debug Block I see tx_sob+tx_eob and the Length Tag, respectively. They >all seem to be at the right place and have the right value. :( ok, so we see something that looks like significant LO leakage. You can use offset tuning, by specifying a tune request instead of simply a target frequency f_t. By doing so, you instruct the USRP to tune the oscillator of the daughterboard to some frequency f_LO, and let the FPGA shift the resulting signal to baseband by a second frequency f_FPGA, so that f_LO+f_FPGA = f_t. You thereby would move the LO leakage out of your desired signal. Would that help you? Thanks for this suggestion. It would be a workaround to the actual problem. And if there is no other way I have to do so. I cannot believe that there is no solution to it since the "tags_demo" application shows that it is indeed possible. :-/ Frederik. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
On 21.10.2014 13:47, Frederik Wing wrote: > Hello Marcus, > > thank you very much for your hints! - You're using an ancient UHD version. Is there a reason you can't use a newer one? >>> I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the >>> packet sources. There is no newer version available. And I don't >>> like to >>> compile myself unless it is absolutely necessary. >> Consider it outdated. Ubuntu's packet sources are most of the time >> horribly out of pace compared to GNU Radio's development process. >> For UHD it's the same. Note that Ettus ships its own Ubuntu packages >> for UHD *and* GNU Radio, so you can get a non-ancient version of both >> without even compiling it. >> By the way: GNU Radio is a software radio developer's framework. You >> can do great things with it without touching a compiler, but at many >> points it becomes helpful when one can write his own C++ block, so >> you definitely need to lose your fear of compilers if you want to use >> GNU Radio to its fullest potential :) > > After some hours of compiling time I could finally update GNU Radio to > version 3.7.6 and UHD to 003.008. > >>> I don't think it's because of an outdated version of UHD as the >>> "tags_demo" application is working perfectly with my current version. >> ... Well, my old tube radio also still works ;) > > Unfortunately, even with the newest version the USRP is still > transmitting its carrier over the air. I tried both with the Message > Burst Source as well as with the Stream to Tagged Stream Block > combined with setting a Length Tag name in the USRP Sink. With the Tag > Debug Block I see tx_sob+tx_eob and the Length Tag, respectively. They > all seem to be at the right place and have the right value. :( ok, so we see something that looks like significant LO leakage. You can use offset tuning, by specifying a tune request instead of simply a target frequency f_t. By doing so, you instruct the USRP to tune the oscillator of the daughterboard to some frequency f_LO, and let the FPGA shift the resulting signal to baseband by a second frequency f_FPGA, so that f_LO+f_FPGA = f_t. You thereby would move the LO leakage out of your desired signal. Would that help you? Greetings, Marcus > > The Length Tag should arrive properly at the Sink. I checked by > changing the tag's name at the Stream to Tagged Stream Block to > something stupid and finally got an "tG" printed out. > > Another interesting observation: > I don't get the "U" underrun output if I use a larger number of > samples for my burst (in Vector Source). Even with only Vector Source > and USRP Sink (no blocks in between) I don't get any "U" printed. I > tried that with 500 samples. > > Has anyone ever succeeded in transmitting proper bursts with a GRC > flow graph? Or at least on Python level? I really feel desperate right > now... > - In current GNU Radio, you can use 'length tags' to mark bursts, if that's any help. >>> I tried using length tags by inserting an "Stream to tagged Stream" >>> block and adding the length_tag_name property to the USRP Sink. Here is >>> my sample code, now with a burst of 5 samples: >> The GNU Radio doxygen contains documentation for the current GNU >> Radio build, containing the newly available message passing >> functionality. >> Maybe that's of interest to you! > > That's definitely an interesting feature. But first of all I'd like to > make sure that transmitting bursts works as expected before making > other improvements in my transmitter chain. > > Frederik > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting bursts with GRC by inserting SOB and EOB
Hello Marcus, thank you very much for your hints! - You're using an ancient UHD version. Is there a reason you can't use a newer one? I am using Ubuntu 14.04 LTS and just pulled GNU Radio and UHD from the packet sources. There is no newer version available. And I don't like to compile myself unless it is absolutely necessary. Consider it outdated. Ubuntu's packet sources are most of the time horribly out of pace compared to GNU Radio's development process. For UHD it's the same. Note that Ettus ships its own Ubuntu packages for UHD *and* GNU Radio, so you can get a non-ancient version of both without even compiling it. By the way: GNU Radio is a software radio developer's framework. You can do great things with it without touching a compiler, but at many points it becomes helpful when one can write his own C++ block, so you definitely need to lose your fear of compilers if you want to use GNU Radio to its fullest potential :) After some hours of compiling time I could finally update GNU Radio to version 3.7.6 and UHD to 003.008. I don't think it's because of an outdated version of UHD as the "tags_demo" application is working perfectly with my current version. ... Well, my old tube radio also still works ;) Unfortunately, even with the newest version the USRP is still transmitting its carrier over the air. I tried both with the Message Burst Source as well as with the Stream to Tagged Stream Block combined with setting a Length Tag name in the USRP Sink. With the Tag Debug Block I see tx_sob+tx_eob and the Length Tag, respectively. They all seem to be at the right place and have the right value. The Length Tag should arrive properly at the Sink. I checked by changing the tag's name at the Stream to Tagged Stream Block to something stupid and finally got an "tG" printed out. Another interesting observation: I don't get the "U" underrun output if I use a larger number of samples for my burst (in Vector Source). Even with only Vector Source and USRP Sink (no blocks in between) I don't get any "U" printed. I tried that with 500 samples. Has anyone ever succeeded in transmitting proper bursts with a GRC flow graph? Or at least on Python level? I really feel desperate right now... - In current GNU Radio, you can use 'length tags' to mark bursts, if that's any help. I tried using length tags by inserting an "Stream to tagged Stream" block and adding the length_tag_name property to the USRP Sink. Here is my sample code, now with a burst of 5 samples: The GNU Radio doxygen contains documentation for the current GNU Radio build, containing the newly available message passing functionality. Maybe that's of interest to you! That's definitely an interesting feature. But first of all I'd like to make sure that transmitting bursts works as expected before making other improvements in my transmitter chain. Frederik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
