Re: [Discuss-gnuradio] Anyone do you know good GPS receiver Method?
I am using fastGPS to do the correlation as well as writing my own MATLAB correlation scripts. Nick On Fri, Nov 25, 2011 at 8:40 PM, Nick Foster wrote: > On Fri, Nov 25, 2011 at 7:01 AM, Nick Othieno > wrote: > > Hi Ryan, > > > > What did you use for your setup, ie daughterboards, antenna and LNA (if > you > > do not mind my asking). I have been trying a setup for months that uses a > > DBSRX2 and a mighty mouse 2 antenna only, but I have never been able to > > acquire the L1 signal. I am wondering where I have gone wrong in the > setup. > > I've successfully used a DBSRX + active antenna to receive GPS signals > before. What software are you using to do the correlation and find the > L1 signal? > > --n > > > > > Nick > > > > On Fri, Nov 18, 2011 at 9:47 AM, Wolfarth, Ryan > wrote: > >> > >> Hi folks, > >> > >> My group is using USRPs to do the task Kouki described, although our > flow > >> diagram is a little different. We only use the USRP2 to receive the > raw RF > >> data which is written to file. This data is processed to the point > where we > >> decode the navigation bits, but no position is ever found. We're more > >> interested in the effects of ionosphere scintillations on GNSS signal > >> structure so we don't need to calculate antenna position. > >> > >> I can recommend two books that have helped me immensely. The Kaplan > "blue > >> book:" > >> > >> > >> > http://www.amazon.com/Understanding-GPS-Principles-Applications-Second/dp/1580538940/ref=sr_1_1?ie=UTF8&qid=1321627222&sr=8-1 > >> > >> And the Kaplan "blue book:" > >> > >> http://www.gpstextbook.com/ > >> > >> I do know of a group that has used a USRP1 to develop a 4 channel L1 > >> receiver, but they had to modify the FPGA to do all the real time > >> processing. Let me know if you have additional questions! > >> > >> -Ryan > >> > >> On Fri, Nov 18, 2011 at 7:56 AM, Brian Padalino > >> wrote: > >>> > >>> 2011/11/18 山本弘貴 : > >>> > Hi, All > >>> > I have very trouble > >>> > My experiment enviroment isUBUNTU 11.04 , USRP N200, DBSRX2 ,active > >>> > antenna and gnuradio > >>> > I am worrying about good software GPS receiver is not exist . > >>> > I want to receive L1 signal , and want to demodulate that signal > >>> > However GPS signal is used Spread spectrum modulation scheme. > >>> > I try to creating gnuradio-companion's blocks.(use to Spread spectrum > >>> > demodulation blocks) > >>> > but that is very difficult so Now I think method is > >>> > > >>> > GPS L1 signal → USRP N200 → gnuradio-companion(UHD_source→File_sink) > >>> > → software decode soft → output(Location data) > >>> > > >>> > > >>> > Eventually I want to Calculate location data, > >>> > Please let me know if you're a good this way > >>> > >>> I recently came across this product listing at Spark Fun: > >>> > >>>http://www.sparkfun.com/products/10981 > >>> > >>> Which has a link to a book all about GPS receiving and even comes with > >>> MATLAB source code: > >>> > >>> > >>> > http://www.amazon.com/Software-Defined-GPS-Galileo-Receiver-Single-Frequency/dp/0817643907 > >>> > >>> I am sure, with the source, you could adapt it to use the USRP > >>> recorded signal, and then possibly port the MATLAB over to either > >>> Python (using Josh's signal processing in Python blocks) or straight > >>> C++. > >>> > >>> > I am sorry that My English is not good > >>> > > >>> > Kouki > >>> > >>> Good luck - it's definitely not a trivial task, but it sounds extremely > >>> fun. > >>> > >>> Brian > >>> > >>> ___ > >>> 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 > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A function named "usb_control_msg"
Dear everyone: You see in usrp_basic.h there is a function named _write_9862() and it uses function usrp_9862_write(),defined in usrp_prims_common.h. And usrp_9862_write() uses function usrp_spi_write(), also defined in usrp_prims_common.h. usrp_spi_write() uses function write_cmd(), defined in usrp_prims_libusb0.c and usrp_prims_libusb1.c. In usrp_prims_libusb0.c write_cmd() uses a function named usb_control_msg(). But I can not find where usb_control_msg() is. Can anyone tell me where it is???___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A function named "usb_control_msg"
2011/11/29 signalswdm : > Dear everyone: > You see in usrp_basic.h there is a function named _write_9862() and > it uses function usrp_9862_write(),defined in usrp_prims_common.h. And > usrp_9862_write() uses function usrp_spi_write(), also defined in > usrp_prims_common.h. > usrp_spi_write() uses function write_cmd(), defined in usrp_prims_libusb0.c > and usrp_prims_libusb1.c. > In usrp_prims_libusb0.c write_cmd() uses a function named > usb_control_msg(). But I can not find where usb_control_msg() is. Can anyone > tell me where it is??? libusb: http://libusb.sourceforge.net/doc/function.usbcontrolmsg.html Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A function named "usb_control_msg"
2011/11/29 signalswdm : > Dear everyone: > You see in usrp_basic.h there is a function named _write_9862() and > it uses function usrp_9862_write(),defined in usrp_prims_common.h. And > usrp_9862_write() uses function usrp_spi_write(), also defined in > usrp_prims_common.h. > usrp_spi_write() uses function write_cmd(), defined in usrp_prims_libusb0.c > and usrp_prims_libusb1.c. > In usrp_prims_libusb0.c write_cmd() uses a function named > usb_control_msg(). But I can not find where usb_control_msg() is. Can anyone > tell me where it is??? It's part of the legacy API for libusb-0.1. http://libusb.sourceforge.net/doc/function.usbcontrolmsg.html Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Spectral Estimation Toolbox: GUI and cyclo estimator now available
Hi list, the SpecEst toolbox has more fun and exciting stuff: - First thing is a GUI. It connects to a file or UHD and can show live spectral estimates of the incoming signal using any of the existing estimators. For simple debugging purpose, this is not as useful as uhd_fft.py, but it's a great tool to show how different estimators (parametric vs. non-parametric) work. And have you ever seen a live ESPRIT based sinusoid tracker? - Cyclostationary estimation is now also possible. This is not integrated into the GUI, as the output is completely different, but comes with demo app that uses Matplotlib to show stuff that's going on (very slow, though!). There's a small example script that uses the output of the cyclo estimator to distinguish QPSK and BPSK, just to see how this can be used. As usual, it's all on our github. You can find it all at https://www.cgran.org/wiki/SpecEst. Happy spectral estimating, 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 pgp2PwwbtwAsS.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Anyone do you know good GPS receiver Method?
I had never heard of fastGPS; sounds pretty useful. What is the end goal for your receiver? Ryan On Tue, Nov 29, 2011 at 5:10 AM, Nick Othieno wrote: > I am using fastGPS to do the correlation as well as writing my own MATLAB > correlation scripts. > > Nick > > > On Fri, Nov 25, 2011 at 8:40 PM, Nick Foster wrote: > >> On Fri, Nov 25, 2011 at 7:01 AM, Nick Othieno >> wrote: >> > Hi Ryan, >> > >> > What did you use for your setup, ie daughterboards, antenna and LNA (if >> you >> > do not mind my asking). I have been trying a setup for months that uses >> a >> > DBSRX2 and a mighty mouse 2 antenna only, but I have never been able to >> > acquire the L1 signal. I am wondering where I have gone wrong in the >> setup. >> >> I've successfully used a DBSRX + active antenna to receive GPS signals >> before. What software are you using to do the correlation and find the >> L1 signal? >> >> --n >> >> > >> > Nick >> > >> > On Fri, Nov 18, 2011 at 9:47 AM, Wolfarth, Ryan >> wrote: >> >> >> >> Hi folks, >> >> >> >> My group is using USRPs to do the task Kouki described, although our >> flow >> >> diagram is a little different. We only use the USRP2 to receive the >> raw RF >> >> data which is written to file. This data is processed to the point >> where we >> >> decode the navigation bits, but no position is ever found. We're more >> >> interested in the effects of ionosphere scintillations on GNSS signal >> >> structure so we don't need to calculate antenna position. >> >> >> >> I can recommend two books that have helped me immensely. The Kaplan >> "blue >> >> book:" >> >> >> >> >> >> >> http://www.amazon.com/Understanding-GPS-Principles-Applications-Second/dp/1580538940/ref=sr_1_1?ie=UTF8&qid=1321627222&sr=8-1 >> >> >> >> And the Kaplan "blue book:" >> >> >> >> http://www.gpstextbook.com/ >> >> >> >> I do know of a group that has used a USRP1 to develop a 4 channel L1 >> >> receiver, but they had to modify the FPGA to do all the real time >> >> processing. Let me know if you have additional questions! >> >> >> >> -Ryan >> >> >> >> On Fri, Nov 18, 2011 at 7:56 AM, Brian Padalino >> >> wrote: >> >>> >> >>> 2011/11/18 山本弘貴 : >> >>> > Hi, All >> >>> > I have very trouble >> >>> > My experiment enviroment isUBUNTU 11.04 , USRP N200, DBSRX2 ,active >> >>> > antenna and gnuradio >> >>> > I am worrying about good software GPS receiver is not exist . >> >>> > I want to receive L1 signal , and want to demodulate that signal >> >>> > However GPS signal is used Spread spectrum modulation scheme. >> >>> > I try to creating gnuradio-companion's blocks.(use to Spread >> spectrum >> >>> > demodulation blocks) >> >>> > but that is very difficult so Now I think method is >> >>> > >> >>> > GPS L1 signal → USRP N200 → >> gnuradio-companion(UHD_source→File_sink) >> >>> > → software decode soft → output(Location data) >> >>> > >> >>> > >> >>> > Eventually I want to Calculate location data, >> >>> > Please let me know if you're a good this way >> >>> >> >>> I recently came across this product listing at Spark Fun: >> >>> >> >>>http://www.sparkfun.com/products/10981 >> >>> >> >>> Which has a link to a book all about GPS receiving and even comes with >> >>> MATLAB source code: >> >>> >> >>> >> >>> >> http://www.amazon.com/Software-Defined-GPS-Galileo-Receiver-Single-Frequency/dp/0817643907 >> >>> >> >>> I am sure, with the source, you could adapt it to use the USRP >> >>> recorded signal, and then possibly port the MATLAB over to either >> >>> Python (using Josh's signal processing in Python blocks) or straight >> >>> C++. >> >>> >> >>> > I am sorry that My English is not good >> >>> > >> >>> > Kouki >> >>> >> >>> Good luck - it's definitely not a trivial task, but it sounds >> extremely >> >>> fun. >> >>> >> >>> Brian >> >>> >> >>> ___ >> >>> 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 >> > >> > >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py
On Tue, Nov 29, 2011 at 1:40 AM, Alex Zhang wrote: > I am using the this example to test the installed next branch of josh: > > http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next > > How ever, the digital_swig is not recognized. And I also checked the > changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets > > Nothing related is found. > > > Traceback (most recent call last): > File "./pkt2.py", line 23, in > import digital_swig > ImportError: No module named digital_swig > > Can someone tell me where to find this package now? > > -- > > Alex, > *Dreams can come true – just believe.* > It looks like you have some left-over code laying around. The pkt2.py is gone and we use pkt.py now, instead. Something must have gotten left behind with a checkout or merge at some point. As for the digital_swig, that's the "real" name of the SWIG'd-up gr-digital module that we export into digital. The internal gr-digital python modules use digital_swig, though. Make sure you've cleaned up previous installs, to a git clean -dxf in your gnuradio checkout and reinstall. Hopefully that'll fix your problems. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector
On Mon, 28 Nov 2011 10:32:28 -0500 "Marcus D. Leech" wrote: On 28-11-2011 10:21 AM, Sebastian Döring wrote: Hello List, just wanted to know exactly how the output vector of ..._rx_cfile.py is structured. Is the first element of the complex vector v[0] the one at the desired frequency sprecified by "-f FREQ"? Thanks Sebastian ' It's just raw complex-float samples in native-binary format. The first item is I the second is Q then I then Q, etc. They're time-series samples, not FFT outputs. Uh ok - explains a lot... Since the data is getting recorded as 32-bit complex float, is "read_complex_binary()" the right octave method to put it into a vector I can use for further processing? I found a gnuradio page that says "read_short_binary()" is supposed to be the right method, but the output vector does not make any sense to me... Regards Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector
On 29-11-2011 11:12 AM, Sebastian Döring wrote: On Mon, 28 Nov 2011 10:32:28 -0500 "Marcus D. Leech" wrote: On 28-11-2011 10:21 AM, Sebastian Döring wrote: Hello List, just wanted to know exactly how the output vector of ..._rx_cfile.py is structured. Is the first element of the complex vector v[0] the one at the desired frequency sprecified by "-f FREQ"? Thanks Sebastian ' It's just raw complex-float samples in native-binary format. The first item is I the second is Q then I then Q, etc. They're time-series samples, not FFT outputs. Uh ok - explains a lot... Since the data is getting recorded as 32-bit complex float, is "read_complex_binary()" the right octave method to put it into a vector I can use for further processing? I found a gnuradio page that says "read_short_binary()" is supposed to be the right method, but the output vector does not make any sense to me... Regards Sebastian Yup, read_complex_binary() is the one, as far as I can tell. I'm not a MatLab/Octave user, but it seems like that reads complex-floats. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Architecture of *_rx_cfile.py output vector
On Tue, Nov 29, 2011 at 11:32 AM, Marcus D. Leech wrote: > On 29-11-2011 11:12 AM, Sebastian Döring wrote: > >> On Mon, 28 Nov 2011 10:32:28 -0500 >> "Marcus D. Leech" wrote: >> >>> On 28-11-2011 10:21 AM, Sebastian Döring wrote: >>> Hello List, just wanted to know exactly how the output vector of ..._rx_cfile.py is structured. Is the first element of the complex vector v[0] the one at the desired frequency sprecified by "-f FREQ"? Thanks Sebastian ' >>> It's just raw complex-float samples in native-binary format. >>> >>> The first item is I the second is Q then I then Q, etc. >>> >>> They're time-series samples, not FFT outputs. >>> >>> >>> >>> >>> Uh ok - explains a lot... >> Since the data is getting recorded as 32-bit complex float, is >> "read_complex_binary()" the right octave method to put it into a vector I >> can use for further processing? >> I found a gnuradio page that says "read_short_binary()" is supposed to be >> the right method, but the output vector does not make any sense to me... >> >> Regards >> Sebastian >> >> >> Yup, read_complex_binary() is the one, as far as I can tell. I'm not a > MatLab/Octave user, but it seems like that reads complex-floats. Yes, that should work for you. The "read_short_binary()" should be usable if you use the '-s' flag in the uhd_rx_cfile.py to output shorts. I think you'll have to deinterleave the I&Q after you read it in, IIRC. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py
Just found the digital_swig.py is located at /usr/local/lib/python2.7/dist-packages/gnuradio/digital So I change "import digital_swig" to "from gnuradio.digital import digital_swig" and the complaining disappeared. Seems for these python modules, i still need to give a full path, even I have imported the gnuradio, gnuradio.digital in the beginning of the code. On Tue, Nov 29, 2011 at 9:57 AM, Tom Rondeau wrote: > On Tue, Nov 29, 2011 at 1:40 AM, Alex Zhang wrote: > >> I am using the this example to test the installed next branch of josh: >> >> http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next >> >> How ever, the digital_swig is not recognized. And I also checked the >> changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets >> >> Nothing related is found. >> >> >> Traceback (most recent call last): >> File "./pkt2.py", line 23, in >> import digital_swig >> ImportError: No module named digital_swig >> >> Can someone tell me where to find this package now? >> >> -- >> >> Alex, >> *Dreams can come true – just believe.* >> > > > It looks like you have some left-over code laying around. The pkt2.py is > gone and we use pkt.py now, instead. Something must have gotten left behind > with a checkout or merge at some point. > > As for the digital_swig, that's the "real" name of the SWIG'd-up > gr-digital module that we export into digital. The internal gr-digital > python modules use digital_swig, though. > > Make sure you've cleaned up previous installs, to a git clean -dxf in your > gnuradio checkout and reinstall. Hopefully that'll fix your problems. > > Tom > > -- 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] can not import digital_swig for the example of pkt.py
On 11/29/2011 01:40 AM, Alex Zhang wrote: > I am using the this example to test the installed next branch of josh: > > http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next > > How ever, the digital_swig is not recognized. And I also checked the > changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets > > Nothing related is found. > > > Traceback (most recent call last): > File "./pkt2.py", line 23, in > import digital_swig > ImportError: No module named digital_swig > > Can someone tell me where to find this package now? > > > Here is my digital python directory, what is yours missing that mine has? > ls /usr/local/lib/python2.7/dist-packages/gnuradio/digital/ > bpsk.py_digital_swig.la __init__.pyofdm.pyo > ofdm_sync_pn.pypsk2.pyc > bpsk.pyc digital_swig.py__init__.pyc > ofdm_receiver.py ofdm_sync_pn.pyc psk.py > bpsk.pyo digital_swig.pyc __init__.pyo > ofdm_receiver.pyc ofdm_sync_pn.pyo psk.pyc > cpm.py digital_swig.pyo modulation_utils2.py > ofdm_receiver.pyo packet_utils.pypsk.pyo > cpm.pyc_digital_swig.so modulation_utils2.pyc > ofdm_sync_fixed.py packet_utils.pyc qam.py > cpm.pyodqpsk.py modulation_utils.py > ofdm_sync_fixed.pycpacket_utils.pyo qam.pyc > crc.py dqpsk.pyc modulation_utils.pyc > ofdm_sync_fixed.pyopkt2.pyqam.pyo > crc.pycgeneric_mod_demod.py modulation_utils.pyo > ofdm_sync_ml.pypkt2.pyc qpsk.py > crc.pyogeneric_mod_demod.pyc ofdm_packet_utils.py > ofdm_sync_ml.pyc pkt2.pyo qpsk.pyc > d8psk.py generic_mod_demod.pyo ofdm_packet_utils.pyc > ofdm_sync_ml.pyo pkt.py qpsk.pyo > d8psk.pyc gmsk.pyofdm_packet_utils.pyo > ofdm_sync_pnac.py pkt.pycutils/ > dbpsk.py gmsk.pyc ofdm.py > ofdm_sync_pnac.pyc pkt.pyo > dbpsk.pyc gmsk.pyo ofdm.pyc > ofdm_sync_pnac.pyo psk2.py ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py
On 11/29/2011 10:57 AM, Tom Rondeau wrote: > On Tue, Nov 29, 2011 at 1:40 AM, Alex Zhang wrote: > >> I am using the this example to test the installed next branch of josh: >> >> http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next >> >> How ever, the digital_swig is not recognized. And I also checked the >> changeset at http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets >> >> Nothing related is found. >> >> >> Traceback (most recent call last): >> File "./pkt2.py", line 23, in >> import digital_swig >> ImportError: No module named digital_swig >> >> Can someone tell me where to find this package now? >> >> -- >> >> Alex, >> *Dreams can come true – just believe.* >> > > > It looks like you have some left-over code laying around. The pkt2.py is > gone and we use pkt.py now, instead. Something must have gotten left behind > with a checkout or merge at some point. > Sorry for the correction, pkt2 is my doing. I re-implemented pkt.py with message passing capabilities. > As for the digital_swig, that's the "real" name of the SWIG'd-up gr-digital > module that we export into digital. The internal gr-digital python modules > use digital_swig, though. > > Make sure you've cleaned up previous installs, to a git clean -dxf in your > gnuradio checkout and reinstall. Hopefully that'll fix your problems. > I think Alex is importing pkt2.py from in-tree and not from an installed location. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD vs. USRP2 driver questions
Hi, We're using USRP2s with the RFX2400 daughterboards, and we've recently switched from the old USRP drivers to the UHD drivers as per general recommendation. However, we've run into a few problems that have us stumped: 1) Previously, our receiver gains were set to 0 dB and we had no problem receiving a signal with >30 or 40 dB SNR. However, now the UHD receiver blocks need specified gain around 30 or 40 dB to achieve this same performance; did baseline values change? 2) As far as we can tell through searching the Internet, the sampling rate in the Tx/Rx blocks has replaced the decimation and interpolation fields from the legacy blocks. But what exactly are we specifying with the sampling rate now? Is it the sampling rate the rate at which the transmitter transmits samples, with interpolation assumed if the data going into the block isn't throttled? In which case, would higher sampling rate imply lower 'interpolation' rate? Bottom line, we have no idea how to play around with the sample rate, or how important it is. Thanks for your help, Kevin Tien ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD vs. USRP2 driver questions
On 11/29/2011 02:38 PM, Kevin Tien wrote: > Hi, > > We're using USRP2s with the RFX2400 daughterboards, and we've recently > switched from the old USRP drivers to the UHD drivers as per general > recommendation. However, we've run into a few problems that have us > stumped: > > 1) Previously, our receiver gains were set to 0 dB and we had no > problem receiving a signal with >30 or 40 dB SNR. However, now the UHD > receiver blocks need specified gain around 30 or 40 dB to achieve this > same performance; did baseline values change? > Are you selecting the correct antenna? Its possible the default RX antenna setting is different. > 2) As far as we can tell through searching the Internet, the sampling > rate in the Tx/Rx blocks has replaced the decimation and interpolation > fields from the legacy blocks. But what exactly are we specifying with > the sampling rate now? Is it the sampling rate the rate at which the > transmitter transmits samples, with interpolation assumed if the data > going into the block isn't throttled? In which case, would higher > sampling rate imply lower 'interpolation' rate? Bottom line, we have > no idea how to play around with the sample rate, or how important it > is. > The sample rate is the rate of samples between host and USRP. on RX: sample_rate = dsp_rate/decimation on TX: sample_rate = dsp_rate/interpolation -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] can not import digital_swig for the example of pkt.py
Hi Josh, I have no d8psk*, dbpsk*, modulation_utils2*. Which branch do you use for this? On Tue, Nov 29, 2011 at 1:30 PM, Josh Blum wrote: > > > On 11/29/2011 01:40 AM, Alex Zhang wrote: > > I am using the this example to test the installed next branch of josh: > > > > http://gnuradio.org/cgit/jblum.git/tree/gr-digital/python/pkt2.py?h=next > > > > How ever, the digital_swig is not recognized. And I also checked the > > changeset at > http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeSets > > > > Nothing related is found. > > > > > > Traceback (most recent call last): > > File "./pkt2.py", line 23, in > > import digital_swig > > ImportError: No module named digital_swig > > > > Can someone tell me where to find this package now? > > > > > > > Here is my digital python directory, what is yours missing that mine has? > > > ls /usr/local/lib/python2.7/dist-packages/gnuradio/digital/ > > bpsk.py_digital_swig.la __init__.py > ofdm.pyo ofdm_sync_pn.pypsk2.pyc > > bpsk.pyc digital_swig.py__init__.pyc > ofdm_receiver.py ofdm_sync_pn.pyc psk.py > > bpsk.pyo digital_swig.pyc __init__.pyo > ofdm_receiver.pyc ofdm_sync_pn.pyo psk.pyc > > cpm.py digital_swig.pyo modulation_utils2.py > ofdm_receiver.pyo packet_utils.pypsk.pyo > > cpm.pyc_digital_swig.so modulation_utils2.pyc > ofdm_sync_fixed.py packet_utils.pyc qam.py > > cpm.pyodqpsk.py modulation_utils.py > ofdm_sync_fixed.pycpacket_utils.pyo qam.pyc > > crc.py dqpsk.pyc modulation_utils.pyc > ofdm_sync_fixed.pyopkt2.pyqam.pyo > > crc.pycgeneric_mod_demod.py modulation_utils.pyo > ofdm_sync_ml.pypkt2.pyc qpsk.py > > crc.pyogeneric_mod_demod.pyc ofdm_packet_utils.py > ofdm_sync_ml.pyc pkt2.pyo qpsk.pyc > > d8psk.py generic_mod_demod.pyo ofdm_packet_utils.pyc > ofdm_sync_ml.pyo pkt.py qpsk.pyo > > d8psk.pyc gmsk.pyofdm_packet_utils.pyo > ofdm_sync_pnac.py pkt.pycutils/ > > dbpsk.py gmsk.pyc ofdm.py > ofdm_sync_pnac.pyc pkt.pyo > > dbpsk.pyc gmsk.pyo ofdm.pyc > ofdm_sync_pnac.pyo psk2.py > > > ___ > 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] UHD vs. USRP2 driver questions
Are you selecting the correct antenna? Its possible the default RX antenna setting is different. We'll check it out, but we only have the one antenna hooked up... It'd be interesting to find out that the SMA connector can pick up the signal! So I gather there should /not/ be any change in received SNR values? The sample rate is the rate of samples between host and USRP. on RX: sample_rate = dsp_rate/decimation on TX: sample_rate = dsp_rate/interpolation Ah okay great, thanks for your help. --Kevin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD vs. USRP2 driver questions
On 11/29/2011 03:37 PM, Josh Blum wrote:
On 11/29/2011 02:38 PM, Kevin Tien wrote:
Hi,
We're using USRP2s with the RFX2400 daughterboards, and we've recently
switched from the old USRP drivers to the UHD drivers as per general
recommendation. However, we've run into a few problems that have us
stumped:
1) Previously, our receiver gains were set to 0 dB and we had no
problem receiving a signal with>30 or 40 dB SNR. However, now the UHD
receiver blocks need specified gain around 30 or 40 dB to achieve this
same performance; did baseline values change?
Are you selecting the correct antenna? Its possible the default RX
antenna setting is different.
Yes, I believe the default under the old usrp drivers was "TX/RX". The
default under the new setup is "RX2". You can make a call
usrp->set_rx_antenna("TX/RX"). That should, in theory, restore the old
behavior (although I've seen what might be unpredictable behavior in
this mode - I don't know for sure though) unless you have some full
duplex shenanigans going on. Alternatively, you can just screw on an
antenna on the RX2 port and you should see a strong signal, which is the
approach I often use.
Arun
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 starts passing garbage data
I have an application that runs 24/7 with a USRP1. I am having occasional problems where it appears the USRP (using UHD) starts returning garbage data after an apparently random period of time. In the most recent case, the app ran with no problem for approximately 36 hours, although previously we have run as long as 7 days without an issue or restart (not all restarts are due to a problem). I don't believe I am running out of memory. The flow graph appears to continue to run, and I don't think the data is zeored out as I get occasional partial frame syncs (random) during this time. Restarting the app is sufficient to fix the problem - I don't have to recycle USRP or reseat USB. What would be the best place to look to determine the root cause? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 starts passing garbage data
On 11/29/2011 08:20 PM, Ryan Pape wrote: I have an application that runs 24/7 with a USRP1. I am having occasional problems where it appears the USRP (using UHD) starts returning garbage data after an apparently random period of time. In the most recent case, the app ran with no problem for approximately 36 hours, although previously we have run as long as 7 days without an issue or restart (not all restarts are due to a problem). I don't believe I am running out of memory. The flow graph appears to continue to run, and I don't think the data is zeored out as I get occasional partial frame syncs (random) during this time. Restarting the app is sufficient to fix the problem - I don't have to recycle USRP or reseat USB. What would be the best place to look to determine the root cause? Could you describe your set-up in more detail? Do you get overruns before you start getting "garbage", and what is the character of your "garbage" is it samples full of noise, or zeros, or some other fixed value? Do you have completely up-to-date UHD and Gnu Radio? What type of host machine is it? OS? -- 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] Issues with benchmark_tx and benchmark_rx codes
Hi Tom, Thanks for the reply. I have a few more question on this regard and also some additional questions on benchmark_rx and tx. 1. There is a 'thres' parameter in the receive_path.py code, associated with the benchmark_rx.py code. The default value is 30. It says, thres = 30, # in dB, will have to adjust. What does it mean? 2. Does the 'packet Ok = true' in benchmark_rx inherently perform a CRC check? I implemented a CRC separately in the received payload, i.e., I was watching if there is a single bit error in the packet. I saw that whenever the benchmark_rx says 'packet Ok = true', it passes my CRC test and vice versa. It can't be coincidence, can it? 3. I am using the June 2011 version of gnuradio. My colleague just recently downloaded the latest version and he is trying to install the firmware in the SD cards. Now, with that June 2011 version, my benchmark tx and rx codes work predictably for gmsk modulation. By predictable, I mean that the codes work for --tx-ampl ranging from 0.05 to 0.9. At very low and high tx amplitude, it probably suffers from low signal strength and saturation. However, the dbpsk and dqpsk modulation work somewhat randomly, i.e., at one moment dbpsk may receive 100% packets at --tx-ampl 0.1. But, in the next moment, it may receive all packets as false at --tx-ampl 0.1. Therefore, I think that the problem is arising from the phase synchronization in the receiver. You talked in great details about control loop gain variables in http://gnuradio.squarespace.com/blog/2011/8/13/control-loop-gain-values.html. I just wonder which options in benchmark_rx are associated with these variables, i.e., the options that we can control? I can think of --costas-alpha, --gain-mu, alpha (in the receive_path.py code). Is there any other? 4. What is the difference between --costas-alpha (benchmark_rx option) and alpha (given with default value = 0.001 in the receive_path.py code)? Sorry for the long email. Your feedback will be very appreciated. Thanks, Nazmul On Sat, Nov 26, 2011 at 12:23 PM, Tom Rondeau wrote: > On Sat, Nov 26, 2011 at 12:13 PM, Nazmul Islam > wrote: > >> Tom, >> >> Thanks a lot for your reply. I appreciate it. I will upgrade to GNUradio >> 3.5. But I have a few more questions on the options. >> >> 1. Is there a roughly standard range of the option values that one should >> use? (the values of --tx-ampl, --tx-gain, --rx-gain, threshold, alpha, >> --costas-alpha, etc). For example, the values of alpha and thresh are given >> as 0.001 and 30 in the receive_path.py program. Shall I change these? If >> so, by how much? Are these values completely dependent on the local >> daughterboards? >> > > No since this is going to depend more on what USRP and daughterboard you > are using (or some other RF platform if it's not a USRP). We have not made > any measurements or analysis of this (and if you do, I hope you will share > it with the rest of us; since there are manufacturing tolerances on all of > these, any measurement should also come with a range (max/avg/min)). > > So right now, you're going to have to look at the output of your > transmitter to see if there is any distortion and play with the signal > levels to understand your system's behaviro. > > > >> 2. Is there any file or document that describe these options in more >> details? From my communication systems course, I can roughly understand >> these options. But some options, e.g. the effect of --tx-ampl versus the >> effect of --tx-gain are not clear to me. >> >> Any feedback will be really appreciated. >> >> Thanks, >> >> Nazmul >> > > No, there is nothing on this, yet. You're right that there should be > though... > > For now (so as to be cataloged on this mailing list at least), the > difference between --tx-ampl and --tx-gain is this. > > --tx-gain is a USRP/HW setting. It is the gain value (in dB) that is > applied by the analog stages of the USRP and daughterboard. > > --tx-ampl is a digital setting that sets the scale of the transmitted > signal. In the UHD world, all signals are between +/-1, so this scaling > factor should be < 1.0. > > Tom > > > >> On Sat, Nov 26, 2011 at 11:36 AM, Tom Rondeau wrote: >> >>> On Wed, Nov 23, 2011 at 1:49 PM, Nazmul Islam < >>> mnis...@winlab.rutgers.edu> wrote: >>> Hello All, I am trying to measure packet error rates for different modulation schemes using benchmark_tx and benchmark_rx codes. I run my codes on XCVR2450 USRP2 dughterboard and I am using the UHD_003_002_001 image (That image was downloaded on June, 2011 from the website, I believe). Now, I am getting strange results in terms of packet error rate. The benchmark_rx codes don't receive anything for d8psk modulation. It receives packets for dqpsk and qbpsk, but the work-ability depends on the inputs in a weird way. I am listing down some of the results that I have observed for different commands: Scenario 1: ./benchmark_tx.py -f 2.4G -r 1M
