[Discuss-gnuradio] USRP2 MIMO system implementation
Hello, I want to implement a MIMO system using USRP2, I just have USRP2s and MIMO cable. 1. Do I have to use an external clock source ? 2. I searched the maillist and found: Each USRP2 can handle 1 antenna with most daughterboards, or 2 if you have your own external RF sections connected to the USRP2 at IF. Does it mean I should buy external RF sections to use 2 antennas on 1 USRP2? Or where can I get them? 3. If I want to build a 2X2 MIMO system,-- 2 USRP2s, 1 MIMO cable, the external RF sections said above, -- Is that enough? Any suggestion is appreciated. Thank you.. -- Best regards, Luyuan Pan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about OpenBTS
On 2012/6/4 23:28, Thomas Tsou wrote: On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuanpanluy...@gmail.com wrote: Hello, I want to set up the OpenBTS, and I want to know which board is better, USRP1 or USRP2? Or any other suggestion? Thank you. Both USRP1 and USRP2 work with OpenBTS and neither can be considered better without describing your requirements. USRP2 / N2xx will support higher bandwidths with the GigE interface if that is important to you. USRP1 (or B100) will be cheaper. For stable clocking, the USRP1 requires hardware modification to support an external 52MHz clock signal. Other devices can use a more accessible internal or external 10 MHz reference source. Also, OpenBTS is not gnuradio, and the openbts-discuss or usrp-users lists may be better sources for that type of information. http://lists.sourceforge.net/lists/listinfo/openbts-discuss http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Thomas Sorry, This may not the proper place to ask question about OpenBTS, But I just want to ask one more questions. My scenario is : I want to set up a BTS, scan the user nearby and get their IMSI, then attract them to my fake BTS and broadcast them a message. 1. I want to use USRP1 to do the project, Is it enough? (I have both of USRP1 and USRP2 at hand) 2. Is it that SMS-CB a better choice for me? (my ultimate goal is to broadcast some messages) Thank you for your help! -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about OpenBTS
Hello, I want to set up the OpenBTS, and I want to know which board is better, USRP1 or USRP2? Or any other suggestion? Thank you. -- Best regards, Pan, Luyuan ___ 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] Question about stream tag
On 2012/5/24 22:34, Tom Rondeau wrote: On Thu, May 24, 2012 at 10:27 AM, Pan, Luyuanpanluy...@gmail.com 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] How to implement a TDMA system
Hello, Thank you so much for your reply. And I also read your presentation and audio about "Stream tag" on the website of GnuRadio Conference 2011, I want to know a few questions about it: 1. I think you defined some auxiliary control information to make the stream start or stop on desired time, but above the UHD/gr-uhd and has nothing to do with UHD, did I misunderstand it? 2. May I use the "stream tag" to achieve my goal of TDMA system?(consider the precision and efficiency) 3. If so, and as the time-stamp cannot get through the gr-uhd, whether is it more convenient for me to use the "stream tag"? Or maybe I can code in some higher level like python? Any comment/suggestion is greatly appreciated, thank you~ -- Best regards, Luyuan Pan Tom Rondeau 2012423 22:15 On Sun, Apr 22, 2012 at 3:16 AM, Pan, Luyuan panluy...@gmail.com wrote: Hi everyone, I want to implement a TDD system with three USRP2 and an IBM server with three Ethernet cards. The scenario is one relay and two nodes exchange data through the relay, I want them to transmit data in their fixed time slot, it does not need to be too precise, about 100 milliseconds per slot is OK. The question is: 1. Can I achieve my goal with the current equipment? I'm pretty sure, yes. The 100 ms should be pretty easily achievable. 2. I want to use the time-stamp in UHD to precise control the time to send and recv, but without external clock, does the UHD have to use the external clock to get the time? No, you do not need an external clock for this. All time in the UHD land is relative, so you should be able to say "send packet 100 ms from now" without caring what absolute time 'now' is. Tom Thank you in advance! -- Best regards, Pan, Luyuan Pan, Luyuan 2012422 15:16 Hi everyone, I want to implement a TDD system with three USRP2 and an IBM server with three Ethernet cards. The scenario is one relay and two nodes exchange data through the relay, I want them to transmit data in their fixed time slot, it does not need to be too precise, about 100 milliseconds per slot is OK. The question is: 1. Can I achieve my goal with the current equipment? 2. I want to use the time-stamp in UHD to precise control the time to send and recv, but without external clock, does the UHD have to use the external clock to get the time? Thank you in advance! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to implement a TDMA system
Hi everyone, I want to implement a TDD system with three USRP2 and an IBM server with three Ethernet cards. The scenario is one relay and two nodes exchange data through the relay, I want them to transmit data in their fixed time slot, it does not need to be too precise, about 100 milliseconds per slot is OK. The question is: 1. Can I achieve my goal with the current equipment? 2. I want to use the time-stamp in UHD to precise control the time to send and recv, but without external clock, does the UHD have to use the external clock to get the time? Thank you in advance! -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about underrun
Hello everyone, I am wondering what will the USRP and GnuRadio do if an underrun happens? i.e. The console/terminal print out U. Does the USRP restart again or the flow-graph restart? I now face the problem that USRP takes more time to transmit all the data out(I need to add time.sleep() to make sure all the data are sent out successfully), does it have some relation with the underrun. Any suggestion is appreciated. Thank you for your help! -- 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 USRP2 Tx procedure
original mail-- Message: 11 Date: Fri, 13 Apr 2012 08:25:36 -0700 From: Josh Blumj...@ettus.com To:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Question about USRP2 Tx procedure Message-ID:4f884570.5010...@ettus.com Content-Type: text/plain; charset=ISO-8859-1 On 04/13/2012 06:54 AM, Pan, Luyuan wrote: Hi everyone, I now have some trouble in understanding how the usrp2 sent out the data. My scenario of the test is: We tried to control the usrp2 to transmit in a fixed time slot, such as 5 seconds. The code is: tb = usrp.transmit_path() # Create the path t1 = time.time() tb.start() while (time.time() - t1 5): .. # The code to send out the data continue; time.sleep(0.65)# to ensure all the data are sent truly out. Question?? WHY tb.stop() tb.wait() My question lies in line time.sleep(0.65). if we don't use time.sleep(), we can not receive all the packets, every time the receive side will lose about 50 packets(each one is 1500 bytes), and if time.sleep()0.65s, it will still lose but less than 50. So, I want to know why it need such a time(about 650ms)? And we have some hypotheses: 1. The usrp did not send out data instantly at tb.start(), it need time to build the flow graph. But we do an experiment to get the time we received the first packet, and found the truth is not that. The time tb.start and (in the recv side)the time we received the packet is almost the same. So, It send out immediately. 2. But we encountered another dilemma, if we let it send an extremely short time, like while (time.time() - t1 0.02) (generally less than 50 packets), and do not use time.sleep(), it will never send out the data. Only add time.sleep(), it will success. Why? I really confused!~ 3. Considering that we only need 650ms, no matter how long we send(like 10s or more). We guess there is a fixed size cache in the usrp and it send the cached data at a precise-controlled time, but I can not persuade myself. Can anyone interpret the strange phenomenon? Any suggestion is appreciated, thank you!! The is buffering in the USRP2, about 1 MB. Give your sample rate and 4 bytes per sample you can approximate the sleep time. The more proper way to do this is to send an end-of-burst tag with the last sample and to wait on the async message queue for a burst ACK packet. About the TX tags for the sink block: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n52 Also see the async message source: http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_amsg_source.h -josh -- Hello, In order to find out the reasons, today we did another test, we used wireshark to capture the data through the wEthernet card. But, we guess the problem may lies in the FIFO in the software side, the scenarios are: 1. we use while (time.time() - t1 0.05) and no time.sleep(), then the receive side can get only one packet. the useful data through the Ethernet is about 55 packets(not take into account the packet less than 1498 bytes, we consider them as the control info). 2. we use while (time.time() - t1 0.05) and time.sleep(0.65), so we can receive all the data(10 packets). And the data through the Ethernet is nearly 600 packets. For the fact 1/10 almost equals 55/600, we think USRP2 send the data out immediately after he get it from the host PC. The main problem now is for some unknown reason the PC did not pass the data to USRP2, so he has nothing to send. Did I misunderstand something or some other reasons? Thank you for your help! -- Best regards, Pan, Luyuan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about USRP2 Tx procedure
Hi everyone, I now have some trouble in understanding how the usrp2 sent out the data. My scenario of the test is: We tried to control the usrp2 to transmit in a fixed time slot, such as 5 seconds. The code is: tb = usrp.transmit_path() # Create the path t1 = time.time() tb.start() while (time.time() - t1 5): .. # The code to send out the data continue; time.sleep(0.65)# to ensure all the data are sent truly out. Question?? WHY tb.stop() tb.wait() My question lies in line time.sleep(0.65). if we don't use time.sleep(), we can not receive all the packets, every time the receive side will lose about 50 packets(each one is 1500 bytes), and if time.sleep()0.65s, it will still lose but less than 50. So, I want to know why it need such a time(about 650ms)? And we have some hypotheses: 1. The usrp did not send out data instantly at tb.start(), it need time to build the flow graph. But we do an experiment to get the time we received the first packet, and found the truth is not that. The time tb.start and (in the recv side)the time we received the packet is almost the same. So, It send out immediately. 2. But we encountered another dilemma, if we let it send an extremely short time, like while (time.time() - t1 0.02) (generally less than 50 packets), and do not use time.sleep(), it will never send out the data. Only add time.sleep(), it will success. Why? I really confused!~ 3. Considering that we only need 650ms, no matter how long we send(like 10s or more). We guess there is a fixed size cache in the usrp and it send the cached data at a precise-controlled time, but I can not persuade myself. Can anyone interpret the strange phenomenon? 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] [discuss-gnuradio] The Gnu radio's stream mode
Hello everybody, Many people say the Gnuradio operates in stream mode with the flowgraph, but I am not clear about the stream mode, for it is too abstract. Does anyone have a better way to understand it or interpret it in plain words? And one thesis says,'Gnu Radio is not designed to work in packet mode, rather the scheduler is designed to operate on continuous data stream', so if I want to get precise-time control of the data packet, what should I do? (What I recently do is to switch the TX/RX using one antenna, I just make two top_blocks and switch them, the problem is there is too much delay. If I want to send 5 seconds, I also need to wait to 1.5 sec to make sure it successfully sent all the data) Can I so lucky to reference someone's information or get a hand from you? Thanks very much ! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
