Re: [Discuss-gnuradio] Baseband GPS OTA USRP capture that anyone can share?
Hello, A while ago (May 9) there was a post to the list about raw GPS data as captured by a USRP. These web pages may or may not be useful, I don't know if the data files on the first one are the right format for you (they were not captured by a USRP) but they may still be helpful. http://michelebavaro.blogspot.com/2012/04/spring-news-in-gnss-and-sdr-domain.html If not, Michele might be able to help point you to where you could find data that is. Also, you should check out this web page: http://gpspp.sakura.ne.jp/indexe.html Tomoji Takasu has done quite a bit of amazing stuff with GPS including SDR development. (you may have to dig a bit for it but its there) Between one or the other you should be able to find what you are looking for. On Mon, 2011-05-09 at 10:27 -0500, John Andrews wrote: > Hi, > > Is there is anyone here who has GPS OTA capture using USRP that they > are willing to share? I don't have a USRP and I am interested in > demodulating the GPS signal. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Persistence causes glAccum exception
On Thu, May 24, 2012 at 10:51 PM, Marcus D. Leech wrote: >> On Thu, May 24, 2012 at 10:18 PM, Marcus D. Leech >> wrote: >> I'm really hoping that we can get the qtgui working nicely for >> everyone soon and that we can replace all functionality of the wxgui >> with it. And then, yes, I won't shed any tears to let wxgui fade >> away. >> >> Tom >> >> > The only heartburn it gives me is thinking about all those flow-graphs out > there that use wxGUI. [And more important personally, all > the flow-graphs *I* have that use wxGUI]. Yeah, that's why I said "fade away." It'd be a pretty long deprecation process, I think, on this one. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Persistence causes glAccum exception
On Thu, May 24, 2012 at 10:18 PM, Marcus D. Leech wrote: I'm really hoping that we can get the qtgui working nicely for everyone soon and that we can replace all functionality of the wxgui with it. And then, yes, I won't shed any tears to let wxgui fade away. Tom The only heartburn it gives me is thinking about all those flow-graphs out there that use wxGUI. [And more important personally, all the flow-graphs *I* have that use wxGUI]. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Persistence causes glAccum exception
On Thu, May 24, 2012 at 10:18 PM, Marcus D. Leech wrote: >> Other then the Mesa software only stack it does not work on any Intel >> or ATI driver provided stack, but nVidia blob driver DOES support it. >> WXFFT also maxes out my 2 core 3Ghz machine ( a lot of people often >> get locked up i7's so this is a problem ), wxfft realy needs a c++ >> re-write if anything. > > I couldn't get the VESA/MESA stuff working the other night, so went back to > fglrx, which is what the Fedora installer chose for my machine. > > I keep my update rates quite modest, and I can support multiple wxGUI FFT > sinks on the same machine. I'm running two different applications > 24 x 7 that have both Waterfall and FFT sinks, and my machine is only > lightly loaded. But I keep the update rates down to 5Hz or so. > > Well, the qtGUI stuff is being worked on at the moment, and it should have > much better performance, and provided it can give a similar > amount of user-friendly stuff, perhaps at some point, we let the wxGUI > stuff die. Unless some brave soul wants to seriously work it over > and make it a better performer, and eradicate the openGL edge cases that it > keeps tripping over. I'm really hoping that we can get the qtgui working nicely for everyone soon and that we can replace all functionality of the wxgui with it. And then, yes, I won't shed any tears to let wxgui fade away. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Persistence causes glAccum exception
On May 24, 2012, at 6:44 PM, Marcus D. Leech wrote: > Near as I can tell, the "persistence" feature is intended to give a kind of > storage-scope effect, or high-persistence phosphor effect. I achieved a similar effect in the ubertooth-specan-ui Python app, built on top of Qt's newer PySide Python library. Perhaps it'll be a useful reference for reimplementation in Qt without relying on OpenGL. The general technique is to draw the graph into an off-screen image. During each frame update, black is drawn over the existing image, with a small alpha value, which effectively fades the prior image. The new graph is rendered over the top at alpha = 1.0, then the image is copied to the screen. It seems to perform quite well. I presume most video drivers can push the pixels-with-alpha BLTing into the hardware. http://ubertooth.svn.sourceforge.net/viewvc/ubertooth/trunk/host/specan_ui/ubertooth-specan-ui?view=markup The meat of this technique is in RenderArea._draw_graph(). I imagine the code would map directly to the C++ Qt API. I hear the author of Kismet has done something similar in his software, but I don't know what graphics API he built it on. - Jared ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Persistence causes glAccum exception
Other then the Mesa software only stack it does not work on any Intel or ATI driver provided stack, but nVidia blob driver DOES support it. WXFFT also maxes out my 2 core 3Ghz machine ( a lot of people often get locked up i7's so this is a problem ), wxfft realy needs a c++ re-write if anything. I couldn't get the VESA/MESA stuff working the other night, so went back to fglrx, which is what the Fedora installer chose for my machine. I keep my update rates quite modest, and I can support multiple wxGUI FFT sinks on the same machine. I'm running two different applications 24 x 7 that have both Waterfall and FFT sinks, and my machine is only lightly loaded. But I keep the update rates down to 5Hz or so. Well, the qtGUI stuff is being worked on at the moment, and it should have much better performance, and provided it can give a similar amount of user-friendly stuff, perhaps at some point, we let the wxGUI stuff die. Unless some brave soul wants to seriously work it over and make it a better performer, and eradicate the openGL edge cases that it keeps tripping over. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Persistence causes glAccum exception
Other then the Mesa software only stack it does not work on any Intel or ATI driver provided stack, but nVidia blob driver DOES support it. WXFFT also maxes out my 2 core 3Ghz machine ( a lot of people often get locked up i7's so this is a problem ), wxfft realy needs a c++ re-write if anything. On Thu, May 24, 2012 at 9:44 PM, Marcus D. Leech wrote: > So, I did a quick "audit" this evening of four different machines in my > house, running both Ubuntu recent and Fedora recent, but with > different generations of video hardware/motherboards, and tried the > "Persistence" control on all of them. > > EVERY SINGLE ONE OF THEM failed, provoking an OpenGL exception from glAccum, > which, it turns out, is an optional feature, and at least in > this little survey, not a single piece of my hardware supported that op. > > How many people actually use "persistence"? (As opposed, I must be clear, > to "Peak Hold"). I suspect that a workable approach is to, > for now, remove that feature entirely, but I don't have a good feel for who > uses it. > > Near as I can tell, the "persistence" feature is intended to give a kind of > storage-scope effect, or high-persistence phosphor effect. > But the "effect" uses a non-mandatory OpenGL feature (the accumulator > buffer) which appears, at least on the garden-variety > video hardware I use, not to be supported. And to be clear, I'm running > modern motherboards on two of my systems, but using > the on-board video, since I'm not a gamer, and really, the simple 2D > effects Gnu Radio uses aren't particularly taxing. > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > 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] Persistence causes glAccum exception
So, I did a quick "audit" this evening of four different machines in my house, running both Ubuntu recent and Fedora recent, but with different generations of video hardware/motherboards, and tried the "Persistence" control on all of them. EVERY SINGLE ONE OF THEM failed, provoking an OpenGL exception from glAccum, which, it turns out, is an optional feature, and at least in this little survey, not a single piece of my hardware supported that op. How many people actually use "persistence"? (As opposed, I must be clear, to "Peak Hold"). I suspect that a workable approach is to, for now, remove that feature entirely, but I don't have a good feel for who uses it. Near as I can tell, the "persistence" feature is intended to give a kind of storage-scope effect, or high-persistence phosphor effect. But the "effect" uses a non-mandatory OpenGL feature (the accumulator buffer) which appears, at least on the garden-variety video hardware I use, not to be supported. And to be clear, I'm running modern motherboards on two of my systems, but using the on-board video, since I'm not a gamer, and really, the simple 2D effects Gnu Radio uses aren't particularly taxing. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Recording I-Q stream with uhd_rx_cfile
Hello, I want to transmit a continuous stream of 1's or 0's (with bpsk modulation) and record the received I-Q stream. I am trying to use the 'digital_bert_tx.py' code for transmission and the uhd_rx_cfile code (gr-uhd/apps) for reception. Thereafter, I use the read_complex_binary code to read the data in Matlab. Surprisingly, I am receiving similar type of I-Q stream (around 0.3 + j 0.3) for both 1 and 0 transmission. I am using the following commands: self._bits = gr.vector_source_b([1,], True) (I either transmit infinite 1 or infinit 0's. When I transmit infinite 0's, I replace '1' by '0' in the command) ./digital_bert_naz_tx.py -r 5M -m bpsk -f 450M --gain 0.1 --non-differential(I am using non-differential since I want to see the different amplitude levels for '1's or 0's) ./uhd_rx_cfile -N 1000 -f 450M --samp-rate 5M file.dat (Since I am using bpsk, sample-rate should be equal to bit rate, I assume) Ideally, the I-Q stream of bpsk should show 180 degree phase shift for 1 and 0 transmission. I am getting the same value for both transmission. Can anyone suggest where I am making mistakes? Thanks, Nazmul -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I transmit and receive bit level data using the benchmark codes of gnuradio?
I think Matlab can handle this, depending your PC memory You need to write some Matlab code to read the file which may contain the complex samples (gr-complex). On Thu, May 24, 2012 at 3:18 PM, Nazmul Islam wrote: > Thanks, Alex. > > I tried using the log files in benchmark_rx. But the file has 200 Megabit > size and Matlab could not handle it. Can you limit the size of the recorded > data? > Maybe you can add some control to start and stop the data recording, in your python code. > > Besides, can you transmit bit level data using the benchmark_tx code? I > can transmit '1', '2', 'a', etc. but I cannot transmit 1, 0. I assume that > '1', '2', etc. are being transmitted as bytes. (I know that the > digital_bert codes allow bit level processing but I wonder how I can > transmit 0 and 1 using the benchmark_tx and rx codes, i.e., in a packetized > format). > I never tried it yet. Why not just try to compose these bits to bytes and then feed to the physical layer? And why do you need to do that? > > Thanks, > > Nazmul > > > On Thu, May 24, 2012 at 3:58 PM, Alex Zhang wrote: > >> I just turn on the log and read the log files in Matlab. >> The intermediate signal processing results can be written into files. >> Hope it help you. >> >> On Thu, May 24, 2012 at 11:31 AM, Nazmul Islam < >> mnis...@winlab.rutgers.edu> wrote: >> >>> Hello, >>> >>> Can I transmit and receive bit level data using the benchmark_tx and rx >>> codes of the narrowband/OFDM folder? At present, I can transmit and receive >>> byte level data using the codes, i.e., I can put 1500 characters (or 1500 >>> bytes) in each packet and receive it. But I want to transmit (i.e. 0 and 1 >>> / -1 and +1) and receive the demodulated bits (not the bytes or >>> characters). Can I do it using the benchmark or any other codes of gnuradio? >>> >>> >>> Any suggestion will be highly appreciated. >>> >>> >>> Thanks, >>> >>> Nazmul >>> >>> >>> -- >>> Muhammad Nazmul Islam >>> >>> Graduate Student >>> Electrical & Computer Engineering >>> Wireless Information & Networking Laboratory >>> Rutgers, USA. >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> >> -- >> >> Alex, >> *Dreams can come true – just believe.* >> >> > > > -- > Muhammad Nazmul Islam > > Graduate Student > Electrical & Computer Engineering > Wireless Information & Networking Laboratory > Rutgers, USA. > > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I transmit and receive bit level data using the benchmark codes of gnuradio?
Thanks, Alex. I tried using the log files in benchmark_rx. But the file has 200 Megabit size and Matlab could not handle it. Can you limit the size of the recorded data? Besides, can you transmit bit level data using the benchmark_tx code? I can transmit '1', '2', 'a', etc. but I cannot transmit 1, 0. I assume that '1', '2', etc. are being transmitted as bytes. (I know that the digital_bert codes allow bit level processing but I wonder how I can transmit 0 and 1 using the benchmark_tx and rx codes, i.e., in a packetized format). Thanks, Nazmul On Thu, May 24, 2012 at 3:58 PM, Alex Zhang wrote: > I just turn on the log and read the log files in Matlab. > The intermediate signal processing results can be written into files. > Hope it help you. > > On Thu, May 24, 2012 at 11:31 AM, Nazmul Islam > wrote: > >> Hello, >> >> Can I transmit and receive bit level data using the benchmark_tx and rx >> codes of the narrowband/OFDM folder? At present, I can transmit and receive >> byte level data using the codes, i.e., I can put 1500 characters (or 1500 >> bytes) in each packet and receive it. But I want to transmit (i.e. 0 and 1 >> / -1 and +1) and receive the demodulated bits (not the bytes or >> characters). Can I do it using the benchmark or any other codes of gnuradio? >> >> >> Any suggestion will be highly appreciated. >> >> >> Thanks, >> >> Nazmul >> >> >> -- >> Muhammad Nazmul Islam >> >> Graduate Student >> Electrical & Computer Engineering >> Wireless Information & Networking Laboratory >> Rutgers, USA. >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > > Alex, > *Dreams can come true – just believe.* > > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I transmit and receive bit level data using the benchmark codes of gnuradio?
I just turn on the log and read the log files in Matlab. The intermediate signal processing results can be written into files. Hope it help you. On Thu, May 24, 2012 at 11:31 AM, Nazmul Islam wrote: > Hello, > > Can I transmit and receive bit level data using the benchmark_tx and rx > codes of the narrowband/OFDM folder? At present, I can transmit and receive > byte level data using the codes, i.e., I can put 1500 characters (or 1500 > bytes) in each packet and receive it. But I want to transmit (i.e. 0 and 1 > / -1 and +1) and receive the demodulated bits (not the bytes or > characters). Can I do it using the benchmark or any other codes of gnuradio? > > > Any suggestion will be highly appreciated. > > > Thanks, > > Nazmul > > > -- > Muhammad Nazmul Islam > > Graduate Student > Electrical & Computer Engineering > Wireless Information & Networking Laboratory > Rutgers, USA. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Log power FFT block - bug?
On Mon, May 21, 2012 at 4:52 AM, Urban Kuhar wrote: > Hi everyone! > > I've been using log power FFT block for signal power estimation. I've fed > the output of Log Power block to my custom block in which I search for peak > in power spectrum and then I sum up bins left and right from that peak until > the turn is reached. C++ code for power estimation: > > // move right from the max > iCount = iMax_index + 1; > while (in[iCount] < in[iCount-1]) > fTotalPower += in[iCount++]; > > // move left from the max > iCount = iMax_index; > while (in[iCount] > in[iCount - 1]) > fTotalPower += in[iCount--]; > > > I've set the frame rate property to 10 frames per second (each 32768 > samples) and I use sample rate of 200kSPS. What happens is that every fourth > power estimate sample has magnitude for about 1dB lower than the other > three. I've looked deeper into situation and I found out that every fourth > power spectrum from log power FFT block has about three of four bins thinner > signal and that's why the total magnitude of the signal is lower. I've tried > lower frame rate (2 frames per second) but situation doesn't change. > > Next I tried the FFT block instead of log power FFT and the problem > disappears. So I am guessing that there is some kind of problem in Log Power > FFT block. Has anyone experienced similar problem? > > Regards, > Urban Hey Urban, Any chance you could send along a simulation that could be easily run that shows the bug? That'd help us understand the problem and find a fix. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about stream tag
> In Tx side, This may be the 'best' solution at present. But in Rx side,
> I just want the USRP to sample for 5 seconds, then stop. Is there any
> way to reach this goal? Should I use the "stream_cmd" in uhd to set the
> receive mode in USRP or any better alternative? Can the modes ("Start
> continuous", "Stop continuous","Num samps and done"...) achieve my goal?
> Any suggestion is appreciated. Thank you.
So, you have access to start(), stop() and set_start_time() on the
source object; The issue is that you cant really stop the block while
the flow graph is running or the source block will timeout, return 0,
and quit. So, here is a potential fix to make the work function block
when the streaming is stopped:
http://gnuradio.org/cgit/jblum.git/commit/?h=wip_uhd_stopper&id=c78d307ecd5dac4e28190e5aa9b8377538f65ffa
heres my git repo:
git://gnuradio.org/jblum.git
-josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about stream tag
If you know your sample rate, you can calculate how many samples will occur
over 5 seconds and pass that as "num samps and done" to a stream command. (I've
never used stream command interface myself, but I think this will work).
-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf
Of Pan, Luyuan
Sent: Thursday, May 24, 2012 11:03 AM
To: Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Question about stream tag
On 2012/5/24 22:34, Tom Rondeau wrote:
> On Thu, May 24, 2012 at 10:27 AM, Pan, Luyuan wrote:
>> Hello,
>> I want to use my USRP2 to implement a TDMA system, and I want to
>> send 5 seconds, receive 5 seconds, and do the recycle. I used the
>> stream tag demo in gr-uhd/taguhd. The question is:
>> 1. As sean have said in
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00506.h
>> tml we should use "tx_time", "tx_sob" (start-of-burst), and "tx_eob"
>> (end-of-burst) to tag the data flow, but yend B in
>> http://www.ruby-forum.com/topic/3832986 said the data not enclosed by
>> sob-eob tag pair was dropped. Is this problem really exist? And any
>> solution?
>> 2. Is there any way to switch the Tx/Rx? And how to tell the USRP to
>> receive for a desired time slot such as 5 seconds then stop? The only
>> parameter I can see in gr_uhd_usrp_source is 'rx_time'(tells when to
>> start receive), I do not know how to stop the streaming after 5 seconds.
>> Thank you for your help. Any suggestion is appreciated.
>> --
>> Best regards,
>> Pan, Luyuan
> It sounds like you need to add a rate control to your MAC layer.
> Obviously, when you aren't transmitting, you don't want to be
> generating any samples. You'll need to buffer them. This is going to
> take some work outside of GNU Radio to create an app that has a thread
> to control the samples and pass them to a message source block in GNU
> Radio.
>
> I'm not sure there's a good example of this, and we don't really have
> a 'best practices' for this right now.
>
> Tom
In Tx side, This may be the 'best' solution at present. But in Rx side, I just
want the USRP to sample for 5 seconds, then stop. Is there any way to reach
this goal? Should I use the "stream_cmd" in uhd to set the receive mode in
USRP or any better alternative? Can the modes ("Start continuous", "Stop
continuous","Num samps and done"...) achieve my goal?
Any suggestion is appreciated. Thank you.
--
Best regards,
Pan, Luyuan
___
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] How can I transmit and receive bit level data using the benchmark codes of gnuradio?
Hello, Can I transmit and receive bit level data using the benchmark_tx and rx codes of the narrowband/OFDM folder? At present, I can transmit and receive byte level data using the codes, i.e., I can put 1500 characters (or 1500 bytes) in each packet and receive it. But I want to transmit (i.e. 0 and 1 / -1 and +1) and receive the demodulated bits (not the bytes or characters). Can I do it using the benchmark or any other codes of gnuradio? Any suggestion will be highly appreciated. Thanks, Nazmul -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about stream tag
On 2012/5/24 22:34, Tom Rondeau wrote:
On Thu, May 24, 2012 at 10:27 AM, Pan, Luyuan wrote:
Hello,
I want to use my USRP2 to implement a TDMA system, and I want to send 5
seconds, receive 5 seconds, and do the recycle. I used the stream tag demo
in gr-uhd/taguhd. The question is:
1. As sean have said in
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00506.html we
should use "tx_time", "tx_sob" (start-of-burst), and "tx_eob" (end-of-burst)
to tag the data flow, but yend B in
http://www.ruby-forum.com/topic/3832986 said the data not enclosed by
sob-eob tag pair was dropped. Is this problem really exist? And any
solution?
2. Is there any way to switch the Tx/Rx? And how to tell the USRP to receive
for a desired time slot such as 5 seconds then stop? The only parameter I
can see in gr_uhd_usrp_source is 'rx_time'(tells when to start receive), I
do not know how to stop the streaming after 5 seconds.
Thank you for your help. Any suggestion is appreciated.
--
Best regards,
Pan, Luyuan
It sounds like you need to add a rate control to your MAC layer.
Obviously, when you aren't transmitting, you don't want to be
generating any samples. You'll need to buffer them. This is going to
take some work outside of GNU Radio to create an app that has a thread
to control the samples and pass them to a message source block in GNU
Radio.
I'm not sure there's a good example of this, and we don't really have
a 'best practices' for this right now.
Tom
In Tx side, This may be the 'best' solution at present. But in Rx side,
I just want the USRP to sample for 5 seconds, then stop. Is there any
way to reach this goal? Should I use the "stream_cmd" in uhd to set the
receive mode in USRP or any better alternative? Can the modes ("Start
continuous", "Stop continuous","Num samps and done"...) achieve my goal?
Any suggestion is appreciated. Thank you.
--
Best regards,
Pan, Luyuan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about stream tag
On Thu, May 24, 2012 at 10:27 AM, Pan, Luyuan wrote: > Hello, > I want to use my USRP2 to implement a TDMA system, and I want to send 5 > seconds, receive 5 seconds, and do the recycle. I used the stream tag demo > in gr-uhd/taguhd. The question is: > 1. As sean have said in > http://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00506.html we > should use "tx_time", "tx_sob" (start-of-burst), and "tx_eob" (end-of-burst) > to tag the data flow, but yend B in > http://www.ruby-forum.com/topic/3832986 said the data not enclosed by > sob-eob tag pair was dropped. Is this problem really exist? And any > solution? > 2. Is there any way to switch the Tx/Rx? And how to tell the USRP to receive > for a desired time slot such as 5 seconds then stop? The only parameter I > can see in gr_uhd_usrp_source is 'rx_time'(tells when to start receive), I > do not know how to stop the streaming after 5 seconds. > Thank you for your help. Any suggestion is appreciated. > -- > Best regards, > Pan, Luyuan It sounds like you need to add a rate control to your MAC layer. Obviously, when you aren't transmitting, you don't want to be generating any samples. You'll need to buffer them. This is going to take some work outside of GNU Radio to create an app that has a thread to control the samples and pass them to a message source block in GNU Radio. I'm not sure there's a good example of this, and we don't really have a 'best practices' for this right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about stream tag
Hello, I want to use my USRP2 to implement a TDMA system, and I want to send 5 seconds, receive 5 seconds, and do the recycle. I used the stream tag demo in gr-uhd/taguhd. The question is: 1. As sean have said in http://lists.gnu.org/archive/html/discuss-gnuradio/2012-04/msg00506.html we should use "tx_time", "tx_sob" (start-of-burst), and "tx_eob" (end-of-burst) to tag the data flow, but yend B in http://www.ruby-forum.com/topic/3832986 said the data not enclosed by sob-eob tag pair was dropped. Is this problem really exist? And any solution? 2. Is there any way to switch the Tx/Rx? And how to tell the USRP to receive for a desired time slot such as 5 seconds then stop? The only parameter I can see in gr_uhd_usrp_source is 'rx_time'(tells when to start receive), I do not know how to stop the streaming after 5 seconds. Thank you for your help. Any suggestion is appreciated. -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem linking app with qtgui_sink_c
On Wed, May 23, 2012 at 7:11 PM, Stephen wrote:
>> I'm not sure what's going wrong there, but that set_yaxis is exposed
>> through the SpectrumGUIClass as "SetFrequencyAxis", which is called
>> via the qtgui_sink_{c,f} as "set_frequency_axis". Can you use either
>> of those for what you want? (the naming was changed so that the
>> function exposed in GNU Radio is in the non-CamelCase style we use).
>>
>> Tom
>
> Now I remember how I missed this. I was wanting to change the y axis,
> the decibel values, not the x axis, frequency. So I didn't look at that
> routine. That routine name doesn't match what it does.
>
> stephen
Sure. But set_y_axis also doesn't fit, since you don't know which
y-axis you're talking about (time, waterfall, psd, etc.). Maybe
frequency_y_axis would have been better, but this was one of those
"Get it done now at all costs"(TM) type things as I recall.
It's been mentioned before that there's a rearchitecting of the gtgui
sinks going on now. As part of that, we'll try to make the many, many
properties of the sinks more accessible. I'm thinking like a keyword
lookup structure so we don't have to keep having these multiple layers
of wrapping to expose a method in a class contained down N levels.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Depends for Ubuntu 12.04
On Thu, May 24, 2012 at 03:19:27PM +1200, John Boy wrote: > I too used build-gnuradio and it worked fine on 32-bit Ubuntu > (obviously not AMD but i7). Same here, worked fine on 32-bit 12.04. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpv3Kg6gbWlF.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
