[Discuss-gnuradio] new CGRAN upgrades complete!
Hi everyone, The CGRAN upgrades are finally complete. After our server took a hit last week, I figured it was time to upgrade some things while I fixed some others. CGRAN is now using Trac 0.11.4 and subversion 1.6.0, with some python and apache module updates in the background. This seems to have solved our painful internal server error that anyone ever using the wiki probably saw a million times. Upgrading to Trac 0.11.4 was a little painful. Our previous theme is not supported by 0.11.4, so it's back to the default look for now, and the custom account manager I wrote didn't seamlessly move to 0.11 either, so I had to rework that. For anyone interested in the custom account manager, it's in svn/admin/. When a user registers, their account is crippled (no editing the wiki or SVN commit access). I receive an e-mail when a user registers, then I can use the trac to simply authorize them, granting them both wiki and SVN access. It's pretty useful. If anyone hits any Trac errors please let me know directly so I can work them out. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] XCVR2450 fix announcement
To users having difficulty with the XCVR2450 daughterboard. A bug was found that effects the XCVR2450 in transceiver applications, especially tunnel.py. A fix has been applied to the host code in r10853 of the trunk. This fix is for XCVR2450 + USRP (does not apply to the USRP2). Testers are welcome. Thanks, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the dqpsk modulator
Thanks a lot for the feedback. I got it to work eventually. Eric Blossom wrote: On Tue, Apr 14, 2009 at 04:03:13AM -0700, karim wrote: Eric Blossom wrote: On Thu, Apr 09, 2009 at 09:46:43AM -0700, karim wrote: Hi, I am trying to use the dqpsk modulator block to modulate some data and then take the output and separate it to real and imag. This is the code, it runs but the sinks are empty and have no data. What am I doing wrong? You're printing the contents of the vector sinks in your initialization code, before the graph has started running. Try printing their contents after my_top_block().run() returns. Eric I added a function to print the sinks after I call my_top_block().run() But the sinks are still empty. I also tried directing the output of the qpsk modulator to a file and it's also empty (the code below). You may want to spend some time with the most excellent Python 2.X tutorial: http://www.python.org/doc You are creating two instances of my_top_block(), calling run() on the first one and calling print_data() on the second. Try this instead: if __name__ == '__main__': try: tb = my_top_block() tb.run() tb.print_data() except KeyboardInterrupt: pass Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Sockets
On Wed, Apr 15, 2009 at 04:20:20PM -0400, devin kelly wrote: > I've been looking over the GNU Radio code and I can't seem to figure what is > being done in /usrp2/host/lib/open_usrp2_socket.cc file. Specifically, > lines 97 through to 128. > > What I think is happening is that a pair of connected sockets is created > (97) then a process is forked (102). So, the child process has it's own > pair of sockets? Are sockfd[0] in each process connected? That would > explain why sockfd[1] is closed (114) immediately after the fork, but it > would not explain the need for socketpair to begin with. > > So, my questions are: why is socketpair needed? What is the fork doing? > And, why is the socket closed right after the fork? > > Any help is appreciated. > Devin This code allows us to open a SOCK_RAW socket without being root by using a setuid-root helper program, usrp2_socket_opener. The setuid program opens the socket on our behalf and passes it back to us through the socket pair using the socket capability feature. Look at the code for the helper program, usrp2_socket_opener.c and read the man pages for each system call to see what's going on. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN_80211 and gr.hier_block2 (I only have USRP1s)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jane Chen wrote: > Hi all,, > > I read the [Discuss-gnuradio] and know that gr.hier_block is gone in current > GNU Radio. > http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg12193.html > > I used the command: svn co > https://www.cgran.org/cgran/projects/bbn_80211/trunk bbn_80211 > > I checked out the bbn trunk and got the codes only have gr.hier_block. The > codes have not been updated for 5 months. I am wondering if anyone maintains > the codes? I browsed the source at the link > https://www.cgran.org/browser/projects/bbn_80211/branches and found that > there is a usrp2_version which all files have been coverted to the > hier_block2 format. However, I only have USRP1s. Do I need to convert all the > codes in the trunk from gr.hier_block to gr.hier_block2 by myself or I can > just use the examples in the usrp2_version? Or I should buy USRP2s? > > Thank you, > Jane > In the branches on CGRAN - if you look under douggeiger you'll see the branch that has been converted over to hier_block2 (and still talks to the USRP1). Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ5kPygfOzzR5bXIgRAjWnAKCNBg8XrBQAJkymHMPK/HsH6fm/oQCfWVNR LRkZpEtndxq2AeKKjz1WTnA= =zUes -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using the dqpsk modulator
On Tue, Apr 14, 2009 at 04:03:13AM -0700, karim wrote: > Eric Blossom wrote: >> On Thu, Apr 09, 2009 at 09:46:43AM -0700, karim wrote: >>> Hi, >>> I am trying to use the dqpsk modulator block to modulate some data >>> and then take the output and separate it to real and imag. This is >>> the code, it runs but the sinks are empty and have no data. What am >>> I doing wrong? >> >> You're printing the contents of the vector sinks in your >> initialization code, before the graph has started running. >> >> Try printing their contents after my_top_block().run() returns. >> >> Eric >> > > I added a function to print the sinks after I call my_top_block().run() > > But the sinks are still empty. I also tried directing the output of the > qpsk modulator to a file and it's also empty (the code below). You may want to spend some time with the most excellent Python 2.X tutorial: http://www.python.org/doc You are creating two instances of my_top_block(), calling run() on the first one and calling print_data() on the second. Try this instead: if __name__ == '__main__': try: tb = my_top_block() tb.run() tb.print_data() except KeyboardInterrupt: pass Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Sockets
I've been looking over the GNU Radio code and I can't seem to figure what is being done in /usrp2/host/lib/open_usrp2_socket.cc file. Specifically, lines 97 through to 128. What I think is happening is that a pair of connected sockets is created (97) then a process is forked (102). So, the child process has it's own pair of sockets? Are sockfd[0] in each process connected? That would explain why sockfd[1] is closed (114) immediately after the fork, but it would not explain the need for socketpair to begin with. So, my questions are: why is socketpair needed? What is the fork doing? And, why is the socket closed right after the fork? Any help is appreciated. Devin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help initial problems with the USRP2
On Wed, Apr 15, 2009 at 04:59:15PM +0200, Ane Andersen wrote: > Hi Eric > ...Okey now I have another problem. I downloaded rev 10851 of the gnuradio > from the trunk and now I get two errors when I try to make. > > I configured ld.so.conf as describe in your wiki. But I still have make > errors > > Br > Ane Ane, You haven't shown us what the two errors are. Putting it mildly, that makes it impossible to help you. Please read and follow the suggestions in http://gnuradio.org/trac/wiki/ReportingErrors Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
On Tue, Apr 14, 2009 at 01:48:21PM -0700, Smith L. wrote: > > Hi, > > I am trying to establish communication between USRP2 and USRP1. I am using > RFX2400 daughterboard. I am using Ubuntu 8.10. I am using the svn version of > GNU Radio. I dont know the revision number. I am not able to receive > anything on USRP2 when USRP1 is transmitting and vice versa. The python > codes for USRP2 work perfectly fine. I guess there is some problem with the > ADC and DAC incompatibility (interpolation and decimation) between USRP2 and > USRP1. I am attaching all the necessary files that I am using currently. I > would appreciate if someone can look at these files and help me to sort out > the problem. My guess is that the two are not running at the same bit rate. You haven't provided us much to go on. Please see http://gnuradio.org/trac/wiki/ReportingErrors, and try asking again. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timestamps, data rates
On Tue, Apr 14, 2009 at 02:19:38PM -0500, Douglas Geiger wrote: > I'm running some experiments with my two USRP2's - as I want to get > synchronized samples out of them. I have the clock's locked to my > external 10Mhz, and they sync_to_pps correctly (i.e. the timestamp > resets on the next PPS). > However, the difference between timestamps from the two USRP2's does > not seem to be a constant at low data rates: they are constant between > subsequent received frames (i.e. USRP2 A vs. USRP2 B) - but each time I > start my application, or even if I send sync_to_pps commands while > streaming, the difference changes. I'm trying to figure out if this is > due to some non-deterministic timing on the USRP2, or some other source. > At higher data rates (e.g. decimation <= 16), the difference between > timestamps from the two USRP2's gets more erratic, and tends to > fluctuate (quite wildly down at -d 4). Doug, I wouldn't expect the time stamps in the streams to start at the same point (the start_rx_streaming command doesn't accept a "start at time T argument). I would expect that there is a constant delta_t between subsequent frames, and that that delta_t would be the same for both of the USRP2s. At -d 4 you are likely to be getting overruns (indicated by an 'S' (sequence error) on stderr). That is, the host can't keep up. Are both USRP2's connected to the same host? If so, are they each connected to their own dedicated ethernet port, or are they connected to a switch that feeds a single ethernet port? If both USRP2s are connected to a single machine, and even if they are connected to dedicated ethernet ports, I'd be pleasantly surprised if you could run -d 8 on both of them. I doubt the problem is in the USRP2 firmware; the overhead of the host code and lack of sufficient horsepower on the host is almost certainly the bottleneck. > My plan has been to setup buffers to align samples based on timestamp - > but with such variations it looks to me like it could be quite > difficult to implement. Or at the very least, I'd need very large > buffers, and could end up needing/wanting to change their size often. > Any suggestions on how to best deal with this? Should I be looking into > the USRP2 firmware code to try to get some more predictable behavior out > of it? > Thanks, > Doug Doug, assuming that the host can keep up without overruns, aligning samples from the two USRP2s should be no big deal. I wouldn't expect that you need more than 200 ms of buffer. If the host isn't keeping up, all bets are off. I'd start with something like -d 64 of each of them, get that working, then start reducing the decimation rate until you get failures. Then go after those. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BBN_80211 and gr.hier_block2 (I only have USRP1s)
Hi all,, I read the [Discuss-gnuradio] and know that gr.hier_block is gone in current GNU Radio. http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg12193.html I used the command: svn co https://www.cgran.org/cgran/projects/bbn_80211/trunk bbn_80211 I checked out the bbn trunk and got the codes only have gr.hier_block. The codes have not been updated for 5 months. I am wondering if anyone maintains the codes? I browsed the source at the link https://www.cgran.org/browser/projects/bbn_80211/branches and found that there is a usrp2_version which all files have been coverted to the hier_block2 format. However, I only have USRP1s. Do I need to convert all the codes in the trunk from gr.hier_block to gr.hier_block2 by myself or I can just use the examples in the usrp2_version? Or I should buy USRP2s? Thank you, Jane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CGRAN upgrades currently in progress
Hi all, I'm upgrading the trac version that we are using for CGRAN and trying to work out our internal server error. The CGRAN subversion server will not be going down, but the wiki will be out of usage for a little while right now. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Hi all, Since I have tested the tx code (bbn_80211b_tx_port2.py), I wanted to run the bbn_80211b_rx.py inorder to capture the packets sent but I encountred this error: # ./bbn_80211b_rx.py Traceback (most recent call last): File "./bbn_80211b_rx.py", line 179, in main () File "./bbn_80211b_rx.py", line 174, in main app = app_flow_graph() File "./bbn_80211b_rx.py", line 159, in __init__ self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, options.width_16, options.verbose, options.gain, options.freq) File "./bbn_80211b_rx.py", line 97, in __init__ self.u.set_decim(decim_rate=(decim * 1.5)) File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py", line 499, in set_decim return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, **kwargs) TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 arguments (1 given) do you have any idea about the origin of this problem? Thank you in advance. On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück wrote: / Updated from the trunk and I'm not getting that msg anymore./ / / / Everything seems to be ok now./ Glad to hear it! Thanks for letting us know. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Basics questions
You want to probe the SMA connectors. The pins tx0-tx7 are digital control lines. If you see any signal on the control lines, it is probably very weak leakage from the DAC. Somya Ajmera wrote: Hi Josh, on the SMA connectors I had connected my transmit receive antennas. I wanted to know if while transmitting and receiving signals using USRP sink and source blocks, can I silmatenously probe any pin on the transmit/receive daughter board inorder to see the signal out and in to USRP. Also I was trying to make an OFDM system by implementing the following blocks: Random Source:>OFDM Modulator:>USRP Sink [Minimum=0;[ Modulation:8 QAM [Unit Number=0 Maximum=2; FFT Length=512 Interpolation=400 Num Samples=1MOccupied tones: 200 Frequency=100M Repeat=Yes] CP Length: 128Gain=0 Pad for USRP=Yes Side=Side A] Payload length=0] After running this, when I probed pin tx0 - tx7 on the daughter board, I was able to see some waveforms on the scope. But when I build the receiver system: USRP Source:--->OFDM DeModulator:>FFT Sink [Unit Number=0[ Modulation:8 QAM Decimation=400FFT Length=512 Frequency=100M Occupied tones: 200 Gain=0CP Length: 128 Side=Side A RX Antenna=RXA ] I am get the following warning: "** (python:4085): WARNING **: IPP request failed with status 1030 Timeout " You can ignore this, its just wxpython molesting your printers. and now if i probe the same pins on the daughter board, I am not able to see any waveforms. Can you please help me to figure out this behaviour. Thanks & Rgards, Somya Ajmera ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
Johnathan, It works ok for me, except for the mpsk_receiver with the setup from http://www.nabble.com/QPSK-phase-noise-td22934944.html. This is the constellation I get for a > 40 dB SNR BPSK: http://www.nabble.com/file/p23060683/Screenshot.png Screenshot.png Johnathan Corgan-2 wrote: > > GNU Radio 3.2 release candidate 2 is now available for download and > testing: > > http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz > http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.2rc2.tar.gz > > -- View this message in context: http://www.nabble.com/GNU-Radio-3.2-Release-Candidate-2-available-for-testing-tp23049229p23060683.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
Jonathan, It works ok for me, except for the mpsk_receiver with the setup from http://www.nabble.com/QPSK-phase-noise-td22934944.html. This is the constellation I get for a > 40 dB SNR BPSK: http://www.nabble.com/file/p23060668/Screenshot.png Screenshot.png Johnathan Corgan-2 wrote: > > GNU Radio 3.2 release candidate 2 is now available for download and > testing: > > http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz > http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.2rc2.tar.gz > > -- View this message in context: http://www.nabble.com/GNU-Radio-3.2-Release-Candidate-2-available-for-testing-tp23049229p23060668.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help initial problems with the USRP2
Hi Eric ...Okey now I have another problem. I downloaded rev 10851 of the gnuradio from the trunk and now I get two errors when I try to make. I configured ld.so.conf as describe in your wiki. But I still have make errors Br Ane 2009/4/8 Eric Blossom > On Wed, Apr 08, 2009 at 03:43:26PM +0200, Ane Andersen wrote: > > > > > > Hi Eric > > I just tried flashing the SD ram as instructed on the web. It didn't > change > > much. Now when I run the two scripts I randomly get either "segment > fault" > > or some lines of traceback print with a runtimeerror "Unable to retrieve > > daughterboard info. I also tried another USRP2 with newest FW. It > responded > > the same way. This however had the DBSRX mounted (unfortunately not > modified > > for USRP2 since we didn't know until yesterday). I > > I suspect that you're not using the latest code in the trunk. Please > update, build and install that. That will fix the segfault. > > The fact that you're still getting the "Unable to retrieve > daughterboard info" message makes me think that you didn't > successfully update the firmware on the SD Card with the latest > firmware binary. > > Eric > > > > > Maybe you could help me if I write exactly what I do > > with RFX1200 mounted > > If I write: sudo ./usrp2_fft.py -f1300e6 > > I get this response: > > > > Traceback (most recemt call last); > > File "./usrp2_fft.py, line 274 in > > main() > > File"./usrp2_fft.py, line 270, in main > > app=stdgui2.stdapp(app_top_block, "USPR2 FFT", nstatus=1) > > File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", > > line 36 in __init__ > > wx.App.__init__(self, redirect=False) > > File "/usr/lib/python2.5/sit-packages/wx-2.8-gtk2-unicode/wx/_core.py", > line > > 7912, in __init__ > > self._BootstrapApp() > > File "/usr/lib/python2.5/sit-packages/wx-2.8-gtk2-unicode/wx/_core.py", > > line 7487, in > > _BootstrapApp > > return _core_.PyApp__BootstrapApp(*args, **kwargs) > > File > "/usr/lib/python2.5/sit-packages/wx-2.8-gtk2-unicode/wx/stdgui2.py", > > line 39 , in OnInit > > frame=stdframe (self.top_block_maker, self.title, self._nstatus) > > File "/usr/lib/python2.5/sit-packages/wx-2.8-gtk2-unicode/wx/stdgui2.py", > > line 60 in __init__ > > self.panel=stdpanel (self, self, top_block_maker) > > File > "/usr/lib/python2.5/sit-packages/wx-2.8-gtk2-unicode/wx/stdgui2.py", > > line 81 in __init__ > > self.top_block=top_block_maker(frame, self, vbox, sys.argv) > > File "./usrp2_fft.py", line 70 in __init__ > > self.u=usrp2.source_32fc(options.interface, options.mac_addr) > > File "/usr/local/lib/python2.5/site_packages/gnuradio/usrp2.py", line > 585, > > in source_32fc > > return _usrp2.source_32(*args, **kwargs) > > RuntimeError: Unable to retrieve daughterboard info > > "Unable to retrieve daughterboard info " any more but segment fault. > > > > Br > > Ane > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPS SDR
Haha, had exactly the same idea and posted it before reading your email. Good to know we're on the same wavelength, though! Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International On Wed, Apr 15, 2009 at 07:06, Bob McGwier wrote: > It appears Heckler has repaired his site and in fact the git repository has > seen activity since the beginning of the year. It is good that the hacked > wiki, etc. has been recovered. > > This would be a PERFECT candidate to go into cgran (open source, not > assigned to FSF). > > HINT > > > Bob > > -- > (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, > AMSAT-DL, TAPR, Packrats, > NJQRP, QRP ARCI, QCWA, FRC. > "It is human nature to think wisely and act in > an absurd fashion.", Anatole France. > Twitter:rwmcgwier > Active: Facebook,Myspace,LinkedIn > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using gnuradio for GPS
Should we try and put this on CGRAN? I tried to contact the developer regarding some issues (specifically, that gps-usrp doesn't compile with the latest gnuradio trunk), but got no response. Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International On Wed, Apr 15, 2009 at 06:50, Bob McGwier wrote: > The person has not been maintainingthe web site for a while. It had been > hacked and hacked. Its wiki was so hacked that it was unusable. Every now > and again, I would go and set the wiki pages back to the date before the > hacking occurred but the hackers would just come and wipe it out again. It > is such a shame to see this work go into the dustbin. > > Bob > > > > Woody Dickson wrote: > >> The link is not active. Does anyone know why? >> >> Thanks, >> Woody >> >> >> On Tue, Apr 14, 2009 at 12:15 PM, davek wrote: >> >> >>> www.gps-sdr.com >>> >>> On Tue, Apr 14, 2009 at 12:05 AM, Woody Dickson >>> wrote: >>> >>> Hi, Does anyone know if there is any reference implementation on the use of gnuradio for GPS? I am interested in DIYing my own GPS system. Any information will be greatly appreciated. Thanks, Woody ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> > > > -- > (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, > AMSAT-DL, TAPR, Packrats, > NJQRP, QRP ARCI, QCWA, FRC. > "It is human nature to think wisely and act in > an absurd fashion.", Anatole France. > Twitter:rwmcgwier > Active: Facebook,Myspace,LinkedIn > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using "send_now=0" on USRP2
Dear All,
I am trying to issue 5 calls to tx_16sc (of 371 samples each i.e.,
one ETH packet per call) to the USRP2. I transmit a simple sinuswave. If
I set "send_now=1" in the metadata it works as expected and I can see
the signal on a spectrum analyzer. If I set send_now=0 I can only
occasionally see the signal pass and then for only very short time. Here
are some more details: I first receive a few frames to get the
time-stamp from the received frames, this timestamp is stored in the
variable last_time_stamp. Then I transmit using the code below (the
interpolation factor is set to 10). Is there anything I have
misunderstood ?
metadata.send_now=0;
metadata.start_of_burst=1;
metadata.end_of_burst=1;
int i1;
for (i1=0;i1tx_16sc(0,
buffer,
NO_SAMPLES,
&metadata)) {
printf("Transmit data failed!\n");
};
metadata.start_of_burst=1;
};
metadata.end_of_burst=1;
u2->tx_16sc(0,
buffer,
NO_SAMPLES,
&metadata);
};
BR/
Per
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
